<div class="gmail_quote">On Mon, Jun 7, 2010 at 2:27 PM, Peter Watkins <span dir="ltr"><<a href="mailto:peterw@tux.org">peterw@tux.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Mon, Jun 07, 2010 at 01:26:53PM -0700, John Panzer wrote:<br>
> On Mon, Jun 7, 2010 at 1:13 PM, SitG Admin<br>
> <<a href="mailto:sysadmin@shadowsinthegarden.com">sysadmin@shadowsinthegarden.com</a>>wrote:<br>
<br>
</div><div class="im">> > Intent differs from effect. Breaking privacy to encourage browsers to fix<br>
> > it for you is provocative, whether meant to be so or not.<br>
<br>
> OK. To be clear, I do not believe that XAuth breaks privacy.<br>
<br>
</div>Do you mean that your current, centralized XAuth implementation doesn't break<br>
privacy, or that your "end game" desired XAuth would not break privacy?<br></blockquote><div><br></div><div>Both. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> I think it would be great to have a discussion about privacy and security<br>
> aspects of XAuth. Which should start with a discussion about what attacks<br>
> we're worried about preventing, and how XAuth affects them. As an example,<br>
> there could be a security concern that knowing that I have an active session<br>
> with Google may help phishers know which identity provider to simulate when<br>
> I go to their site. Or, there may be a concern that XAuth will help sites<br>
> broadcast the fact that I have a "session" with them to the world, and thus<br>
> expose linkages I would prefer not to have exposed. Or there may be worries<br>
> that XAuth would allow sites to 'spam' my list of available IdPs if they can<br>
> get me to visit them. These are all certainly issues, but they require<br>
> individual discussions, and it's not clear to me that moving functionality<br>
> to the browser affects any of these issues in a fundamental way.<br>
<br>
</div>Exactly. That's why I ask about "current" vs "end game". Do you think those<br>
concerns are not significant enough to say that the current XAuth "breaks"<br>
privacy, or do you imagine some browser-based intelligent XAuth system that<br>
would defend against those attacks?<br></blockquote><div><br></div><div>I don't think they add significant risk to the status quo. Note that it is today possible for a rogue RP and rogue IdP to collude to leak your identity with or without XAuth. XAuth provides mechanisms to allow IdPs to whitelist the RPs they'll expose information to. IdPs can also require user opt-in to turn on XAuth. I don't think it's that useful to require opt-in for services used by more than 50% of the population, but it could be useful for <a href="http://myownname.com">myownname.com</a> personal IdP. I think that browser support would make some things easier -- perhaps defending against "pretend" IdPs that use social engineering to get themselves on your IdP list -- but (a) those attacks aren't privacy issues and (b) they appear low value to me. </div>
<div><br></div><div>I will agree that things would be more secure if we encased every client computer in concrete with no 'net connection and sank them to the bottom of the ocean. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
If you take these privacy & security concerns seriously, why not document<br>
them the way Mozilla's Account Manager project does?<br>
<a href="https://wiki.mozilla.org/Labs/Weave/Identity/Account_Manager/Spec/Latest#Security_Considerations" target="_blank">https://wiki.mozilla.org/Labs/Weave/Identity/Account_Manager/Spec/Latest#Security_Considerations</a></blockquote>
<div><br></div><div>Sir, I am but one man. And XAuth isn't even my project. But yes, I think that <a href="http://groups.google.com/group/xauth">http://groups.google.com/group/xauth</a> should discuss security considerations and document them. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
I haven't given a lot of thought to this, but it appears to me that the<br>
current XAuth setup isn't some rough draft of an oversimplified account<br>
management mechanism that could easily be extended or improved. It looks<br>
to me like a pretty mature, feature-complete system. I mean, you seem pretty<br>
tied to some very specific HTML5 tech in XAuth, and adding more intelligence<br>
or controls to make XAuth more "private" doesn't look very straightforward<br>
to me. Would browsers treat postMessage() calls to an XAuth resource<br>
differently than other HTML5 postMessage() calls?<br></blockquote><div><br></div><div>No. I'm envisioning that browsers would directly replace the higher-level JS API so there would be no postMessage() calls at all. Why would there need to be? The providers just need to call setters and the relying parties to call getters (or queriers).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
BTW, I think it's a little sad that Google is pushing this early centralized<br>
model for gaining "deployment experience" when you could bake this into Chrome<br>
and Firefox extensions (or even release custom builds of Firefox) to test the<br>
system with decentralized code.<br></blockquote><div><br></div><div>Sure, we could host extensions at <a href="http://xauth.org">xauth.org</a>. And then people could download them. From, um, a centralized site. How is that more decentralized exactly?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
-Peter<br>
<br>
</font></blockquote></div><br>