Following our blog post on GDPR, this is a thread dedicated to conversation around GDPR compliance: the challenges we face, the steps we need to take, and what being compliant means.
Feel free to discuss GDPR preparation, challenges, and and interpretations of the rights and obligations outlined for data subjects within the legislation.
For instance, we are very interested in helping our users not only have the technological mechanisms in place to serve data related to user requests, but the operational proofs and processes to clearly demonstrate compliance under any scrutiny.
Feel free to ask us any questions you might have about how we’re handling GDPR internally, as well.
Thanks @antman! I wanted to share the first couple of pieces of open-source work that we are doing in preparation for GDPR and ePrivacy. We’d love feedback on these or any other GDPR-related ideas:
PII enrichment in Snowplow
Pseudonymization or masking of PII, whether through hashing or encryption, is an important building block in addressing concerns around the processing of personally identifiable data.
This feature idea for Snowplow has been around for some time, but with GDPR on the horizon we have now specified it and our own @knservis is now working on this.
Tracking user consent
We are planning on tracking user content with a pair of new event types - the corresponding methods for the Snowplow JavaScript Tracker are being specified here:
A little bit of an odd question but should trackConsentGranted and trackConsentWithdrawn have the option of sending a consent token in the schema to enable some kind of signing on the request?
This would in theory make it more difficult for someone to accidentally or maliciously consent by forging a request with the right parameters (document, user_id)
Another thing to possibly capture might be the way in which consent was given or revoked - most of the time this will probably be through the web but could be over the phone, via email or SMS. Does this belong in an event? Is there a way to capture changes in consent if a proxy (autonomous or otherwise) acts on behalf of a user?
It’s an interesting idea. My gut says that it would be better to cover this as part of our general “authenticated events” RFC (hopefully coming soon), but maybe there’s something about consent events in particular which makes them different.
Adding a placeholder ticket to consider this further:
To your next point:
Is the thinking here that maybe consent is granted via e.g. SMS, and then some Java code or similar would read that from Twilio and emit the consent event into Snowplow? I can see that you would want to capture that, but it feels very open-ended - maybe at that point you’d need to attach an additional company-bespoke context?
Yes - it sounds like authenticated events would be a good fit for this.
You might need something company specific here as it is quite open ended (e.g., a user calling up for support may need to grant consent to a support agent) or alternately (in the case of an autonomous agent) you might have a script that logs in to services to revoke consent - that might be too specific.