<div class="gmail_quote">On Mon, Jun 7, 2010 at 7:35 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 04:38:11PM -0700, John Panzer wrote:<br>
> On Mon, Jun 7, 2010 at 2:27 PM, Peter Watkins <<a href="mailto:peterw@tux.org">peterw@tux.org</a>> wrote:<br>
</div><div class="im">> > Do you mean that your current, centralized XAuth implementation doesn't<br>
> > break<br>
> > privacy, or that your "end game" desired XAuth would not break privacy?<br>
<br>
> Both.<br>
<br>
</div>Thanks for clarifying.<br>
<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<br>
> > example,<br>
> > > there could be a security concern that knowing that I have an active<br>
> > session<br>
> > > with Google may help phishers know which identity provider to simulate<br>
> > when<br>
</div>> > > I go to their site. Or, ....<br>
<div class="im"><br>
> > 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<br>
</div><div class="im">> > would defend against those attacks?<br>
<br>
> I don't think they add significant risk to the status quo. Note that it is<br>
> today possible for a rogue RP and rogue IdP to collude to leak your identity<br>
> with or without XAuth. XAuth provides mechanisms to allow IdPs to whitelist<br>
> the RPs they'll expose information to.<br>
<br>
</div>Whitelists again? Ugh. Chris had that nice video explaining how XAuth could<br>
put a few IdPs up their in a short, relevant list of choices. Now you're<br>
saying to make privacy OK, IdPs have to whitelist RP sites? That sounds<br>
like a mess, and like a much weaker and less interesting approach to improving<br>
the UX than I expected. And why would the IdP be in the business of<br>
whitelisting? It's more likely, as I've said in other threads, that the<br>
end user would want to control what information was sent to each RP.<br></blockquote><div><br></div><div>What makes you think their IdP wouldn't be doing this based on the user's preferences?</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 that browser support would make some<br>
> things easier -- perhaps defending against "pretend" IdPs that use social<br>
> engineering to get themselves on your IdP list -- but (a) those attacks<br>
> aren't privacy issues and (b) they appear low value to me.<br>
<br>
</div>What social engineering? Getting you to open a page with an XAuth iframe?<br>
That sounds like a relatively easy attack to carry out, esp. in the era<br>of tinyurl and <a href="http://bit.ly" target="_blank">bit.ly</a>.<br></blockquote><div><br>And if successful, it gets the attacker a slightly annoying link with a big glowing verified pointer back to their web site. I hope spammers do attempt this; it'll be much easier to combat than other things they do today.</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 will agree that things would be more secure if we encased every client<br>
> computer in concrete with no 'net connection and sank them to the bottom of<br>
> the ocean.<br>
<br>
</div>Excuse me?<br></blockquote><div><br></div><div>My somewhat flippant point was that eliminating all possible risks also eliminates all possible usefulness.</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 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<br>
> > pretty<br>
> > tied to some very specific HTML5 tech in XAuth<br>
<br>
</div><div class="im">> No. I'm envisioning that browsers would directly replace the higher-level<br>
> JS API so there would be no postMessage() calls at all. Why would there<br>
> need to be? The providers just need to call setters and the relying parties<br>
> to call getters (or queriers).<br>
<br>
</div>Ah, looking at your (Google's) current XAuth materials, I don't get the<br>
sense of this changing.<br>
<div class="im"><br>
> > BTW, I think it's a little sad that Google is pushing this early<br>
> > centralized<br>
> > model for gaining "deployment experience" when you could bake this into<br>
> > Chrome<br>
> > and Firefox extensions (or even release custom builds of Firefox) to test<br>
> > the<br>
> > system with decentralized code.<br>
<br>
> Sure, we could host extensions at <a href="http://xauth.org" target="_blank">xauth.org</a>. And then people could download<br>
> them. From, um, a centralized site. How is that more decentralized<br>
> exactly?<br>
<br>
</div>Users could vet the code and not worry about it changing on them the way it<br>
could from a SaaS site like <a href="http://xauth.org" target="_blank">xauth.org</a>.</blockquote><div><br></div><div>Of course regular users are not going to vet the code. And <a href="http://xauth.org">xauth.org</a> is not a SaaS site. It's just a stock web server.</div>
<div><br></div><div>But yes, it would be better for _security in the long run_ to have this code be baked into an otherwise trusted download (like the browser). It is not necessary to do this to start with, and indeed is a very bad idea while the APIs are still in flux.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <a href="http://xauth.org" target="_blank">xauth.org</a> would have no indication<br>
whatsoever that a user was interacting with XAuth-compatible Extenders or<br>
Receivers.</blockquote><div><br></div><div>Not sure what you're saying here. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> And if you use a decent license (or write a nice spec), anyone<br>
else could implement their own extension. Including IE extensions, I don't<br>
know why I omitted IE from my list.<br></blockquote><div><br></div><div>Absolutely -- if the OWFa isn't the stated goal for xauth, it should be. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
I'll post this on the xauth group now, too, but for instance currently the<br>
<a href="http://xauth.org" target="_blank">xauth.org</a> site is not accessible via a https URL (at least not one that<br>
passes normal CN/hostname checks), so a malicious wifi hotspot operator<br>
could intercept traffic and do interesting things like read that shared<br>
LocalStorage even if all the normal RP and IdP traffic was https. Switch<br>
to an in-browser model and that hole, and others, disappear.<br>
<font color="#888888"><br></font></blockquote><div><br></div><div>Heh. They're currently using Akamai to mitigate SPOF issues and Akamai is responding to SSL requests as *.<a href="http://akamai.net">akamai.net</a> hosts. Obviously this configuration issue will be fixed.</div>
<div><br></div><div>(Note that exactly the same issues arise when downloading extensions. JS is just a way of delivering always-latest-version extensions to your browser.)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888">
-Peter<br>
<br>
</font></blockquote></div><br>