Time to go through old threads again... The short answer is "no, i don't think we can deprecate packaged apps yet".
The big problem is still how to expose APIs that are security sensitive and whose implications we can't explain well enough to the user. This generally mean all *security* sensitive APIs, we shouldn't ask the user security questions. Privacy questions and things like resource-use questions can be ok, but security questions generally should be avoided. So far the only solution we have is "review and sign by trusted 3rd party", and the only realistic solution for signing that we have is packaged apps. Or at least solutions that aren't "the web". I think it will take many years to solve the packaged apps problem. However it will take longer than that if we don't start working on it now. So what are we doing to try to help with the packaged apps problem? We have started exploring creating a URL standard that would allow linking to resources inside a .zip file. This would actually allow having URLs to packaged apps. Not sure what the latest here is. Anne could probably fill in the blanks. We tried to standardize packaged apps so that they at least would be interoperable. Unfortunately this is going less well. There's currently at least 3 different standards: FirefoxOS packaged apps, ChromeOS packaged apps, Widget packaged apps (which I believe is what tizen is using). Attempts at getting these to align has so far failed. Basically only mozilla has expressed willingness to actually change the implementation and implement a standard. My next plan here is to attack the hosted apps and get those standardized. This is going much better and I hope that we can have a spec draft for the bookmark-to-homepage use case in just a couple of weeks. I've talked with multiple mobile browser vendors and there is a lot of interest here (I don't want to speak for others which is why I'm avoiding names). Once we have that standardized, we have most of what we need for hosted apps. Slap some API on top of that and you have an app store. Though it's unclear who apart from us would be interested in implementing such an API though. We've also done some discussions with google around WebIntents/WebActivities. Having standardized WebIntents/WebActivities should enable more apps to not need the APIs that require "privileged" level, and so would help reduce the packaged apps problem. At this point I think we have a better understanding of what it would take to create a standardized WebIntents/WebActivities spec. Unfortunately we haven't gotten further than that here. Action is on me to put together some information about what we know so far so that others can pick up this work. So while there is little concrete progress, we're not doing nothing. But I'm all for help in doing more. In particular I'd like to see us do more work on getting WebIntents/WebActivities standardized. And do more work on finding safe-to-expose-to-the-web variants or subsets of our existing privileged-only APIs. I'd personally put a safe subset of DeviceStorage API high up on the priority list. / Jonas On Mon, Jul 8, 2013 at 2:31 PM, 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
