On Sat, Jul 14, 2012 at 12:04 AM, Jonas Sicking <[email protected]> wrote: >> 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.
OK. That's foreign to the Web in the sense that on the Web, you have no browser-side assurances of the hackability of a Web app's server which can also leak private data. >> (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. On the Web, it's safe to *go* anywhere, but it's not safe to *enter your private data into* random sites. As far as Web apps that process your private data for your own benefit go where you have to enter private data for the use of the app to make any sense, you have to trust that the organization at the other end of the pipe 1) won't willfully use your private data in a way that you disapprove of AND 2) is competent enough to avoid client-side XSS or server-side vulnerabilities that would enable a hostile third-party to use your private data in a way that you disapprove of ...and the way you recognize the organization at the other end of the pipe is https but no one technically certifies to you what the organization *really* is able to do with your private data. So compared to the Windows model, in the case applications that process your private data, you actually have trust the organization that provides the application *more* in the Web case than in the Windows case. In the Windows case you have to trust that the organization won't make the application exfiltrate your private data from your computer and then willfully use your private data in a way that you disapprove of and you need to trust the organization to be competent enough not to let third parties inject hostilities into their software updates, but you don't need to trust them to be competent to defend against other hostile Windows applications (because installed applications are presumed not to be hostile is the Windows model, though the incorrectness of this assumption is the root of all the troubles) or to defend against threats to your private data on their servers, since your private data isn't on their servers but on your computer. For applications that don't process your private data, such as games, you need to trust the organization that provides the application *less* in the Web case than in the Windows case, because the browser is enforcing that the app really doesn't have the opportunity to process your private data. Now, the privileged APIs need to be privileged, because they automate giving your private data to the application (as opposed to you typing stuff into Google docs or uploading stuff to Flickr yourself). Therefore, the privileged applications fall into the category of applications that process your private data. And that category, as noted above, traditionally requires *more* trust to the organization providing the application in the Web case than in the Windows case. So trying to require *less* trust in that case is novel for the Web (and leads to un-Webbiness as a consequence). > 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. That's a foreign to the Web guarantee, so it leads to un-Webby solutions. (I'm not suggesting that lesser hackability by hostile third parties wouldn't, as such, be a desirable characteristic.) -- Henri Sivonen [email protected] http://hsivonen.iki.fi/ _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
