Make `defaultUserIdentifier` public, or supply `clientUser` once somehow about swiftclient

[winsmith]

(If you don't mind, I'm closing this ticket since #30 describes better what can be done in code, but feel free to continue the discussion)

[winsmith]

Hi @mflint, thanks for asking.

Providing a way to supply a default user is definitely on the roadmap. It gets repetitive and error prone to supply a user identifier each time if it's not the default one. It is one of the very next things I want to tackle in the Swift Client.

The TelemetryManager.defaultUserIdentifier is based on UIKit's identifierForVendor property where available, so you could in theory just query that, but here's where you're starting to bump up against one of the core principles of AppTelemetry:

The user identifier, whatever it ends up being, is hashed once on the client device, and then once more, with a secret salt, on the server before the signal is saved. This is because only if it is not possible for you as the developer, nor for us as the people who have access to the database to recreate the link between the person who is your customer and the data in our database... only then it is considered anonymous as defined by the GDPR and CCPA.

In other words, we're making it hard or even impossible for your to find out a link between signals and actual users because otherwise that signal data would fall under GDPR and you'd have to disclose that to your users in your privacy policy. (I am not a lawyer, this is not law advice, check with a lawyer to see if you have to do additional disclosures like showing a consent banner)

If you want to purposefully establish a link between signals and your users, you can use the payload metadata for that: Generate a custom identifier and pass it along in the payload metadata. Your signals will then no longer be anonymized but pseudonimized. Make sure you comply with the GDPR and CCPA if you do this.

Ticket #30 might help you there, I'm hoping to implement it soon.

Again, thanks for your question. This is probably not exactly the answer you want to hear, but it helped me think about our position on this. If we ever build a sister system to AppTelemetry whose purpose is crash reporting, the defaults might be different there.