Live data from Hacker News

GDPR – A Practical Guide for Developers (2017)

techblog.bozho.net

131–140 of 202 posts

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

#131

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…

4) If you are not living in the EU you are not obligated to implement any of the changes. Being a small time developer, what is the worst that can happen?

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

#132
post #27

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…

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…

If you need to retain information for a particular reason, for example to provide a service, or to retain for legal reasons, or legitimate reasons in connection with your business, then in many cases that will trump the right to be forgotten. See Art 17(1)(a).

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

#134
post #124
post #122

Earlier quoted context omitted.

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

Yes. Unless you have legacy systems with screen shot based SAR responses for example

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

#135
post #128

Earlier quoted context omitted.

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

Regarding your first statement: It depends if you have a valid contract with the user and the data processing is sufficiently related to the performance of that contract.

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

#136

I’ve been reading the EU’s General Data Protection Regulation, and it seems to contain certain loopholes that may be exploited by less than honest agents. The sad possibility is that the mere existence of such loopholes can push an otherwise law-obedient small companies towards mostly-ignoring GDPR in order to remain competitive. For example, there’s this huge “if” concerning personal data removal, reiterated in mult…

Any exceptions to the regulation will inevitably be subject to a narrow interpretation particularly if it is clear that someone is looking to do something which is outside the spirit of the regulation.

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

#137
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…

The main processing basis for many entities will be straightforward processing to provide service under Art 6.1.b. Legitimate interests like consent should generally be avoided wherever possible due to the additional burden it places on organisations to document the balancing test you've undertaken, and the potential for it to be questioned in future. Although I fully agree in many cases it will be entirely appropriate to use legitimate interests as the relevant processing basis.

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

#138
post #93

Earlier quoted context omitted.

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 problem with this is that this practical guide was released in November 29, 2017. And this is unofficial. EU should have released a practical guide two years ago in my opinion. If the process is gradual the law should reflect that. c) Good to hear :). Apparently it's this: https://ico.org.uk/for-organisations/guide-to-the-general-da... - I hope it's not written from the perspective of the UK legislation. d) Th…

Every country has a slightly different implementation of the directive, so I don't think the EU will have a single example to give.

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

#139

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…

Option 4) - adopt a risk-based approach to compliance, and look to assess whether any aspect of your service, and the way it makes use of data in its current form is an egregious breach of GDPR. If that is the case, you're likely in breach of existing data protection law.

In terms of risk factors, most side projects will generally use data to provide a service to customers. This type of processing is unlikely to attract regulatory attention.

It's also unlikely that the vast majority of entities will be 100% compliant come May 25, but as the Belgian data protection authority has pointed out, it is important that people demonstrate a good faith approach to compliance.

For new requirements around restriction of processing/provision of data in a programmatic manner, again, dependent on risk, it is likely not necessary to implement these features and side project owners should focus on building their product instead.

Relevant risks for a side-project owner are around a) volume of data held, b) types of uses of data, c) likelihood of users making a requests around erasure/restriction (look at any historic requests received here), and d) regulatory focus on specific areas of the legislation.

This law is not going to fizzle out and on a general level, in my view it is advisable for any entity to look to respect user data regardless of legal obligations relating to that.

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

#140
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…

How would the judgement be quashed by american courts? No american court has jurisdiction over European courts. For an entity without presence or business in Europe, enforcing a european court decision might be a problem, but that’s a different matter. I’m sure the EU will find a way if the sum is sufficiently high.
Post reply on HN