[OpenID] Automating the user's selection of OP

[SitG Admin]

To minimize a selector's surface area, while also minimizing the
amount of user involvement that would be required for it to work, the
server could send some Javascript to outsource checkid_immediate (or
equivalent functionality) to the user's browser; the browser would
request some secure (access restricted) area of the first website in
a list provided by the RP, then move on through the list as it
received access denied errors, but serve up a customized login
suggestion screen for that OP if the response suggested that the user
had an account with the OP already. All connections would be done
from the user's browser, through their connection, sparing the server
all this work (but pinging OP's every time a user ran the script).

-Shade has odd ideas in the wee hours of the morning
_______________________________________________
general mailing list
gen...@openid.net
http://openid.net/mailman/listinfo/general

[Andrew Arnott]

Hi Shade,

You may be interested in my OpenIdAjaxTextBox sample, which has a similar idea.  As soon as you type in an identifier, it goes to work in the background scanning the XRDS of the identifier and then sending checkid_immediate to a moving window of up to x maximum OPs simultaneously from the XRDS.  The result is that if the user is logged into any of the OPs listed in his XRDS file, then the site pretty much guarantees that he won't have to log in explicitly to any of them in order to visit this site -- provided the site is already trusted by his OPs.  So it works better the second time you visit. :)

http://demo.dotnetopenauth.net/v3.0/OpenIdRelyingPartyWebForms/ajaxlogin.aspx

Oh, and at the moment it doesn't work well with IE8.  But IE7, Chrome, FF all work decently with it.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire

[SitG Admin]

>You may be interested in my OpenIdAjaxTextBox sample, which has a
>similar idea. As soon as you type in an identifier,

I was hoping to prompt the user slightly before that; if we assume
that most users (a very high percentage, as adoption picks up and
actual "users" do not consist mainly of us technically aware
individuals) have an account at a major OP, we (RP's) can pre-load a
list of OP's to check for. This would also be an opportunity to
preferentially check for OP's we would like the user to log in with.

-Shade

[Andrew Arnott]

That makes sense.  I knew it was a different although the idea is similar.  

User agents don't let you make cross-site HTTP calls however, which may block the implementation of your idea.  My control works with a concert of hidden iframes and coordinated redirects between the RP and OP.  But I think you can't rely for any redirects from an OP doing what you're suggesting, so any iframe you create will just sit there, and since it's a cross-site iframe your javascript will never get any information back from it, including the HTTP status code I believe.

Don't let me stop you from trying, but I just will be surprised if it will work.

Didn't you mention (or discuss on a thread) sometime back the idea of emitting links to OPs using javascript, then sniffing whether they were "visited" links or not in order to see which OPs the user has been to and thereby guess which OPs are most effective to display to the user?

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire

On Mon, Apr 20, 2009 at 4:17 AM, SitG Admin <sysa...@shadowsinthegarden.com> wrote:

You may be interested in my OpenIdAjaxTextBox sample, which has a similar idea.  As soon as you type in an identifier,

[SitG Admin]

>User agents don't let you make cross-site HTTP calls however, which
>may block the implementation of your idea.

They don't? I thought that was why XSS attacks (literally,
"cross-site scripting") were so dangerous; but then, since you don't
need scripts enabled (just images would do) for that, I may be
conflating two meanings of "scripting". Depending on what content at
OP's is restricted, and *how* it gets restricted, a script may not
need to examine HTTP Response headers - if it could just look at
whether a requested image was returned at all, or the size of that
image?

Or, if OP's were to set up a special URL for allied RP's to test
whether users were logged in - but no matter what can be achieved
through cooperation that way, which OP's would *want* to mitigate
OpenID's privacy by letting arbitrary sites (whoever sent the users
similar scripts) check which supporting OP's the user was currently
logged into (if not what their account name was), and easily transmit
that data back to the RP?

>Don't let me stop you from trying, but I just will be surprised if
>it will work.

I'm queasy about the idea now. Much like using XSS "for a good
cause", I don't want to encourage users to rely on insecurity for
their conveniences. It was just a thought; let's work on selectors a
bit longer, make sure we do it right.

>Didn't you mention (or discuss on a thread) sometime back the idea
>of emitting links to OPs using javascript, then sniffing whether
>they were "visited" links or not in order to see which OPs the user
>has been to and thereby guess which OPs are most effective to
>display to the user?

I don't think so, though this does seem to be another instance of
"attack" techniques (I do recall reading about it; there's a Firefox
addon addressing the risk) being used for "good".

We've all had a lot of ideas, but they tend to get lost among the
older threads. I'm of a mind to embark on a project to index all
these ideas so we can easily find them later on, when we need them or
are just interested.

-Shade

[Chris Messina]

On Mon, Apr 20, 2009 at 1:10 PM, SitG Admin <sysa...@shadowsinthegarden.com> wrote:

User agents don't let you make cross-site HTTP calls however, which may block the implementation of your idea.

