4 ms·

This is a bit troubling as an iPhone developer. It'd be nice to be able to keep a profile on your users not for the purposes of advertising, but for the purpose

by jonpaul 16y ago

This is a bit troubling as an iPhone developer. It'd be nice to be able to keep a profile on your users not for the purposes of advertising, but for the purposes of developing meaningful use-case metrics. I suppose the proper thing to do would be to provide a opt-int one-time popup prompt that notified users what you were planning to do... sort of like Visual Studio, Netbeans, or Eclipse in what they do. Any thoughts on other ways for developing analytics for parts of your app?

fmkamchatka 16y ago
It feels also troubling since having Ads in your app simply expose you to these complains since the advertisement SDKs are sending whatever data they want and you have no control on it.
- extension 16y ago
  Though you do have control over which 3rd party code you drop in your app (unlike your users).
  - fmkamchatka 16y ago
    You don't have that many options if you want to provide the user with a free ad-supported application. I bet almost all ad networks are using the UDID...
bbatsell 16y ago
I don't think there's much problem with Apple providing a unique ID to an app — the problem is that Apple is providing a unique ID that's universal to every single app, making it far easier for some very troubling data correlation and identification by third-party services. Just a simple hash of the UDID and an app's bundle ID would probably be sufficient. Edit: Now that I think about it, it would probably need to be a salt that Apple keeps privately — since bundle IDs are known and UDIDs are fixed-length, those that really wanted to could brute-force UDIDs out of the resulting hashes.
- Xuzz 16y ago
  Probably would be better to use a vendor-specific salt, so you can compare users between your application. Since the UDID is just SHA1(SerialNumber + IMEI + WiFiAddress + BluetoothAddress), adding in a "vendor ID" at the end when generating it was a huge mistake in the original iPhone SDK, and they can't fix it now.

by jonpaul 16y ago

fmkamchatka 16y ago

It feels also troubling since having Ads in your app simply expose you to these complains since the advertisement SDKs are sending whatever data they want and you have no control on it.

extension 16y ago
Though you do have control over which 3rd party code you drop in your app (unlike your users).
- fmkamchatka 16y ago
  You don't have that many options if you want to provide the user with a free ad-supported application. I bet almost all ad networks are using the UDID...

bbatsell 16y ago

I don't think there's much problem with Apple providing a unique ID to an app — the problem is that Apple is providing a unique ID that's universal to every single app, making it far easier for some very troubling data correlation and identification by third-party services. Just a simple hash of the UDID and an app's bundle ID would probably be sufficient. Edit: Now that I think about it, it would probably need to be a salt that Apple keeps privately — since bundle IDs are known and UDIDs are fixed-length, those that really wanted to could brute-force UDIDs out of the resulting hashes.

Xuzz 16y ago
Probably would be better to use a vendor-specific salt, so you can compare users between your application. Since the UDID is just SHA1(SerialNumber + IMEI + WiFiAddress + BluetoothAddress), adding in a "vendor ID" at the end when generating it was a huge mistake in the original iPhone SDK, and they can't fix it now.