Proposal: MailExtensions API to allow UI overlays, but no script injection

Eyal Rozenberg eyalroz at
Wed Oct 16 19:05:41 UTC 2019

I like Axel's question :-)

A couple of comments:

 > Core needs to do more than Add-ons ... which is partly true

Is it though? I'm not sure. Certainly not when it comes to Thunderbird's 
UI code. Actually, one could argue that extensions need to be able to do 
more than the core does.

2. Vetting/trust etc.

Here I oppose Axel's view. I believe this is a non-argument. We aren't 
talking about automatically-included extensions, or 
Thunderbird-council-endorsed extensions or anything like that. 
Extensions are independent entities. Thunderbird + extension is just 
like Thunderbird + another app where it comes to security and such. 
There is no need for trust - the user installs the extensions s/he likes 
and it's totally on them. Requiring a level of trust of the developer 
sounds like a compiler team saying they won't compile code by developers 
they don't trust. It's none of the core developers' business! If I'm 
going to develop the "delete all your mail folders and send lots of spam 
messages" extension - that should install and run smoothly!

On 16/10/2019 15:31, Axel Grude wrote:
> Eyal wrote:
>> Extensions should be able to do essentially everything. Certainly 
>> everything the TB's _*own UI*_ code can do. 
> (emphasis by me)
> That's essentially echoing what my thought was about "Thunderbird eating 
> it's own dog food", so let me re-iterate the question:
> *How would a Thunderbird developer re-design the API if they were forced 
> to use it in their own front-end (JavaScript) code?*
> This question may sound a little ridiculous at first glance, but it is 
> an interesting thought experiment, because it forces the Core Developer 
> to think about the restrictions proposed on us who want to add *more 
> functionality* and *improve existing functions*. If you think about it 
> our goals aren't vastly different to those from thunderbird core.
> If the API is the "safe point" for the front end, then why not force 
> Thunderbird Core code through the same gate? Possible answers
>   * Core needs to do more than Add-ons
>        (which is partly true, but Add-ons add stuff that core didn't
>     think of and users still find useful, so it also goes the other way)
>   * Core code is vetted and Firefox does not review web extensions code
>        (so far we did manually review and vet the code for security with
>     the Add-on reviewers crew. Which mainly consists of other
>     developers. Whether this is a big problem going forward remains
>     debatable; AFAIK there was *one* documented security breach caused
>     by an ADd-on in Tb within the last 10 years, which is not a bad
>     statistic compared to OS like windows)
>   * Core Developer are Trusted, anyone can  develop Add-ons
>        (I think this a stronger argument; the question is whether it
>     would be possible to have specially vetted / trusted Add-on
>     developers and only allow them XPCOM access and  how to vet these
>     people - A strong committment to the user base and regular
>     maintenance, bug fixing etc. would be good markers to start from. So
>     far I assumed there wasn't such a big difference in the development
>     community, except that core devs could be financed by the
>     foundation, whereas addon devs had to organize monetization
>     themselves. Maybe that aspect needs to be solved at the same time.)
> I would still be very interested in at least one of the core devs going 
> through this thought experiment, even if just to come to the conclusion 
> that it's impossible. It may be not? Or it may lead to a completely 
> different answer.
> Axel
> *Axel Grude <mailto:axel.grude at>*
> Music Production and Composition
> Thunderbird Add-ons Developer (QuickFolders 
> <>, 
> quickFilters 
> <>, 
> QuickPasswords 
> <>, 
> Zombie Keys 
> <>, 
> SmartTemplate⁴ 
> <>) 
> Visit my YouTube Channel 
> <> 
> for email productivity tips Get Thunderbird!
>> *Subject:*Re: Proposal: MailExtensions API to allow UI overlays, but 
>> no script injection
>> *From:*Eyal Rozenberg <eyalroz at>
>> *To:*Thunderbird Planning (Moderated) <tb-planning at>; John 
>> Bieling <john.bieling at>
>> *Sent: *Saturday, 10/12/2019, 15:56 15:56 IST +0100 [Week 41]
>> Sorry for sounding like a broken record, but:
>> On 12/10/2019 9:25, John Bieling wrote:
>>> Why is it, extension should no longer be able to style the UI as before? 
>> ... not just the UI. Extensions should be able to do essentially 
>> everything. Certainly everything the TB's own UI code can do.
>> Eyal
>> _______________________________________________
>> tb-planning mailing list
>> tb-planning at
>> .
> _______________________________________________
> tb-planning mailing list
> tb-planning at

More information about the tb-planning mailing list