Skepticism about a new Electron-based product

Philipp Kewisch kewisch at thunderbird.net
Fri May 12 14:08:33 UTC 2017


Hi Henri,

thanks for bringing in your opinion. I fully agree that part of what
Thunderbird is, is using Mozilla technologies as a basis. This is also
where I am slightly concerned about the rewrite and would like to look
into further options.

To start out, please note I am speaking in my personal opinion in this
email, what I say does not reflect council discussions or decisions. It
has also gotten substantially longer than I wanted, but you bring up a
lot of good points that I would like to respond to, some of which have
been on my mind for a while too.


-- web technology and UI future

I just want to state this for others since it has been a common
misconception: There has been some confusion on the use of the term "web
technologies", understandably so. To me, this means the use of HTML,
Javascript and related technologies, as opposed to using XUL, XPCOM and
a mix of C++ and Javascript. It does not make a statement on if it would
be a client-server app, even if it were a local model. I am certain
there will always be *some* native part, as we want to ship a desktop
application on all major platforms.

Regardless of what option we choose, I think it is important to give the
UI a similar look and feel we have today, to not alienate users. I
believe we will be using native os styling and per-OS themes as we have
before and offering a slightly refreshed but otherwise similar look. Of
course there are areas that could use improvement and can look different
in a new version.


-- importance of getting a heads up for changes

In the case of a rewrite, the current Thunderbird still needs to run, at
least until a majority of the current features are also available in the
new version. Therefore I wouldn't consider it "soon" that Thunderbird
will no longer be using m-c. Of course there are other factors at play.
If Firefox makes drastic changes to the platform, we'll eventually have
to make the hard decision on if we can still follow m-c with backouts,
or if we need to stay on a previous Mozilla Platform version.

As a conclusion, I think it is still important to have support from
developers such as yourself in getting a heads up if there are changes
coming up that would affect us. While we cannot always react instantly,
if every time there is a major change in m-c we only noticed when the
tree breaks, the day we have to decide on fork vs branch with backouts
will come very soon. As I haven't had the chance to in the past, I'd
like to thank you for putting in the extra effort of checking if your
work affects Thunderbird and letting us know!


-- electron and other email clients

As for teaming up with other existing email client projects, I am
concerned that this would also convey the wrong message. Would
Thunderbird really still be Thunderbird if it were a forked or
picked-apart version of another email client? I suspect not.

Moving forward to the electron proposal, the way I understood it was
that Thunderbird Next should be written in a way that the components
could run on native platform containers, including but not limited to
electron. I agree with what you said about using electron not fitting
into the current cultural setting and I am reluctant to go this
direction for just those reasons. Personally I feel that Thunderbird
should not just be an email client, but a product where you can easily
see that it originates from the Mozilla community.


-- thoughts on the current proposal

I am not yet in a position where I can make a compelling
counter-proposal supporting a gradual rewrite. I think that despite the
fact that a gradual rewrite would take longer in total, it would still
be a viable option to consider. The reason we are having so much trouble
with the Mozilla Platform is because we are relying on many internals
that are all set to migrate or have already changed. If we can
essentially use the Platform only as a container that shows a html page
with the Thunderbird UI, then our dependencies will be minimal.

If what I just described were the goal, then experimenting with other
containers (including mobile) on the way would be feasible without
losing control of what Thunderbird currently is. It would also not be
very far from the rewrite proposal, just that the importance of all the
basic platform features that we'd have to re-write when moving away from
the Mozilla Platform would only be relevant at a later stage.

I don't want to restart all the discussions on technical paths forward
(and I'd appreciate if we could do that separately when there is a
counter-proposal), and I do want to reach an agreement soon.
Nevertheless, the decision shouldn't be rushed and other options should
not be dismissed out of fear of the project not being able to continue
in the future. Making decisions out of fear is never a good idea.


If you made it to here, thank you very much for reading!
Philipp



