Use Advertising ID instead of Android ID.

[georgiev-martin]

https://github.com/bugsnag/bugsnag-android/blob/master/src/main/java/com/bugsnag/android/DeviceData.java#L140

[kattrali]

This is a nice catch, @georgiev-martin. Since identifier implementations tend to vary between manufacturers (and Android ID is now deprecated), it is best to replace it. The better implementation is probably to generate and persist a UUID for the device rather than use the advertising identifier though, since play services may not be available (on Amazon phones, for example).

[snmaynard]

The issue with changing this is that when customers update to use the new version we will suddenly count additional users affected by issues as the default user id will have changed

[kattrali]

True, but it's known to not be consistent (nor unique in some cases), already. Persisting an ID going forward would allow us to have a fallback in the case that we change the behavior incrementally.

[d4rken]

Is this really an issue at the moment? In what way does this change help you @georgiev-martin ?

@kattrali Where is it depcrecated? http://developer.android.com/reference/android/provider/Settings.Secure.html#ANDROID_ID

I agree with @snmaynard that changing it would skrew the backend and it's tracking over.

Going into the future the AndroidID should become more and more reliable as buggy devices drop out of use (assuming newer devices are not worse) and if desired we can already use Client.setUserId(String) with a self persistet UUID.

[kattrali]

@kattrali Where is it depcrecated?

@d4rken I miswrote, I meant Advertising ID. :)

[snmaynard]

As we don't want to double count the users affected by a bug when people upgrade to a new version of a notifier, and that the AndroidID seems to be working well for us right now - I'm going to close this issue.

[felipecsl]

I'd like to resurrect this issue again as this was just flagged to us as a security issue, please see the explanation below:

Android_ID is a 64-bit number (as a hex string) that is randomly generated when the user first sets 
up the device and should remain constant for the lifetime of the user's device. In should be noted 
that Google has introduced the Advertising ID for the exact same purpose. The advertising ID is a 
user-specific, unique, resettable ID for advertising, provided by Google Play services. It gives users 
better controls and provides developers with a simple, standard system to continue to monetize 
your apps. It is an anonymous identifier for advertising purposes and enables users to reset their 
identifier or opt out of interest-based ads within Google Play apps.

[snmaynard]

We could have a configuration option that people could opt in to switch it over. I'm a little concerned that changing the user id will double count all users affected as Bugsnag will see the same user with a different id. Maybe having some kind of option will solve this.

[felipecsl]

sounds like exposing this as a configuration parameter would be the best option

[d4rken]

I don't think we need an extra configuration parameter.

We generate a random UUID, save it and use that to identify installs.

To transition to this we detect if an app is was upgraded and does not have a UUID yet, if so we generate the new UUID based on the Android_ID. For new app installs we generate a completely random UUID. This way we don't generate duplicates on current deployments due to the code change.

Now from that point on, by default, bugsnag tracks by install (new app installs means new generated UUID). It's good for peoples peoples privacy and if someone wants to still track across installs, something like Android_ID can still be used with setUserId. We can add some info about this to the docs. The only caveat is that with the old way (Android_ID) a user could reinstall the app, crash it, and still be recognized as the same user... I think due to factory resets, modding and chinese phones, this number may be skewed anyways.

The difficult part is finding out if we are a new install or an upgrade, to know whether we need to use the Android_ID one last time to generate a UUID.
AFAIK Bugsnag does not create any kind of file, so we can't check that.
We could compare PackageInfo.firstInstallTime and PackageInfo.lastUpdateTime which are equal if the app was not upgraded.
The caveat is that these fields are API9+, so on devices with API4-8 we would generate duplicate users... but I don't think there are too many of those.

This would solve @felipecsl concerns over the Android_ID and minimize @snmaynard concern about duplicating the user counts.

I don't think this is a security concern, but rather a user privacy issue and I'm in favor of having the default configuration be the one with increased privacy.

Thoughts on this?

[JakeWharton]

👍 to having no configuration. Configuration should always be a last
resort, not a first, since inevitably you're exposing the ability for more
people to do a wrong thing.

On Fri, Sep 2, 2016 at 2:05 PM Matthias Urhahn [email protected]
wrote:

I don't think we need an extra configuration parameter.

We generate a random UUID, save it and use that to identify installs.

To transition to this we detect if an app is was upgraded and does not
have a UUID yet, if so we generate the new UUID based on the Android_ID.
For new app installs we generate a completely random UUID. This way we
don't generate duplicates on current deployments due to the code change.

Now from that point on, by default, bugsnag tracks by install (new app
installs means new generated UUID). It's good for peoples peoples privacy
though and if someone wants to still track across installs, something like
Android_ID can still be used with setUserId. The only caveat is that with
the Android_ID a user could reinstall the app, crash it, and still be
recognized as the same user, but due to factory resets, modding and chinese
phones, this number may be skewed anyways.

The difficult part is finding out if we are a new install or an upgrade,
to know whether we need to use the Android_ID one last time to generate a
UUID.
AFAIK Bugsnag does not create any kind of file, so we can't check that.
We could compare PackageInfo.firstInstallTime and
PackageInfo.lastUpdateTime which are equal if the app was not upgraded.
The downside is that these fields are API9+, so on devices with API4-8 we
would generate duplicate users... of which I don't think there are too
many...

I don't think this is a security concern, but rather a user privacy issue
and I'm in favor of having the default configuration be the one with
increased privacy.

This would solve @felipecsl https://github.com/felipecsl concerns over
the Android_ID and minimize @snmaynard https://github.com/snmaynard
concern about duplicating the user counts.

Thoughts on this?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#83 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEEEcL-oStNNhKCv1Sy9_q_nIPzMahOks5qmGVUgaJpZM4Gxicr
.

[felipecsl]

Yep, this is ultimately a privacy issue. Having it UUID based works for me too, I don't have a strong opinion on the actual implementation details.

[felipecsl]

Any update on this?

[d4rken]

Implemented my idea of this in #141

[d4rken]

Android O changes ANDROID_ID behavior:
https://developer.android.com/preview/behavior-changes.html#privacy-all

[fcduarte]

@kattrali any news about this issue?