They don't? I thought that was why XSS attacks (literally, "cross-site scripting") were so dangerous; but then, since you don't need scripts enabled (just images would do) for that, I may be conflating two meanings of "scripting". Depending on what content at OP's is restricted, and *how* it gets restricted, a script may not need to examine HTTP Response headers - if it could just look at whether a requested image was returned at all, or the size of that image?

Or, if OP's were to set up a special URL for allied RP's to test whether users were logged in - but no matter what can be achieved through cooperation that way, which OP's would *want* to mitigate OpenID's privacy by letting arbitrary sites (whoever sent the users similar scripts) check which supporting OP's the user was currently logged into (if not what their account name was), and easily transmit that data back to the RP?

This is how Facebook Connect works. XSS can be very useful; in and of themselves, they're not intrinsically evil, but abusing this feature of browsers/servers leads to bad things.

The problem with your proposal is that the RP would need to have a unique cross-domain script that talks to N number of OPs, which is tractable but not terribly efficient. It also adds an extra burden on the OPs and can additionally lead to an inconsistent or "squishy" user experience — where, depending on local system settings (and whether the user is on their personal computer or on a shared terminal, like in an Apple store), the positive hints you receive about logged in OPs may be misleading or downright wrong.

This is why the CSS history detection trick [1][2][3] is so brittle — it depends a current browser behavior that can change in its effectiveness depending on how often a user clears their history, uses non-personal computers or works across several different devices.

 

 

Didn't you mention (or discuss on a thread) sometime back the idea of emitting links to OPs using javascript, then sniffing whether they were "visited" links or not in order to see which OPs the user has been to and thereby guess which OPs are most effective to display to the user?

I don't think so, though this does seem to be another instance of "attack" techniques (I do recall reading about it; there's a Firefox addon addressing the risk) being used for "good".

Luke Shepard wrote about this idea recently:

http://www.sociallipstick.com/2009/04/15/lets-detect-logged-in-state/

 

We've all had a lot of ideas, but they tend to get lost among the older threads. I'm of a mind to embark on a project to index all these ideas so we can easily find them later on, when we need them or are just interested.

I'd be thrilled if you'd take this on using OpenID wiki! http://wiki.openid.net!

Alternatively, you could submit them to ideas.openid.net.

Thanks,

Chris

[1] http://www.azarask.in/blog/post/socialhistoryjs/

[2] http://www.niallkennedy.com/blog/2008/02/browser-history-sniff.html 

[3] http://www.niallkennedy.com/blog/2006/03/automatic-favor.html

 

-Shade

_______________________________________________
general mailing list
gen...@openid.net
http://openid.net/mailman/listinfo/general

--
Chris Messina
Citizen-Participant &
 Open Web Advocate

factoryjoe.com // diso-project.org // vidoop.com
This email is:   [ ] bloggable    [X] ask first   [ ] private

[Santosh Rajan]

Chris Messina wrote:
>
>
> Luke Shepard wrote about this idea recently:
>
> http://www.sociallipstick.com/2009/04/15/lets-detect-logged-in-state/
>
>
>

Does not look like a practical idea to me.

1) Detecting logged in status for a set of OP's even if it is possible, will
mean an extra delay in the login process.
2) Even if you detect a person logged in to an OP we cannot assume that it
is the OP the user would like to use for the particular RP.
3) You may find the user logged in to more than one OP's,

So you are still back to asking the user which OP's he would like to login
with.

You might as well ask the question at the start itself and set a cookie for
the user.

-----

Santosh Rajan
http://santrajan.blogspot.com http://santrajan.blogspot.com
--
View this message in context: http://www.nabble.com/Automating-the-user%27s-selection-of-OP-tp23134539p23147925.html
Sent from the OpenID - General mailing list archive at Nabble.com.

[SitG Admin]

>So you are still back to asking the user which OP's he would like to login
>with.
>
>You might as well ask the question at the start itself and set a cookie for
>the user.

Which returns you to the problem this was intended to solve: isn't it
a bit much to ask the user to type in their OpenID when you can fill
it in for them automatically?

-Shade

[Santosh Rajan]

Are you suggesting that typing a url is easier for the user than selecting
from a list like here the one below?
http://myfeeds.myofiz.com http://myfeeds.myofiz.com

-----

Santosh Rajan
http://santrajan.blogspot.com http://santrajan.blogspot.com
--

View this message in context: http://www.nabble.com/Automating-the-user%27s-selection-of-OP-tp23134539p23148446.html

Sent from the OpenID - General mailing list archive at Nabble.com.

_______________________________________________

[SitG Admin]

We're going in circles here.

>Are you suggesting that typing a url is easier for the user than selecting
>from a list like here the one below?

How do you populate the list?

>http://myfeeds.myofiz.com http://myfeeds.myofiz.com

I only see Google and Yahoo - your list is woefully incomplete.

