On Sat, Mar 10, 2012 at 1:00 PM, Jim Straus <jstr...@mozilla.com> wrote: > Jonas, Paul, etc. - > For any app, but in particular, a third party hosted apps, we could require > that the manifest contain a signed cryptographic hash of the core of the > application (javascript, html, css?), along with the signature of the trusted > store. This hash would be validated as signed by a trusted source (like or > the same as SSL certs) and that the applications core matches the hash. This > would require that the browser/device pre-load the given content, but > hopefully apps will be using the local-cache mechanism, so this should not be > burdensome. Using this, once a trusted store has validate an application, > the application can't be changed, even if it is hosted by a third party. We > would have to enforce that a signed application can't download untrusted > javascript (eval becomes a sensitive API?). This would allow a third party > to host the apps approved by a given store. It would also prevent a hacked > store site from distributing hacked apps (well, things like images could > still be hacked, but not functionally) as long as the hacker doesn't have > access to the signing system (which should clearly not be on a public > machine). This doesn't prevent a hacker from gaining access to information > communicated bak to a server, but at least makes sure that it isn't > re-directed somewhere else.
It's not entirely clear what problem it is that you are trying to solve? Are you trying to avoid relying on SSL for safe delivery? Or trying to provide the ability for stores to do code verification before the grant apps access to sensitive APIs while still letting those apps be hosted outside of the store? I don't see a problem with relying on SSL. It's a technology that developers understand very well and which we should IMHO encourage more (especially in combination with SPDY). I'm not a big believer in code signing. It's much too easy to miss something in a big codebase and JS certainly doesn't lend itself well to static analysis (which is what code review really is), neither by humans or computers. Additionally one of the big benefits of the web is the ease of deploying new code, which would be significantly hampered if developers had to get any new version reviewed by stores. So I'd prefer to push back against code reviews as much as we can. If we end up needing it, then something like what you are describing might be a possible solution. > The signing mechanism can also be used to black list an app. If Mozilla > maintains a site with a list of blacklisted signatures and devices query that > site, the apps could be disabled. In whatever UI we have to view the list of > apps and control their permissions, a blacklisted app would show up as black > listed and all permissions denied. A user, who needs the app would then > explicitly re-enable it and re-add permissions (making it a pain to go > through the process of looking at the permissions and enabling them), along > with suitable warnings when they do so. Probably the black list site should > contain both the signatures to deny and an explanation of why, (consumes > excess resources, connects to high-cost SMS servers, leaks contacts, etc.) so > that the user can make an informed choice such as to allow an app that > consumes excess resources, but not allow an app that leaks personal > information or incurs excessive costs. I think black-listing would be more effectively done by black listing a origin (scheme+host+port), rather than by signature. Working around a blacklist that is by signature is easy enough that I'd be worried people would even do it by mistake. But I like your ideas about including a description when black listing, as well as (probably optionally) disabling an apps all elevated privileges. In fact, I think one of our blacklist options should be to let an app keep running, but disable a specific elevated privilege. So for example a game which works great but ends up sharing high scores over SMS a bit too much should still be able to run, but have the SMS capability disabled. / Jonas _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
