views:

109

answers:

5

I'd like to create a piece of code that can be embedded on many different websites (widget).

Is there any way that my code can identify a user without them logging in? I.e, can I use any of the established identity mechanisms floating around the web to reliably identify them across instances of this widget?

I don't need to (nor should I be able to) tap into any information about this user, just identify them.

The websites will be heterogeneous; there's no guarantee that they will have any common aspects, so the widget code needs to be entirely self contained.

+3  A: 

OpenID is sort of a SSO for the whole internet, yet they still have to sign in to OpenID. Other than that, I can't think of a solution.

bkritzer
I'm looking to avoid any sort of sign in.Still, I've got an eye on OpenID. I haven't seen it work well at all for anything other than technical sites. Hasn't made it into the mainstream yet. Likely confusing to most users, IMHO.
Laizer
A: 

Sounds like you want to implement a Single Sign On framework. Basically when you first see the user, if you don't know them, you redirect them to the single sign on server. Wich authenticates them and redirects them back to you with a authentication token. You verify the authentication token with a web service call to the SSO server. Ff it is valid then you mark that user as signed on.

EDIT

So thinking about it more and reading tovare's answer and your comments. Why not create some javascript code that works like an google ads? You put the javascript on the page and it does an a request to your central tracking server using a dynamic iframe.

Have your tracking server return an image tag with src of the unique id (its own session id) embedded. <img src=contentserver.com/track.php?id=12345668>

The content server has a server side script (track.php above) that maps its local session id to the unique id received from the tracking server.

The unique id stays the same across all sites.

Edit2

Instead of using an image, use the javascript trick. The content server just requests a javascript file from the tracking server. but the file is a dynamic one generated on the server side. it returns a generated javascript function called unique_id() it returns the unique id from the tracking server. Call the track.php using ajax to determine if this is a unique user.

Byron Whitlock
I may end up having to go this way, but I'm particularly interested in seeing if I can avoid ever having to have them sign up. Perhaps hitchhiking on existing systems (Google? Facebook?)
Laizer
No existing system without horrible security flaws is going to allow you to do this. If you find a way to do it, you should expect the method you used to be eliminated as soon as they find out about it.
Wooble
@Laizer Wooble is right. Any existing sites that would let you do this are horribly broken. Would you want any random site knowing your google id?
Byron Whitlock
I may be splitting hairs here, but I'm not concerned with picking up the actual ID, or anything about the person - just dependably and uniquely identifying them.
Laizer
+2  A: 

What you want to do is what cookies were invented for. But browsers have gotten wise to people being tracked without their permission, and now limit 3rd party cookies.

The Electronic Frontier Foundation recently put up a proof of concept for uniquely identifying a visitor based on attributes of their browser. It's uses things things like:

  • User-Agent string
  • http-accept values
  • timezone
  • screen resolution and color depth
  • the installed plugins
  • if cookies are enabled

It's not guaranteed to be unique, but my browser certainly is, and it will get you on your way to doing the bad things that people don't like.

Ian Boyd
Yeah but you can't access cookies across domains.
Byron Whitlock
@Byron: Which is what i meant by "browsers...now limit 3rd party cookies"
Ian Boyd
At my company, all 15000 employees use the same browser without ability to customize and everyone goes through the exact same proxy accessing the internet.
tovare
@tovare: Check it anyway. My iPod Touch is unique, and nothing about it looks particularly unique. Try two computers and see if it says the browser is unique.
Ian Boyd
A: 

Hi,

I would suggest Open-ID rather than some workaround like this, but if you don't like that solution you might consider something like this:

You can use a cookie from a single domain, then use that domain to redirect to the correct site adding user-id as a parameter or part of the URL-path

For instance a link to add a personal widget on the foo.com -site, could look something like:

http://bar.com/addwidget1?backtoo=http://foo.com/main/

bar.com would own the cookie, change the user preferences and then add user-id to the back-link before re-directing:

foo.com/user-id/

Issues with this approach includes

  • You need to rewrite every page dynamicly with the user-id.
  • It's a bit clumsy I think
  • You can't fully take advantage of web-caches around the net.
  • The user might loose their cookie.

Benefits

  • No login
  • Since you redirect a lot you get stats on the users movement across your sites.
tovare
A: 

Use OpenID, or a simplified variant, with your own site as the identity provider. Redirect the user to your identifier site which sets or checks a cookie, then redirect the user back with the user's identity, which was indicated by the cookie, added as a URL argument.

Your identifier site can be an OpenID identity provider which doesn't require any user interaction to authenticate. The sites which receive this identity are probably not OpenID consumers, since they don't offer the user a choice of providers. You can probably do away with some of the signing required by OpenID if your cookie and identifier are signed.

Facebook provides something similar; a site can find the Facebook identity of a user (assuming the user has one) without any action on the user's part.

Karl Anderson