Sentry seems to defaults to a random, persistent user ID which is attached to error events and other sentry data. This is appears to be a persistent app installation ID.
For metrics, we are taking steps to minimize user tracking by using a random ID and rotating that ID each UTC month.
I think we should do the same for the ID used by Sentry, to avoid a persistent identifier being attached to Sentry data. To do this, I think we need to call Sentry.setUser({ id: ourRandomId }) immediately after Sentry.init() is called.
For metrics, we are hashing a permanent ID with the UTC year and month to get the "monthly ID", but hashing is async, and we want this immediately for Sentry.
I suggest we just generate a new random ID each UTC month, e.g.
Sentry.init()
const storage = new MMKV()
let sentryId = storage.get('sentry.id')
const sentryIdMonth = storage.get('sentry.idMonth')
const now = new Date()
const currentUTCMonth = now.getUTCYear() + '-' + now.getUTCMonth()
if (!sentryId || sentryIdMonth !== currentUTCMonth) {
sentryId = generateRandomId()
storage.setItem('sentry.id', sentryId)
storage.setItem('sentry.idMonth', currentUTCMonth)
}
Sentry.setUser({ id: sentryId })
Sentry seems to defaults to a random, persistent user ID which is attached to error events and other sentry data. This is appears to be a persistent app installation ID.
For metrics, we are taking steps to minimize user tracking by using a random ID and rotating that ID each UTC month.
I think we should do the same for the ID used by Sentry, to avoid a persistent identifier being attached to Sentry data. To do this, I think we need to call
Sentry.setUser({ id: ourRandomId })
immediately afterSentry.init()
is called.For metrics, we are hashing a permanent ID with the UTC year and month to get the "monthly ID", but hashing is async, and we want this immediately for Sentry.
I suggest we just generate a new random ID each UTC month, e.g.