On Mon, Jul 9, 2012 at 8:04 PM, Jonas Sicking <[email protected]> wrote: > With that, let me start by enumerating the requirements that we have had in > mind for trusted apps: > > * They are reviewed in some form. ... > However, there are a couple of problems with this solution. > > As Brian Smith has pointed out, signing HTTP responses isn't trivial. ... > Additionally, there are some things that are very non-webby with this > solution. ... > Hence we have changed the plan to instead base trusted apps on a "packaged" > solution.
I think the basic problem here is that the problem being solved is a problem that has not been previously solved on the Web, so trying to solve it on a tight schedule is bound to lead to un-Webby solutions. Basically, on the Web the model is that if you want to use an app that processes your private data for your own benefit (e.g. webmail app processes your e-mail for your benefit) you have to trust the entity that serves you the webmail interface with your private data. There isn't a way to obtain the webmail interface from an un-trusted source and have a third party certify that the bits you received over the wire are okay. As far as I can tell, the problem that you're trying to solve is enabling un-trusted entities to provide apps that deal with private data for the users benefit. (As opposed apps that want to deal with private data but not to the benefit of the user, e.g. a game that wants the user's geolocation and deviced identity for advertising rather than gameplay purposes--a case that could be addressed by feeding synthetic lies to the app rather than actually treating the app as trusted.) I suggest we address this issue by not addressing it: By requiring users to obtain apps that deal with the users' private data for the users' benefit only from entities that the users trust. This seems to be the Webby way: You get your webmail app from an entity you "trust". You don't get your webmail app from someone you don't trust and rely on a third party to inspect and sign the client-side code. After all, in most cases on the Web, there's a server-side component whose signatures you don't have a chance to verify anyway, so third-party audit and certification of the client-side part would be moot. Verifying that you are interacting with an entity you "trust" (as opposed to receiving bytes certified in advance by a third party) is already a solved problem on the Web: https. I suggest that the B2G security model attached trust to suppliers of applications rather than to particular bits of client-side application code. This way, there's no need to solve the problem of verifying signatures on client-side pieces of application code and it's possible to instead focus on hardening https identity verification e.g. by pinning the https private key of the trusted app so that the app is safe against attacks leveraging the multitude of CAs. It's also worth noting that we ourselves consider us so trustworthy that once a user has agreed to install bits supplied by us on a Windows machine, we want authorization to replace those bits with new ones without third-party (Microsoft) or even first-party (user) interference. It would be kind of ironic if our platform didn't allow e.g. an email app operate under the kind of trust relationship with the user we ourselves want to operate under when we ship a browser. Even if a third party (Mozilla) can't review and certify bit of code before hand in a model where technically the trust is placed in the private key of the app supplier instead of the private key of the reviewer third party, we could still have an after-the-fact way of revoking trust in keys that have been shown not to have been trustworthy. This is the model Apple is pushing for Mountain Lion, FWIW. If we opt for Mountain Lion-style way of dealing with rogue app behavior (as opposed to the iOS way of advance review of bits), we can use Webby solutions based on (pinned) https trust. -- Henri Sivonen [email protected] http://hsivonen.iki.fi/ _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
