On Mon, Jun 07, 2010 at 01:26:53PM -0700, John Panzer wrote: > On Mon, Jun 7, 2010 at 1:13 PM, SitG Admin > <[email protected]>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 _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
