is it possible to get a unique identification number from a mobile device?_问答_开发者

I am currently working on mobile device web applications, and I was wondering if there is some sort of unique id number per device that could be detected via the browser.

开发者_如何学GoThe purpose would be to store this number in order to recognize people who already visited the site.

I was working with bluetooth quite a lot, and there some sort of mac address you can store when you detect a device, and I was using this as Id number, so that's my question, is there a general ID number I can detect from the browser...?

Thanks.

Well after further research, the answer is: No, it's not possible right now to get a mobile device id number from its browser...

A solution I found is to generate a "unique" number (in my case I worked with php, so I used the session_id() number mixed with a number generated with the rand() function, it ends up being a quite big number that will hardly occur twice...) and then store it in a cookie that never expires.

It's not a perfect solution, as it will not work if cookies are disabled or if the user clears his cookies, but actually after using it for sometimes now, it turns out that it is working quite well, mobile device mostly have cookies enabled, and the users don't seem to clear them often...

Also (depending of your application) if you store an email or a username and then associate it with this "unique" number into a database, you can even recover someone's identity and store a new cookie by asking him his username or email again...

Hope this will help some people!

Sam Greenhalgh just found a way of setting a device ID via "Super Cookie":

http://www.radicalresearch.co.uk/lab/hstssupercookies (archived link)

This is an old question. Hope this helps someone in future.

Although "Experimental", MDN Web Docs now has a method to get deviceID. Except IE, all browsers are supported at this time. This solution seems to be better than nothing - as the ID is not reliable and I have to fill gaps with some custom workaround.

The deviceId readonly property of the MediaDeviceInfo interface returns a DOMString that is an identifier for the represented device and is persisted across sessions. It is un-guessable by other applications, and unique to the origin of the calling application. It is reset when the user clears cookies. For private browsing, a different identifier is used that is not persisted across sessions.

var deviceID = MediaDeviceInfo.deviceId

I know this is old - but I found this and wanted to share my thoughts on the OP's next best thing using GUID type numbers.

Unless you need the security of a HUGE non-guessable identifier - it makes more sense for the server to create a simple counter instead - e.g start at ~100 and for every visitor that doesn't already have your cookie use max(counter) + 1 to create their new cookie.

Now you have a very short and 100% unique identifier that you can store for both client and server.

Also, as you mention storing an email address is also useful, in theory the email address should be unique - not only that - it is cross browser compatible. i.e their cookie exists on one browser - but when going to a new browser, if they enter the same email address you can map to their original connection profile.

Although you mention this and its true, it is also important to note that anyone putting in dodgy data e.g. anon@anon.com will likely be loaded up with another users history. i.e in your case - a brand new user putting in anon@anon.com will not get to see the intro pages.

In some countries carriers include some id in http headers when consumer is browsing through WAP gateways. There is some aggregators with APIs for consumer identification, normaly it works only when consumer is browsing through WAP gateways too.

I'm doing something similar but for a HTML local page for stocking ids in localstorage and eventually update to server: - taking the date in epoch ms - and then replace the leading number with a random number (foolish hope to limit the size of the number) Somehow I think mobile are more likely to be on time.