On Mon, Jun 07, 2010 at 04:22:15PM -0700, John Panzer wrote: > Specifically, I haven't seen a privacy issue which is simply 'solved' by > moving responsibility into the browser. I believe browsers are in the best > position to do certain things (like not rely on a central DNS name, remove > SPOFs, and help implement anti-phishing) but these don't specifically > address 'privacy'. Is there a specific privacy attack / leak you're worried > about that we could discuss?
You haven't seen any privacy issues at all that are solved in browser? None? The current XAuth implementation has sites using IFRAME elements to access the XAuth service/JS code. Web browsers send Referer headers with IFRAME, so whoever runs xauth.org is in a position to see information about what Extender and Receiver sites a user accesses. Currently auth.org has pretty good settings -- cache control headers telling browsers they can cache the page for a week. But that could change. Move responsibility into the browser and that problem is solved. Also, xauth.org could start delivering JS code that reports information to the xauth.org mothership in addition to simply "working". Say the local government tries to compel xauth.org to deliver additional code to specific IP addresses (not that Google has *ever* had any trouble with any government legal pressure, right?). xauth.org could deliver pristine, trustworthy JS to everyone else. How would the government targets, let's say political activists maybe, be able to tell their privacy was being subverted? Move the function to the browser and that hole is closed. This is by no means a comprehensive list (shoot, it's been less than 24 hours since I startd reading up on XAuth), but I think it's enough that you can't say there are no privacy issues that going to an in-browser model would solve no privacy issues. -Peter _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
