Sentry: Support the DNT policy

[dcramer]

Discussion to support the DNT policy:

https://www.eff.org/dnt-policy
https://www.eff.org/privacybadger#faq--I-am-an-online-advertising-/-tracking-company.--How-do-I-stop-Privacy-Badger-from-blocking-me?

What would this look like?

• It'd be located at //sentry.example.com/.well-known/dnt-policy.txt
• We would not automatically capture the IP address from SDKs (we mostly don't do this already)
• We could forcefully scrub IP and User context from events (this might not be acceptable, and could be crossing the line since the customer controls their data). We could at least make this an opt-out/opt-in option.
• We'd apply this to sentry.io (though it might not be a concern given everything's opt-in already)

[lightswitch05]

There is a technical implementation guide here: https://github.com/EFForg/dnt-guide#eff-how-to-implement-dnt-guide

[dcramer]

Some notes:

DNT Users are opting out from tracking across the Web. It is possible
that for some feature or functionality, we will need to ask a DNT User to
"opt back in" to be tracked by us across the entire Web.

Seems like given we already require opt-in, that we might be safe here. One caveat is how this affects our terms. I'm fine with saying the terms require opt-in, which is also how it works today. I imagine this is also how any reasonable business would implement things.l

That said, we'll need to evaluate how this affects our logs for sentry.io. That might make this a non-starter, and frankly tracking a users behavior (server-side) is a serious security requirement that we may not be willing to forego. 10 days is not nearly enough history when security incidents can often be identified months after the original incident, and logs are crucial to understanding the event.

Update: Upon further reading, its unclear that DNT implies "you cannot track me at all after 10 days" or simply that we must anonymize to a larger degree (fuzzy to >5000 users). If the latter, we might be ok to compromise there.

[lightswitch05]

Maybe someone from the EFF and Privacy Badger could answer these questions. @ghostwords do you answer DNT implementation questions?

[ghostwords]

cc @alanton

[dcramer]

There's still security concerns around DNT not supporting us storing IP addresses, but I wanted to post a couple updates:

• Sentry complies with GDPR's requirements universally (we dont barrier any of it on country of origin)
• We now provide a feature to completely scrub IP addresses from incoming events. This is still controlled by the customer but its the maximum we'll do there.

We have a bunch of compliance stuff to do going into the new year, so that'll be an appropriate time to revisit if we can hash IP addresses (hitting our web servers). Given an attack from a single IP needs to be audited over a long period of it, it's possible we'll side the risk is too much.

[dcramer]

It sounds like -- technically speaking -- our SDK ingestion complies with DNT with the caveat that its up to the customer whether they store PII or not. That means ultimately its up them if they're DNT compliant, not us. We could potentially provide an option to ease compliance, but that shouldn't really dictate whether they are or are not.

Of note, SDK ingestion is constantly what this "stop blocking Sentry" battle is over.

In a hypothetical world where we let the user have an easier way of configuring this we could:

1. Provide a "Don't store events from users enabling DNT"
2. Provide a "Don't store anything user specific from users enabling DNT"
3. Provide a way to "delete events after 10 days from users enabling DNT" (or whatever the equiv we'd do for logging, which ideally is anonymize, not delete)

[dcramer]

https://developer.mozilla.org/en-US/docs/Web/API/Navigator/doNotTrack

[dcramer]

cc @cameronmcefee @adhiraj this is a pet project at this point but just want to give you a heads up as I might spend some spare cycles to get us closer to implementation.

[untitaker]

FWIW the newer SDKs do not capture IP addresses or really any user information (email address/username/userid) by default. There's an option called send_default_pii to undo this behavior, but this is basically up to the customer.

Most recent discussion of this is at https://github.com/getsentry/sentry-docs/pull/814 where it seems that websites are breaking when the SDK is not loading.

[BYK]

Closing this issue due to staleness. Feel free to comment here if you think we should still work on this.