Hacker News Reader

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

The GDPR says when you collect data, you have to tell the user what you intend to use it for. "Minimization" applies within the context of those stated uses. So if your business purpose is to mail something to the customer, full physical address is OK to collect. If your business purpose is to help them find a nearby store location, you may be expected to collect something less granular like ZIP code or metro area, depending on how many locations you have.

As a corollary, if you can't link a piece of data to a business use, you shouldn't be collecting it. This was a good idea before, but GDPR makes it more relevant.

Note that this is similar to the ethical guidelines for medical research. "Harm Minimization" is a central pillar of ethical research. Harm, and risk of harm, is acceptable, but there is an affirmative duty to seek the least-harmful means of achieving your goal from those available.

> That's a really unsettling description of a law.

That's how HIPAA works, actually. I have a professor who argues this model of legislation is more effective than traditional sector-specific regulation, because it puts the onus of subject-matter expertise onto the people who are actually subject-matter experts, and because it allows for creative and adaptive solutions.

> So if your business purpose is to mail something to the customer, full physical address is OK to collect. If your business purpose is to help them find a nearby store location, you may be expected to collect something less granular like ZIP code or metro area, depending on how many locations you have.

I would also like to stress out that, from my understanding, this data would rather be deleted immediately after use. That is, not saved at all after the query, or the delivery, unless the user explicitly opted-in to give you such data for advertising, etc...

my company seems to be going on a encrypt everything spree. I am not sure how GDPR requires encryption.

Can you be GDPR complaint ( in theory) with zero encryption?

The GDPR, as with existing EU data protection law requires technical & organisational measures in place to protect data. The GDPR specifically calls out (Article 32 if you're interested) encryption as one measure that entities should consider in determining whether their technical & organisational measures are fit for purpose.

Generally speaking, encryption is an obvious choice when it comes to measures designed to protect user data.

Of course—if you don't store personal data (trivially).

In fact, encryption (security) is mostly orthogonal to how you track and handle personal and sensitive data (privacy protection). You could encrypt everything and still be wildly GDPR non-compliant, if the encrypted information you're storing lacks clear purpose and explicit consent.

Indeed.

We store data encrypted because it

A) leaves no room for misunderstanding with different regulators or their respective auditors, and

B) provides a computationally infeasible barrier against accidental personal information disclosure even if the storage system was improperly decommissioned

Point B in particular can be explained to auditors without problems. They understand both the intent and the technical measures put in place. But how we store data is only tangentially relevant to how we handle data. Let alone what we need to collect in the first place.

(The KYC/AML/SOW requirements in gambling are quite demanding; they impose significant data collection and retention needs.)

To further emphasize your point You could encrypt everything and still be wildly GDPR non-compliant, we need to be able to respond to a request by each and every individual user to delete the information that they no longer wish us to carry.

... unless you actually need that data (billing for past services, keeping records as required by law, etc).

> The GDPR says when you collect data, you have to tell the user what you intend to use it for.

Then that part is worthless, just another click-through "agreement" practically nobody reads.

That part won't change anything.

> So if your business purpose is to mail something to the customer, full physical address is OK to collect. If your business purpose is to help them find a nearby store location, you may be expected to collect something less granular like ZIP code or metro area, depending on how many locations you have.

I always wonder one thing: Is the penalty going to be high enough to justify not breaking this law?

All business decisions are cost-benefit. If the costs of doing something outweigh the benefit, you don't do that. This includes following the law: If you can reliably get more money by breaking the law, you break the law, and pay the penalty if you get caught. Unless you're very unlucky, you're still right-side-up after you pay the penalty, so your behavior was, on the whole, justified.

> Then that part is worthless

GDPR requires that the use cases be itemized, and the user can opt out of each one individually. So if the user opts out of receiving a mailing but not the store locator, you have to manage how much data you collect about that person. I agree that for the most part this will just be another click-through like the cookie law was, but companies will be required to accommodate those minority that do care.

> Is the penalty going to be high enough to justify not breaking this law?

The penalty is up to 4% of annual global revenue. Global revenue.

Up to 4% or €20 million, whichever is greater.

Let me get it straight: if your global revenue is €10 million, you won't pay 4%(€400k) penalty, you'll pay €20 million, because it's greater of the two? It seems like this will be especially harmful to small companies.

Up to $20 million, depending on the severity of the infringement. I think the reason that floor is there is to handle cases where an organization doesn’t have much revenue, either through accounting shenanigans or because it is a non-profit (made up example: a free PDF to text converter that claims to be stateless but mines passwords and information to blackmail people with)

Almost, it requires the users to actively opt in rather than opt-out.

