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

51–60 of 710 posts

Re: How GDPR Will Change The Way You Develop

#51

Post by robin_reala »

lostcolony wrote: post #38
pythonaut_16 wrote: post #27

Earlier quoted context omitted.

It's good to see Backblaze confirming that their GPDR compliance will benefit all of their users. That's definitely been a hope of mine as someone who doesn't live in the EU, so hearing that is encouraging.

I suspect it will be the norm. For any greenfield development, why would we develop it twice? We have to solve every business problem we have for the EU; why would we solve it differently, to address the same problems, elsewhere? For non-greenfield development, why would we keep two codebases and sets of infrastructure around that we have to support? Better to consolidate. Especially given the positive word of mouth…

And remember that GDPR applies to EU citizens outside the EU too, so you’d need to confirm with the user upfront that they aren’t an EU citizen before capturing the information.

Re: How GDPR Will Change The Way You Develop

#52

Post by setra »

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 personally identifiable. A random cookie sent by the browser is not PII. A cookie stored in conjunction with say an email address could be.

Certain information can be classified as PII if it possible to cross reference it with other stored information to identity a user. For example a European court in a recent ruling stated that a full IP address could be considered PII because an ISP would have a record of IP address and time with a persons name.

Re: How GDPR Will Change The Way You Develop

#53

Post by farazbabar »

mfoy_ wrote: post #29

This article is all very well and good, my only concern is that, imagine in a few years someone wants to find the list of all the laws and regulations and frameworks and whatnot that they need to comply with to run a truly international website... where would they find that information?

I have thought about a natural language understanding (NLP/NLU) based startup to do exactly this. So much to do, so little time.

Re: How GDPR Will Change The Way You Develop

#54

Post by robin_reala »

sb8244 wrote: post #45
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'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.

Re: How GDPR Will Change The Way You Develop

#55

Post by reynoldsbd »

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?

Definitely not true. GDPR significantly broadens the types of data subject to legal requirements. Whereas yesterday I only had to protect PII and content, now even telemetry and performance data becomes subject to new rules.

This is a huge problem for an org that relies on huge amounts of such data to keep our product running and uses systems which were never built with these new rules and classifications in mind.

Furthermore, there are huge complications surrounding "data processor" scenarios (in other words, Enterprise SaaS products). For example, what takes precedence, GDPR deletion or our contractual security/auditing obligations?

Again, I'm not saying that any of this isn't worth while, just that when you get down into the weeds things look a little different.

Re: How GDPR Will Change The Way You Develop

#56

Post by DanBC »

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

It would be useful if people downvoting this could say which bit is incorrect, or what it's missing.

Re: How GDPR Will Change The Way You Develop

#58

Post by aeorgnoieang »

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 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? If so, that seems like it'd be likely as helpful as current terms of service.

Another item mentioned is "Where possible, pseudonymize personal data.". What's a practical example of that?

Yet another item – "Don’t enable social media sharing by default.". Is the thinking that user's shouldn't be able to share something via social media without first explicitly enabling that option? That just seem unfriendly. Or is the idea that doing so protects someone from doing so accidentally? This seems a lot like the 'cookie law', itself an annoying mandated nagging that probably backfired (because everyone was effectively trained to just do whatever necessary to get rid of the corresponding notification on every site they visited).

Again from the privacy-by-design page:

> There is no checklist of ready-made questions that will get you there; General Data Protection Regulation requires developers to come up with the questions as well as the answers.

That's a really unsettling description of a law.

Re: How GDPR Will Change The Way You Develop

#60

Post by reynoldsbd »

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.

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