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

How GDPR Will Change The Way You Develop

smashingmagazine.com

Post reply on HN
Print view View original

61–70 of 710 posts

Re: How GDPR Will Change The Way You Develop

#61

Post by wastedhours »

_o_ wrote: post #37
paulsutter wrote: post #25

I’d love to understand GPDR but this article isn’t helping. Can anyone suggest something more focused and direct?

Very simplified, you can not use or give personal data to someone else without optin given consent (where you must state in non legal, non tech speech for what they will be used) and same goes for enabling others (ad networks, google,..) to get those data. Or you are breaking the law. Further, user must be allowed to view, change or delete those data and remove consent to use them in whole chain (your site, ad networ…

And also, there's also the slightly grey-area requirement that (if you're using it as your legal basis) consent should not be required in order to utilise your product, merely to utilise the feature set that requires the data.

If you need everything, then you'll need to use "fulfilment of a contract" as the basis, and in that case, you probably need to make your ToS pretty tight too.

Re: How GDPR Will Change The Way You Develop

#62

Post by lmkg »

ryandrake wrote: post #35
reynoldsbd wrote: post #11

Earlier quoted context omitted.

Absolutely! Anybody who does business in Europe or even has users in Europe is subject to this law. The amount of effort being put into GDPR compliance within my organization is just staggering. It really makes me think about these kind of laws from a new perspective, because they cost businesses so much to implement. (I'm not saying whether GDPR is right or wrong! Just that it's expensive.)

I would (maybe naively) think that the cost of GDPR compliance would be small if your company is already safeguarding user data and respecting user privacy. If a company’s cost is “staggering“ doesn’t that say a lot about its existing privacy practices?

I presume you're talking about things like informing users how their data might be used, storing user data securely, and not selling it to third parties. That sort of stuff is relatively easy.

The GDPR imposes some new requirements that were not previously part of any privacy best-practices that I'm aware of, and that create some system complexity. Chief among these is the right for users to retract consent after it has previously been granted. This effectively requires processors to be able to delete individuals' data from their records, something that was not a design requirement of many systems. This becomes increasingly more difficult as user data has often been aggregated, and joined with other data sources.

Another key differentiation of the GDPR compared to previous legislation is that it applies not only to data that identifies a person (such as by containing a name or social), but to data that could in theory be linked back to the user through a common identifier. Previous best practices have considered the user's privacy protected if they were identified through a hashed email or an opaque database identifier, but the GDPR does not consider this sufficient anymore.

Re: How GDPR Will Change The Way You Develop

#63

Post by robin_reala »

reynoldsbd wrote: post #60
robin_reala wrote: post #54

Earlier quoted context omitted.

You encrypt the data before it’s stored with a unique key, then destroy the key when the user requests it. Doesn’t help for pre-GDPR data but that’s the way you should be building going forwards.

"We could have done it this way." doesn't pay the bills (or in this case, doesn't prevent steep fines).

Sure, it’s always painful to fix existing systems. In the future it should be no more expensive than business as usual though.

Re: How GDPR Will Change The Way You Develop

#64

Post by reynoldsbd »

ryandrake wrote: post #49
lostcolony wrote: post #39

Earlier quoted context omitted.

It says a lot about the cost of privacy, period. The cost would be staggering whether they're modifying existing things, or creating new things, just in terms of ensuring "Yes, we're doing this correctly".

I just find it hard to believe that the law is a significant cost to companies already doing the right thing. Sure, there is a non zero cost to ensuring your existing practices are lawful, which everyone must pay. But companies already in compliance shouldnt have to modify or create anything. The companies that have to spend significant coin are the ones who are not already complying.

This is incredibly false. When you change the law, you can't assume that people who are currently in compliance will continue to be.

Re: How GDPR Will Change The Way You Develop

#65

Post by trothamel »

sveme wrote: post #10
trothamel wrote: post #4

"The extraterritorial nature of these two frameworks..." I've noticed that this is something the EU has tried to do lately, to just sort of push their regulations on the rest of the world. I don't see what sort of authority they'd have to impose this on citizens of other countries. I wonder if Europe pushes the issue, if this will be treated like libel tourism, where US citizens and companies without a Eurpoean nexus…

