Google just introduced automatic malware scanner for Chrome Web Store submissions: https://plus.google.com/+GoogleChromeDevelopers/posts/3kpAu4VcP5E
They also seem to have this policy of falling back to manual reviews only if automatic checks failed, or app is resubmitted after being suspended: https://developers.google.com/chrome/web-store/faq#faq-listing-08 On Saturday, July 20, 2013 3:05:28 PM UTC-4, Gene Vayngrib wrote: > 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
