Address Bar

Fri Mar 27 16:32:30 UTC 2009

Amen to that. Our testing has shown an almost instinctive aversion to
popups, though I understand why & am implementing them for auth here...

On 3/27/09 9:09 AM, "Chris Messina" <chris.messina at gmail.com> wrote:

> On Fri, Mar 27, 2009 at 10:09 AM, Breno de Medeiros <breno at google.com> wrote:
>> 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!"? 
> 
> Actually, that's not the whole story. On page 9 they mention:
> 
>>> A final argument against any pop-ups is that many web browsers, plug-ins,
>>> toolbars, 
>>> and other technologies block pop-ups or otherwise make them less likely to
>>> be seen 
>>> by users who have installed such technologies. Pop-up blockers are getting
>>> to be 
>>> more popular (because of users’ negative experience with pop-ups) and will
>>> become 
>>> a standard component of Internet Explorer — the most commonly used browser.
>>>  
> 
> 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.
> 
>  
>> My recent experience with popups is that they are used fairly infrequently,
>> and often for login purposes, typically in syndicated enterprise services.
> 
> 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.
> 
> Chris
>  
>> 
>> 
>> On Thu, Mar 26, 2009 at 1:54 PM, Chris Messina <chris.messina at gmail.com>
>> wrote:
>>> Here's the VbV example UI:
>>> 
>>> http://www.flickr.com/photos/factoryjoe/142616582/
>>> 
>>> Apparently VbV has been used in previous scams:
>>> 
>>> http://www.hoax-slayer.com/verified-by-visa-scam.shtml
>>> 
>>> In 2005, one of the VbV program heads said [1]:
>>> 
>>> "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."
>>> 
>>> It actually sounds like the envisioned an OAuth-like pre-registration
>>> solution:
>>> 
>>> "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."
>>> 
>>> More details for personal use of
>>> VbV: https://usa.visa.com/personal/security/vbv/index.html
>>> For merchants: http://usa.visa.com/merchants/risk_management/vbv.html
>>> 
>>> 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:
>>> 
>>>>> Our evaluation supports Visa’s plan to eliminate the use of pop-up
>>>>> windows. Pop-up 
>>>>> windows are mostly perceived negatively by users and often result in
>>>>> disastrous 
>>>>> usability outcomes. People often associate pop-up windows with
>>>>> advertisement or 
>>>>> superfluous content that is unrelated to their immediate task at hand.
>>>>> They are 
>>>>> intrusive, and startling. They make users feel that they are being
>>>>> advertised to, 
>>>>> rather than informed. People often immediately close pop-ups or even
>>>>> worse 
>>>>> struggle with them and lose their place on the website.   
>>>  
>>>>> Embedding Verified by Visa in HTML-based pages is a better strategy than
>>>>> opening a 
>>>>> new window of any size on top of the launching web page’s window. The
>>>>> embedded 
>>>>> approach prevents people from accidentally clicking outside the parent
>>>>> browser 
>>>>> window and thus burying the new window underneath it. We’ve seen users in
>>>>> other 
>>>>> studies make this error over and over again  then they can’t find their
>>>>> way back to 
>>>>> the parent window and conclude that they had lost their data. Also, many
>>>>> people 
>>>>> don’t see the application window’s icon at the bottom of the screen.  
>>> 
>>> and:
>>> 
>>>> The Frame Method preserves context
>>>> When pages look similar, people know they’re still on the same site. Pages
>>>> that look 
>>>> dramatically different are jarring and make people wonder if they’re on the
>>>> right 
>>>> page or even on the right website. Preserving context offers an integrated 
>>>> experience that eases people through the signup and checkout process, which
>>>> is 
>>>> critical in minimizing abandonment.  
>>>> 
>>>> We usually recommend against using traditional frames because of problems
>>>> such as 
>>>> printing and bookmarking. However, in this case, it is acceptable since
>>>> most people 
>>>> will not need to print or bookmark Verified by Visa screens — and the
>>>> benefit of 
>>>> having some branding far outweighs the disadvantages of not having any.  
>>>  
>>> Read it: 
>>> http://usa.visa.com/download/merchants/usability_recommendations.pdf
>>> 
>>> Chris
>>> 
>>> [1] http://www.internetretailer.com/internet/marketing-conference/22592-veri
>>> fied-visa-security-program-used-as-bait-phishing-scams.html
>>> 
>>> 
>>> On Thu, Mar 26, 2009 at 8:04 AM, Breno <breno.demedeiros at gmail.com> wrote:
>>>> The idea is that you must trust the site with your verified by visa
>>>> credentials to start with.
>>>> 
>>>> On Thu, Mar 26, 2009 at 5:00 AM, Ben Laurie <benl at google.com> wrote:
>>>>> > On Thu, Mar 26, 2009 at 1:29 AM, Breno <breno.demedeiros at gmail.com>
>>>>> wrote:
>>>>>> >> I think we are stretching this analogy to the breaking point.
>>>>>> >>
>>>>>> >> Visa Payment Trust Model   vs OpenID Trust Model.
>>>>>> >>
>>>>>> >> Visa Payments: User trusts parent frame (merchant/bank) with
>>>>>> >> credentials (credit card)
>>>>>> >> OpenID: User does not necessarily trust parent frame (RP) with that
>>>>>> >> particular set of credentials (own credentials at the OP)
>>>>>> >>
>>>>>> >> Visa Payments: User does not necessarily trust the framed site
>>>>>> >> (payment processor) with his credentials because of lack of brand
>>>>>> >> recognition.
>>>>>> >> OpenID: User trusts the iframed site (OP) with this particular set of
>>>>>> >> credentials.
>>>>>> >>
>>>>>> >> Visa Payments: Parent frame (merchant/bank) has explicit agreement
>>>>>> >> with payment processor and wishes to leverage the user's trust in the
>>>>>> >> merchant to have him/her enter this credentials at the processor.
>>>>>> >> OpenID: No explicit agreement between RP and OP.
>>>>>> >>
>>>>>> >>
>>>>>> >> So the iframe in Visa Payments is the mechanism by which one
>>>>>> >> accomplishes a transfer of trust (user -> merchant/bank) --> (user ->
>>>>>> >> payment processor), and this is covered by legal agreements.
>>>>>> >> Accordingly, the burden on the user to protect him/herself against
>>>>>> >> phishing is simply to recognize the merchant/bank site. Iframing is
>>>>>> >> the appropriate mechanism in this case.
>>>>> >
>>>>> > I totally don't understand this. When the "merchant" is a phishing
>>>>> > site whose purpose is to get my "verified by visa" password, what
>>>>> > legal agreement is protecting me?
>>>>> >
>>>>>> >>
>>>>>> >> In the case of OpenID, iframing requires that the user transfers (user
>>>>>> >> -> OP) --> (user -> RP). This implies that the OP is leveraging its
>>>>>> >> brand identity (in the login box) to convey trust to the user in the
>>>>>> >> RP (including trust in releasing own OP's credentials there). There is
>>>>>> >> no contractual framework in OpenID to allow that. The user is burdened
>>>>>> >> with the need to recognize that the iframe points to the OP.
>>>>>> >>
>>>>>> >> That is not to be said that the analogy is _never_ good. If the OP
>>>>>> >> implements non-spoofable authentication (e.g., token-based auth), then
>>>>>> >> the trust transference is not required. However, for OP that accept
>>>>>> >> password-based authentication, the iframe model does not work without
>>>>>> >> an explicit (and publicly recognizable by the user base) mutual
>>>>>> >> agreement.
>>>>>> >>
>>>>>> >>
>>>>>> >> On Wed, Mar 25, 2009 at 5:23 PM, jDavid <jdavid.net
>>>>>> <http://jdavid.net> @gmail.com <http://gmail.com> > wrote:
>>>>>>> >>> I wonder if the story for HTTPS/SSL is a good one for us to look at?
>>>>>>> >>>
>>>>>>> >>> or did it just happen so early in browser life that it was easy?
>>>>>>> >>>
>>>>>>> >>> 2009/3/25 Johannes Ernst <jernst+openid.net <http://openid.net>
>>>>>>> @netmesh.us <http://netmesh.us> >
>>>>>>>> >>>>
>>>>>>>> >>>> This is really interesting.
>>>>>>>> >>>>
>>>>>>>> >>>> It seems to me that we are struggling with a problem that is in no
way
>>>>>>>> >>>> specific to OpenID. It sounds like we should try and get everybody
>>>>>>>> in a room
>>>>>>>> >>>> that has the same problem -- like Visa in this example --
>>>>>>>> regardless of
>>>>>>>> >>>> whether they have ever heard of or like OpenID, and come up with:
>>>>>>>> >>>>
>>>>>>>> >>>> 1. this is the best we can do with existing browsers, and we all
>>>>>>>> educate
>>>>>>>> >>>> the user the same way about the flow
>>>>>>>> >>>>
>>>>>>>> >>>> 2. a wish list for the browser companies how to offer better
>>>>>>>> browser
>>>>>>>> >>>> support natively for this particular pattern. Some generic pattern
>>>>>>>> markup
>>>>>>>> >>>> (not OpenID-specific, but for the redirect pattern) might be
>>>>>>>> advantageous.
>>>>>>>> >>>>
>>>>>>>> >>>>
>>>>>>>> >>>>
>>>>>>>> >>>>
>>>>>>>> >>>> On Mar 25, 2009, at 10:57, Martin Atkins wrote:
>>>>>>>> >>>>
>>>>>>>>> >>>>> Allen Tom wrote:
>>>>>>>>>> >>>>>>
>>>>>>>>>> >>>>>> Do you have more details about the verified by visa process?
>>>>>>>>>> I'm not
>>>>>>>>>> >>>>>> familiar with it.
>>>>>>>>>> >>>>>> I actually bought something online this morning, and I noticed
>>>>>>>>>> that the
>>>>>>>>>> >>>>>> merchant's checkout confirmation page mentioned something
>>>>>>>>>> about portions of
>>>>>>>>>> >>>>>> the screen being rendered by my credit card issuer in an
>>>>>>>>>> iframe, which I
>>>>>>>>>> >>>>>> thought was a weird thing to tell to the end user.
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> I'm by no means an expert on 3D-Secure (which is the technology
>>>>>>>>> >>>>> underlying Verified By Visa), but the flow seems very similar to
>>>>>>>>> OpenID:
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> * Merchant does "discovery" on your credit card to find out who
your
>>>>>>>>> >>>>> provider is.
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> * Merchant sends you to that provider where the provider
>>>>>>>>> authenticates
>>>>>>>>> >>>>> you by some means -- in my case, I get asked to enter three
>>>>>>>>> letters out of a
>>>>>>>>> >>>>> secret word and some other security questions, but I assume this
>>>>>>>>> varies from
>>>>>>>>> >>>>> provider to provider -- and sends an assertion back to the
>>>>>>>>> merchant.
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> * The merchant recieves the assertion and processes the
>>>>>>>>> transaction.
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> The ever-reliable Wikipedia tells me that the Verified By Visa
>>>>>>>>> brand of
>>>>>>>>> >>>>> the protocol recommends loading the provider's UI in an iframe
>>>>>>>>> in order to
>>>>>>>>> >>>>> *stop* users seeing the address bar, because many savvy users
>>>>>>>>> mistook it for
>>>>>>>>> >>>>> a phishing scam:
>>>>>>>>> >>>>> 
>>>>>>>>> http://ambrand.com/2006/09/06/is-securesuitecouk-a-phishing-scam/
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> (one might argue that this would be less of an issue if the
>>>>>>>>> issuing banks
>>>>>>>>> >>>>> served the data in their own domain rather than outsourcing it,
but I
>>>>>>>>> >>>>> digress.)
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> The "criticism" section of the Wikipedia page on 3D-secure
>>>>>>>>> details a
>>>>>>>>> >>>>> bunch of problems that OpenID implementors have also
>>>>>>>>> encountered.
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> _______________________________________________
>>>>>>>>> >>>>> user-experience mailing list
>>>>>>>>> >>>>> user-experience at openid.net
>>>>>>>>> >>>>> http://openid.net/mailman/listinfo/user-experience
>>>>>>>> >>>>
>>>>>>>> >>>>
>>>>>>>> >>>>
>>>>>>>> >>>> Johannes Ernst
>>>>>>>> >>>> NetMesh Inc.
>>>>>>>> >>>>
>>>>>>>> >>>>
>>>>>>>> >>>>
>>>>>>>> >>>>  http://netmesh.info/jernst
>>>>>>>> >>>>
>>>>>>>> >>>>
>>>>>>>> >>>>
>>>>>>>> >>>>
>>>>>>>> >>>> _______________________________________________
>>>>>>>> >>>> user-experience mailing list
>>>>>>>> >>>> user-experience at openid.net
>>>>>>>> >>>> http://openid.net/mailman/listinfo/user-experience
>>>>>>>> >>>>
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>> --
>>>>>>> >>> --
>>>>>>> >>> Justin Kruger -- Sr. Software Engineer - MySpace MDP
>>>>>>> >>> http://jDavid.net
>>>>>>> >>> jDavid.net at gmail.com
>>>>>>> >>>
>>>>>>> >>> Anton Freeman: Vincent! How are you doing this Vincent? How have you
>>>>>>> done
>>>>>>> >>> any of this? We have to go back.
>>>>>>> >>> Vincent: It's too late for that. We're closer to the other side.
>>>>>>> >>> Anton Freeman: What other side? You wanna drown us both?
>>>>>>> >>> Vincent: You wanna know how I did it? This is how I did it Anton. I
>>>>>>> never
>>>>>>> >>> saved anything for the swim back.
>>>>>>> >>>
>>>>>>> >>> _______________________________________________
>>>>>>> >>> user-experience mailing list
>>>>>>> >>> user-experience at openid.net
>>>>>>> >>> http://openid.net/mailman/listinfo/user-experience
>>>>>>> >>>
>>>>>>> >>>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> --
>>>>>> >> Breno de Medeiros
>>>>>> >> _______________________________________________
>>>>>> >> user-experience mailing list
>>>>>> >> user-experience at openid.net
>>>>>> >> http://openid.net/mailman/listinfo/user-experience
>>>>>> >>
>>>>> > _______________________________________________
>>>>> > user-experience mailing list
>>>>> > user-experience at openid.net
>>>>> > http://openid.net/mailman/listinfo/user-experience
>>>>> >
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Breno de Medeiros
>>>> _______________________________________________
>>>> user-experience mailing list
>>>> user-experience at openid.net
>>>> http://openid.net/mailman/listinfo/user-experience
>>> 
>>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-user-experience/attachments/20090327/a15837a5/attachment-0002.htm>