<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 07/10/2019 23:03, Magnus Melin
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:107e9d2d-1a15-c988-36e5-fc8795682895@iki.fi">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">On 06-10-2019 12:33, John Bieling
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:a1930879-27fb-263c-d690-ad3957fc761c@gmx.de">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
</blockquote>
<blockquote type="cite"
cite="mid:a1930879-27fb-263c-d690-ad3957fc761c@gmx.de">
<p>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.</p>
</blockquote>
</blockquote>
<p>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?<br>
</p>
<p>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.<br>
</p>
<blockquote type="cite"
cite="mid:107e9d2d-1a15-c988-36e5-fc8795682895@iki.fi">
<blockquote type="cite"
cite="mid:a1930879-27fb-263c-d690-ad3957fc761c@gmx.de"> </blockquote>
<p>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. <br>
</p>
</blockquote>
<p>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).<br>
</p>
<p>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...<br>
</p>
<p>Added onto this, due to the number of add-ons and their
combinations, you simply couldn't just test your way out of it.<br>
</p>
<p>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.</p>
<p>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.<br>
</p>
<p>Thunderbird may not be having such significant issues all the
time, but it is happening, and regardless the risks are there.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:107e9d2d-1a15-c988-36e5-fc8795682895@iki.fi">
<p> </p>
<blockquote type="cite"
cite="mid:a1930879-27fb-263c-d690-ad3957fc761c@gmx.de">
<p>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)? <br>
</p>
</blockquote>
</blockquote>
<p>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...<br>
</p>
<p>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).</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:107e9d2d-1a15-c988-36e5-fc8795682895@iki.fi">
<blockquote type="cite"
cite="mid:a1930879-27fb-263c-d690-ad3957fc761c@gmx.de">
<p> </p>
<p>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.</p>
</blockquote>
<p>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. <br>
</p>
</blockquote>
<p>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.</p>
<p>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?<br>
</p>
<p>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.</p>
<p>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.</p>
<p>On conversations, I've already started <a moz-do-not-send="true"
href="https://github.com/protz/thunderbird-conversations/blob/master/addon/prefs.js">migrating
the preferences</a> 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.</p>
<p>Mark<br>
</p>
</body>
</html>