Hello Mounir, So in your view the review process is the effective way to prevent security issues from flaring up in the Web APIs that have not reached maturity?
Allow me to challenge that. If you look at the amount of code in our framework, on top of which we are building Firefox OS apps ( http://github.com/urbien/urbini ), and the high volume of commits, you will see that reviewer will quickly get lost and certainly will not be able to keep up with the speed of updates. 1. May be what you mean is that the review process allows to remove the app from the marketplace and thus it is a control mechanism used to weed out the malicious or security prone apps? But isn't this 'revocation from the marketplace' control mechanism applicable to the hosted apps, providing they are allowed to be installed on the device only if they are registered (but not reviewed) by the Marketplace? 2. In addition some companies may spring up to do virus checking and vulnerability analysis directly on the hosted app's website, as is quite common on the ecommerce sites, take a look at the survey: http://baymard.com/blog/site-seal-trust Although such mechanism does not provide a bullet proof solution of crypto signatures with the additional guarantee of the uncompromisable zip of the app downloaded directly from the marketplace, if it is done automatically and hourly, it should be good enough. Then Firefox OS app install process could warn the user if the app does not have such a "trust seal". If app is not adorned with the "trust seal", then user will make a decision based on a brand name, app install stats and user reviews scores. 3. Marketplace can offer one more service, paid hosting. It can then serve hosted apps over SSL and have a way to verify apps in real time as they are changed by developers. Some underdog cloud companies will likely jump on this opportunity and will integrate with 'trust seal' companies. This gets Mozilla off the hook and may even provide an extra revenue stream. These moves will allow even the immature Web APIs to be used by the hosted web apps, with 2 small requirement only, a manifest and a quick registration in a marketplace. This is not too much for the developer, and will not bog down Mozilla resources in supporting two app models, hosted and packaged, will free Mozilla resources from hiring, training and managing reviewers (even if they are just volunteers and ask for no pay) and what is more important, it will avoid creating a constant friction with developers around the lengthy and subjective review process. If you think it is non-existent problem, take a look at this two week old post by a developer and the answer from Mozilla: https://groups.google.com/forum/#!msg/mozilla.dev.webapps/Vma71BM2up4/s_MggYloat4J 4. If this is not enough, leave packaged apps for now for some special cases, like apps which need full access to the device's file system, or device backup apps, that need access to everything. 5. Meanwhile, before any changes are made, you might recommend to developers a hybrid model. A small packaged app that is fairly rarely changed and acts like a shell for an iframe with a mozbrowser attribute, where the rest of the app works. This will take the pressure off of the review process, by greatly reducing the frequency of app updates and the amount of code that reviewers need to read. This is the model we are offering to the third-party apps that use our Urbini framework. Hope this helps, -- Gene Vayngrib On Wednesday, July 17, 2013 8:25:03 PM UTC-4, Mounir Lamouri wrote: > Hi, > > > > tl;dr: it is too early to deprecate packaged apps. They are a good tool > > to experiment and can already start taking over the native app world. > > > > Our APIs are not mature enough to be moved to the Web. Most APIs that > > are privileged-only will get significant changes in the future. Packaged > > apps is an environment where we can actually change APIs relatively > > easily. We are actually thinking of adding an "api version" in the > > manifest to make such a mechanism working. > > > > In addition, of not being mature, some APIs have security issues that we > > do not know how to solve yet and solving them is not trivial. Having > > those APIs for packaged apps only with a review system allow us to delay > > having a security model for the Web (where we can't review content). We > > will hopefully get to that at some point. > > > > In other words, I see packaged apps as a nice playground where we can > > experiment things before having them go in the Web. > > > > Furthermore, one of the things Mozilla wanted to solve with Firefox OS > > was to make things simpler for developers and users. Having one platform > > (the Web) that will no longer require you to re-buy apps if you change > > phone. We are not close to solve the second problem but packaged apss > > will help with the former. Even if packaged apps are not really the Web, > > they are using Web Technologies and will help developers to write > > applications that could way easily be ported from a platform to another. > > SysApps could be a good path and we could standardise APIs there in a > > way that, at some point, an application for Chrome, Firefox or Tizen > > would look exactly the same. > > > > Having all those APIs available to the Web is something everyone in the > > WebAPI team want but this is not going to happen overnight and we should > > be realistic and try to fix our problems one at a time. > > > > -- > > Mounir > > > > On 08/07/13 14:31, 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 > > > [email protected] > > > https://lists.mozilla.org/listinfo/dev-b2g > > > _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