Not every little thing needs to be opted into individually. If you have a legitimate use of data for the user’s benefit, you can collect that data after a general consent as long as you provide a way for the user to see that data and delete it. If you use that data for your own benefits (like building an advertising profile), that needs to be opted into separately.

The fines are up to €20 million, or 4% annual global turnover – whichever is higher.

Of course, paying the fine doesn't mean that you can continue with the action - it'd also likely involve imposing a temporary or permanent ban on data processing and ordering the rectification, restriction or erasure of data gathered unlawfully.

> What's the minimum amount of data? Who decides that? Is it dependent on context? I'd hope so!

Elizabeth Denham, UK's information commissioner in charge of data protection enforcement, had this to say:

"Having larger fines is useful but I think fundamentally what I'm saying is it's scaremongering to suggest that we're going to be making early examples of organisations that breach the law or that fining a top whack is going to become the norm. Our office will be more lenient on companies that have shown awareness of the GDPR and tried to implement it, when compared to those that haven't made any effort."

In other words, the compliance decision is not in your hands, but there's a promise of certain lenience. At least to start with.

A practical trouble is that once a company reaches a certain size, they no longer even know what data they have, never mind why. Do we already store personal data? Where? Is it important data such as "names + credit cards", or some god-forgotten IP addresses in a log? Email archives and attachments? How about GoogleDrive and SharePoint? Then, do we redact it, or delete it? How? How do we answer Subject Access Requests?

We've built a product to help companies take care of the most common "private data" cases (https://gdpr-tools.eu), but we're not fooling ourselves that we've solved "personal data". Or that the task is even solvable. That whole space is very much in turmoil and how hard the GDPR whip will get cracked remains to be seen.

Funnily, one of the common fears that clients have is not about the general public. It comes from disgruntled employees ratting on the company. Employees know best where personal data is stored (and often no one else in the company does), so they can really do some surgical damage by reporting their employer to the "authorities".

> A practical trouble is that once a company reaches a certain size, they no longer even know what data they have, never mind why.

That's a very good reason to do a little inventory then. Not knowing what data you have is a real problem in my book.

Indeed, and not only yours. The same issue crops up in B2B due diligence and risk management, irrespective of GDPR.

The automated inventory analysis tools, like ours and others, are only just becoming useful thanks to ML. The previous generation was mostly regex-based and mired by constant false alarms.

Except that's precisely 1/28 of the regulators to which you are subject if you are an American company and, therefore, most likely don't have a lead regulator.

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.

This is one of the things that's bothered me with it - in a similar vein to VATMOSS, GDPR will probably have more of a burden on smaller businesses, whereas larger business will have the development/consultant resource to get it right, and have those larger law firms to provide that "extra context" to brush things under the carpet if something goes awry.

The ICO seems reasonable, so hopefully they won't crush a small software shop for fucking up on something, but they're going to want to go after some people to send a message at some point. I'd guess you'd want to check that professional indemnity insurance policy, just in case.

It is, of course, all down to context. You need to show that you at least took the guidance seriously and tried to mitigate things. A notice of "collect ALL THE THINGS" won't fly, as you're basically admitting you're not prepared to consider it.

I think you're right on the social media sharing thing, it should be fairly well handled by the OAuth notices from most networks (I'd have guessed - "allow this app to post on my behalf" counts as consent?), but yeah, can't be taken as a given. IANAL, of course.

> This is one of the things that's bothered me with it - in a similar vein to VATMOSS, GDPR will probably have more of a burden on smaller businesses

In a weird way, VATMOSS and GDPR kind of work together on this...most things we collect at work that will be covered by GDPR are collected because of VATMOSS.

VATMOSS requires that we be able to justify what country's VAT we collect on a given online purchase with two pieces of "non-contradictory" evidence. So, right there we have to collect at least two things that provide location data about the customer, and GDPR expands the definition of personal data to include location data. I say "at least" because since it is required to have two non-contradictory pieces of evidence, it's prudent to collect at least three.

I think we currently use: (1) country the person selected from the "Country" drop-down on our site, (2) GeoIP at time of purchase, (3) GeoIP at time of filling out quarterly VATMOSS report, (4) GeoIP on IP addresses that they have used when downloading updates, (5) Country of bank that issued the credit card or debit card used for the purchase.

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

Under the GDPR you're not allowed to store personal data.

However, if you have purpose, and need data to fulfil that purpose, you can.

You can also ask for data, in clear terms, and if an informed user, freely choose to share, you might store that.

So, you sell shoes and magazines online. You need an address to ship both. You need a shoe size to ship the right shoes. You can demand to know the shoe size before you ship shoes - but not before you ship a magazine.

