Matt, Mounir, in case you did not see it: an iOS malware app that defies static analysis and calls for a constant app monitoring infrastructure (and a kill switch) on the device.
http://www.technologyreview.com/news/518096/remotely-assembled-malware-blows-past-apples-screening-process/ On Monday, August 5, 2013 3:51:35 PM UTC-4, Matt Basta wrote: > > Google just introduced automatic malware scanner for Chrome Web Store > > submissions > > > > We have similar technology in the Marketplace app-validator. > > > > https://github.com/mozilla/app-validator > > > > Our scans right now are very basic since there's not a whole lot you can do > with the APIs that are available to privileged apps, and all apps are > reviewed regardless of the validator's output (or whether the app is packaged > or hosted). Personally, I prefer Google's approach since it means it's easier > (and faster) for apps to get into the Marketplace, but that's a separate > discussion. > > > > ----- Original Message ----- > > From: "Gene Vayngrib" <[email protected]> > > To: [email protected] > > Sent: Monday, August 5, 2013 12:17:57 PM > > Subject: Re: [b2g] Can we deprecate packaged apps? > > > > 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 _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
