Thunderbird as a Web App revisited

Andrew Sutherland asutherland at asutherland.org
Tue Dec 15 03:53:48 UTC 2015


On Sun, Dec 13, 2015, at 01:18 PM, Paul D. Fernhout wrote:
> The confusion may be in my choice of the word "server". Is there a 
> better one to use here? Maybe I should say "Thunderbird Webapp" instead?

Yes, I was placing and do place a lot of importance on the word server. 
Webapp is a better term, but it can also be a bit fuzzy since it means
many things to many people.

In the context of Firefox OS we have the notion of a "packaged app"[1]
(https://developer.mozilla.org/en-US/Marketplace/Options/Packaged_apps)
which is basically a cryptographically signed zip-file that exists 100%
locally on the device.  The apps can also be installed into Firefox via
the Web Runtime (some details at
https://developer.mozilla.org/en-US/Apps/Build/Architecture).  These
apps are entirely server-less and they get their own distinct
origins[2].

The Firefox OS Gaia Email app is a packaged app (technically it's
certified, but modulo some experimental stuff, it could be privileged),
and it's my goal to get my "glodastrophe" efforts somehow similarly
packaged for Firefox desktop.  I believe this execution model is a
desirable one, but I do, for example, develop using a local Apache
instance with a custom /etc/hosts entry to provide it with its own
origin.  Significantly, these are static files; there is no
server-run/operated logic.

Most of my concern stems from the idea of the server doing anything
other than serving static files.  I think it would be beneficial that if
you are mentioning an additional server of this type that it's made
clear it only serves the application itself and could be replaced
through the use of a packaged app solution.

Andrew

1: Note that these packaged apps are a Mozilla/Firefox OS proprietary
packaging format created in pursuit of standardization.  Google's Chrome
Apps are the closest other thing out there.  The current longer term
strategy for these is not known, but we do like the properties of
offline and cryptographically signed.  Service workers will likely
handle the former, but the latter is still up in the air.  My personal
suggestion is using the subresource integrity effort bootstrapped off of
a root signature reliant on some code-signing trust infrastructure.  The
specific goal would be that someone hacking https://mailapp.example.com/
could not let them replace/compromise the app unless they also managed
to obtain a valid signature.  The Firefox OS marketplace currently
provides this, but AFAIK we don't easily support alternate trust
roots/marketplaces and that needs to be addressed.

2: I believe the bug you reference in Firefox is in its treatment of
"file://" origins.  The file protocol is troublesome for security and
consistency reasons and (to my understanding) is a non-priority other
than ensuring that there is no way for web content or file:// content
from different sub-trees on your disk to access and exfiltrate data from
your local filesystem.  If you need to do local development, you likely
want to be using "localhost"/"*.localhost" since they receive special
treatment under https://w3c.github.io/webappsec-secure-contexts/ and are
allowed to be granted the same API access as "http" sites that only
"https" sites otherwise receive.



More information about the tb-planning mailing list