XAuth critiques

[Peter Watkins]

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