OpenID in desktop apps

[John Panzer]

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
>