Skepticism about a new Electron-based product

Henri Sivonen hsivonen at hsivonen.fi
Fri May 12 06:50:40 UTC 2017


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.)

-- 
Henri Sivonen
hsivonen at hsivonen.fi
https://hsivonen.fi/


More information about the tb-planning mailing list