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)
131–140 of 202 posts
Re: GDPR – A Practical Guide for Developers (2017)
#132I 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…
Re: GDPR – A Practical Guide for Developers (2017)
#133But it really is overkill for the local restaurant that wants to mail their customers.
Using a bazooka to kill some flies.
Re: GDPR – A Practical Guide for Developers (2017)
#134Earlier 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.
Re: GDPR – A Practical Guide for Developers (2017)
#135Earlier 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…
Re: GDPR – A Practical Guide for Developers (2017)
#136I’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…
Re: GDPR – A Practical Guide for Developers (2017)
#137I 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…
Re: GDPR – A Practical Guide for Developers (2017)
#138Earlier 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…
Re: GDPR – A Practical Guide for Developers (2017)
#139I 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…
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)
#140Earlier 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…