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

[Brandon Ramirez]

Comments inline...

- Brandon

Sent from my iPhone

On Dec 12, 2008, at 10:54 AM, Peter Watkins <peterw at tux.org> wrote:

> 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 strongly disagree with this statement.  OpenID carries a LOT of risk  
with it as a relying party.  You forfeit any control over the level of  
authentication and allow any old insecure provider to make security  
decisions on your behalf.  That may be acceptable for blogs or wikis,  
but not for everything.  Risk assessment is essential.

At least if I get into bed with facebook, I know what I'm dealing with.
>
>
> 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