Address Bar

Breno de Medeiros breno at google.com
Fri Mar 27 16:26:45 UTC 2009


On Fri, Mar 27, 2009 at 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.
>

Wholeheartedly agree with this conclusion.


>
> 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-verified-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 at 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 at 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
>>>>
>>>
>>>
>>>
>>> --
>>> Chris Messina
>>> Citizen-Participant &
>>>  Open Web Advocate
>>>
>>> factoryjoe.com // diso-project.org // vidoop.com
>>> This email is:   [ ] bloggable    [X] ask first   [ ] private
>>>
>>> _______________________________________________
>>> user-experience mailing list
>>> user-experience at openid.net
>>> http://openid.net/mailman/listinfo/user-experience
>>>
>>>
>>
>>
>> --
>> --Breno
>>
>> +1 (650) 214-1007 desk
>> +1 (408) 212-0135 (Grand Central)
>> MTV-41-3 : 383-A
>> PST (GMT-8) / PDT(GMT-7)
>>
>> _______________________________________________
>> user-experience mailing list
>> user-experience at openid.net
>> http://openid.net/mailman/listinfo/user-experience
>>
>>
>
>
> --
> Chris Messina
> Citizen-Participant &
>  Open Web Advocate
>
> factoryjoe.com // diso-project.org // vidoop.com
> This email is:   [ ] bloggable    [X] ask first   [ ] private
>
> _______________________________________________
> user-experience mailing list
> user-experience at openid.net
> http://openid.net/mailman/listinfo/user-experience
>
>


-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-user-experience/attachments/20090327/059ea3a4/attachment-0002.htm>


More information about the user-experience mailing list