It's something that basically every big block is trying to do, the US has enforced DMCA and other stuff on other providers as well. Though in principle, GDPR only covers EU citizens - if you would be selling a product from Australia that exploded upon using it for the first time to an EU citizen, wouldn't you expect EU authorities to go after you as well?

No, I'd expect Australian regulators to be the ones that went after you in that case.

Re: How GDPR Will Change The Way You Develop

#66

Post by robin_reala »

setra wrote: post #52

In this article the author states: "The latter definition is important for developers. It includes things like IP addresses, mobile device IDs, browser fingerprints, RFID tags, MAC addresses, cookies, telemetry, user account IDs, and any other form of system-generated data which identifies a natural person.". This information does NOT automatically qualify as personal data. Information being unique is not the same as…

Are you mixing up ‘personal data’ and ‘personally identifiable information’ (a US legal concept that differs from the EU definition of personal data)?

Re: How GDPR Will Change The Way You Develop

#67

Post by ryandrake »

lmkg wrote: post #62
ryandrake wrote: post #35

Earlier quoted context omitted.

I would (maybe naively) think that the cost of GDPR compliance would be small if your company is already safeguarding user data and respecting user privacy. If a company’s cost is “staggering“ doesn’t that say a lot about its existing privacy practices?

I presume you're talking about things like informing users how their data might be used, storing user data securely, and not selling it to third parties. That sort of stuff is relatively easy. The GDPR imposes some new requirements that were not previously part of any privacy best-practices that I'm aware of, and that create some system complexity. Chief among these is the right for users to retract consent after it…

Thanks for the details! I can see how this could get costly for complex systems. As a user though I would think all those things you listed would be existing privacy best practices but I guess that’s being way too optimistic. Scary what companies are currently getting away with, too but not surprising.

Re: How GDPR Will Change The Way You Develop

#68

Post by sb8244 »

robin_reala wrote: post #54
sb8244 wrote: post #45

Earlier quoted context omitted.

I'm not sure. I think this is a very absolutist and probably naive way to look at it, frankly. For a simple example, let's say you use an immutable data store. What do you do if a customer wants every info about them redacted, but you did something like store their IP, name, or email. All common things. Now you must build mutability into your store and all assumptions that used to be made can be removed. This is just…

You encrypt the data before it’s stored with a unique key, then destroy the key when the user requests it. Doesn’t help for pre-GDPR data but that’s the way you should be building going forwards.

Will this satisfy GDPR requirements fully? What if that key had somehow been involved in an unknown leak in the past (of just the keys) and then the data is exposed somehow in the future?

Leaks are punished, as they probably should be, under gdpr anyways. But now do we have to account for all of the keys over time and have it be probably gone? What if we take backups of the systems that stores the keys? Do we have to purge those backups as part of the deletion request? What if they're terabytes in size?

Just thinking through edge cases here

Re: How GDPR Will Change The Way You Develop

#69

Post by robin_reala »

aeorgnoieang wrote: post #58

What's troubling to me is that it's very unclear what specifically is required. I know the linked post isn't legal advice, but in the page about 'privacy by design' linked to by the origin link, they list "Minimize the amount of collected data" as as an item (supposedly to be achieved to be in compliance with the law). What's the minimum amount of data? Who decides that? Is it dependent on context? I'd hope so! Can a…

> Can any site just 'do an end run around' the law by requiring their users to agree to allow them to collect whatever data they collect now or that they've already collected?

No: a consent from a user must be for granular information with a specific listed purpose.

Re: How GDPR Will Change The Way You Develop

#70

Post by aeorgnoieang »

aeorgnoieang wrote: post #58

What's troubling to me is that it's very unclear what specifically is required. I know the linked post isn't legal advice, but in the page about 'privacy by design' linked to by the origin link, they list "Minimize the amount of collected data" as as an item (supposedly to be achieved to be in compliance with the law). What's the minimum amount of data? Who decides that? Is it dependent on context? I'd hope so! Can a…

A really weird example from the same privacy-by-design link [here: https://www.smashingmagazine.com/2017/07/privacy-by-design-f...]:

> As one dramatic example, PayPal’s recent updated notice lists over 600 third-party service providers. The fact that PayPal shares data with up to 600 third parties is not news. That information is simply being brought into the open.

From what I can see of the list of those "600 third parties", a large number are banks and other financial institutions.

Post reply on HN