Live data from Hacker News

GDPR – A Practical Guide for Developers (2017)

techblog.bozho.net

91–100 of 202 posts

Re: GDPR – A Practical Guide for Developers (2017)

#91

It'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)

And it's also protected by the right of freedom of speech: the entity operating the git server has the right to inform the public of who committed which changes. The GDPR explicitly recognizes "exercising the right of freedom of expression and information", although I'm not sure how European courts would interpret this provision. But for an American entity without a physical presence or assets in Europe, any EU judgment would be quickly quashed by American courts.

Re: GDPR – A Practical Guide for Developers (2017)

#92
post #67
post #55

Earlier quoted context omitted.

Dear diary, today I had a discussion on HN with tajen. Will HN support erasing your comment history if you ask?

If you're a European citizen, in a couple of months they'll legally have to (assuming they don't want to just ignore any European court judgements, which is possible but risky). I believe you can already delete your account and comments though?

Plus Hacker news doesn't ask for personally identifyable information in order to use it, unless you choose to put your full name in as a user.

Re: GDPR – A Practical Guide for Developers (2017)

#93
post #84
post #62

Earlier quoted context omitted.

So what's the alternative? Completely lose all of your privacy? It is only developers who can fix this massive PPI leaking.

There's plenty of alternatives. The main problem with GDPR is not the goal of advocating privacy but the details. I would have done it like this: a) bring out regulation gradually instead of in a single big change like GDPR to have companies time to comply b) don't write vague laws c) give specific examples of what GDPR means in practice d) be more lenient on smaller companies

a) companies had 2 years go comply. Furthermore, the guidlines of the European Commission are clear that the process should be gradual - inspect, write recommendations, small fines, bigger fines. Nothing like "20 million in June"

b) the law had to cover a lot of usecases and in order to do that concisely, it may sound vague in places. I also don't like (developers never like uncertainty), but there's established practice already in regulators and courts about what is considered "adequate", "appropriate", etc. I agree it could've been better though.

c) that is happening already, e.g. ICO (the UK regulator) has a pretty good set of guidelines and examples. There's also the process of "prior consultation" where if you are not sure about something, you go ask your regulator for a decision

d) this is exactly what the "proportionate", "adequate", etc. are in for. If you are a small company with 2000 data records, you are not posing a high risk for the rights and freedoms of data subjects and so most of the things are not a strict requirement

Re: GDPR – A Practical Guide for Developers (2017)

#94
post #81
post #73

Does the GDPR state that all this needs to be automated? Given how infrequently a small business will get requests to delete, restrict or export data, is it allowed to just do it manually when requested by email?

The GDPR does not state that it needs to be automated. I assume SME's will also not automate this unless they get a lot of request. Basically all features that are required by the GDPR are already in most common SME software.

In that case, the GDPR actually sounds quite positive - I believe users should be able to request that their data is deleted, and be told in advance if it's going to be used for anything non-obvious (e.g. training an ML model).

Re: GDPR – A Practical Guide for Developers (2017)

#95

Earlier quoted context omitted.

I didn't realize it until reading this post, but certain very popular technologies break GDPR in a deep way. Bitcoin, for instance, contains a wealth of personal information, which by design are both public, persisted forever, and immutable. Are blockchain products all going to need a full rewrite or a complicated hard fork? What about the Wayback Machine? Will they need to have an endpoint that every company will ne…

What personal information does bitcoin contain?

All payment orders and credit transfers to and from all accounts.

For any Bitcoin address you find on the Web.

Re: GDPR – A Practical Guide for Developers (2017)

#96
post #84
post #62

Earlier quoted context omitted.

So what's the alternative? Completely lose all of your privacy? It is only developers who can fix this massive PPI leaking.

There's plenty of alternatives. The main problem with GDPR is not the goal of advocating privacy but the details. I would have done it like this: a) bring out regulation gradually instead of in a single big change like GDPR to have companies time to comply b) don't write vague laws c) give specific examples of what GDPR means in practice d) be more lenient on smaller companies

