Proposal: MailExtensions API to allow UI overlays, but no script injection - what happens to "chrome" ?
axel.grude at gmail.com
Wed Oct 16 12:36:41 UTC 2019
>>>> *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.
what about the "chrome context" is that going away completely?
There is an awful lot talk about *sites */ content tabs / the browser etc. which I
feel isn't really relevant to mail. This is all so Firefox / browser centric.
Does mail live in a "site context"? Would it be "one site per mail server / account"?
Would then something like moving mails from one account to another be prohibited?
What about instant messages?
My view is that the downloaded mails are not living in a site context anymore, they
belong to the user; same when composing an email. That's where the really useful
Add-ons work in my perspective. Thunderbird is not a web browser. :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning