http://developer.apple.com/library/ios/#documentation/uikit/reference/UIDevice_Class/Reference/UIDevice.html identifierForVendor

This is currently a container feature, but should be included in ICEmobile-SX. Since it can be implemented using offline communication and shared between multiple web applications, there are potential privacy implications.

An equivalent android mechanism needs to be investigated.

Sample android code:

http://stackoverflow.com/questions/2785485/is-there-a-unique-android-device-id

final TelephonyManager tm = (TelephonyManager) getBaseContext().getSystemService(Context.TELEPHONY_SERVICE);

final String tmDevice, tmSerial, androidId;
tmDevice = "" + tm.getDeviceId();
tmSerial = "" + tm.getSimSerialNumber();
androidId = "" + android.provider.Settings.Secure.getString(getContentResolver(), android.provider.Settings.Secure.ANDROID_ID);

UUID deviceUuid = new UUID(androidId.hashCode(), ((long)tmDevice.hashCode() << 32) | tmSerial.hashCode());
String deviceId = deviceUuid.toString();

If added to ICEmobile-SX with offline capability, it seems possible for the current Safari application to spoof the current domain and allow the unique ID to be used to identify the user across many different web sites. However, if the domain is spoofed, the ICEmobile-SX return URL will be different, resulting in the ID being transferred to a different web page. (In other words, the privacy implications may be accurately exposed to the user.)

Suggestion from Nils: make the ICEmobile-SX version "opt-in" so that the user must manually set the preference to allow this ID to be propagated to the application. This should resolve any privacy concerns since the user must deliberately enable the feature for a particular domain.

This will require implementation of the whitelist feature to complete.