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

101–110 of 202 posts

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

#101

Post by scrollaway »

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…

The GDPR applies to european citizens living outside Europe.

You have a fire in your kitchen, and instead of addressing it, you're closing the door.

From the inside.

[Edit: And to be clear, if I ever heard about a site pulling this sort of shit, I would be extremely compelled to issue GDPR requests towards it. This mindset amuses exactly nobody except you.]

Edit 2: I'm being a little snarky here, so here's a bit of actual helpful advice: Instead of trying to be a smartass with the law, which never works, do what every other one-man shop your size will do and ignore it until it becomes an issue. Once it does become an issue, comply in the best faith you can.

Most requests you'll get will probably simply be: "Please delete my account" and "Please send me a copy of my data". You have 1 month to comply with it. I have no doubt you'll be able to.

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

#102

Post by jimnotgym »

nawitus wrote: post #84
mycall wrote: 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) It is not a big change from the 1995 regulation. It is incremental. There is a feeling that the previous regulation lacked teeth with the multinationals, some of whom have chosen to ignore it. Facebook have lost two cases over aggregating data in Belgium and Germany in the last month.

b) I don't know if you are familiar with European law, but what you see as vague is what others see as flexibility. Laws setting out the spirit of what you are trying to achieve tend to age better than a rule based approach.

c) They did [0]. Because of b) it is not part of the regulation itself.

d) They were under the existing regulation, so why wouldn't they be now? The 'vagueness' as you put it gives a judge considerable flexibility to see if the steps taken to safeguard privacy were appropriate to your size

edit:add reference [0]:https://ec.europa.eu/info/law/law-topic/data-protection/refo...

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

#103

Post by havkom »

GordonS wrote: post #90
havkom wrote: post #82

Earlier quoted context omitted.

If you use “consent” as your “legal basis” and you are asking for consent that is related to the offering of services over the internet (such as a web shop, a social media web site, discussion forum, ...), you need to somehow verify age (16 years normally) or be very clear that under 18 years olds (“children”) are not to access your service (and not have evidence pointing to that this is undermined) Note that the 16…

In my own case, we only need customer PI as contacts for billing and support, so from what I've read, that doesn't need consent. Thinking about it, I suppose it does make sense to ask users if they are over 16 if you are going to be processing data in a way that does require consent, just so you know that they can legally give that consent.

I believe this is true. In my country (Sweden) it appears like consent outside of offering internet services may require the data subject to be 18, not 13 (Sweden has made a local adjustment to 13 years of the 16-years old rule referred to). So this rule may actually be a relief of who can consent to what.

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

#104

Post by glimmung »

GordonS wrote: 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?

No, it does not have to be automated, and if manual / email approaches work at your scale that's fine.

The legislation explicitly refers to "proportionality", although people exploiting the FUD around it to drum up business rarely use the word.

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

#105

Post by joris »

marcrosoft wrote: post #56

> 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.

That’s not true. You’re within their scope if you process and/or target EU citizens.

It might of course be difficult to execute the judgment but they can still sue you in the EU. In the US that happens also, for example when some stakeholder sues a foreign website that infringes on their rights. If the sued entity doesn’t show up in court, they just issue a default judgment (meaning the plaintiff wins by default). You can even sue a John Doe in court (at least in the US).

In practice, the EU is also resource constrained like any other government entity, so you probably won’t have much to fear. I mean they’re not going to sue millions of companies all over the world, it just means they have created themselves a new stick that they can choose to use.

I hear that they’ll likely first go after entities that have a big impact on the public (i.e., the most blatant cases).

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

#106

Post by ryanworl »

havkom wrote: post #98
bozho wrote: post #88

Earlier quoted context omitted.

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 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 notifications like “we have detected a suspicious login from another continent”.

If you want to stick someone on your marketing email list, asking for consent is a much better option! Unless the context is extremely clear (the email field is specifically for signing up for the email list), asking for consent seems safer.

But in both cases, the basis is about the processing of the data, not the data itself.

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

#107

Post by havkom »

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…

Yes, this is important - GDPR is mainly about how you are allowed to use data, ie for what purposes you are processing the data (although collection and storage is also “processing” as a side point)

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

#108

Post by osteele »

EwanToo wrote: post #68
DangerousPie wrote: post #34

Earlier quoted context omitted.

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.

I can't remember the last time I worked with a database that couldn't write out a query log? 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

Last week I looked at a couple of hosted data services whose free tier didn’t give access to a query log. This is pretty common for hobbyist projects.

This means this logging has to be implemented at the app layer.

The developer has to pay for log retention, which doesn’t come for free with several of the hobbyist-level hosting services that I’m familiar with.

I agree with your general point that there’s no significant technical challenges, at least for even a minimal dev team or a practitioner with time to put into this.

Maybe hobbyists shouldn’t be handling this data in the first place, or maybe this is an opportunity for GDPR-complaint SaaS to help them do so safely.

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

#109

Post by Neuron4ger »

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…

Thank you for emphasizing that last part. I think you might be right.

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

#110

Post by tscs37 »

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…

Preventing abuse is a legimitate interest to keep data even if deletion is requested.

For the same reason users can't request you delete all copies of bills and receipts on them.

Post reply on HN