On Fri, Jul 13, 2012 at 3:30 AM, Henri Sivonen <[email protected]> wrote: > 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.
That is one piece yes. But the bigger piece is that we want to make apps which have access to these more sensitive APIs harder to hack. > (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. Actually, from a user's point of view, I would say this is the security model of Windows, not the security model of the web. In windows you should only ever install applications from parties that you trust. Once you install an application, you should assume that that application can see anything you do and can do anything with any of the data on your system. The webby model is that it's safe to go anywhere. On the web we even try to limit the amount a web app can annoy you by limiting popups and preventing them from writing to your clipboard. If we allowed trusted apps to be installed from anywhere we'd create something much more similar to the windows model. Sure, for some things we can display dialogs asking the user "do you want to allow this app to get your location" and "do you want to allow this app to access your camera". However there are lots of permissions we'd have a really hard time explaining to the user. What about low-level TCP access or USB access? What would we tell the user that they are approving access to? Especially once you consider how many buggy USB drivers there are out there and that providing low-level USB access to a device might mean that the device can be bricked. So the goal of requiring a trusted store has actually been to make things less like windows and more like the web. But like I said in the initial bullet point. I'd like to allow a store to say that it trusts a developer, rather than trusts an app. This creates a developer flow which is more webby since they no longer have to contact the store once to publish an updated version. But even then we have the requirements around signing (by developer, not store) and, CSP and separate cookie jars to protect against the app getting hacked. So even then I think I would lean towards recommending a packaged format for now. > 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. Note that our goal is to have multiple stores which can install trusted apps, as to prevent us from being a gatekeeper to the platform. The various APIs involved here are designed around that idea. / Jonas _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
