<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Yahoo recently finished a usability study in which nearly all of the
participants successfully signed into a large newspaper website using a
prototype version of the Yahoo OpenID Provider that used a popup for
authentication.<br>
<br>
I'm trying to see if we can publicly release the detailed results of
the study, but suffice to say, the results far exceeded expectations
and we believe that the popup will dramatically increase the success
rate for signing in with OpenID.<br>
<br>
Allen<br>
<br>
Ben Clemens wrote:
<blockquote cite="mid:C5F24DB0.562B%25bclemens@currentmedia.com"
type="cite">
<title>Re: Address Bar</title>
<font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">Amen to that. Our testing has shown an almost
instinctive aversion to popups, though I understand why & am
implementing them for auth here...<br>
<br>
<br>
On 3/27/09 9:09 AM, "Chris Messina" <<a moz-do-not-send="true"
href="chris.messina@gmail.com">chris.messina@gmail.com</a>> wrote:<br>
<br>
</span></font>
<blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">On Fri, Mar 27, 2009 at 10:09 AM, Breno de
Medeiros <<a moz-do-not-send="true" href="breno@google.com">breno@google.com</a>>
wrote:<br>
</span></font>
<blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">This analysis (made in 2004) does not take in
account the proliferation of popup blockers that have significantly
reduced the prevalence of such bad, unsolicited popup ads they refer
to. Remember the "Your computer is infected with a virus!"? <br>
</span></font></blockquote>
<font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"><br>
Actually, that's not the whole story. On page 9 they mention:<br>
<br>
</span></font>
<blockquote>
<blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">A final argument against any pop-ups is that
many web browsers, plug-ins, toolbars, <br>
and other technologies block pop-ups or otherwise make them less likely
to be seen <br>
by users who have installed such technologies. Pop-up blockers are
getting to be <br>
more popular (because of users’ negative experience with pop-ups) and
will become <br>
a standard component of Internet Explorer — the most commonly used
browser. <br>
</span></font></blockquote>
</blockquote>
<font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"><br>
I think it IS true that many popups have gone away because they've
become less effective at tricking users. There's still plenty of
popunder ads that exist — and that are created by user actions, such as
clicks, that are much harder to ban.<br>
<br>
<br>
</span></font>
<blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">My recent experience with popups is that they
are used fairly infrequently, and often for login purposes, typically
in syndicated enterprise services.<br>
</span></font></blockquote>
<font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"><br>
For the UI Working Group that was just voted to proceed, we must make
user testing a priority with this work, to verify that common
perceptions of popups have changed, or at least won't diminish the
usefulness of our work.<br>
<br>
Chris<br>
<br>
</span></font>
<blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"><br>
<br>
On Thu, Mar 26, 2009 at 1:54 PM, Chris Messina <<a
moz-do-not-send="true" href="chris.messina@gmail.com">chris.messina@gmail.com</a>>
wrote:<br>
</span></font>
<blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">Here's the VbV example UI:<br>
<br>
<a moz-do-not-send="true"
href="http://www.flickr.com/photos/factoryjoe/142616582/">http://www.flickr.com/photos/factoryjoe/142616582/</a><br>
<br>
Apparently VbV has been used in previous scams:<br>
<br>
<a moz-do-not-send="true"
href="http://www.hoax-slayer.com/verified-by-visa-scam.shtml">http://www.hoax-slayer.com/verified-by-visa-scam.shtml</a><br>
<br>
In 2005, one of the VbV program heads said [1]:<br>
<br>
"Verified by Visa is a program that Visa eliminates online payment
fraud liability for online merchants who provide a mechanism in their
checkout process that lets shoppers enter a special Verified by Visa
cardholder authentication password provided by a Visa card issuer.
About 4 million out of 230 million eligible Visa cards issued in the
U.S. are registered in the Verified by Visa program, and about 25,000
merchants participate in the program worldwide."<br>
<br>
It actually sounds like the envisioned an OAuth-like pre-registration
solution:<br>
<br>
"To make the Verified by Visa program more effective and widespread,
Visa is looking into a system under which a card issuer could require a
cardholder to register for the program before completing an online
checkout process. Under the current system, card issuers can only
produce messages in the checkout process that offer unregistered
cardholders the option of signing up and creating a Verified by Visa
password. The new system could include a software component that would
rate the risk level of a particular cardholder transaction–based on
criteria such as the cardholder’s location or credit history–in
determining whether to require the cardholder to register for Verified
by Visa."<br>
<br>
More details for personal use of VbV: <a moz-do-not-send="true"
href="https://usa.visa.com/personal/security/vbv/index.html">https://usa.visa.com/personal/security/vbv/index.html</a><br>
For merchants: <a moz-do-not-send="true"
href="http://usa.visa.com/merchants/risk_management/vbv.html">http://usa.visa.com/merchants/risk_management/vbv.html</a><br>
<br>
What's most interesting/relevant to us is the Nielson Norman design
document with usability recommendations for implementing VbV. Mind you,
these recommendations are from *2004*. Oh my word:<br>
<br>
</span></font>
<blockquote>
<blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">Our evaluation supports Visa’s plan to
eliminate the use of pop-up windows. Pop-up <br>
windows are mostly perceived negatively by users and often result in
disastrous <br>
usability outcomes. People often associate pop-up windows with
advertisement or <br>
superfluous content that is unrelated to their immediate task at hand.
They are <br>
intrusive, and startling. They make users feel that they are being
advertised to, <br>
rather than informed. People often immediately close pop-ups or even
worse <br>
struggle with them and lose their place on the website. <br>
</span></font></blockquote>
</blockquote>
<font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"> <br>
</span></font>
<blockquote>
<blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">Embedding Verified by Visa in HTML-based
pages is a better strategy than opening a <br>
new window of any size on top of the launching web page’s window. The
embedded <br>
approach prevents people from accidentally clicking outside the parent
browser <br>
window and thus burying the new window underneath it. We’ve seen users
in other <br>
studies make this error over and over again then they can’t find
their way back to <br>
the parent window and conclude that they had lost their data. Also,
many people <br>
don’t see the application window’s icon at the bottom of the screen. <br>
</span></font></blockquote>
</blockquote>
<font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"><br>
and:<br>
<br>
</span></font>
<blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"><b>The Frame Method preserves context<br>
</b>When pages look similar, people know they’re still on the
same site. Pages that look <br>
dramatically different are jarring and make people wonder if they’re on
the right <br>
page or even on the right website. Preserving context offers an
integrated <br>
experience that eases people through the signup and checkout process,
which is <br>
critical in minimizing abandonment. <br>
<br>
We usually recommend against using traditional frames because of
problems such as <br>
printing and bookmarking. However, in this case, it is acceptable since
most people <br>
will not need to print or bookmark Verified by Visa screens — and the
benefit of <br>
having some branding far outweighs the disadvantages of not having any.
<br>
</span></font></blockquote>
<font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"> <br>
Read it: <a moz-do-not-send="true"
href="http://usa.visa.com/download/merchants/usability_recommendations.pdf">http://usa.visa.com/download/merchants/usability_recommendations.pdf</a><br>
<br>
Chris<br>
<br>
[1] <a moz-do-not-send="true"
href="http://www.internetretailer.com/internet/marketing-conference/22592-verified-visa-security-program-used-as-bait-phishing-scams.html">http://www.internetretailer.com/internet/marketing-conference/22592-verified-visa-security-program-used-as-bait-phishing-scams.html</a><br>
<br>
<br>
On Thu, Mar 26, 2009 at 8:04 AM, Breno <<a moz-do-not-send="true"
href="breno.demedeiros@gmail.com">breno.demedeiros@gmail.com</a>>
wrote:<br>
</span></font>
<blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">The idea is that you must trust the site with
your verified by visa<br>
credentials to start with.<br>
<br>
On Thu, Mar 26, 2009 at 5:00 AM, Ben Laurie <<a
moz-do-not-send="true" href="benl@google.com">benl@google.com</a>>
wrote:<br>
> On Thu, Mar 26, 2009 at 1:29 AM, Breno <<a
moz-do-not-send="true" href="breno.demedeiros@gmail.com">breno.demedeiros@gmail.com</a>>
wrote:<br>
>> I think we are stretching this analogy to the breaking point.<br>
>><br>
>> Visa Payment Trust Model vs OpenID Trust Model.<br>
>><br>
>> Visa Payments: User trusts parent frame (merchant/bank) with<br>
>> credentials (credit card)<br>
>> OpenID: User does not necessarily trust parent frame (RP) with
that<br>
>> particular set of credentials (own credentials at the OP)<br>
>><br>
>> Visa Payments: User does not necessarily trust the framed site<br>
>> (payment processor) with his credentials because of lack of
brand<br>
>> recognition.<br>
>> OpenID: User trusts the iframed site (OP) with this particular
set of<br>
>> credentials.<br>
>><br>
>> Visa Payments: Parent frame (merchant/bank) has explicit
agreement<br>
>> with payment processor and wishes to leverage the user's trust
in the<br>
>> merchant to have him/her enter this credentials at the
processor.<br>
>> OpenID: No explicit agreement between RP and OP.<br>
>><br>
>><br>
>> So the iframe in Visa Payments is the mechanism by which one<br>
>> accomplishes a transfer of trust (user -> merchant/bank)
--> (user -><br>
>> payment processor), and this is covered by legal agreements.<br>
>> Accordingly, the burden on the user to protect him/herself
against<br>
>> phishing is simply to recognize the merchant/bank site.
Iframing is<br>
>> the appropriate mechanism in this case.<br>
><br>
> I totally don't understand this. When the "merchant" is a phishing<br>
> site whose purpose is to get my "verified by visa" password, what<br>
> legal agreement is protecting me?<br>
><br>
>><br>
>> In the case of OpenID, iframing requires that the user
transfers (user<br>
>> -> OP) --> (user -> RP). This implies that the OP is
leveraging its<br>
>> brand identity (in the login box) to convey trust to the user
in the<br>
>> RP (including trust in releasing own OP's credentials there).
There is<br>
>> no contractual framework in OpenID to allow that. The user is
burdened<br>
>> with the need to recognize that the iframe points to the OP.<br>
>><br>
>> That is not to be said that the analogy is _never_ good. If
the OP<br>
>> implements non-spoofable authentication (e.g., token-based
auth), then<br>
>> the trust transference is not required. However, for OP that
accept<br>
>> password-based authentication, the iframe model does not work
without<br>
>> an explicit (and publicly recognizable by the user base) mutual<br>
>> agreement.<br>
>><br>
>><br>
>> On Wed, Mar 25, 2009 at 5:23 PM, jDavid <jdavid.net <<a
moz-do-not-send="true" href="http://jdavid.net">http://jdavid.net</a>>
@gmail.com <<a moz-do-not-send="true" href="http://gmail.com">http://gmail.com</a>>
> wrote:<br>
>>> I wonder if the story for HTTPS/SSL is a good one for us
to look at?<br>
>>><br>
>>> or did it just happen so early in browser life that it was
easy?<br>
>>><br>
>>> 2009/3/25 Johannes Ernst <jernst+openid.net <<a
moz-do-not-send="true" href="http://openid.net">http://openid.net</a>>
@netmesh.us <<a moz-do-not-send="true" href="http://netmesh.us">http://netmesh.us</a>>
><br>
>>>><br>
>>>> This is really interesting.<br>
>>>><br>
>>>> It seems to me that we are struggling with a problem
that is in no way<br>
>>>> specific to OpenID. It sounds like we should try and
get everybody in a room<br>
>>>> that has the same problem -- like Visa in this example
-- regardless of<br>
>>>> whether they have ever heard of or like OpenID, and
come up with:<br>
>>>><br>
>>>> 1. this is the best we can do with existing browsers,
and we all educate<br>
>>>> the user the same way about the flow<br>
>>>><br>
>>>> 2. a wish list for the browser companies how to offer
better browser<br>
>>>> support natively for this particular pattern. Some
generic pattern markup<br>
>>>> (not OpenID-specific, but for the redirect pattern)
might be advantageous.<br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> On Mar 25, 2009, at 10:57, Martin Atkins wrote:<br>
>>>><br>
>>>>> Allen Tom wrote:<br>
>>>>>><br>
>>>>>> Do you have more details about the verified by
visa process? I'm not<br>
>>>>>> familiar with it.<br>
>>>>>> I actually bought something online this
morning, and I noticed that the<br>
>>>>>> merchant's checkout confirmation page
mentioned something about portions of<br>
>>>>>> the screen being rendered by my credit card
issuer in an iframe, which I<br>
>>>>>> thought was a weird thing to tell to the end
user.<br>
>>>>><br>
>>>>> I'm by no means an expert on 3D-Secure (which is
the technology<br>
>>>>> underlying Verified By Visa), but the flow seems
very similar to OpenID:<br>
>>>>><br>
>>>>> * Merchant does "discovery" on your credit card to
find out who your<br>
>>>>> provider is.<br>
>>>>><br>
>>>>> * Merchant sends you to that provider where the
provider authenticates<br>
>>>>> you by some means -- in my case, I get asked to
enter three letters out of a<br>
>>>>> secret word and some other security questions, but
I assume this varies from<br>
>>>>> provider to provider -- and sends an assertion
back to the merchant.<br>
>>>>><br>
>>>>> * The merchant recieves the assertion and
processes the transaction.<br>
>>>>><br>
>>>>> The ever-reliable Wikipedia tells me that the
Verified By Visa brand of<br>
>>>>> the protocol recommends loading the provider's UI
in an iframe in order to<br>
>>>>> *stop* users seeing the address bar, because many
savvy users mistook it for<br>
>>>>> a phishing scam:<br>
>>>>> <a moz-do-not-send="true"
href="http://ambrand.com/2006/09/06/is-securesuitecouk-a-phishing-scam/">http://ambrand.com/2006/09/06/is-securesuitecouk-a-phishing-scam/</a><br>
>>>>><br>
>>>>> (one might argue that this would be less of an
issue if the issuing banks<br>
>>>>> served the data in their own domain rather than
outsourcing it, but I<br>
>>>>> digress.)<br>
>>>>><br>
>>>>> The "criticism" section of the Wikipedia page on
3D-secure details a<br>
>>>>> bunch of problems that OpenID implementors have
also encountered.<br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> user-experience mailing list<br>
>>>>> <a moz-do-not-send="true"
href="user-experience@openid.net">user-experience@openid.net</a><br>
>>>>> <a moz-do-not-send="true"
href="http://openid.net/mailman/listinfo/user-experience">http://openid.net/mailman/listinfo/user-experience</a><br>
>>>><br>
>>>><br>
>>>><br>
>>>> Johannes Ernst<br>
>>>> NetMesh Inc.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> <a moz-do-not-send="true"
href="http://netmesh.info/jernst">http://netmesh.info/jernst</a><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> user-experience mailing list<br>
>>>> <a moz-do-not-send="true"
href="user-experience@openid.net">user-experience@openid.net</a><br>
>>>> <a moz-do-not-send="true"
href="http://openid.net/mailman/listinfo/user-experience">http://openid.net/mailman/listinfo/user-experience</a><br>
>>>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> --<br>
>>> Justin Kruger -- Sr. Software Engineer - MySpace MDP<br>
>>> <a moz-do-not-send="true" href="http://jDavid.net">http://jDavid.net</a><br>
>>> <a moz-do-not-send="true" href="jDavid.net@gmail.com">jDavid.net@gmail.com</a><br>
>>><br>
>>> Anton Freeman: Vincent! How are you doing this Vincent?
How have you done<br>
>>> any of this? We have to go back.<br>
>>> Vincent: It's too late for that. We're closer to the other
side.<br>
>>> Anton Freeman: What other side? You wanna drown us both?<br>
>>> Vincent: You wanna know how I did it? This is how I did it
Anton. I never<br>
>>> saved anything for the swim back.<br>
>>><br>
>>> _______________________________________________<br>
>>> user-experience mailing list<br>
>>> <a moz-do-not-send="true"
href="user-experience@openid.net">user-experience@openid.net</a><br>
>>> <a moz-do-not-send="true"
href="http://openid.net/mailman/listinfo/user-experience">http://openid.net/mailman/listinfo/user-experience</a><br>
>>><br>
>>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Breno de Medeiros<br>
>> _______________________________________________<br>
>> user-experience mailing list<br>
>> <a moz-do-not-send="true" href="user-experience@openid.net">user-experience@openid.net</a><br>
>> <a moz-do-not-send="true"
href="http://openid.net/mailman/listinfo/user-experience">http://openid.net/mailman/listinfo/user-experience</a><br>
>><br>
> _______________________________________________<br>
> user-experience mailing list<br>
> <a moz-do-not-send="true" href="user-experience@openid.net">user-experience@openid.net</a><br>
> <a moz-do-not-send="true"
href="http://openid.net/mailman/listinfo/user-experience">http://openid.net/mailman/listinfo/user-experience</a><br>
><br>
<br>
<br>
<br>
--<br>
Breno de Medeiros<br>
_______________________________________________<br>
user-experience mailing list<br>
<a moz-do-not-send="true" href="user-experience@openid.net">user-experience@openid.net</a><br>
<a moz-do-not-send="true"
href="http://openid.net/mailman/listinfo/user-experience">http://openid.net/mailman/listinfo/user-experience</a><br>
</span></font></blockquote>
<font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"><br>
<br>
</span></font></blockquote>
</blockquote>
</blockquote>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
user-experience mailing list
<a class="moz-txt-link-abbreviated" href="mailto:user-experience@openid.net">user-experience@openid.net</a>
<a class="moz-txt-link-freetext" href="http://openid.net/mailman/listinfo/user-experience">http://openid.net/mailman/listinfo/user-experience</a>
</pre>
</blockquote>
<br>
</body>
</html>