Foreseeing (with a touch of deja vu) our next step in this cycle, how
do we avoid confusing the user with a long list of OP's, most of
which they will be uninterested in using, and many of which they may
have never heard of?

http://www.azarask.in/blog/post/socialhistoryjs/

That's one of the XSS links Chris Messina posted. Read down through
the image of a "bird-shot" approach. We don't want users to be lost
in a sea of icons, hunting down the only one they find familiar.

[Luke Shepard]

Thanks for your feedback.

> 1) Detecting logged in status for a set of OP's even if it is possible, will
> mean an extra delay in the login process.

The detection can be done in the background, in parallel, and the results displayed only once they come back. If the OPs are fast, then loading from 20 OPs generates 40 HTTP requests (20 if you optimize the return_to). This is no worse than loading 40 images on a page.

> 2) Even if you detect a person logged in to an OP we cannot assume that it
> is the OP the user would like to use for the particular RP.

That’s true. The user still needs to choose to login, but at least now the RP can place the choice much more prominently than it would be able to without this information.

‘> 3) You may find the user logged in to more than one OP's,

I specifically addressed that objection in my post. If the user is logged into more than one OP, then you can still give them a choice.

> You might as well ask the question at the start itself and set a cookie for the user.

With this technique, you could run the detection for a much larger set of OPs, and ask a more intelligent question. Otherwise, how do you ask a user to choose from 100 services, most of which they have never heard of?

In any case, this suggestion has yet to be implemented. The right way to tell if this is correct is to implement and test to see if it performs better than the NASCAR approach.

[George Fletcher]

We could use smart software in the browser to handle this (e.g. Verisign
Seatbelt or Sxipper) but with a much better set of features for the
user, and better detection of web sites that support OpenID (e.g. the
Vidoop plugin for flock).

While we can't ever get away from the need to support "dumb browser"
experiences, in my mind it makes more sense to optimize for an "identity
agent" aware device while not precluding the "dumb browser" experience.
There is a lot we can do to make a seamless user-centric experience
using an "identity agent" on the user's device.

My 2 cents:)

Thanks,
George

[SitG Admin]

>While we can't ever get away from the need to support "dumb browser"
>experiences, in my mind it makes more sense to optimize for an
>"identity agent" aware device while not precluding the "dumb
>browser" experience.

Ideally, we could use *both* techniques in parallel; dumb browsers
wouldn't have protection against the attack methods yet, and we
wouldn't *need* them for smart browsers. But we're going to see users
with Privacy addons that leave us in the worst of both worlds (smart
enough for the attack tricks not to work, but not smart enough to
handle OpenID automatically), so we'll still need to have *some* kind
of generic interface as a fallback.

[Chris Messina]

On Tue, Apr 21, 2009 at 1:29 PM, George Fletcher <gffl...@aol.com> wrote:

While we can't ever get away from the need to support "dumb browser" experiences, in my mind it makes more sense to optimize for an "identity agent" aware device while not precluding the "dumb browser" experience. There is a lot we can do to make a seamless user-centric experience using an "identity agent" on the user's device.

I support that concept.

I think there is much to be learned from video gaming system that support either local or portable profiles. Clearly they've worked out the user experience here for both efficiency and typical users... Would be curious to know if we have any contacts on the Xbox or Wii teams.

Chris

 

SitG Admin wrote:

So you are still back to asking the user which OP's he would like to login
with.

You might as well ask the question at the start itself and set a cookie for
the user.

Which returns you to the problem this was intended to solve: isn't it a bit much to ask the user to type in their OpenID when you can fill it in for them automatically?

-Shade
_______________________________________________
general mailing list
gen...@openid.net
http://openid.net/mailman/listinfo/general

_______________________________________________
general mailing list
gen...@openid.net
http://openid.net/mailman/listinfo/general

 

[Eric Norman]

On Apr 21, 2009, at 3:29 PM, George Fletcher wrote:

> While we can't ever get away from the need to support "dumb browser"
> experiences, in my mind it makes more sense to optimize for an
> "identity agent" aware device while not precluding the "dumb browser"
> experience. There is a lot we can do to make a seamless user-centric
> experience using an "identity agent" on the user's device.

So you encourage more deployment, use, and development of information
cards, right?

Eric Norman

[Nat]

Hey, if you can spec out something, I may allocate some of my R&D
budget to make it.

=nat@San Francisco via iPhone

[Peter Williams]

but dont forget to do the iphone, the gphone, the wmphone, the wapphone, the strangephone, too - and the java and .net apps on those phones...

openid has to work everywhere, and is best kept tight to the web - vs the device.

This obviously conflicts with the device-centric view of the world.

Think SSL. SSL required no browser level plugin... and scaled to web scale.
________________________________________
From: general...@openid.net [general...@openid.net] On Behalf Of Nat [saki...@gmail.com]
Sent: Wednesday, April 22, 2009 12:18 AM
To: George Fletcher
Cc: Santosh Rajan; gen...@openid.net
Subject: Re: [OpenID] Automating the user's selection of OP