Address Bar

Breno breno.demedeiros at gmail.com
Fri Mar 27 16:18:05 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.

However, these do not block popups initiated by button clicks. So the
conclusions of this analysis are not relevant.


>
> 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
>
> _______________________________________________
> user-experience mailing list
> user-experience at openid.net
> http://openid.net/mailman/listinfo/user-experience
>
>



-- 
Breno de Medeiros

More information about the user-experience mailing list