hasAccount
Satisfaction, some new web service or other, has a neat wrinkle; on the sign-up page, you can specify your ID in one of a number of other services (flickr, technorati, last.fm, twitter, others) and it’ll retrieve your (publically available) information from there so you don’t have to fill it all in again. A good idea, I think. (It’s all done through the Magic Of Microformats.)
Something that would make it more useful, though, is if it highlighted which services it thinks you’re a member of. It’d be possible to do that if these online services provided a way to say “does the current user have an account here?” Imagine that Flickr, say, made available a URL http://flickr.com/services/hasAccount. When you call it as http://flickr.com/services/hasAccount?callback=myFunction, it looks to see if you, the user requesting the URL, are logged into Flickr. If you are, it returns this JavaScript:
myFunction(1);
otherwise (i.e., you don’t have a Flickr account, or you do and you’re not logged into it, or possibly you do and you are logged into it and you’ve ticked “hide my online status from other websites” in the Flickr account page) it returns
myFunction(0);
This would usefully let the Satisfaction signup page (and other services that want to offer the same sort of function) display which services it thinks you’re a member of: so for me, it would leave Upcoming and Flickr in the list and disable or grey-out or otherwise de-emphasise Cork’d and Twitter because I don’t have accounts there. This would be relatively trivial to do: Flickr just write somewhere “our hasAccount URL is http://flickr.com/services/hasAccount?callback=” and your code just calls that URL (by creating a <script> element with it in the src) and drops a callback-function name on the end of it so it can read the results. A nice usability enhancement, and it doesn’t particularly invade privacy (it’s a slight violation that site A can know that you’ve got an account at site B, but not a major one since they don’t get any details, and you allow people to opt-out if they choose).
For extra ease-of-use bonuses, although a quantum leap of privacy violation above that, have a hasAccount URL return
myFunction({”username”:”sil”});
instead, and then use hCard as above to automatically fetch the public information from that site. Obviously this is a lot less appealing from the point of view of keeping your information secret, though.
Apart from that it requires all the services to bother doing this, any reason why it shouldn’t happen?
I should note that you can pretty much emulate hasAccount without co-operation from the other services by using the link:visited CSS trick, but that’s rather more sneaky; this would be a supported sort of thing, and people would be able to opt out of it.
85 seconds later
I’d never allow other sites to run unaudited javascript on some service.
98 minutes later
It leaves you a bit open to dictionary attacks to discover what usernames are in use and can be fished for, I think.
5 hours later
Presumably openid could make this a lot more trivial, as you would be able to talk about a single ID?
6 hours later
Aquarion: nope. You can’t say “does this arbitrary username have an account”, it’s for saying “does this user here have an account”, without ever saying who “this user here” is. It’s the user on your website, and it works because their browser is the one requesting it.
7 hours later
mrben: hrm, maybe. OpenID doesn’t actually make this specific use-case any easier (requesting whether someone has an account), but it’s designed to reduce the need for it (because some of the signup information you need will be stored at your openid provider).
7 hours later
bkor: at the point at which this runs, no-one’s signed in (it’s on the signup page), so I’m not sure that the JavaScript can actually _do_ much damage.
7 hours later
“Hide my online status from other applications” becomes an entirely new security nightmare unto itself. Do you have this turned on by default (hint: nobody will ever turn it off), or off by default, potentially allowing malicious websites to perform cross-site scripting attacks?
Ignoring security implications, what if someone has a Flickr account and hasn’t logged into it in a long time? (or just reinstalled their computer and hasn’t logged in yet) Then the user isn’t made aware of features that are useful to them.
Sorry, but I really don’t think this is a good idea. Your idea potentially creates a whole new class of security issues, while the benefits it brings are dubious.
8 hours later
And there was me thinking this was going to be a lol* type post.
canHasAccount?
8 hours later
Eh, evaluating random javascript from some other server seems like a really bad idea. What’s wrong with it just returning “1″ or “0″?
12 hours later
Also, your closing quote character is not the correct character. It should be U+201D (http://salami.ox.compsoc.net/~resiak/cgi-bin/unicloud?cp=201D), but is U+2033 DOUBLE PRIME (http://salami.ox.compsoc.net/~resiak/cgi-bin/unicloud?cp=2033) and hence looks silly. :-)
12 hours later
I agree with others that returning Javascript is a bad idea. Why not just use the HTTP sttus codes? 404 for not found, 200 for OK etc etc. That gives us a wealth of existing status.
You can kind of do something like this by just looking for http://flickr.com/photos/USERNAME.Hackesh and site dependant though.
13 hours later
Stuart: imagine if the flickr page returned a script that posted document.cookies back to them instead of calling myFunction().
I don’t know what sort of authentication system you are using for your account, but many work by first associating a session cookie with the user, then associating an account with the session cookie when they log in.
So while the user may not have an account at this point, the session cookie may become valuable a short time into the future …
13 hours later
The reason I don’t want it to return just a 1 or a 0 or a status code is that then you need help from the server to fetch it, and the server can’t say “am *I* logged in” because it is not the user. If I, Stuart, open up example.com in my web browser, and example.com includes a script src tag to flickr.com/services/hasAccount, my web browser fetches it (and thus it can evaluate whether I, Stuart, am logged in there or not). If it can’t be included with script src then it has to be fetched by a server process on example.org itself (because my browser can’t make cross-domain XMLHttpRequests to flickr.com) and the example.org server is not me and won’t have my Flickr login cookie.
13 hours later
Once you know that a site does have an account for the user, you… ?
…still require them to enter their username for the foreign site — hasAccount returning username would give too much info to malicious scripts imho,
…still require them to fill in more details the foreign site might not have or show publically (like email).
If they used OpenID, it would be:
user provides OpenID URL, [user logs into provider, ] user confirms trust at provider, provider sends simple reg details, sign up complete.
I think OpenID is the way we all want sign–up to go — not this current trend of focusing on popular social networking sites for account details ;)
Oh, and your OpenID URL could always host your hCard anyway, so win–win.
15 hours later
[...] unknown wrote an interesting post today on hasAccountHere’s a quick excerpt [...]
18 hours later
Simpler is to take the users URL (be that their OpenID or just a ‘homepage’ field value) and parse it for links to profile pages on supported services. The rel=”me” microformat provides a mechanism to indicate a related page with further information about the person described by the current page.
See my OpenID URL (drewmclellan.net) for an example.
3 days later
drewm: nice. I didn’t know about that. Something to look at…
3 days later