MySpace OpenID Popup spotted in the wild

Chris Messina chris.messina at gmail.com
Thu Apr 30 17:26:18 UTC 2009


On Thu, Apr 30, 2009 at 2:08 AM, David Christiansen <
openid-userexperience at davidchristiansen.com> wrote:

> Hi All,
> Trying to maintain a 'Can Do Attitude' here but I have personal
> reservations about going back to the days of browser pop-up windows -
> however I fully appreciate the reasoning behind the need to show an address
> bar to the user.
>

This is absolutely critical, as phishing attacks are as prevalent as ever
and will becoming increasingly so:

http://www.thestandard.com/news/2009/04/29/facebook-phishing-attack-progress
http://www.techcrunch.com/2009/04/30/new-phishing-attack-spreading-on-facebook-this-time-from-fbstarter/

Folks have tried to argue that on trusted sites such inline dialogs are safe
— especially between partners — and there's some truth to that. But I think
the problem is that it allows for a certain kind of complacency to set in —
and it takes away any indicators whatsoever that the user could use to try
to evaluate whether to trust the login dialog presented to them.

That isn't to say that web security has become something of an oxymoron —
but in the case where you can give people at least ONE familiar tool to
evaluate their situation, I think we should.

Popups may not seem to be the ideal place to put the experience, but we have
few other choices, and at least it works across browsers.


> Tell me, how do we permanently avoid the pitfalls experienced back in the
> day (a couple of years ago) where pop-up blockers got in the way of every
> attempt to honestly launch a browser window from javascript. I know there
> are 'work around' to bypass pop-up blockers, but they only work until the
> pop-up blockers are updated. I guess this is why 'inline' windows became so
> popular.


As long as the user clicks a link, the popup should launch. It doesn't
require any special trickery or hacking.

Inline dialogs became popular because people could start building interfaces
with AJAX and trust that most people would have a decent experience. Most of
Facebook is written in Javascript — and I have no idea what the experience
is like without Javascript turned on, but I imagine that, by and large, most
people's experience of Facebook is enhanced by Javascript (if not MADE by
Javascript).

Inline dialogs also allow you to take some interaction "without leaving the
page" — cutting down latency and increasing efficiency since you didn't have
to do a full page refresh.

In other words, inline windows were the result of improvements in
technologies centered on user experience, not because popup blockers became
so powerful (at least in my view).



> So what we are needing - is an inline window...with an modal address bar
> :working:
>

Well, this is a long way off — and really runs counter to the user
experience that I think a lot of sites want.

Indeed, most sites would prefer better user experience over security (though
they won't say that) and besides, setting those two things as opposites
really is defeating all of our goals. As hard as it is to come by, we do
need usable security — that doesn't necessarily completely compromise the
user experience (see Windows VISTA).



>
> Another potential downside I can see is that we would also be mandating
> that the user's browser had javascript enabled, is this a good thing? maybe
> not even an issue.
>

Again, I think this issue has been put to rest. We do need to think about
mobile and set-top experiences, but nothing about the popup window should be
impossible in non-Javascript environments.

Thanks for your comments. I do think that a way to better detect the source
of an inline dialog would certainly be a nice browser enhancement, but given
that we have to work with the web we have, it might be something to work on
over the long term.
Chris


-- 
Chris Messina
Open Web Advocate

factoryjoe.com // diso-project.org // openid.net // 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/20090430/d86f7322/attachment.htm>


More information about the user-experience mailing list