Barebones CMS

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
GDPR compliant websites (General Data Protection regulations)
Many thanks for the great software, I have everything installed and working well on my personal website. In light of the new GDPR data protection regulations, I'm hoping someone can help me with a couple of things.

Firstly, what is the correct procedure for users to change their email address and password. Before I enabled the email account recovery setting, users had the option to change their details as they signed in. With email recovery in place this is no longer possible. It seems to be one or the other, when it would be useful to have both options available. For the time being, I have added a message in the footer to the effect, if you want to change your details, click 'can't access account' and use the email recovery system, which works but is not very slick.

Under the new GDPR regulations, users apparently have the right to delete the information you hold about them (the account). Is there any way to allow users to remove their data?

Many thanks
Changing the e-mail address and password via the e-mail recovery module requires the extra verification step that the user is actually the owner of the account before they can change that information. If you don't like the current module's behavior, you can always make a new module that does what you want.

Currently, the SSO server/client is partially GDPR compliant as per:

To gain more complete GDPR compliance with the current SSO server, you could create a simple web form that e-mails you when a user wants to delete their account or even obtain details about the information you have on them. You can also apparently charge a reasonable fee for processing GDPR related requests (e.g. the upper limit was about $14 USD pre-GDPR). So, there's an interesting tradeoff between (attempted) automation and making sweet, sweet money to be had here.

Deleting an account is a much more complex process than simply deleting the user account out of the SSO server. Here's why: Many SSO client applications tend to copy data from the SSO server into their respective databases and update the local copy whenever the SSO server provides updated information. And you might not use all SSO client applications with gathered user information. When a user requests account deletion, they mean everywhere. GDPR isn't really the best policy in a SSO-enabled universe (they should have asked me what I thought). The SSO server is just the primary arbiter of information but other systems interacting with the SSO server may maintain their own copies for system performance and understandable logistical reasons. The API keys carefully control which fields are accessible to each SSO client so no more information is provided than needed by the respective application. In many ways, the SSO server already handles most of the requirements of GDPR out of the box as long as you aren't spamming the inboxes of your users.

There is, of course, room for improvement. To make the SSO server more GDPR compliant with streamlining user deletions will likely require adding a new database table for tracking deleted user IDs (just the integer) and an API and SSO client interface for requesting deleted IDs so that SSO client applications can run regular cron jobs to delete information from their databases and repeat the process for anything downstream of them. In addition, an audit log table of the last action per user per API key in the SSO server would help with GDPR compliance too - it would allow the user to access a single screen containing every application they've allowed to use their information and what information has been made available to the application.

I doubt there's such a thing as complete GDPR compliance. This checklist covers the highlights:

If someone requests a deletion of a Google account, does that make any website that accepted that account responsible for deleting the account information too? Imagine the propagation nightmare that would ensue - millions of websites would have to query Google's servers daily to get the latest list of deleted accounts just in case someone deleted their account. And if you miss just one account, you are liable for the hefty penalty for not deleting. GDPR, depending on the interpretation, may completely kill off "Sign in with Google" and other social providers. I'm kind of playing that aspect by ear at this point because no one has really put GDPR to the test (yet). GDPR might put a real damper on those one-click sign in mechanisms. We'll have to go back to ye olde "sign up with your e-mail address only" mechanisms where verification e-mails don't arrive because e-mail is unreliable.
Author of Barebones CMS

If you found my reply to be helpful, be sure to donate!
All funding goes toward future product development.

Forum Jump:

Users browsing this thread: 1 Guest(s)