Proposal: MailExtensions API to allow UI overlays, but no script injection
kewisch at thunderbird.net
Sun Oct 13 19:48:27 UTC 2019
> On 13. Oct 2019, at 2:47 PM, John Bieling <john.bieling at gmx.de> wrote:
>>> 2. Overlay is a security issue
>>> We simply disallow any JS and ignore any JS when parsing the overlay file. There is no security issue. After removing all the JS script stuff, the API will probably be even shorter than 500 lines.
>> If no js is running, how would you for example insert a button to click on?
> The idea was to have an event fired after a registered overlay has been injected into a window, which the api user can subscribe to. Here my knowledge about WebExt is still to limited to outline this further, but maybe the event returns an object with "id: element" members of the added elements and we can then do something with them, like adding event handlers to execute JS functions available in the webExt context. That would also seperate UI and logic.
This might be an area to look in to more then. As soon as you have one element of a dom tree, you have full access to the dom. For example, element.appendChild(element.ownerDocument.createElement("script")). Or element.ownerDocument.querySelector("img").setAttribute("onerror", "evil()")
Therefore, if you want interactive elements then you'll likely end up with a declarative API.
I'm also not sure you can pass DOM nodes around in WebExtension APIs, they are meant to work across process boundaries and passing raw nodes would likely also break the upcoming site isolation.
>> How would you prevent extensions from removing UI elements that belong to security features, e.g. validating certificates?
> I did not know, you can remove elements by applying an overlay file. But I am not talking about full DOM access. I just need access to the elements defined/added in my overlay file.
You can remove elements, add attributes like hidden, etc. Granted the overlay loader that mimics the xul overlays is pretty powerful.
But even if you just add elements, you'll need css to style it. With position: absolute you can put your nodes anywhere, covering other elements.
>> Removing all of the js script stuff reliably would likely require a library like DOMPurify, or a tag/attribute whitelist.
> It is not enought to blacklist all on* attributes and to require src attributes to be chrome urls or local urls in the api users xpi? We can also check if the urls target exists. Is there really so much more besides src attributes and on* attributes that needs to be looked after?
There are a bunch of unsuspecting things that would need to be locked down. Best use a well maintained library instead of a homebrew solution. This is an implementation detail though, there would certainly be a solution to this aspect.
>>> 3. Addons may break due to changes in the Thunderbird UI
>>> That is true and it is the compromise I am asking for. But breaks due to UI changes are easy to fix, you mostly have to update an ID. And how often will the UI change, after all that XUL -> HTML transition is done?
>> The UI may change at any time, even if subtly. What would the depreciation strategy look like for making UI changes? Would Thunderbird developers need to track and document each element they are changing?
> No, I do not want to add more work for you. The hg log shows already, which UI files have been changed. That is the compromise I was talking about, we have to adapt our addons.
I believe you that you don't want to burden others with more work but I think you are underestimating what is required in the bigger picture.
If your strategy is that Thunderbird would accept that add-ons could break in any release and it would be up to the developer to stay up to date, I feel this would be a fair amount of work for developers to keep up with all the UI changes, as we have it now.
You see in other threads here requests for documenting exactly what changed. If we change an id, some developers will expect us to tell them, bec. So it would be work for the Thunderbird team to communicate and document this.
The experience for users wouldn't be great either, because either their add-ons are breaking, or the add-on broke the UI and Thunderbird support and bug triagers would have more to do.
All that said, if the UI is stable then it surely won't be a lot but it will still add up. I'm also not saying that we wouldn't have any of this overhead with other approaches, but I do feel it would be less.
>> How would you handle extensions that break Thunderbird UI due to their overlays?
> Hard to tell. Report it to review and disable or restrict to last-known-working-version?
Reviewing wouldn't fix existing users, so you'd have to soft-block the add-on. This has a pretty devastating effect on the user and the add-on gets disabled. There is a process involved with blocking as well, it isn't as simple as rejecting an add-on. Also, we don't want to train users to re-enable soft blocked add-ons, if we are doing this regularly many might just click it away eventually and the soft block would be useless.
>> This is the Firefox deprecation policy, I feel that if we are allowing access to all nodes we would have to follow a such thing for basically any UI change.
> Again, I am not asking for full DOM access. I want to add stuff. Can current overlays actually modify existing elements? Did not know that. Do not want that, just the 3 methods mentioned above.
> It may be better for this discussion, if I just try to code the API, so we can see what it really does and how useful it is in the end?
This is what experiments are for, so feel free to take a stab. I feel there are too many open questions and planning required to get started, but of course I am biased given my opinion on feasibility and product direction.
Either way, I'm glad we are having this discussion, I hope I'm able to give some insight into WebExtensions and you are giving me good feedback on how this affects developers.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning