OpenID in desktop apps

jDavid jdavid.net at gmail.com
Tue Feb 10 14:53:31 UTC 2009


i am looping in two of my coworkers on this thread.

On Mon, Feb 9, 2009 at 11:16 PM, John Panzer <john at johnpanzer.com> wrote:
> So yes: A ux best practice to always let a user escape to their own
> browser via a link (and come back again) might help with the last bit.
>  Would require experimentation and user testing.
>
> On 2/9/09, Chris Messina <chris.messina at gmail.com> wrote:
>> On Mon, Feb 9, 2009 at 8:56 AM, Christopher St John
>> <ckstjohn at gmail.com>wrote:
>>
>>> On Mon, Feb 9, 2009 at 5:42 AM, Paul Walker <pwalker at myspace.com> wrote:
>>> >
>>> > Why should we not further the expectations of downloaded/installed apps
>>> when
>>> > it comes to security no matter the platform?
>>> >
>>>
>>> But nobody has come up with a way to do that. I'm arguing
>>> that it's currently impossible. (The suggestions so far provide
>>> only the illusion of security because they can trivially be
>>> spoofed by evil apps)
>>
>>
>> I think the take-away point here is that, if a desktop app has been
>> compromised, or isn't trustworthy to begin with, not only will the app NOT
>> do the browser-based popup flow (and users wouldn't like notice the
>> difference anyway since there's so much inconsistency in interfaces), but if
>> it has the ability to load a browser view inline, it can essentially sniff
>> all the traffic sent between the view and the web server, regardless of
>> whether it shows a 300px tall lock icon.
>>
>> The reality is we're in Matrix territory here: anything graphical on the
>> user's computer can, and probably will, at some point, be spoofed to look
>> more secure than it really is.
>>
>>
>>
>>> > I don't see a big
>>> > detriment in the user workflow for even a mobile app that pops up the
>>> > browser and, after auth, returns to the custom protocol of the app (i.e.
>>> > facebook:///mygarden_is_now_authed), which communicates back to the app
>>> the
>>> > output.
>>> >
>>>
>>> Well, "current thinking" seems to be that the delegated authc/authz
>>> dance is a detriment, so saying it's not is controversial (and ref
>>> evidence that even small impediments to usability can significantly
>>> reduce user acceptance of security enhancements)
>>
>>
>> I think we need more user testing here.
>>
>> Certainly interface language can help, and screens like this that raise
>> awareness without raising alarm might be useful (though people eventually
>> gloss over when they seem them, like EUL Agreements):
>>
>> http://flickr.com/photos/factoryjoe/3267114792/
>>
>>
>>> If the platforms don't have mechanisms that help the users insure
>>> > the Provider, let's make it so rather than "punting" on the issue.
>>> >
>>>
>>> By "make it so" I'm assuming you mean lobby the people in charge
>>> of desktop and mobile devices to add new security mechanisms to
>>> their operating systems? I might buy that, actually. But it doesn't
>>> help in the short term.
>>>
>>> If you mean "pretend that forcing use of a browser really adds some
>>> sort of security even though we know it doesn't" then I'd disagree
>>> strongly.
>>>
>>
>> I think that the increasingly reliance on security-through-browser-popups is
>> creating a pretty juicy target (not that we didn't know that already, but
>> still).
>>
>> One argument that I use in favor of OpenID and popping out of desktop apps
>> for doing authentication is the use of secondary or alternative
>> authentication mechanisms, such as SMS PINs, phone confirmation or image
>> shields (as in the case of Vidoop — where your password literally changes
>> EVERY TIME you authenticate — making sniffing traffic much less useful).
>>
>> If you merely use an inline WebView, it's unclear to me whether you are
>> afforded the ability to use whatever arbitrary authentication mechanism you
>> might use to in your browser, not to mention inhibiting the user's ability
>> to use their password manager.
>>
>> Fortunately 1Password found a way to add itself to most apps that leverage
>> the WebKit embedded WebView, but I don't think that this is the common case.
>>
>> If we accept that authentication should eventually move beyond mere
>> usernames and passwords, I think that it becomes much more obvious why we
>> should think very hard about popping out of desktop apps and into the
>> browser (or some context that allows for arbitrary authentication
>> mechanisms).
>>
>> Chris
>>
>> --
>> Chris Messina
>> Citizen-Participant &
>>  Open Web Advocate-at-Large
>>
>> factoryjoe.com # diso-project.org
>> citizenagency.com # 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
>



-- 
-- 
Justin Kruger -- Sr. Software Engineer - MySpace MDP
http://jDavid.net
jDavid.net at gmail.com

"A dreamer is one who can only find his way by moonlight, and his
punishment is that he sees the dawn before the rest of the world." -
  --  Oscar Wilde



More information about the user-experience mailing list