How DOES this persistent cookie thing work?

[Schtibbie]

Kinda old article, but this is still pending resolution:
http://www.wired.com/threatlevel/2010/09/html5-safari-exploit/

Are there any devs on this forum who might be able to answer this question for me:

HOW can a webpage end up with access to your unique device ID (of your iphone)? I understand how *apps* do it. There's an API call that your apps can access to see your device ID. But that article, and others, seem to imply that the Safari HTML5 cookies, like RLDGUID, have access to your device ID and so even deleted them doesn't help because the next time you visit a RLDGUID-using site (never mind installing an app!), it grabs your device ID again and recreates the same "cookie".

If this device ID *is* possible to access through HTML5, this seems unacceptable and an undefeatable individual-person tracking tool.

 

[kdarling]

The article didn't say it got your device id.

It said they stored a unique id (that they made up) on your device:

Mobile Safari users visiting sites with Ringleader ads are assigned a unique ID number which is stored by the browser,

They're stored in an HTML5 database on your phone. Go to Settings - Safari -Databases to see what's on your iOS device.

 

[Schtibbie]

The article didn't say it got your device id.

It said they stored a unique id (that they made up) on your device:

But other articles on the same topic indicate that device ID *is* one of the things they get. I'm thinking that's either a mistake in those articles or... not.

What makes me think it is true is that folks have tested deleting the database as you described only to find that after further browsing it not only reappeared, but reappeared with the SAME info in it, indicating that somehow something about your device (its ID) is recognizable even after you deleted that Safari HTML5 "cookie".

Make sense? Anyone know if iphones are uniquely identifiable to websites even with HTML5 cookies cleared from one session to another?

 

[ulbador]

But other articles on the same topic indicate that device ID *is* one of the things they get. I'm thinking that's either a mistake in those articles or... not.

What makes me think it is true is that folks have tested deleting the database as you described only to find that after further browsing it not only reappeared, but reappeared with the SAME info in it, indicating that somehow something about your device (its ID) is recognizable even after you deleted that Safari HTML5 "cookie".

Make sense? Anyone know if iphones are uniquely identifiable to websites even with HTML5 cookies cleared from one session to another?

It's not possible to retrieve the UDID via HTML or Javascript, (short of some unbeknown Safari exploit).

There is no such thing as an HTML 5 cookie. A cookie is a cookie. HTML 5 does expand on the cookie concept by adding additional storage types, but the same basic security rules still apply.

HTTP traffic, be it HTML4/5 or otherwise is completely stateless. The only way a remote site can identify you (unless they are trying to track by IP which is iffy at best) is to store a cookie or use HTML5's local storage (which is basically a more extensive cookie). If you delete this cookie or local storage, they have no way of knowing who you are until you allow them to store more data.

From checking out the articles, it looks like this ringleader company might be exploiting something in Safari's local database implementation in HTML5.

 

[kdarling]

Normally I'd say that the writers were mixing up reports. However...

Ringleader does say that it uses "non-personally identifiable information, such as browser identifiers, session information, device type, carrier provider, IP addresses, unique device ID, carrier user ID and web sites visited".

I wonder if the same company has donated code inside any native iPhone apps that uses their advertising. If so, such an app could get the Device ID and perhaps then store it locally via some hidden webkit HTML5 database access... allowing later overt web accesses to see it.

 

[ulbador]

Normally I'd say that the writers were mixing up reports. However...

Ringleader does say that it uses "non-personally identifiable information, such as browser identifiers, session information, device type, carrier provider, IP addresses, unique device ID, carrier user ID and web sites visited".

I wonder if the same company has donated code inside any native iPhone apps that uses their advertising. If so, such an app could get the Device ID and perhaps then store it locally via some hidden webkit HTML5 database access... allowing later overt web accesses to see it.

I notice on my phone I have both cookies from this RINGLDR group and a HTML5 "database" under a separate setting. All the articles I read about this mention deleting the cookie, but nothing about the database. I bet this is where it is storing the purported "UDID" at (and therefore why it lives after deleting the cookie). I could delete it, but I have no idea of sites to visit it to see if it stayed the same.

I don't remember ever seeing the "Database" option under the Safari settings, so I wonder if it's new as of 4.1.

 

[Schtibbie]

I wonder if the same company has donated code inside any native iPhone apps that uses their advertising. If so, such an app could get the Device ID and perhaps then store it locally via some hidden webkit HTML5 database access... allowing later overt web accesses to see it.

Holy cow. Good thinking! THAT needs looking into. I'd be surprised if apps were allowed to save off the device ID (which, as I mentioned IS discoverable by apps) outside their sandbox in the Safari database where it could be used by web pages as you describe.

Any developers know?

 

[ulbador]

Holy cow. Good thinking! THAT needs looking into. I'd be surprised if apps were allowed to save off the device ID (which, as I mentioned IS discoverable by apps) outside their sandbox in the Safari database where it could be used by web pages as you describe.

Any developers know?

Once an app has the UDID, it can do anything it wants with it. Sure it could save it on the device, but it could just as easily post it to a website somewhere or save it in a remote database somewhere or anything else you can think of.