[OpenID] Automating the user's selection of OP

[Chris Messina]

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:

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