Skepticism about a new Electron-based product
369 views
Skip to first unread message
Henri Sivonen
May 12, 2017, 4:19:04 AM5/12/17
to tb-pl...@mozilla.org
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
hsiv...@hsivonen.fi
https://hsivonen.fi/
_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning
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
hsiv...@hsivonen.fi
https://hsivonen.fi/
_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning
Philipp Kewisch
May 12, 2017, 10:08:41 AM5/12/17
to Thunderbird planning (moderated), Henri Sivonen
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
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
Henri Sivonen
May 12, 2017, 2:08:08 PM5/12/17
to Thunderbird planning (moderated)
On Fri, May 12, 2017 at 5:08 PM, Philipp Kewisch
<kew...@thunderbird.net> wrote:
> 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've been asked off-list where I even got the notion that Thunderbird
<kew...@thunderbird.net> wrote:
> 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.
was considering Electron.
https://mail.mozilla.org/pipermail/tb-planning/2017-April/005508.html
put Electron first and mentioned Gecko as the last item with the
remark "mostly for historical reasons". Additionally,
https://blog.mozilla.org/thunderbird/2017/05/thunderbirds-future-home/
said "we hope to be independent from Gecko in the long term" and
"Thunderbird will remain a Gecko-based application at least in the
midterm" which I read in the context of the earlier Electron remarks
on this list.
(FWIW, I originally wrote a reply to the thread I linked to above, but
the moderator didn't want me to hijack a thread, hence the lack of
reply quoting for context in my email.)
R Kent James
May 12, 2017, 2:09:40 PM5/12/17
to tb-pl...@mozilla.org, Henri Sivonen
On 5/11/2017 11:50 PM, Henri Sivonen wrote:
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.
With the legal home decision finally out in the open, I'm glad we can start to talk about this issue.
I've followed Myk Melez's attempts at variants of Gecko that are not browsers, but as far as I can tell none have gotten any traction (Positron, qbrt, Headless Firefox). It's not clear to me that MoCo has interest in anything other than Firefox, and attempts to "go faster" and "focus" seem to encourage people to actively disengage from any effort that is not focused on a better Firefox. I don't mean that as a criticism, after all Firefox has its own difficult race to run, but we have to face reality.
But reality can change. Several of the key features that underlie
the success of the modern web were born in email technology
(XMLHttpRequest in Outlook Web Access, and GMail as the model of
the potential of AJAX to emulate a desktop app). In my dreams,
Mozilla would embrace Thunderbird as their own, and work to ensure
that Gecko technology would be effective on the entire stack of
platforms expected of a modern application. In the process a
vision of Gecko that extends to desktop, mobile, and web could
emerge.
But just as Firefox has a difficult race to run, so does Thunderbird. Electron is available today, with lots of tutorials and support, and a rapidly growing ecosystem. In contrast, as Myk says, "qbrt is immature and unstable!". It would be great if Mozilla would embrace qbrt or a related project, and encourage Thunderbird to be the early demo of that. Hopefully now we will at least be invited to those discussions. But let's get back to today. My vision of a Thunderbird++ is an app that runs on all currently viable platforms. When you look at new apps that target a similar vision, what are they using? Increasingly I see Electron for the desktop, and React/React Native for the UI and Mobile support. (See Keybase for this week's example). Electron may have its issues, but forking or branching Electron to solve issues is still easier than trying to imagine bootstrapping a Gecko equivalent.
For the Caspia Contacts project, we are explicitly exploring how a common code base would support multiple platforms. In the current sprint, we'll do a barebones HTML contacts form that runs as a website and as an Electron app. But the goal is not really to support Electron per se, but rather to explore how to structure the code to be platform agnostic. We would like to understand what advantages Electron gives us over, say, using modern browser technologies for offline support including Service Workers and IndexedDB.
So from the Thunderbird perspective, I would say that there is no decision to use Electron as the base of Thunderbird++, and I would hope that a decision on that would be delayed until considerably more experience is gained with the alternatives. We would welcome more engagement with the Mozilla platform team on how to effectively use Gecko technologies instead.
:rkent
Magnus Melin
May 12, 2017, 2:36:19 PM5/12/17
to tb-pl...@mozilla.org
On 5/12/17 5:43 PM, Henri Sivonen wrote:
> Additionally,
> https://blog.mozilla.org/thunderbird/2017/05/thunderbirds-future-home/
> said "we hope to be independent from Gecko in the long term" and
> "Thunderbird will remain a Gecko-based application at least in the
> midterm" which I read in the context of the earlier Electron remarks
> on this list.
The above should be read in the light of higher level hopes for
> Additionally,
> https://blog.mozilla.org/thunderbird/2017/05/thunderbirds-future-home/
> said "we hope to be independent from Gecko in the long term" and
> "Thunderbird will remain a Gecko-based application at least in the
> midterm" which I read in the context of the earlier Electron remarks
> on this list.
implementing new components and modules. That the code at a core should
not tie into XPCOM and XUL - which means the code could (with effort) be
used on another platform too.
-Magnus
Ben Bucksch
May 12, 2017, 2:46:02 PM5/12/17
to tb-pl...@mozilla.org
R Kent James wrote on 12.05.2017 20:09:
I've followed Myk Melez's attempts at variants of Gecko that are not browsers, but as far as I can tell none have gotten any traction (Positron, qbrt, Headless Firefox). It's not clear to me that MoCo has interest in anything other than Firefox, and attempts to "go faster" and "focus" seem to encourage people to actively disengage from any effort that is not focused on a better Firefox. I don't mean that as a criticism, after all Firefox has its own difficult race to run, but we have to face reality. ...
But just as Firefox has a difficult race to run, so does Thunderbird. Electron is available today, with lots of tutorials and support, and a rapidly growing ecosystem. In contrast, as Myk says, "qbrt is immature and unstable!". It would be great if Mozilla would embrace qbrt or a related project, and encourage Thunderbird to be the early demo of that. Hopefully now we will at least be invited to those discussions. ...
So from the Thunderbird perspective, I would say that there is no decision to use Electron as the base of Thunderbird++, and I would hope that a decision on that would be delayed until considerably more experience is gained with the alternatives. We would welcome more engagement with the Mozilla platform team on how to effectively use Gecko technologies instead.
+1
Reply all
Reply to author
Forward
0 new messages