Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GDPR – A Practical Guide for Developers (2017)

techblog.bozho.net

Post reply on HN
Print view View original

121–130 of 202 posts

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

#121

Post by Pete_D »

wtfstatists wrote: post #15

Lets 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 ?

I would go with "better safe than sorry" if I had to manage this sort of data. It might be fine so long as the URLs are all non-identifying stuff like the Wikipedia home page. But I bet I would have users with much more revealing bookmarks, like, say, their Keybase profile page, or URLs with session/auth tokens in query strings, or the home page of their church which has a congregation of less than 50 people.

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

#122

Post by havkom »

havkom wrote: 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…

> Functions that allow the users to delete and automatically download/access their own data is good practice for legitimate interest but not needed. You are anyway in general allowed to deal with these types of request on a case by case basis if you provide your data subjects with an email address.

I want to be very clear - you _almost always without exception_ have to provide access to/copy of personal data to the data subject no matter what legal basis is used (consent or not). “Data portability”, providing the data in a commonly used electronic format, such as JSON/XML download, is optional when using legitimate interest but mandatory when using consent.

You also _normally_ have to delete personal data of those data subjects who have requested it. You also normally have to stop using the data for the purposes the data subject requests you to stop with.

These processes do not normally need to be automated (but with consent it should be as easy to provide consent for the data subject as it is to revoke it).

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

#123

Post by lifeisstillgood »

deltron3030 wrote: post #71
lifeisstillgood wrote: post #12

I think the right to be forgotten is a serious flaw in what otherwise is a major step forward in Data handling law. Data today has been compared by Schneier to pollution in the industrial revolution. The GDPR is probably the first anti-pollution law with real bite and with a real grasp of just how far this all goes (the extra-territoriality etc) This does not make this perfect solution. I honestly don't think that "b…

Like pollution laws, it's nonsense if not enforced worldwide. The web can't be contained to a specific locality anymore, it's against the core idea of the technology. The people in the EU who are responsible for this have no clue about the technology.

The GDPR specifically states that any processing of EU citizens personal / private data

essentially two huge things come out of GDPR - personal data about a EU citizen belongs to that citizen, and if you process data about an EU citizen even if you are out of the EU, you are covered by this law (extra-territoriality)

These are huge forward thinking political steps. they do get this stuff. I just think the deletion part is a mis-step

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

#124

Post by x0x0 »

havkom wrote: post #122
havkom wrote: 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…

> Functions that allow the users to delete and automatically download/access their own data is good practice for legitimate interest but not needed. You are anyway in general allowed to deal with these types of request on a case by case basis if you provide your data subjects with an email address. I want to be very clear - you _almost always without exception_ have to provide access to/copy of personal data to the d…

Data portability is no big deal; you can simply dump the unformatted output of your SAR process. So if you've built the SAR process you've built that as a byproduct.

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

#125

Post by grabeh »

nawitus wrote: post #83
havkom wrote: 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…

This is the biggest problem with GDPR, there's no agreement what it means, but it will go into effect in a few weeks.

What makes you say that there's no agreement as to what it means?

It feels like I see this sort of view expressed quite frequently. My guess is that it's primarily because people want a reason not to look to comply in lots of cases, or to dismiss GDPR. "How can we comply if no one knows what it really means to comply".

In many cases, the GDPR simply reiterates/builds upon existing data protection law which has a wealth of interpretative decisions and guidance. In other areas, the Article 29 Working Party has been issuing guidance on specific aspects of GDPR.

Yes, the GDPR is a lengthy piece of legislation but there are straightforward steps people can take and they generally centre around respecting users' data.

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

#126

Post by x0x0 »

sovietmudkipz wrote: post #25
DangerousPie wrote: post #16

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…

One man shop here... Cloudfront forwards country information to your origin servers in AWS. My plan was to not do business or display content in European countries until an easy solution to GDPR enables me to quickly meet it's criteria. Certainly libraries will crop up helping to ease the burden of the regulation for smaller operations. Though... I'm not quite sure what happens when a European citizen uses VPN to spo…

Do you do business in Europe? If you only have a handful of European customers, what exactly can happen if you get a letter from the French privacy regulator? Toss is in the bin and move on with your life. Maybe delete the complainants account if you want.

The major costs with GDPR for a small player are things

* understanding the law (far from trivial, particularly given how the various privacy regulators can't be arsed to produce final guidance even to date). Consent is moderately straightforward, but eg legitimate interest balancing tests aren't.

* figuring out every database and table that has user data stored in it

* figuring out 3rd party systems with such data (your transactional mailer, marketing mailer, billing, logging, etc)

* were your marketing consents gdpr-compliant (pro-tip: they weren't). What consent is every marketing contact tied to? Why do we have to reconsent everyone when there is already a working 1-click opt-out link in every marketing email?

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

#127

Post by r3bl »

CM30 wrote: post #60
DangerousPie wrote: post #33

Earlier quoted context omitted.

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.

The point about IP addresses and emails makes me wonder what would happen to spammer blacklists. If they're personal information, does that mean services like Stop Forum Spam and Akismet need to remove data when requested, even if it makes life harder for forum admins and community managers? What about those topics you see on admin forums where you're given a giant list of IPs and emails to copy into the ban settings…

> where you're given a giant list of IPs and emails to copy into the ban settings page?

If you're behind HN, and I email you and tell you to delete CM30's profile, would you do it or would you request me to prove ownership of the profile?

If you're behind HN, and I email you asking you to delete thousands of accounts, would you just do it or would you request me to prove ownership of those 1000 profiles?

Point being: You're not gonna delete anything until you have verified that the user is really who he is claiming to be.

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

#128

Post by grabeh »

ryanworl wrote: post #106
havkom wrote: post #98

Earlier quoted context omitted.

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 consen…

It seems like when using legitimate interest as a basis for processing that _what you do_ with the data is much more important than what it is you’re collecting in the first place. When registering an account with an online service, you will probably have to give up your email address. The legitimate interest is to be able to let you log in again and to send password reset emails, or other account related notificatio…

You would not use legitimate interests to cover off your processing of data in connection with letting a user log in to your site, if it is a requirement of using the service that you are logged in, for example to authenticate who you are. The correct processing basis here would be to process data to provide a service, not under legitimate interests.

If you were processing someone's data to, for example, ensure the safety of your network/detect unauthorised login attempts, then that would likely fall under legitimate interests, because it is processing that is not necessary to provide the underlying service, but is in the users' interests to ensure the protection of their personal data.

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

#129

Post by x0x0 »

bozho wrote: post #93
nawitus wrote: post #84

Earlier quoted context omitted.

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 prac…

a) The regulators had 2 years to write final regulations. They didn't do that either. Apparently it's too much to ask to have eg final guidance more than 3 months before the implementation deadline.

aa) In actuality, the ICO has made it clear that grace periods are not part of their regulation strategy. See eg speeches by senior regulators.

b) hahaha go spend a pile of cash on lawyers (we're at roughly $50k) who are familiar with 30-ish countries privacy regulators. American companies are quite unlikely to have a lead regulator.

d) proportionate and adequate are words that create giant legal bills, because the gdpr naturally declines to spell out in any concrete fashion what those mean.

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

#130

Post by nokcha »

marten-de-vries wrote: post #63
Neuron4ger wrote: post #43

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)

> Paragraphs 1 and 2 shall not apply to the extent that processing is necessary: > [...] > (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 no…

What if the purpose of the archiving is to not only record what was changed but also who changed it?
Post reply on HN