[OpenID] FB Connect, OpenID and UX

Mon Dec 15 20:06:41 UTC 2008

You're absolutely correct Steven.
This is something that was discussed at the OpenID UX Summit.

This tension to get the sign-in experience into the page (thus avoiding
taking the user out of the current context to authenticate) versus forcing
them out of the local context and into the context of the OP is the number
one challenge facing OpenID.

Facebook Connect has an appreciable advantage because it rejects user
choice. You click a button, and it executes an experience from Facebook.com
on the current page. Though Sebastian Kupers has proposed applying the FB
Connect experience to OpenID [1], by keeping the experience within an
iframe-style interface, you lose certain affordances that are otherwise
recommended to provide users context clues to determine whether or not to
trust the webpage in front of them (i.e. the URL bar, the HTTPS lock, etc).

Now, at the UX Summit, it was agreed, and Facebook agreed to this as well,
that all authentication should be done in popup windows. It certainly is an
uncomfortable experience, but Facebook agreed that having those affordances
that I mentioned visible and available were necessary to provide at least
*some* aid in determining whether the sign in form was hosted at
facebook.com or not.

Unfortunately, since FB Connect has launched, it appears that they've
waffled on this. I've tested the TechCrunch FB Connect integration and have
seen both the popup AND the inline experience. Facebook does provide you
with a mechanism to "pop" the sign in experience if you don't "trust" the
current site, but it's unlikely that typical users will necessarily use that
feature (or, to put it another way, phishing sites will obviously leave out
that link).

Now, I've heard the argument before that if someone's going to want to
connect their Facebook account to a site, they're going to trust it,
regardless of the sign in experience. In other words, if someone is on a
site that they frequent, and somehow that site has been compromised to point
the FB Connect API to a phishing site, regardless of all the browser chrome
that you throw at someone, it will already be too late and they'll provide
their credentials to any interface put in front of them.

Unfortunately I think we're going to see people get burned with Facebook
Connect before it gets better. At the same time, Facebook at least is in the
position to legally confront such abuses, which is something terribly
lacking in the OpenID ecosystem.

While legal remedy alone cannot stem abuse, it is one tool that would
greatly enable us to innovate the user experience given all the concerns
about phishing and privacy... just as people trust the postal service to
transmit confidential documents with little more shielding than a sealed
paper envelope.

I think in order to advance this situation, we need to do much more research
about reality, about how much protection is *actually* afforded by browser
chrome affordances and derive some recommendations about the threat model in
delegated authentication models and inform OPs and RPs on how best to
communicate to users the risks, but also the benefits of the new system, and
how to teach users and communicate with them about what to expect and what
to look for when signing in to remote sites.

Chris

[1]
http://pixelsebi.com/2008-12-14/open-connect-a-ux-proposal-for-the-openstack/

On Mon, Dec 15, 2008 at 11:49 AM, Steven Livingstone-Perez <
weblivz at hotmail.com> wrote:

>  Been on other things so apologies if this was discussed in the previous
> thread on FB Connect …
>
>
>
> Perhaps I am mistaken on how FB Connect works, but today I read [1] that
> one "issue" with OpenID is that you need to GO to the provider web site to
> log in and so it's a hassle for users, whereas with FB Connect you can log
> in on that page and no redirect is required.
>
>
>
> I think we all agree that UX is one issue other than phishing that OpenID
> has had to deal with over the last few years.
>
>
>
> However, I'm slightly perturbed that FB Connect is perceived to be **
> easier** when it seems to me it is potential phishing security nightmare
> (worse than anything thrown at OpenID) in the works. Let me first apologize
> if I am off base here as I have read some of the doco and admit the devil
> can be in the detail sometimes.
>
>
>
> However, I can't imagine any secure manner (possibly, beyond something like
> CardSpace integrated into the OS) in which you can ask a user to log in via
> an **inline** browser window. I can ONLY see an absolute requirement that
> you go to your provider and get redirected back – that the web site you are
> entering the details into is the one shown in your address bar.
>
>
>
> In no time at all many of us could hack a image popup that looks like the
> FB Connect login screen. In fact even if you were 100% sure (say via a
> browser button) that the script added WAS that of FB Connect, it is trivial
> using a DIV and CSS's z-index and any number of other methods to put another
> identical window on top of that one.
>
>
>
> I am seriously seriously missing something here? I love the UX on FB
> Connect but all I see are potential security holes.
>
>
>
> IMHO OpenID should be build **into** the browsers if we want to get this
> kind of inline authentication mechanism.
>
>
>
> steven
>
> http://livz.org
>
>
>
> [1] *http://tinyurl.com/5puo96*
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>

-- 
Chris Messina
Citizen-Participant &
 Open Technology Advocate-at-Large
factoryjoe.com # diso-project.org
citizenagency.com # vidoop.com
This email is:   [ ] bloggable    [X] ask first   [ ] private
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-user-experience/attachments/20081215/b0e1033a/attachment-0002.htm>