[OpenID] Automating the user's selection of OP

Chris Messina chris.messina at gmail.com
Mon Apr 20 20:50:45 UTC 2009

On Mon, Apr 20, 2009 at 1:10 PM, SitG Admin <sysadmin at 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:


> 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!

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



[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
> general at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090420/48c4936c/attachment.htm>

More information about the general mailing list