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

71–80 of 202 posts

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

#71

Post by deltron3030 »

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.

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

#72

Post by FooBarWidget »

geocar wrote: post #64
crazygringo wrote: post #48

Earlier quoted context omitted.

I'd hardly say that. "Forget me" can take a lot of design work (can introduce a ton of edge cases). "Export data" requires building an entire information processing pipeline. Larger corporations have the resources to dedicate to this. But for a small startup deciding between spending 4 dev-months on "forget me" and "export data" versus on enabling the top 3 new primary use cases users are asking for, I understand how…

I would. I'm doing some GDPR consulting at the moment and most of my conversations are "I don't think it's as complicated as you do". Americans tend to read law very pathologically unless they are familiar with how European legislation works, and every programmer out there thinks they are an armchair lawyer since there are "obvious" skillset similarities between decoding software and decoding law. "Forget me" is very…

Interesting. Do you have a link to your consulting company? Do you have a blog on GDPR related topics?

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

#74

Post by geocar »

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…

I cannot imagine why anyone would want to intentionally violate someone's privacy and ignore their stated preferences; to use their data in a way they would not want, regardless of what country they live in. It surprises me that anyone would want to make an insecure system on purpose and take no responsibility for being hacked.

That's what "ignoring the GDPR" means on some level.

It just so happens that the GDPR provides a powerful tool to protect me and my rights, even when I'm in the USA on business, at a Starbucks on their public Wifi.

There's a lot of guffing about IP addresses and weblogs that is confusing a lot of people. Without knowing what kind of information you think you need to collect without permission and without benefitting the person involved, it's difficult if you're a chicken little, or if you're a scumbag spammer: I'll have no sympathy for the latter, but am happy to try and decode the GDPR for the former (within reason: I'm doing some GDPR consultancy at the moment)

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

#75

Post by andygcook »

TheAceOfHearts wrote: post #29
majewsky wrote: post #17

Earlier quoted context omitted.

How is identifiable data important for institutional knowledge transfer?

I can imagine scenarios where it would be important to know who worked on something. For example, using git blame I might learn someone was heavily involved with a project or feature. Then I might look on our internal Wiki for old posts which include discussions explaining why certain design decisions were made.

Right, this is the scenario I was thinking of. Most systems that include any type of communication nowadays require you to use a real identity. An ex-employee that asks to have their identify obfuscated from all their work breaks the system of record to answer questions like who worked on what, what decisions were made by whom, etc.

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

#76

Post by goblin89 »

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 multiple sections of GDPR. Quoting the very first section about data processing principles[0], personal data can be stored even after you’ve achieved the initial explicitly stated purpose, as long as it:

> will be processed solely for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes in accordance with Article 89(1) subject to implementation of the appropriate technical and organisational measures required by this Regulation in order to safeguard the rights and freedoms of the data subject (‘storage limitation’)

How wide is the range of activities that can be reasonably claimed to be for scientific or statistical purposes, or for safeguarding the rights and freedoms of your user? How strictly would this be enforced in cases where scientific and statistical purposes are closely intertwined with commercial interests, as it often happens?

Meanwhile, the referenced Article 89(1)[1] doesn’t seem to take a hard stance except for requiring “data minimization”. Even pseudonymisation is explicitly optional, as long as you’ll have a convincing argument that pseudonymising the PII you’ve collected prevents you from fulfilling your “statistical purposes”.

I’m not a lawyer and I’m wondering if someone with more expertise can weigh in on this.

[0] https://gdpr-info.eu/art-5-gdpr/

[1] https://gdpr-info.eu/art-89-gdpr/

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

#77

Post by marten-de-vries »

FooBarWidget wrote: post #51
marten-de-vries wrote: post #39

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

I suspect preserving git history is allowed for the purpose of determining copyright compliance.

There's an exception 'for the establishment, exercise or defence of legal claims.', but there's situations where that would not apply. E.g. commits fixing a single spelling mistake are probably not copyrightable.

Also, I doubt you can just keep a copy of all data you ever process, just because it might some day be useful as legal evidence.

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

#78

Post by hanoz »

As a freelance developer I'm quite sure that if I were to force my clients to comply with as strict an interpretation of GDPR as this, I would pretty shortly find myself replaced by a freelance developer with a more relaxed attitude to GDPR compliance.

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

#79

Post by FooBarWidget »

marten-de-vries wrote: post #77
FooBarWidget wrote: post #51

Earlier quoted context omitted.

I suspect preserving git history is allowed for the purpose of determining copyright compliance.

There's an exception 'for the establishment, exercise or defence of legal claims.', but there's situations where that would not apply. E.g. commits fixing a single spelling mistake are probably not copyrightable. Also, I doubt you can just keep a copy of all data you ever process, just because it might some day be useful as legal evidence.

Why would you say that? If you can get sued for a piece of code written 30 years ago, then it seems legitimate to me to store legal evidence for at least 30 years. As far as I know there is no time limit to being sued over something.

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

#80

Post by rectang »

boggio wrote: post #26

God damn it EU, all these regulations make it impossible for small companies, indie developers to cope with all the bureaucracy. The VAT for digital products, now the GDPR. 10 more years of regulation and you will spend 90% of the time working on implementing legal requirements and 10% on the actual product.

It wasn't the company's data to begin with. Modern businesses have caused harm to countless individuals by treating data cavalierly.

The GDPR puts things right. It brings the externality into the market, and now the market can correct.

Businesses that rely upon slinging private information around irresponsibly need to adapt. If they can't, their failure in the marketplace is just.

Post reply on HN