On Mon, Jun 7, 2010 at 10:17 PM, Eran Hammer-Lahav <[email protected]>wrote:
> > > > -----Original Message----- > > From: [email protected] [mailto:openid-specs- > > [email protected]] On Behalf Of John Panzer > > Sent: Monday, June 07, 2010 9:47 PM > > > (Note that exactly the same issues arise when downloading extensions. JS > is > > just a way of delivering always-latest-version extensions to your > browser.) > > Only in this case, the user is in full control over what extensions are > being installed and updated in its browser. > 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). I'm not saying that extensions don't offer some advantages, just that "full control" is not really accurate in practice. > > 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. > 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. 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. > > 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. > 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. > > 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 xauth.org site operator can gather without > anyone's knowledge, this becomes a scary proposition. > I think it's reasonable to raise these concerns about administration of xauth.org, and would welcome efforts to mitigate risks. It's not at all clear to me how xauth.org could really gather data without anyone's knowledge -- it is trivial to verify that no data is being sent back to xauth.org 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". (Aside: Your DNS servers have much more information about your web footprints than xauth.org will. Why aren't you scared about their operators?) > > 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. 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. > 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. > It's actually a huge improvement, because it allows for an easy upgrade to a client-only solution in the future. > 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. > I don't believe anyone has asked for blind trust. Trust, but verify. Everything is out in the open. Let's say I convinced the Chrome team to implement this; clearly it'd be actually implemented in the Chromium open source codebase at www.chromium.org. But then you're really trusting the people who maintain www.chromium.org not to play tricks -- clearly code you download via that site could be spying on you, right? (It isn't. Trust me.) This does raise the question: Why would you trust www.chromium.org more than xauth.org, exactly? Would it help if the code for the xauth site was completely open source 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.) > EHL >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
