Dropping legacy support: Moving forward

Mark Banner mbanner at mozilla.com
Thu Oct 10 11:56:41 UTC 2019


On 07/10/2019 23:03, Magnus Melin wrote:
> On 06-10-2019 12:33, John Bieling wrote:
>>
>> We are in this situation, because Firefox/Mozilla decided, that 
>> WebExt is the new thing. If Firefox would not have done that, we 
>> would be still be able to create powerful add-ons, which can do 
>> almost everything. There has never been a security issue with 
>> Thunderbird extensions. The reason Firefox closed WebExt Experiments, 
>> are security issues, I think.
>>
Please can you give your citation to back up that there's "never been a 
security issue with Thunderbird extensions"? Have you checked all the 
security reports that Thunderbird's ever had? Have you checked that 
every single extension has never loaded a message in a chrome context or 
handled unsanitized code?

We might not know about it, but it might still have happened. Generally 
I've always had the impression that because of the smallish user base, 
Thunderbird's never really been a significant target for hackers, but 
that's speculation, and we don't know if there's targeted efforts 
happening that don't get reported to us.

> There is a security issue with current style add-ons: They can do 
> anything per design - but that's not a desired design related to 
> security.
>
I'd like to expand on Magnus' comments here with my own understandings 
of what was causing the change (these are not always first-hand 
observations, but what I've come to understand over the years, so the 
actual reasons may be slightly different, but I think these still fit well).

For Firefox, it wasn't just about security. There were lots of things, 
to name a few: extensions causing Firefox to be unusable on startup 
after an upgrade or at other times because we'd changed the backend 
code, theming issues, causing crashes, two add-ons interacting badly... 
as well as being able to introduce security issues by displaying items 
in the wrong context, or altering behaviour badly etc etc. Another 
example is that extensions could actually break Firefox's upgrade 
process, because they could change anything...

Added onto this, due to the number of add-ons and their combinations, 
you simply couldn't just test your way out of it.

All of that was ending up with a bad experience for users, and they 
would generally blame Firefox. You'd also get the extension authors 
complaining about the amount of changes, and having to keep up.

So what do you do? Simplify the API with a firm decision to support it 
as much as possible (which stops the user facing issues) and as a result 
give the add-on authors a route where they aren't going to have to do 
changes every version.

Thunderbird may not be having such significant issues all the time, but 
it is happening, and regardless the risks are there.


>> I can understand, that we need to follow the WebExt path, but 
>> disabling WebExt Experiments is your own choice, right? If WebExt 
>> Experiments do allow us to do all the things we need, why are we not 
>> allowed to use them (later)?
>>
I think at some stage, this all access pass does need to go away, for 
the reasons above, and to make everyone's life simpler and more 
reliable. You're complaining about these big backend changes, dropping 
xul etc, but you're also complaining that you now won't get as much 
access. The big changes aren't going to be stopping any time soon...

With my add-on author hat firmly on, yes it might be a shame for there 
to be less access, but I also see this as an opportunity to help shape 
the MailExtension API and Thunderbird. For example, Thunderbird 
Conversations completely changes the message preview view - without 
privileged access replacing that might be hard. However, I'm starting to 
think about what does Conversations really need to access from 
Thunderbird? What sort of API would fulfil that? How could some of the 
message display functionality be replaced in a useful way for 
WebExtensions, that doesn't potentially break everything like it does 
currently (yes, the monkey patching is scary).


>> I think this question must be answered now, as I do not want to go 
>> through this in 5 years, when my addons again stop working, because 
>> WebExt Experiments will be disabled.
>>
> To put this in perspective: converting your bootstrapped add-on to an 
> experiment should not be terribly hard or much work. The work you'd 
> put into maintaining that add-on over 5 years is by my guess quite 
> negligible.
>
I haven't tried this yet, as I'm in the middle of a big rewrite that's 
mainly be caused for other reasons, but I'm mainly expecting that to 
convert from 'legacy' to WebExt experiments based, I could probably just 
move my functions from bootstrap.js into some calls behind an experiment.

The hardest bit might be the startup/shutdown functions, although I'd be 
tempted to see if they're really needed now - as in, do you just need to 
cause a module to be loaded? Could that be done from a background script?

They could probably be replaced by the runtime.on* events that the API 
provides, so worst case I could channel those through a simple 
experiment API, and have that do what bootstrap used to do.

Overall, that would be fairly simple, I doubt it'd take too long, and 
it'd give a good introduction to how experiments work, that you could 
then translate everything across.

On conversations, I've already started migrating the preferences 
<https://github.com/protz/thunderbird-conversations/blob/master/addon/prefs.js> 
from Thunderbird's preferences system to the storage system, using an 
experiment API. It enabled me to also get the button for preferences 
back on the add-ons page. Once that's been out for a while, I'll likely 
drop reading/saving the preferences on the Thunderbird side completely. 
This only took me an hour or two to figure out.

Mark

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20191010/ce42f20a/attachment.html>


More information about the tb-planning mailing list