On 5/12/17 8:50 AM, Henri Sivonen wrote:
> I'm a bit skeptical about the notion of writing a new
> Thunderbird-branded product as an Electron app.
>
> What's Thunderbird now? I'd say Thunderbird is a Free / Open Source
> Software cross-platform desktop email client based on the
> Netscape-originating Mozilla technologies.
>
> It seems that the Free / Open Source Software part is
> non-controversial. That's good.
>
> It seems that the have been some ideas aired about whether a future
> Thunderbird should be something other that an "email client", but me
> read so far is that the core devs still want to develop an email
> client. Also good.
>
> The main areas of proposed change seem to be in "cross-platform
> desktop" and "based on the Netscape-originating Mozilla technologies".
>
> The proposed new direction seems to be that a future product would run
> across desktop platforms but the UI would be locally-running Web tech
> UI instead of a XUL UI mimicking a native UI.
>
> If the new Thunderbird-braded product no longer has the unique user /
> IT department-facing characteristic of having the UI paradigm and look
> of a native desktop app but yet running on Windows, Mac and Linux (as
> opposed to only one or two of them), is it Thunderbird enough to be
> accepted as an upgrade to the current Thunderbird by users? But it
> seems that using Web tech instead of e.g. Qt has been so strongly
> decided that it's probably not worthwhile to question that part.
>
> Instead, I'm going to focus on the details of how Web tech is used.
>
> On the point of current Thunderbird being based on Mozilla technology
> and https://blog.mozilla.org/thunderbird/2017/05/thunderbirds-future-home/
> saying the Mozilla Foundation has agreed to continue as Thunderbird's
> "cultural home", it seems really weird for Thunderbird to be
> transitioning to Electron. It would be like the Eclipse Foundation
> doing a Netbeans-based project or the Python Foundation doing a
> prominent Ruby project. Not that there's anything wrong with Ruby.
> Just that when there's an org that's the home of some core tech, it's
> really weird for them to host a project based on tech competing with
> the core tech even if hosting orthogonal things would be neutral.
>
> While the potentially harmful optics for Mozilla itself may not need
> to be of concern to Thurderbird, there does seem to be a practical
> side to this: If the stated goal of Thunderbird is to move away from
> Mozilla tech, how is that going to affect the relationship with the
> Mozilla tech that, for the time being, is still the upstream? One
> could argue that the relationship is already so bad from the
> Thunderbird perspective that it can't get any worse and that it would
> be spiteful and ungraceful of mozilla-central developers if they
> accommodated Thunderbird even less knowing that Thunderbird intends
> not to use m-c soon anyway, but how do you expect the stated intent to
> migrate to Chromium tech affect the relationship with m-c for the
> short term? As an m-c developer, am I just wasting time researching
> the impact of my actions on c-c and sending heads-up emails about
> impact?
>
> In general, it's not clear that grass would be that much greener on
> the Electron side. Like m-c, the Chromium project is making a browser
> at their pace and the downstreams just have to deal. It just happens
> that so far Chromium hasn't undergone the kind of big changes that
> Firefox is now undergoing with the introduction of e10s and Servo code
> and the removal legacy tech that stands in the way: XPCOM extensions
> and XUL.
>
> Still, Chromium does what it does, and Electron has to deal. If
> Thunderbird was downstream from Electron, it would be even further
> removed from the engine than it is from m-c today.
>
> One key area where this matters is security updates to the engine. So
> far, Thunderbird has been able to benefit from the Firefox ESR release
> process. In the Chromium case, Chromium provides security patches for
> the latest Chrome release and, other than that, downsteams are on
> their own: https://www.chromium.org/Home/chromium-security/security-faq#TOC-Can-I-see-these-security-bugs-so-that-I-can-back-port-the-fixes-to-my-downstream-project-
>
> The security posture of the Electron ecosystem is pretty bad:
> https://twitter.com/bcrypt/status/852316922683076608 . This may be OK
> for apps like Atom that are used to edit text files you made yourself
> or someone on your team made, but an email app is different. An email
> app manages a lot of privacy-sensitive data and it's easy to have
> targeted maliciously-crafted input delivered to an email app: you send
> an email to the person you want to target.
>
> While email provides a lesser attack vector to the underlying Web
> engine than general Web content, it still seems like a very bad idea
> for the Web engine used in an email app to be allowed to lag behind in
> updates to the underlying Web engine.
>
> Note that Brave ended up forking Electron into Muon in order to be
> able to do security (and, it seems, extension support) better than
> Electron.
>
> Relying on the system-provided Web engine isn't a good security
> solution, either, especially because WebKit security updates don't get
> into Linux distros in a timely manner:
> https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/
>
> It seems to me that the best way to deal with security updates for the
> Web engine part of an app that uses Web tech is to let a competent
> browser vendor deal with updating the Web engine by not bundling a Web
> engine and letting the user use their actual browser to connect to
> your app. This can work locally, which is the Mailpile model.
>
> Granted, the Mailpile model is even further removed from the current
> Thunderbird desktop app paradigm than an Electron app, but since it
> seems that giving up on the current paradigm is happening anyway, it
> seems like a good idea to take it a step further and gain better Web
> engine security with less work for the Thunderbird developers. (And,
> as a side effect, allow the use of Mozilla's Web engine without
> Thunderbird having to integrate it into something other than Firefox.)
>
> Of course, that then brings the question: What would a new
> Thunderbird-branded product bring to the table compared to Mailpile
> itself to justify a new product as opposed to pooling efforts with
> Mailpile? There was concern about needing a new performant email
> database. Mailpile started by doing the database and its search engine
> first and only then doing the UI. Why reinvent the wheel there? (Even
> in the Electron scenario, there's the question of what would a new
> Thunderbird-branded product bring to the table compared to pooling
> efforts with Nylas.)
>



More information about the tb-planning mailing list