WOW what a ride! Some 200 days has passed since I first started reading EU General Data Protection Regulation, finding GDPR friends in the WordPress COmmunity, and seeing the project take form inside WordPress core.
The day has arrived – 25th of May – I’ve said that date quite a few times now, and although it’s an important data as the deadline has kept us focused in our work – the work is not at all “done”.
Our work continues, and updates to the current GDPR hooks and filters you will find in WordPress code as well as backend tools for site administrators, are first versions of the central tools. Many more to come I suspect.
One such tools is a logging feature which we started working on at Peytz when we where still had about 50 days to go before the 25th…
Although you see a logging feature as part of the current GDPR tools in admin, these do not meet the requirements of logging, in terms of the regulation.
Therefore we’ve set out to define an logging feature that can hook into WordPress actions allowing developers log actions performed in code
– separated from the database
Wait – what: re-actionable and separated from the database. That sounds messy!
Well, yes, and it’s not strictly WordPress but let me explain.
To make a log compliant with GDPR, we need to make sure that it does not hold any information that can identify a natural beeing.
We also need to maintain a log that is not part of the data it’s logging.
This makes for an external logging mechanism you can put data into, and also query to fetch previous actions performed on certain data.
A unique but non-personal hashed value will serve as an ID. One that only make sense if a user provides the personal data on which the hashed value has been created.
Stay tuned for more information after today 🙂
Am I poud? Hell ya. Did i code a single line – nope 😉
But nonetheless, my team has spend roughly 125hours to help out on this project that we gave birth to. The project was adpoted by the WordPress community and the result is now in Beta for the upcoming WordPress 4.9.6 version:
I’m quite sure, by know, you know that I’m heavily invested in GDPR. Specifically when it comes to looking past the law texts surrounding the regulation, focusing on providing the actual tools needed to comply with the new lives of a website administrator after May 25th, 2018.
Another thing is how to handle the request your users are now permitted to bring before you because of the General Data Protection Regulation.
Yes yes yes – I’m STILL talking about:
- What data do you have on me?
- Can you provide me with a copy of the data you have on me(readable, and machine-readable?)
- Can you allow me to make changes to the data?
- Can you please delete or otherwise anonymize the data you have on me so that it is no longer data that points to me as a human being?
- Do you have means of notifying me and the appropriate authority within your country if a data breach occurs?
- Can I retract consent previously given to you partly or in full?
- Do you have a log in place that collects any interaction I might have on your system when it concerns personal data and given content on my part?
- How do you handle if a backup with my data is re-introduced after I’ve asked for deletion?
- How do you handle if a 3rd party element of your website changes it’s compliance texts and ways they use any data your website might share with them ?
Soo many questions – many are possibly easy to answer from a technical standpoint, and some might not even require a technical solution – a simple written Todo might be sufficient in some cases.
For WordPress at least, we’re making real headway with since the GDPRWP.com project has been adopted by the community and now lives inside WordPress Trac tickets – being actively developed by the community – something I’m quite happy with 🙂
Interested in GDPR in relation to your website?
Please don’t hesitate – reach out
Kåre Mulvad Steffensen
In December 2017 together with Peter Suhm from WPPusher.com, we’d just launched the basic idea of a PHP object Interface to tackle the upcoming GDPR challenges. Our Ideá was that a common interface adopted and implemented by the general community of WordPress would ensure a unified way of identifying Personal Data, and this makes it possible for the ecosystem to create plugins utilizing this interface to provide the needed tools for Website administrators to uphold the law of the regulation.
GDPRWP.com was live and a GitHub repository to go with it, with a basic readme file to explain the idea. With the help of Peters contacts, we got a few articles on WPTavern which lead to this interview for the monthly Meetup in Porto, Portugal.
This is the full article about the meetup:
Since then, the GDPR for WP project has moved forward, and to focus more on how WordPress is doing things, it’s not a strict PHP interface anymore.
The carefree “let’s code this stuff, and ask visitors for their names and personal preferences” so that we can ____ is over!
In about 192 days from now, EU General Data Protection Regulation will protect any personally identifiable information on any EU citizen, anywhere on the web – no matter where in the world your company or server is located.
I’ve been reading through the final text of the regulation, and the more I read, I feel the urge to remove the “EU” from the name of this regulation. It may be a massive regulation already, and how it’s going to be enforced by various controlling bodies within the EU alone is anybody’s guess. But from a personal perspective, in a world where big data is used more and more to target users in both commercial and political situations, this law lay the foundation that should reach across borders.
GDPR is coming – in one form or the other. If not from the top, then from the people fed up with the non-transparent usage of their personal data.