<div class="gmail_quote">On Mon, Jun 7, 2010 at 10:17 PM, Eran Hammer-Lahav <span dir="ltr"><<a href="mailto:eran@hueniverse.com">eran@hueniverse.com</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"><br>
<br>
> -----Original Message-----<br>
> From: <a href="mailto:openid-specs-bounces@lists.openid.net">openid-specs-bounces@lists.openid.net</a> [mailto:<a href="mailto:openid-specs-">openid-specs-</a><br>
> <a href="mailto:bounces@lists.openid.net">bounces@lists.openid.net</a>] On Behalf Of John Panzer<br>
> Sent: Monday, June 07, 2010 9:47 PM<br>
<br>
> (Note that exactly the same issues arise when downloading extensions. JS is<br>
> just a way of delivering always-latest-version extensions to your browser.)<br>
<br>
</div>Only in this case, the user is in full control over what extensions are being installed and updated in its browser.<br></blockquote><div><br></div><div>In theory, perhaps. In practice the majority of users just click "okay" when offered a prompt (except for the ones that don't and miss critical security patches that leave their machines vulnerable).</div>
<div><br></div><div>I'm not saying that extensions don't offer some advantages, just that "full control" is not really accurate in practice.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
If Google, Yahoo, Microsoft, and the rest of the companies supporting the OpenID effort deployed the server-side half of this proposal, and spent a little money on developing plug-ins for all the major browsers (with Google and Microsoft able to also include it in the next release of their browser), it will create the tipping point in getting some form of identity selector in the browser.<br>
</blockquote><div><br></div><div>I am skeptical that boiling the ocean will result in anything useful, but I certainly support this effort and would be very pleasantly surprised to be proved wrong.</div><div><br></div><div>
My assertion is simply that "deploy[ing] the server-side half of this proposal..." is best expedited by making it work without the need for browser plugins (but making sure it'll work better with them). One of the issues with OpenID was that it didn't define any clean interface for browsers to hook into, and I think XAuth needs to do the opposite.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
It was one thing for the OpenID community of 3 years ago to hack the protocol around the limitations of that time. These arguments are just insincere when they come from Google, now that you have a pretty successful browser (especially considering its age) and massively huge web footprint to promote such a feature.<br>
</blockquote><div><br></div><div>The Chrome team has a lot on their plate already, and to be clear, I don't speak for them. And my arguments are quite sincere and are based on my evaluation of the empirical evidence. But I think that commitments from RPs and IdPs to implement XAuth would be very helpful in convincing Chrome and others to implement a client side solution. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
At the end, until you no longer use a script hosted in a single server, whoever is in control of this server can do whatever they like. Yes, if they do something bad it will be noticed, but that's like putting a bag full of cash on a street corner with a video camera next to it. Add to that the wealth of information the <a href="http://xauth.org" target="_blank">xauth.org</a> site operator can gather without anyone's knowledge, this becomes a scary proposition.<br>
</blockquote><div><br></div><div>I think it's reasonable to raise these concerns about administration of <a href="http://xauth.org">xauth.org</a>, and would welcome efforts to mitigate risks. It's not at all clear to me how <a href="http://xauth.org">xauth.org</a> could really gather data without anyone's knowledge -- it is trivial to verify that no data is being sent back to <a href="http://xauth.org">xauth.org</a> in normal operation, and _any_ data being sent back would be a sign of serious problems. Recording of requestor IPs (or NATted IP) and referrers for non-cached responses is of course possible but that same information is available via all types of embedded content on the Web as well. I do think that, should xauth gain enough traction to make it a useful target, it would also have enough traction to make it obvious that browser vendors should implement it. This is _not_ the argument that "they shoudl fix it" but the argument that "they will want to take advantage of this functionality anyway".</div>
<div><br></div><div>(Aside: Your DNS servers have much more information about your web footprints than <a href="http://xauth.org">xauth.org</a> will. Why aren't you scared about their operators?)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Your entire argument is that my concerns are "overblown", but not that the basic premise is incorrect. XAuth uses a single web server which is the most essential part of the proposal.</blockquote><div><br></div>
<div>Actually, XAuth uses Akamai, like a huge percentage of sites on the Internet. If you want to worry about an entity gathering usage data you really should worry about Akamai first :). It's also not essential to the core proposal, which is an API that lets IdPs provide and RPs consume user preference data. The mechanism by which they do this is clearly not essential to that.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> The fact that the data itself isn't stored on that server (say, in a cookie sent to it) is an improvement over using cookies to store this data, but not by much.<br>
</blockquote><div><br></div><div>It's actually a huge improvement, because it allows for an easy upgrade to a client-only solution in the future.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
If this was something like the gravatar service - maybe. But you are asking for blind trust in something that is core to web security and privacy.<br></blockquote><div><br></div><div>I don't believe anyone has asked for blind trust. Trust, but verify. Everything is out in the open.</div>
<div><br></div><div>Let's say I convinced the Chrome team to implement this; clearly it'd be actually implemented in the Chromium open source codebase at <a href="http://www.chromium.org">www.chromium.org</a>. But then you're really trusting the people who maintain <a href="http://www.chromium.org">www.chromium.org</a> not to play tricks -- clearly code you download via that site could be spying on you, right? (It isn't. Trust me.) </div>
<div><br></div><div>This does raise the question: Why would you trust <a href="http://www.chromium.org">www.chromium.org</a> more than <a href="http://xauth.org">xauth.org</a>, exactly? Would it help if the code for the xauth site was completely open source</div>
<div>and the source JS could be compiled and checksummed to ensure that it was the same code being served up to clients? (This would actually be more secure than a compiled Chromium browser package, I believe.)</div><div>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
EHL<br>
</font></blockquote></div><br>