Thanks. This is pretty relevant to work I have upcoming.
GDPR for developers
Came across this while digging around for a more practical guide on how we can think about implementing code/procedures around the GDPR. Didn't want to bump one of the old threads, so just posting here in case anyone else finds it useful :-)
@Mick79 oops - clicked the correct answer button (again) instead of the thumbs up one :-). Have some points anyway :-).
GDPR-wise the really nasty bit for me is the 'restrict processing' part - the anonymisation/export stuff is all quite straightforward, but having to have a flag that prevents users being processed (or even seen) is a bit of a pain. I'm leaning towards some kind of global scope at the moment - but it's just kind of 'masking' the problems as everything needs to become 'restricted processing' aware :-/
At the first point I am already a bit lost, the forget me part. He is talking about deleting users and nulling all foreign keys on an order table for example.
But what I have been told by a (Dutch) lawyer "specialized" in this ( as far as anyone can call him or herself specialized on something as vague as the GDRP in these early stages ). Is that making a user not recognizable as an individual reallife identity/person is enough.
So renaming all "deleted" to John Doe, assigning "Acme" addresses is enough and at that point you can leave the database ID intact.
A bonus is that your access log to that john doe is still intact as well.
That goes for enumerating numbers (PK auto increment), would still mean that one is pretty fucked when you only use natural keys everywhere on columns like SSN's like they teach you on university.
As far as data retention goes, you can still keep data for a loong while as long as you have stated it in your terms and have probable reasons for it. E.g. in ecommerce customers have a warranty period but that can be limited to the customer (person) that made the purchase.
So anonymizing data is only needed on records that have no active use what so ever anymore to use cases that are needed to satisfy any rights a user may have as defined in the laws of a country. (tax, warranties etc)
What do you guys think about this or what have you heard? Am I completely wrong? I am curious to learn more or to be corrected if my information is completely off.
@DirkZz the legal advice we've had is that anonymising the user is probably good enough. But no-one is quite sure yet - and I guess no-one wants to be the 'test case' ;-). I've taken the fairly simple steps for user accounts and just changed the username/email/etc to be 'ANON{$ID}' so that the user isn't identifiable as a 'person' any more, but I don't need to go through null'ing lots of data.
I'm not quite sure what to do in cases where the user has identified themselves though (like on here if I signed this post with my real name in the body of the post). My username would be anonymous - but my data would still be there. So I think having a fall-back of deleting (or at least emptying) all the data might be needed if users can do that kind of thing.
Keeping data around is, again from the advice I've had, is to keep it as long as you require for legitimate business purposes - but no longer. So if you need to keep it around for insurance, legal reasons - whatever - then you're fine. If you keep it around for 10 years just because you might want to send them a 'hey - we haven't heard from you in a while' marketing email - then that's not ok.
The 'prevent processing' is still my main issue. I have lots of reports, mailing list generators etc that scan the users table - which all have to become 'processing' aware now. Which isn't quite so bad if everything is in Laravel - but when I've got a python script that does something, a bit of Perl to mangle some DB->CSV stuff, storage allocation etc - then it become quite annoying to do. I've got some systems where the data is 'copied forward' each year (eg, duplicated but with a '2017/2018', '2018/2019' flag for the current year) - but if the user has asked that their data isn't processed - do I skip their record and all relations? I don't know - it would make the DB a bit of a mess if they then said it was now ok to process their data - coping it forward into a changed DB would be a royal pita :-/
Great article link đ
Hey!
I wonder how the dust settled for Laravel community? What you guys are using to make your projects GDPR compliant?
Found this: https://github.com/sander3/laravel-gdpr
What else?
@aurawindsurfing, what else... (context: my wife is one of the founders in the industry of REGTECH)... do NOT force a user to make a choice, only prompt. For example TONS of sites show the notice forcing you to agree. NOT actually compliant.
@webrobert A choice/prompt regarding what exactly?
I may be misunderstanding what you mean by âchoiceâ and âpromptâ, but if youâre talking about cookie consent, for example, forcing the user to make a choice (e.g., between âAccept Allâ and âNecessary Onlyâ, or between âAcceptâ and âRefuseâ) is compliant, and forcing the user to agree (by only giving the âAgreeâ option) is also compliant if you only use strictly necessary first-party cookies on the site.
Complying with legal requirements is not something that can be magically achieved by installing a Composer package.
for example, forcing the user to make a choice (e.g., between âAccept Allâ and âNecessary Onlyâ, or between âAcceptâ and âRefuseâ) is compliant.
@kokoshneta that is not compliant and is an infringement according to the authorities the Cookie Banner Taskforce talked to in their report, they did that report last month on Cookie Banners, and to quote a portion of the report.
a vast majority of authorities considered that the absence of refuse/reject/not consent options on any layer with a consent button of the cookie consent banner is not in line with the requirements for a valid consent and thus constitutes an infringement.
@thinkverse So youâre saying the EDPB website that carried out and hosts the report you linked to is itself not compliant? Their cookie options force the user to make a choice between âAccept cookies for aggregated statisticsâ and âNo thanks, only essential cookiesâ, which is precisely the type of choice I described, and which you say is an infringement.
I havenât read the report in details, but a quick read-through does not bear out your assertion that such a consent banner is not compliant. The section you quoted is explicitly not the type of banner I was describing, since both scenarios I described contain refuse/reject/not consent options.
Its about correct interpretation, notice how its does here...
https://gdpr.eu You can click NO. and not agree. you are not forced to agree to anything.
the real problem is this whole field is like trying to heard cats.
So going to the EDPB site... https://edpb.europa.eu/
They force a selection "No thanks, only essential cookies." No Bueno.
But if you read their about....
The European Data Protection Board (EDPB) is an independent European body, which contributes to the consistent application of data protection rules throughout the European Union, and promotes cooperation between the EUâs data protection authorities.
They are doing their best.
My wife consulted the GDPR on the actual laws. My best practice, have the popup but let the user close it without making a choice. [though the gdpr site doesn't do this either]
EDIT: and clearly the gdpr.eu site did remember I clicked NO because when I revisit the popup doesn't come back. ha.
@kokoshneta aah, I read that as either having a Accept All or Necessary Only or Reject meaning automatic opt-in, didn't notice the and there, my bad. đ¤Śââď¸
@thinkverse yeah it's their report and "#6 bad practice no reject button" and they don't have one.
@webrobert When I open gdpr.eu, I donât get any cookie consent banner at all. I donât recall visiting the site recently, but I see that there is a compliance_hide_a session cookie set, so perhaps I did.
More importantly, though, where are you getting that providing an âexitâ option on cookie banners is required to be GDPR/EPD compliant? The GDPR page on cookie compliance does not mention this, nor does (as far as I can tell) the EDP itself.
Yes, itâs good practice to allow the user to close the prompt without making a choice, but I cannot find any indication that it is a requirement in order to be compliant.
yeah it's their report and "#6 bad practice no reject button" and they don't have one.
They do have one. âNo thanks, only essential cookiesâ is a reject button, since essential (= strictly necessary) cookies do not require consent.
They do have one. âNo thanks, only essential cookiesâ is a reject button, since essential (= strictly necessary) cookies do not require consent.
again, interpretation, who am I? but a man. I write contracts in business and to me, that is not a reject button. I am being forced to agree to essential cookies. It's a tricky legal thing. Reject is reject... "NO"
And, let me clarify, I didn't say compliant, I said my best practice. Where did I get it. I live with my wife. đAnd for literally years she has been saying (every time I'm near her and she opens a site that forces a choice), "that is not correct". So though there is a new report (the one being talked about here) that does clearly say it is bad practice. She was there years ago when the GDPR laws were being authored.
Let me see if I can summarize the issue as I understand it.
No one has the right to force their views or opinion on another. When a site forces you to agree they are breaking the law. This is clearly over stated but I think it puts color on the actual issue.
So storing an essential cookie is legally ok. BUT forcing me to agree to it is not. Make sense? This is the crux.
which explains why the gdpr site didnt ask me to agree to storing an essential cookie. They just did it. They can. But they did let me NOT agree to [whatever the notice is about]
@martinbean for sure! but I was just wondering if there was some comprehensive guide of what to install and what to do, step by step ;-)
@aurawindsurfing đ
@webrobert wishful thinking ;-)
Please or to participate in this conversation.