Address Bar

Chris Messina chris.messina at gmail.com
Fri Mar 27 16:09:05 UTC 2009


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-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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-user-experience/attachments/20090327/45742b88/attachment-0002.htm>


More information about the user-experience mailing list