B2G applications are Open Web Apps, you can read about them here
https://developer.mozilla.org/en-US/apps
They're hosted on a web server like a web site, there's no packaging format
but they may be cached locally using the existing appcache standard.
Also, B2G won't host apps on localhost by the time it ships on devices,
this is just a temporary hack because wifi wasn't working to begin with on
the Galaxy SII!
Ben
On Fri, Mar 16, 2012 at 4:27 AM, Lucas Adamski <ladam...@mozilla.com> wrote:
> 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-webapps mailing list
> dev-weba...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapps
>
> --
> Ben Francis
> http://tola.me.uk
>
> <https://lists.mozilla.org/listinfo/dev-webapps>
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
