XAuth critiques

Peter Watkins peterw at tux.org
Mon Jun 7 21:27:37 UTC 2010


On Mon, Jun 07, 2010 at 01:26:53PM -0700, John Panzer wrote:
> On Mon, Jun 7, 2010 at 1:13 PM, SitG Admin
> <sysadmin at shadowsinthegarden.com>wrote:

> > Intent differs from effect. Breaking privacy to encourage browsers to fix
> > it for you is provocative, whether meant to be so or not.

> OK.  To be clear, I do not believe that XAuth breaks privacy.  

Do you mean that your current, centralized XAuth implementation doesn't break 
privacy, or that your "end game" desired XAuth would not break privacy?

> I think it would be great to have a discussion about privacy and security
> aspects of XAuth. Which should start with a discussion about what attacks
> we're worried about preventing, and how XAuth affects them.  As an example,
> there could be a security concern that knowing that I have an active session
> with Google may help phishers know which identity provider to simulate when
> I go to their site.  Or, there may be a concern that XAuth will help sites
> broadcast the fact that I have a "session" with them to the world, and thus
> expose linkages I would prefer not to have exposed.  Or there may be worries
> that XAuth would allow sites to 'spam' my list of available IdPs if they can
> get me to visit them. These are all certainly issues, but they require
> individual discussions, and it's not clear to me that moving functionality
> to the browser affects any of these issues in a fundamental way.

Exactly. That's why I ask about "current" vs "end game". Do you think those
concerns are not significant enough to say that the current XAuth "breaks" 
privacy, or do you imagine some browser-based intelligent XAuth system that 
would defend against those attacks?

If you take these privacy & security concerns seriously, why not document
them the way Mozilla's Account Manager project does?
https://wiki.mozilla.org/Labs/Weave/Identity/Account_Manager/Spec/Latest#Security_Considerations

I haven't given a lot of thought to this, but it appears to me that the
current XAuth setup isn't some rough draft of an oversimplified account
management mechanism that could easily be extended or improved. It looks
to me like a pretty mature, feature-complete system. I mean, you seem pretty
tied to some very specific HTML5 tech in XAuth, and adding more intelligence
or controls to make XAuth more "private" doesn't look very straightforward
to me. Would browsers treat postMessage() calls to an XAuth resource 
differently than other HTML5 postMessage() calls?

BTW, I think it's a little sad that Google is pushing this early centralized
model for gaining "deployment experience" when you could bake this into Chrome 
and Firefox extensions (or even release custom builds of Firefox) to test the
system with decentralized code.

-Peter



More information about the specs mailing list