[OpenID] Facebook Connect in 8 minutes, feat Luke Shephard

[Eran Hammer-Lahav]

The problem with this argument is your expectation that people will choose security over comfort, and that is almost never the case.

For example, when eBay and PayPal came out with support for security tokens that required you typed in a short-lived generated pin to log in, I was one of the first to try it out. VeriSign also allowed me to use the same token for my OpenID account with them. After one month I removed the feature from PayPal and eBay. I plan to remove it from my OpenID account as soon as I get around to do it. Why? Because it annoyed me more than it made me feel secure, but I have no doubt it offers better security (even with the email/text workaround, it still adds another barrier).

In addition, the Facebook Connect model is designed for the threat-level associated with the sites that use it. I don't think Facebook is trying to sell this to banks or ecommerce sites as their exclusive authentication mechanism. One of the know problems with the OpenID community is that the conflict between usability and security has never been resolved. We have multiple camps here with strong positions on both sides (and the middle) which have led to a protocol design that can accommodate both, scarifying (consistent) user experience (or at least ignoring it).

What makes Facebook Connect its potential is that it is a product designed both on security and functionality to meet the needs of a very well defined subset of sites and services. At least that is my understanding of the process Facebook followed to design it. It was not designed to be the ultimate Single-Sign-On solution platform, or to appeal to sites beyond those on the same level as Facebook itself (social, casual, and "low value" resources).

EHL



> -----Original Message-----
> From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
> Behalf Of Peter Watkins
> Sent: Friday, December 12, 2008 7:55 AM
> To: Chris Messina
> Cc: diso-project; general at openid.net List
> Subject: Re: [OpenID] Facebook Connect in 8 minutes, feat Luke Shephard
>
> On Thu, Dec 11, 2008 at 11:41:17PM -0600, Chris Messina wrote:
>
> > So, this is the kind of screencast/helpful information that we need
> about
> > OpenID and about integrating it with your site.
> > http://mashable.com/2008/12/11/facebook-connect-blog/
> >
> > They make it look so easy. And, indeed, it really seems to be.
>
> Easy, and insecure.
>
> From what I've seen[0], Facebook Connect requires you to embed a
> <script>
> tag that references a facebook.com server. You're asking your visitors
> to trust Javascript from a third party that you cannot vet, and
> therefore
> cannot trust.
>
> OpenID, by contrast, doesn't ask your users to execute any third party
> Javascript (unless you're using something like ID Selector or whatever
> it's now called, which I think is a bad idea, too).
>
> Allowing my site visitors to use OpenID poses *zero* risk from a
> security
> standpoint and a privacy standpoint. That's why we're embracing OpenID,
> and rejecting Facebook Connect.
>
> I don't think Connect *has* to be this way, at least not for Facebook
> to act as an IdP.[1] They could do something like ask RPs to embed an
> IMG
> link to facebook.com that uses HTTP redirects to make info available to
> vetted first-party JS, and then use AJAX and WS calls to communicate
> with
> the facebook backend. Connect isn't just easy for RPs, it takes the
> easy,
> and insecure route, for Facebook, too.
>
> Perhaps one answer to Connect would be for OpenID to develop an
> alternative
> that didn't violate best practice guidelines for embedding client-side
> code?
> For those who wanted an easy install and didn't care about best
> practices,
> a version of the required Javascript could be hosted on openid.net and
> utilize code running on openid.net. For those who do care, the JS<-
> >server
> interaction would be well documented so entities could host the JS and
> required server code themselves.
>
> -Peter
>
> [0] I've expressed these concerns directly to Facebook staff, without
> any
> sort of response.
>
> [1] Using something like <script> makes it much easier to embed chunks
> of HTML *and* maintain full control over the HTML. But they also could
> offer
> vetted HTML that an RP could embed if the Facebook WS said it was OK.
> Or
> pass the chunk of HTML to the RP so the RP could check it before
> embedding it.
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general