You can store order information (indeed have to, due to financial regulation). So you have a record of shipped shoe size and customer data.

You may not, without consent, store a permanent profile with shoe size and magazine preference. But it's OK to let users opt in to a profile.

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

Good question. Off the top of my head I can't think of useful pseudonymyzation related to the GDPR.

Perhaps things like hashing IP addresses for traffic stats, or using opaque identifiers for storing session interactions rather than linking directly to IP or real names. Useful pseudonymyzation is hard.

In e-commerce, order data and item level data can be exported to reported engines to gather info but you can pseudorandom the names to prevent data leakage

Another bad sentence (from the original link):

> What do you do about users who have used plaintext or silly passwords?

I don't even know what to write about that. The whole tone of the page is lecturing – about "fundamental human rights"! – and yet it's suggested that developers handle "plaintext or silly passwords"!

> What's the minimum amount of data? Who decides that? Is it dependent on context? I'd hope so!

You decide, based on context and consent. I think consent now needs to be non-blanket.

> That's a really unsettling description of a law

I know it's not ideal, but it's far from the only vague area. The law of negligence is very important to anyone running a business and is almost entirely caselaw, for example.

It's also a lot like CE certification, which takes a while to get your head around but is similarly based around both standards and self-certification.

A good chunk of europe isn't common law, how much does case law apply in these cases? In those countries the statute matters a lot more.

The GDPR is a series of rights given to people, and not a list of requirements given to business. That's the difference.

What is specifically required is pretty clear:

You must provide the user with a detailed description of what personal data of theirs you are collecting, who you are sharing it with and what your business purpose for collecting it is, and if the data is something that you need their consent to collect, you get their explicit consent to collect that data and you must let them opt-out of providing that consent without preventing them from doing business with you.

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

And consent can be revoked, and must be as easy to revoke as to give.

How granular? Every field? Every character? Every bit?

You’re thinking about it in terms of pieces of information, but GDPR thinks about it more in terms of the uses of that information. You wouldn’t expect to ask a user “Can we store your email address?“. The granular action for storing the email address is “Can we email you from time to time product offers?”. Once the user consents then that email address (and potentially full name, etc etc) can only be used for that consented action.

> You’re thinking about it in terms of pieces of information, but GDPR thinks about it more in terms of the uses of that information.

That seems sensible but is that really based on the actual text of the law or is this just your own summary?

Oh, absolutely only my own interpretation based on the reading I’ve been doing. IANAL and I’ve only skipped through the legal text.

The problem I have is that a site could tie acceptance with allowance.

e.g., I run a free, ads and promotion funded site, but I actually supplement revenue by selling the user's actions on the site to a third party. users can also have accumulated virtual currency as rewards, which can be used for premium sections of the site.

then along comes GDPR, and I tie acceptance of some virtual currency rewards with acceptance of the GDPR consent, with the threat of site access being cut off if they don't consent. is that still legal?

No, that's not presumed to be freely given consent.

https://gdpr-info.eu/recitals/no-43/ "Consent is presumed not to be freely given if ... the performance of a contract, including the provision of a service, is dependent on the consent despite such consent not being necessary for such performance."

If the data is actually needed to execute the contract (i.e. a delivery address if you're mailing stuff to the user), then you don't need separate consent; but if it's not (e.g. just revenue) then any "confirmation clicks" that are tied to site access being cut off would be just that - simply clicks that don't count as freely given consent.

Also, if you consider giving a reward for acceptance of GDPR consent, then you must also consider that consent can be revoked at any time (including 5 seconds afterward) and it must be literally as easy to withdraw consent as it is to give it.

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

Most social media sharing buttons are in fact scripts hosted outside the website currently visited. So even without using them a lot of data is send to Facebook, G+ and other social medias. If you want to see a good implementation of the idea, check Schneier's website: https://www.schneier.com/

If you want a practical example of psuedonymisation then consider a case where you have two internal systems that serve different purposes (say one is used as a CRM, the other is used for business reporting).

The CRM database is copied over to a separate database that the reporting system feeds from. Now in reality the reporting system (which will generally give you aggregated trend reporting) doesn't need a full copy of all production data as it only needs to utilise a limited subset of the overall data.

So instead of the full copy of the CRM database being copied over to the reporting database, you filter the data so you only copy over an anonymised dataset. That is pseudonymisation in a nutshell. Because you still retain the separate dataset in your system, the data is not truly anonymised, so is said to be pseudonymised. Overall I see it as linked to the requirement for data minimisation. Any particular system should only have access to the data it needs to perform its role.

Agreed, if that page is accurate, than basically it was all very best effort, except some things about requiring consent.

You have discovered the difference between principles-based regulation and rules-based regulation .