The thoughts and ideas presented in this mail are very cogent. Some of
these issues
can probably be addressed with more independence than others.
Lifting the app:// protocol up to https://, leaving everything else the
same, doesn't
seem like it should be that big of a difficulty. This would resolve the
"apps don't have
a URI" issue directly.. if perhaps in a shallow way.
The other issues seem more challenging. The main challenge of packaged vs.
non-packaged apps relates to deficiencies in connectivity in the current
mobile world.
The web is designed for always-connected. Any page or resource is
implicitly assumed
to have the ability and right to send you to another location to fetch
some associated
information. The web doesn't try to force a clear notion of boundaries
between
what should be included in a single pull and what's OK to leave to
secondary pulls
induced by HREFs embedded in the first pull.
This model doesn't fit so well with the mobile world, where each access
to the
network, and each byte transferred, may be ridiculously expensive. Under
that context,
it's very important to clearly define the boundaries between actions
that induce network
traffic, and actions that stay within resources that have already been
pulled.
We need some way to transparently indicate to the OS that "this is the
set of resources
you need to pre-fetch to minimize the set of subsequent fetches when
using the
application".
Fabrice mentioned the possibility of app manifests, and I think that's a
very workable
approach to this. In fact, it would be great if we can introduce the
notion of packaged
resources to the web transparently, independent of the specific
mobile-apps use case.
Using Fabrice's suggested syntax, a URL of the form:
http://host/some/path/name!/sub/path
Would indicate to the client agent that the resource located at
'.../name' is allowed
(but not required) to be a packaged file of some set of standardized
formats (e.g. zip).
The specified client behaviour when fetching this URL would be to first
try fetching
the full path: ("http://host/some/path/name!/sub/path";), and if that
request fails
with a NOT FOUND, to try fetching "http://host/some/path/name";, checking
to see if
the identified resource is an appropriately packaged file, and if so,
retrieving
"/sub/path" from within the package, and using that as a resource.
This would keep backwards compatibility, and transparently introduce a
notion
of locality to packaged web-resources, which should help us take another
step towards making packaged apps first class citizens of the web.
Kannan
On 13-07-08 5:31 PM, Ben Francis 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-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g
_______________________________________________
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g
