search

TelemetryDeck / SwiftSDK

Swift SDK for TelemetryDeck, a privacy-conscious analytics service for apps and websites.
https://telemetrydeck.com/
Other
149 stars 31 forks source link

Make `defaultUserIdentifier` public, or supply `clientUser` once somehow #28

Closed mflint closed 3 years ago

mflint commented 3 years ago

Description

I guess that sessions, when implemented, can be filtered by their user identifier. So if a customer sends a support email via my app, I'd like to include that user ID in the body of the email.

Problem

The TelemetryManager.defaultUserIdentifier property is internal - so I can't include it in the email body.

Alternatively...

Alternatively, I could make my own user UUID, store it somewhere, and then supply it with every call to TelemetryManager.send(...). But that's a very repetitive process.

Would it be possible to set a custom user value once - either in TelemetryManagerConfiguration, or TelemetryManager itself - and have that value used for every signal?

(I'd be happy to make a pull request - but would like some guidance first about your preferred approach!)

winsmith commented 3 years ago

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.

winsmith commented 3 years ago

(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)