Discussion so far has illustrated the fact that we need to define what a "B2G
app" actually means at a foundational level. That means defining what an app
can consist of, the origin of those assets, and how they are delivered, updated
and stored on the device. I'd like to fork this into its own topic to ensure
it gets the focus it deserves without derailing discussion of Jonas's proposal.
I'm not going to introduce anything novel here other than to summarize the
various points that have been made during the discussion so far, then maybe
make a stab or two at some assumptions. I'm guessing many of the participants
in this discussion have a pretty clear idea of these already, but they all seem
to differ somewhat.
To keep it simple, lets assume an app contains JS, HTML, CSS, various media
assets and (maybe) a manifest. It does not contain any binary or other
inscrutable components.
== Types of apps ==
At a high level, B2G apps fall into two or three general categories:
a1) Privileged applications that have special abilities that could cause
serious damage to the user or device if abused
a2) Normally privileged applications that look and feel like a typical device
application, but are restricted from accessing API's that could compromise the
device or the hurt the user (without explicit consent or maybe never)
a3) Web sites that want to use certain privileges
It could be argued that a2 and a3 are largely the same thing, but they may vary
in default privileges (and maximum privileges) so I'm breaking them out for now.
There is also the OS/kernel itself, but lets assume thats out of scope for this
particular discussion as it warrants its own separate security discussion.
== Deployment ==
b1) static application package, downloaded once from a remote server and
authenticated & installed locally
b2) dynamic remote app locally launched and cached ("locamote"?), identified by
a manifest
b3) typical remote web app with no local presence, identified by a domain
== Scope ==
c1) only locally installed code, authenticated by a code signature, is
considered and permitted to be part of the app. May load remote data and
assets?
c2) remote code cached locally, restricted to loading code from a specific
domain or set of domains as identified by a manifest (requires HTTPS-only for
the restriction to be meaningful)
c3) remote code cached locally, not restricted to any particular domain (does
not require HTTPS); may have manifest? (what security properties would that
provide?)
c4) remote code, no manifest and no implicit trust
== Putting it together ==
Here's where I go out on a limb and assume from the recent discussions that we
are coalescing towards three models.
Gaia app: consists of a1, b1, c1.
A typical local app, with a static codebase that is installed once,
authenticated by a code signature and prohibited from dynamically loading
additional code. Granted signicant privileges in return. Origin of these apps
is probably restricted to a small set of app stores as defined by OS
configuration. Explicit update process.
B2G app: a2, b2, c2
Remotely hosted but locally cached, identified by a manifest. Appears to user
as a local app. Codebase restricted to a single origin, requires HSTS for
authentication. All code (JS, HTML CSS) must be loaded from this origin.
Explicit trust may allow some limited implicit privileges (i.e. fullscreen).
Transparent, implicit update process. Can load assets from other domains
(specifics TBD).
Web app: a3, b3, c4
No manifest, no implicit trust, not cached locally (i.e. no offline mode).
Normal web content security model. No install experience. Really just a
remote site that requests certain webAPIs.
I'm sure I've trampled on some assumptions & use cases. Thoughts?
Lucas.
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
