The major thing keeping apps privileged and not webby (and also therefore packaged - [3] below notwithstanding) is the APIs. I'd be interested to know if there has been any progress in moving APIs from privileged to non-privileged too. (And certified to privileged - the only production API I remember changing was the Camera API from certified to privileged.)

On 30/01/2015 14:48, Benjamin Francis wrote:
Hi,

It feels like a good time to bring up this topic again.

One of the main themes in suggestions for Firefox OS 3.0 has been to make
the OS more "webby", moving away from packaged apps to something inherently
more web-like, and even turning the built-in Gaia apps into hosted apps.

When we last spoke in this thread, the W3C "Manifest for Web Application"
specification [1] was at its first public working draft. That spec has
recently reached an important milestone by being declared feature complete
and is expected to transition to a Candidate Recommendation soon, already
having being implemented in Chrome.

Service Workers seem to be moving along in Gecko [2], and have also been
one of the hot topics in Firefox OS 3.0 discussions, particularly in
relation to offline functionality.

There have been several proposals of how to provide privileged hosted apps,
including work around hosted packages [3] and discussions around a security
model.

There have been several prototypes demonstrated with hosted versions of
Gaia apps doing all sorts of interesting things, and proposed design
concepts around new ways of thinking about web apps, like Pinned Apps [4].

There are lots of separate teams working on things in this area so I
thought it might be useful to share what everyone is working on. How close
are we to being able to deprecate packaged apps? How are hosted privileged
apps coming along? What's the latest thinking on a security model? How are
Service Workers coming along? Where is the source code of some of the
prototypes people have been working on for hosted Gaia apps? What is still
missing?

Please share!

Ben

1. http://w3c.github.io/manifest/
2. https://bugzilla.mozilla.org/show_bug.cgi?id=903441
3. https://bugzilla.mozilla.org/show_bug.cgi?id=1036275
4. https://wiki.mozilla.org/FirefoxOS/Pinned_Apps

On 8 July 2013 at 22:31, Ben Francis <bfran...@mozilla.com> wrote:

Sorry for the typo in the subject line. It wasn't an attempt at a clever
pun...

Hello all,

Apologies for the length of this email, I didn't have time to write a
shorter one.

A year ago Jonas sent out an email [1] outlining the requirements for a new
breed of trusted web apps. He explained some of the challenges of
fulfilling these requirements with hosted apps and set out the rationale
for starting with a packaged app solution, with a view to exploring
something more "webby" later.

Now that we have shipped v1 of Firefox OS [2] with a packaged solution for
trusted apps I would like to re-open this discussion and get your feedback
on whether and how we might make trusted apps more web-like.

In order to gain access to many of the new APIs we have created in Firefox
OS, web content creators must change their entire distribution model and
package the assets of their app into a zip file to be signed and served
from one or more app stores. These assets do not have their own URIs on the
Internet and are served over a local app:// protocol instead of HTTP. This
is similar to how native apps on other mobile platforms work, and is also
similar to the packaged apps used in Chrome & Chrome OS, as well as W3C
widgets. However, it isn't much like how the web works. There is no one
definitive version of the app at a single URI and the update process is
very different.

The System Applications Working Group [3] at the W3C have actually started
some early drafts of specifications to standardise an app manifest/package
format and the app:// URI scheme, based largely on the work done by
Mozilla. Meanwhile at Google I/O, Google showed a version of the Chrome Web
Store [4] where hosted apps are re-branded simply as "web sites", with the
term "app" being limited to packaged apps using their own .crx packaging
format. I have also heard suggestions that support for hosted apps may at
some point be deprecated in Chrome altogether, in favour of supporting only
packaged apps. The message coming from both Mozilla and Google right now is
that all trusted apps must be packaged, hosted web apps can simply not be
trusted with access to new privileged APIs.

What's sad about this vision of the future is that many of the most
interesting apps that get written using web technologies like HTML, CSS and
JavaScript will not actually be part of the web. As Tim Berners-Lee
recently put it in an interview with the BBC about native apps [5], when
apps and their content don't have a URI on the Internet they are not part
of the "discourse" of the web and are therefore non-web. This was a topic
discussed at the "Meet the TAG" event hosted by Mozilla in London recently,
with members of the W3C's Technical Architecture Group expressing
disappointment in this trend.

Are we happy with a packaged model for trusted apps going forward, or is
now the time to embrace the challenge of making trusted apps genuinely part
of the web? Perhaps we don't even need to restrict our thinking to the
"app" and "app store" model and can explore ways of exposing more
privileged APIs to all web content in a trusted way.

If you're interested in the nitty gritty of this problem, I've tried to
summarise Jonas' original email below. I hope he forgives me if I
mis-represent him in any way, but you can read his original email in the
archives [1].

...

In his email, Jonas proposed the following requirements for trusted apps:
1. The ability for a trusted party to review an app and indicate some level
of trust in the app (or potentially in the app developer).
2. A mechanism for signing an app to verify that the app actually contains
the content that was reviewed.
3. Use of a minimum CSP policy for all pages of an app to ensure only the
reviewed code runs.
4. A separate data jar for local data to ensure a compromised web site can
not write to the local data of an app to alter the way it behaves.
5. A separate origin for the resources of an app so that the app can not be
tricked into running un-reviewed code from the same origin with escalated
privileges.

Jonas explained that the initial intention was to host trusted apps in the
same way as non-trusted apps, to retrieve the signatures for reviewed files
from an app store, but the files themselves directly from the app's own web
server.

He explained some problems with this approach:
a) HTTPS must be used to ensure proxies don't modify the headers or body of
HTTP responses, invalidating the signature. This would create an overhead
for app developers.
b) If multiple stores host signatures for the same app but review the app
at different speeds, updating of the app resources and signatures must be
synchronised between different stores and be limited to the speed of the
slowest review.
c) Signed resources have to be static because if a resource is dynamically
generated by a server side script, the signature would also need to be
dynamically generated, requiring a private key to be stored on the same
server, which largely defeats the object of the signing system.

It was argued that this would result in a system which, while hosted like
the rest of the web, is not very "webby" and is the worst of both worlds.

This led to the conclusion for us to package up trusted apps and to serve
their resources locally over a new app:// protocol.


My question is what might a hosted solution to this problem look like?

Ben

1. https://groups.google.com/forum/#!topic/mozilla.dev.webapps/hnCzm2RcX5o
2. https://wiki.mozilla.org/WebAPI
3. http://www.w3.org/2012/sysapps/
4. https://twitter.com/bfrancis/status/335728228897550336/photo/1
5. http://www.bbc.co.uk/iplayer/episode/b036zdhg/Click_06_07_2013/
_______________________________________________
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps


_______________________________________________
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Reply via email to