Hello all, I don't have much to add in the way of implementation suggestions, but I do want to make a few points from an overall product and end user perspective. (much of this is probably well known to this list, but it may spark some further thought)
As was already mentioned, it is important that our solution provides users with the freedom to obtain and use apps in a manner that suits them best in an environment encumbered by connectivity constraints (costs, network availability, etc.). So, to the extent that a given app's developer intended such a use for their app, the user should be able to opportunistically "download" the app as it suits them (ie. WiFi) for later use when not having local assets would otherwise render that app useless. Moreover, right or wrong, I believe the average user expectation is such that when an icon for an app persists on the device then that app can function in an offline mode. When there is a lack of connectivity, it may be worth exploring, using some user experience tests, whether or not visually distinguishing between apps that don't have such local content and apps that do provides clarity and benefit to the user. (I believe there were some proposals/contributions on this front) The other part of the picture are users that don't tend to seek out and install third party apps for later/repeated use. Our data for our target markets indicates that the average smartphone user does not use more than a few (< 2-3) third party apps. It is for these users that I think that pushing the boundary with respect to the use cases a hosted app is capable of satisfying (ie. APIs available to that app) would provide product differentiation and round out the "instant app" story. These are not users who will go to an app storefront to seek out apps that they can install for later use. It is more likely that they will have a specific task in mind that they would like to accomplish. A discovery mechanism for such apps to meet the task at hand, paired with unencumbered app access to device functionality (beyond what is possible using hosted apps today and to the extent possible while still protecting the user) that can create an "instant" experience without having to downlo ad the app would go a long way to meeting the workflow needs of these types of users. Peter ----- Original Message ----- From: "Ben Francis" <[email protected]> To: "dev-b2g" <[email protected]>, [email protected] Sent: Monday, 8 July, 2013 2:31:49 PM Subject: [b2g] Can we deprecate packaged apps? 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 [email protected] https://lists.mozilla.org/listinfo/dev-b2g _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