> a) bring out regulation gradually instead of in a single big change like GDPR to have companies time to comply

GDPR wasn't announced yesterday. The time span between announcement and implementation date is over two years. Of course if you only start now there isn't much time left, but then that's your own fault.

Re: GDPR – A Practical Guide for Developers (2017)

#97
post #91

Earlier quoted context omitted.

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)

And it's also protected by the right of freedom of speech: the entity operating the git server has the right to inform the public of who committed which changes. The GDPR explicitly recognizes "exercising the right of freedom of expression and information", although I'm not sure how European courts would interpret this provision. But for an American entity without a physical presence or assets in Europe, any EU judgm…

And Facebook has the right to 'inform' another company about all data it collected from its users (only in exchange for a nice sum of money!)

Except in the EU, freedom of speech and privacy are both considered human rights, which need to be weighed against each other. Freedom of speech will win when someone uses the GDPR to try to censor e.g. an online news article with some personal facts. But it won't for my Facebook tongue-in-cheek example, and I doubt it will for the redacted committer example either.

Re: GDPR – A Practical Guide for Developers (2017)

#98
post #88
post #54

I just want to point out that a lot of the article is the authors own opinion on how the regulation should be implemented into software and a lot of things are probably not needed normally and would be a burden for businesses. My own take (and the take of most European data protection lawyers I meet) is that consent is not needed, and also possibly is inappropriate in 90% of the cases - instead the “legal basis” call…

A few clarifications (author here) 1. yes, you are correct, most of the features don't need to be implemented in code and having documented procedures would be sufficient (and that is pointed out in a number of places in the article). However, if you are not a small business or have a lot of users, the time needed to implement the features will be negligible compared to the amount of time needed for handling manual r…

Thanks for commenting my comment.

2. Yes, up to the legal team and what types of processing you do. If you do processing that the data subject would not expect you to do or that is not in their interest you have to consider this carefully. Maybe allowed or not under legitimate interest but you have to be careful and do a proper assessment. I believe, and I have heard many EU data protection lawyers state, that consent is a last resort option. Probably not universally shared but many ppl appears to think in that way. Also, remember that consent bypasses important principles, such as the necessity test present for all other legal basis.

3. I agree, both RTBF and SAR rights under legitimate interest but no absolute requirement to automate the process in any case. Implementing voluntarily data portability good practice which could tip the balance when using legitimate interest, see below.

4. Yes, and concerning legitimate interest, if you implement these best practice measures this could “tip the balance” in your favor if you read the WP29 legitimate interest opinion.

Re: GDPR – A Practical Guide for Developers (2017)

#99

> In this particular case, it applies to companies that are not registered in Europe, but are having European customers. Umm, nope. The EU doesn't have any authority to enforce companies outside of the EU to do anything.

You are confusing legislation and enforcement. A great deal of legislation has an extra-territorial dimension.

We live in a connected world, so ignoring this legislation should not be assumed to be free of consequences.

Re: GDPR – A Practical Guide for Developers (2017)

#100
post #27

Earlier quoted context omitted.

It looks like the maximum fine is 4% of annual revenue... seems like the regulation has no teeth if you have no revenue. IANAL and could be totally wrong. To your point about small companies, I agree, it feels onerous. What irks me about the right to be forgotten is that it directly counters my right to remember things. Should a shop keeper be allowed to record their observations about who enters their store each day…

Re the last question, yes, absolutely. Why would data format matter?

I don't think it matters to the principle, but rather to the practicality. It's now practical to aggregate massive amounts of data and create a privacy concern that's unlikely to have existed in the world of offline records.

The principle is freedom of speech. If you tell me that I cannot write down the names of the people who came to visit me today without their permission, you are violating my right to freedom of speech.

Post reply on HN