I really don't understand how this is going to work in practice for small side projects with a single part-time developer. How are they supposed to afford implementing all these changes, none of which seem trivial or even practical for your standard little PHP site? So if I run a forum as a side project, what are my options? 1) Spend all free time over the next few months adding these features and neglect any other w…
GDPR – A Practical Guide for Developers (2017)
61–70 of 202 posts
Re: GDPR – A Practical Guide for Developers (2017)
#62God damn it EU, all these regulations make it impossible for small companies, indie developers to cope with all the bureaucracy. The VAT for digital products, now the GDPR. 10 more years of regulation and you will spend 90% of the time working on implementing legal requirements and 10% on the actual product.
Re: GDPR – A Practical Guide for Developers (2017)
#63It's interesting to see how the GDPR seems to clash with some popular data models. For example, git. Rewriting history of a shared branch is disastrous, but it's currently the only way to redact, say, an e-mail address someone committed with a couple of years ago. I'm curious how the various code hosting sides plan to handle that. Perhaps we'll see an extension of the data model that links commits to committer UUIDs,…
Apparently Git is ok by GDPR as data subjects do not have the right to erasure if the information is meant for archiving purposes in the public interest [1]. [1] http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:320... (Article 17)
> [...]
> (d) for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes in accordance with Article 89(1) in so far as the right referred to in paragraph 1 is likely to render impossible or seriously impair the achievement of the objectives of that processing;
(emphasis mine)
I'd not say redacting a git repository does 'seriously impair' processing for archiving purposes. All the data (with the exception of the redacted e-mail) is still there, after all.
Still, the hashes will have changed, making the repo less useful for current users. But that has nothing to do with archival.
Re: GDPR – A Practical Guide for Developers (2017)
#64Earlier quoted context omitted.
GDPR—while vastly different to what has become the defacto standard practice in most companies—is largely simple, basic, common decency and common sense. My very tiny startup won't have any problems complying because we've actually given a smidgen of consideration to our users' privacy up until now. In fact, I foresee it being a much greater tax on large corporations: the work in GDPR is not compliance—that's relativ…
I'd hardly say that. "Forget me" can take a lot of design work (can introduce a ton of edge cases). "Export data" requires building an entire information processing pipeline. Larger corporations have the resources to dedicate to this. But for a small startup deciding between spending 4 dev-months on "forget me" and "export data" versus on enabling the top 3 new primary use cases users are asking for, I understand how…
"Forget me" is very simple: If someone calls you up and asks you to stop using their data, you stop using it and remember that they've done this.
You do not have to:
- Destroy invoices
- Delete web logs
- Delete the record of them asking you to stop using their data
- Reprocess all of your backups
- Recall any reports you might have sent out
Or anything else that is silly. But your salespeople aren't allowed to see that person's details in your CRM anymore.
"Export data" is also very simple for most companies. If you have a CRM containing information about a person, then that person can ask for that information.
> probably less so for a meme generator startup
What possible "personal information" do you think a meme generator startup actually has to collect on individuals that aren't their customers?
They should have a CRM containing companies who are purchasing advertising space on their meme generator startup, and perhaps leads that they have obtained through various incremental marketing sources. They probably do not have any personal information on their users, or if they do, their business will not be impacted by simply not collecting that personal information.
But maybe I don't understand what a "meme generator startup" would do because I'm not in their target market.
Re: GDPR – A Practical Guide for Developers (2017)
#65Lets say I have a bookmark file which contain list of urls. It is associated with one user account. Its likely associated with one person but I cannot identify that person. There is no other information associated with the user account. Is the bookmark file personal data ?
In general, it's probably even sensitive personal data. A list of URLs can potentially identify a person's religious beliefs, sexual orientation, political views etc.
But can he be identified ? I believe if its too difficult to identify using even "religious beliefs, sexual orientation, political views etc" then its not personal data. Though I cant seem to find link to the page where I read it.
On similar note, even IP _alone_ appears to be non personal data if since it cannot identify a person [1].
From Case 582/14 – Patrick Breyer v Germany [2]
On appeal, the Regional Court of Berlin (the "Kammergericht") ruled that IP addresses in the hands of website operators could qualify as personal data if the relevant individual provides additional details to the website operator (e.g., name, email address, etc.) in the course of using the website.
Lol even German Govt cant seem to figure out its own laws. They should have gone to one of those consultants.
[1] https://www.gdpreu.org/the-regulation/key-concepts/personal-...
[2] https://www.whitecase.com/publications/alert/court-confirms-...
Re: GDPR – A Practical Guide for Developers (2017)
#66Earlier quoted context omitted.
Don't store a bunch of personally identifiable data and you don't have to do any of this. We have seen what this laissez faire attitude to "capture everything, delete never" has done. Trust has been supremely squandered so at this point I don't think anyone is particularly inclined to believe when someones cries wolf.
The problem is that pretty much everything seems to be considered personally identifiable data. Any web community will at least be storing usernames, passwords, emails and most likely IP addresses. As far as I know, all of that counts. And even if you don't have a login system, your web server is still going to be logging people's IP addresses.
If you're not using IP addresses for those reasons, you shouldn't collect it. It is good advice to mask off the bottom bits of the IP address since it will still likely be unique enough for you, without being useful to someone who has an unrelated list of IP addresses.
You should probably be doing that anyway: If you get hacked, you're basically giving your attacker a list of targets.
You should be able to delete usernames, passwords and email addresses on request. You should be able to remember that request if you restore from backups. You should not be storing passwords since that puts your users at risk if you get hacked, and you're responsible for keeping their personal data safe.
Re: GDPR – A Practical Guide for Developers (2017)
#67Earlier quoted context omitted.
Yes, for privacy reasons, it’s not appropriate to keep observations on your fellow citizen...
Dear diary, today I had a discussion on HN with tajen. Will HN support erasing your comment history if you ask?
I believe you can already delete your account and comments though?
Re: GDPR – A Practical Guide for Developers (2017)
#68Earlier quoted context omitted.
Small side project means small data too, easy to manually sort out gdpr requests as need arises. No need to automate everything.
True for some parts of it, but what about things like asking for explicit consent, logging each read access to the database or implementing a "restricted" feature? None of these things are supported by most standard software.
That's not to say GDPR isn't a pain, but there's not any significant technical challenges that I know of, it's much more of a challenge in terms of business processes
Re: GDPR – A Practical Guide for Developers (2017)
#69Re: GDPR – A Practical Guide for Developers (2017)
#70Please tell me this is only required when age is relevant, such as for sale of alcohol and tobacco?
Otherwise, surely most data holders don't need a customer's age, and this would be forcing them to collect more personal information!
And personally, as a consumer, I don't want to provide information that isn't relevant, so I'm more likely to use a competitor that doesn't ask for such needless PI.