Hacker News Reader

> Even if someone were willing to send us "strong" ID

Amusing that legislation intended to improve privacy is normalising sending IDs to sites one doesn’t trust enough to keep one’s personal data.

I think I have a "legally safe", but slow, solution:

1. The user requests information about them but claims that they lost the password and the email address.

2. The company sends a form (in English) that basically asks for the information on the id (name, date of birth, etc) and the information being requested (ex: password reset).

3. The user prints this form, fills it out and attach a copy of their ID.

4. The user goes to a notary in their country to get the signature and ID verified.

5. The user sends the form to the client's country Ministry of Foreign Affairs to get the notary's signature verified.

6. The user sends the form to the embassy of the company's country to get the Ministry of Foreign Affairs seal/signature verified.

7. The user takes a picture of them holding the form and sends that picture via email or similar to the company.

8. The user sends the form via snail mail to the company.

This process can be shortened if both the company's country and the client's country have ratified the Apostille Convention, formally known as the Hague Convention Abolishing the Requirement of Legalisation for Foreign Public Documents.

Nope, that's not legally safe -- we've been told by data authorities that the verification methods cannot be "overly burdensome" to the data subject.

I live in dread of subject access requests (and thankfully have only had one, and it happened to be really easy to verify).

Maybe you can require this long process only for people that aren't in your country.

I don't know where you live, but here in Brazil having to get documents and signatures verified by a notary is super common (and super hated).

For example: I once wanted to unregister a domain I had. The only two ways of doing it were: don't pay the renewal fee OR get a paper form verified by a notary sent over snail mail to the registro.br office.

--------

Also, you may give your clients the option of verifying their signature at the embassy of the company's country in the client's country. This would skip on that whole Ministry of Foreign Affairs non sense.

--------------

A hacky way of avoiding this "excessive burden" problem is to offer all your users the possibility of linking their public gpg key to their account.

Almost no one would do it, but you gave them the opportunity to do so, thus you cover your ass at least a bit.

IIRC they also allow charging the person - for a "reasonable" amount - for the data retrieval process (which I assume would include the "identity verification" part).

Maybe using the 3-D Secure protocol (especially the second revision) would be enough to unburden yourself for verifying the identity as Mastercard/Visa/American Express supposedly check it for you.

This would work only in some conditions (the data subject should have a card to their name that supports 3-D Secure protocol, and you need to had a complete payment platform to your website/app/whatever) and doesn't solve all the other problems we have (like being sure we are delivering the right information esp. regarding homonyms and so on), but that could be something to investigate.

Just as a fun tidbit, I've grown accustomed to using Estonia's banklinks, and then like approx. 10 years after that the 3D-secure system starts appearing on foreign sites that almost provides the same functionality - it's nice to see finally some steps taken but damn, it's basically 20 years behind what everyone could have had.

The ability to charge is only for either (a) additional copies of data or (b) if the request is "manifestly unfounded or excessive." Given that there's no guidance on (b), that eliminates 99.9% of all SARs.

Government officials created an untenable law in the name of the technological boogey man?! </mild-shock>

Not bogey. Misuse of personal days it's happening daily, but the law is not exactly super great. Better than nothing I suppose.

I think whether the current implementation of GDPR is better than nothing is still up for debate. The intention is mostly good, but the execution leaves an immense amount to be desired (as evidenced by common threads like this) and disproportionately affects/burdens small businesses.

Hey now. Mass surveillance, data breaches, and non-consensual data sale are absolutely issues, and will continue to be. This isn’t a boogey man, this is real, and it’s entirely the technology industry’s fault. Maybe we wouldn’t have to deal with the GDPR if we treated data as a liability from the beginning.

This isn’t a boogey man, this is real, and it’s entirely the technology industry’s fault.

I agree there are real dangers, but I don't think blaming it entirely on the tech industry is fair. The financial services industry has been profiling as much as it could get away with forever. Government security services and the like obviously do this sort of thing as well. Modern technology has made these things easier and surely provides a generous source of additional data to both of the above groups, and targeted ads have created another not entirely welcome variation on the theme, but modern technology is hardly the original source of creepy data-hoarding behaviour.

The email used during registration is sufficient. If you don't have email then username+password.

If they don't have that they don't get access to data. They need to be able to prove who they are and reasonably that is the same information that is used during registration.

If password is lost then tough luck.

> If password is lost then tough luck

This is your personal opinion of how it should work, not GDPR.

I doubt that a black-hat attacker is going to file a lawsuit to obtain someone else's personal information.

But what if the request is genuine?

Then the user will be authenticated by the court, and you will have to make your case that without the court's intervention, you could not be certain of the requester's identity.

This isn't black and white. It is legally ok to question the validity of GDPR data subject requests.

> I doubt that a black-hat attacker is going to file a lawsuit

If you tell someone requesting their own data under GDPR “tough luck, you lost your password,” that could invite remedies under the law.

What are they going to sue for? "I can’t identify myself but still want the data of some random person I claim to be"?

GDPR requires the user to identify themselves to request data.

If a password and username is the only possible way of identification then that is enough. And if one can not provide that then tough luck it is.

I'm not sure it should be this hard. If all you know about a customer is his e-mail address and site password, then you can only verify the user's identity by e-mail address and password. A "strong" ID only helps if you have prior information about that ID stored on your end.

Likewise, it stands to reason that you shouldn't provide information about a user at e-mail request only, without proof that said user also knows the password to your site. You could even create a policy that a user cannot do GDPR requests for up to seven days following a e-mail password reset action, to mitigate the account hijack situation.

As for data processors, who have no direct relationship with end users, the safest policy is to not collect personally-identifying information at all, only use the data controller's surrogate identity. And if you must collect PII, then use that previously stored data to verify the user, not an ID card that you have no way of validating. If you only have the natural address of the user (for example, you're a shipping company), then only offer to send the data to that known address, or make the user prove his residence (e.g. utility bills); if you only know a bank account number, ask for a (sufficiently-redacted) bank statement to that effect, etc.

A government-issued ID is only worth asking for if you can verify it.

One option would be to evaluate if it would be safe to delete the data.

In that case you could offer to delete the data. Countries typically have some expensive way to proof identity. So, delete or actually proof who you are. Of course, sending a message to, say, a know email address that to intent to do that helps avoiding angry customers.

If you cannot delete the data because it is valuable to the customer, then just to offer the service you already have to figure out have to give people access to their accounts if they lost the password.

Offering to let attackers delete customer data is not a good solution.

"Hi, I'd like to request all my user data under the username phicoh." --> "I've forgotten the password to my account; would you just delete it instead then?"

> If we get scammed by fake ID then we're breaking the law.

The person who committed fraud by providing a fake ID is breaking the law. I'd think that a regulator would take into account when deciding whether it would be in the public interest to prosecute you.

This is nothing new. People could make "subject access requests" before the GDPR, and you could charge up to £10 (in the UK) to reply.

It's perfectly lawful to refuse to disclose anything until you have received reasonable evidence of the person's identity and payment (I don't know if you can still charge under the GDPR -- Edit: Apparently you may not charge for the first copy, but you may for further copies).

Considering the potential risks (including bad PR) and penalties it is better to refuse to disclose data because you have doubts rather than to disclose easily.

"but what if they don't or they claim to have forgotten their password etc?"

How do you manage this kind of use case in your normal operation? Does it mean that if you cannot reset your password your account is locked forever? If not how is this process less valid to answer a GDPR request?

> we don't have any special knowledge of what official government-issued ID looks like in every country where we have customers, nor the human resources or automated technology to investigate in detail whether any ID that is sent might be faked.

This sounds like one of the risks of doing international business. If you can't follow the laws then don't play.

OP sounds like he was trying hard to navigate and follow the law? The problem is he ended up finding no reasonable solution that both protected his users privacy while also following the rules, and was disturbed by the implications of it all considering it was supposed to protect them in the first place. Those are very valid criticisms.

Simply dismissing everyone who shows concern about a law as mere law dodgers or foreign bad actors disinterested in following the local law is unhelpful and borderline anti-intellectual.

One of the intended goals of GDPR is to reduce the processing of personal data - not only that the companies should do it differently, but that at least half of the companies who currently have my data really shouldn't have it in the first place.

It depends on the circumstances of each scenario, but it would be completely reasonable if large numbers of smallish companies acknowledge that they lack the capacity to handle personal data properly and the recommended strategy for GDPR compliance is that they should simply stop requesting and storing that data. Yes, it raises the barriers for entry in areas where that data is absolutely necessary. But it also makes companies think twice whether it's really necessary and worth it, and that's a good thing.

> it also makes companies think twice whether it's really necessary and worth it

The simple fact that someone has an account at a service can be private information. For anything requiring even a modicum of persistence, keeping these data is tough to avoid.

I think most of HN agrees GDPR’s goals are good. It was just sloppily drafted, passed and implemented.

GDPR does not care about privacy.

It cares about personal identification. Such as full name and address, and a bunch of other protected things.

Why would any random service request, process or more importantly store these?

> Why would any random service request, process or more importantly store these?

So they can identify users for purposes of complying with GDPR? (For example, to handle the data requests highlighted in this post.)

The GDPR recitals do not recommend gathering additional data solely to be able to fulfill these requests.

See https://gdpr-info.eu/recitals/no-64/ and https://gdpr-info.eu/recitals/no-57/ - the key part is "A controller should not retain personal data for the sole purpose of being able to react to potential requests."

> The GDPR recitals do not recommend gathering additional data solely to be able to fulfill these requests

One, these are non-binding recitals.

Two, the conflict between (a) data-furnishing requirements and (b) advice against retaining data that would validate the requestor is exactly the point of this post.

That’s simply not the law. The official guidance (https://gdpr.eu/eu-gdpr-personal-data/) is that even just an IP address or a license plate number are sufficient to count as identifying a person.

It depends on the circumstances of each scenario, but it would be completely reasonable if large numbers of smallish companies acknowledge that they lack the capacity to handle personal data properly and the recommended strategy for GDPR compliance is that they should simply stop requesting and storing that data.

That's not a reasonable strategy at all. Any company doing more than selling basic goods in person for cash probably needs to process some level of personal data for legitimate reasons. In fact, it will probably be legally required to do so in several respects.

It's all very well arguing that you want to reduce processing of personal data, but I think what you really mean is that you want to reduce processing of personal data in ways you don't like. Some amount of processing of personal data about you is always going to be necessary, and indeed essential to your vital interests and the normal functioning of society.

"Any company doing more than selling basic goods in person for cash probably needs to process some level of personal data for legitimate reasons." is a bit tricky, and I'm not certain that it's true. I'd say that many common business processes use personal data for reasons of tradition, but don't really need it.

1) "Selling for cash" - accepting credit cards and wire transfers (paying by check isn't really a thing in most of EU) doesn't necessarily require you to store PII. Yes, you could get cardholder name, but perhaps you shouldn't; just as you (most likely, for PCI DSS reasons) don't handle CC numbers but delegate it to e.g. some merchant gateway service, if you also delegate CC fraud analysis to them, then you don't need any details about the transcaction beyond the amount and ID.

2) "Selling in person" - delivery is tricky, but you can reduce the exposure a lot by having the information be transient. If you're delivering pizza, then you don't need to store every order's phone number and address forever; and if you don't store the delivery data beyond the delivery, then if someone requests all the data you have on them, then you can honestly say "nothing".

etc. Of course, details matter, and yes, that definitely don't fit all cases, but it's my feeling that they work in half the cases where companies had my data.

"Selling for cash" - accepting credit cards and wire transfers (paying by check isn't really a thing in most of EU) doesn't necessarily require you to store PII.

How are you going to identify the source of a wire transfer if you don't have a customer to match it against?

Also, if you're selling online then anything service-like is already caught by the EU VAT place-of-supply rules (which require verification of the buyer's location and keeping adequate evidence for up to 7 years) and there have been proposals to extend that to sales of physical goods for some time.

If you're delivering pizza, then you don't need to store every order's phone number and address forever; and if you don't store the delivery data beyond the delivery, then if someone requests all the data you have on them, then you can honestly say "nothing".

And that's exactly what you'll have to tell everyone's credit card company when they start disputing charges as product-not-delivered and you have nothing to counter with.

I'm afraid you're being extremely optimistic about how much personal data processing can be avoided in even these everyday situations. And this is before you do anything like marketing, customer relations, logging use of your electronic systems, having any employees, paying any suppliers, etc. I don't doubt that some cases where companies currently have your data could be avoided, but I suspect 50% is a gross exaggeration.

"How are you going to identify the source of a wire transfer if you don't have a customer to match it against?"

Already in current practice you generally don't identify the source, you identify the order # or invoice # in the transfer details and ignore the payer which can be and often is different from the ordering customer (family members, companies paying some bills, etc), the payer information currently gets used only in case of mistakes and such.

My point is that I'd like all these companies to do their best to treat these purchases as if they were anonymous. But your point about VAT rules is a valid issue that might have wider implications about the general necessity to store data.

"what you'll have to tell everyone's credit card company when they start disputing charges as product-not-delivered and you have nothing to counter with." that's absolutely not an issue, that might be the case for card-not-present transactions but for as long as I can remember every single pizza courier or similar would use a wireless terminal to get a chip&pin (or now contactless) card-present authorisation which can't really be disputed in this way.

My point is that I'd like all these companies to do their best to treat these purchases as if they were anonymous. But your point about VAT rules is a valid issue that might have wider implications about the general necessity to store data.

Yes, you still have VAT records to keep. You also need to prove that you provided all required information to the customer under the consumer protection rules or you can end up having to refund everything going back quite a long time. All these protection rules require accompanying record-keeping as evidence of compliance, which unfortunately is going to undermine your hope to make even simple transactions anonymous in many cases.

that's absolutely not an issue, that might be the case for card-not-present transactions but for as long as I can remember every single pizza courier or similar would use a wireless terminal to get a chip&pin (or now contactless) card-present authorisation which can't really be disputed in this way.

Do you often go into a pizza place and witness a card present transaction to pay for a delivery order? :-)

> Do you often go into a pizza place and witness a card present transaction to pay for a delivery order? :-)

Yes, that's exactly what I'm saying, almost all the pizza/goods delivery/taxi/whatever are card-present transactions; whenever I order something like a pizza for delivery, the delivery dude arrives at my door with a wireless card terminal and I pay with my card present (chip+pin or contactless if the amount is small) upon receiving the pizza, and this has beeen this way for so many years now already that I don't remember when they switched from the earlier model, now businesses such as these usually don't have card-not-present acquiring contracts, possibly for cost or fraud reasons as both these things are worse if you have card-not-present permitted.

>you don't need any details about the transcaction beyond the amount and ID. //

That's a lot of trust in the merchant services. "What transaction?", then if all you had was a transaction ID what do you do?

Also, to process refunds you need to have payment details.

In your second case only store the details if people explicitly want you to. You can do repeat customer discounts by sending vouchers for a later order with the present order confirmation. (You can't restrict discounts to those who give up their PII if I'm reading things right.)

What do you mean by ""What transaction?", then if all you had was a transaction ID what do you do?" - that's a common process in online stores, you make a contract with an acquiring bank with the default scenario that you won't be processing transactions yourself (as most smallish customers can't or don't want to handle full PCI DSS compliance), then you (or the bank) contracts with one of the merchant gateway providers, and whenever you forward them a customer order session and get back a confirmation token, then you verify it afterwards (usually next morning after closing of business day) with your bank that you've got each transaction. Or something similar, details may vary - but it's an established process that works for thousands and thousands of companies without any significant trust issues. Yes, the gateway has to be trustworthy - in part that's the service they provide, to handle card data in a trustworthy manner because you don't want to be required to be trustworthy because doing things in a trustworthy manner is complicated and expensive - secure facilities, regular audits, four-eyes principle, separation of duties that's infeasible for smallish companies, etc, etc. You also have to trust your acquiring bank, and Visa/Mastercard network, that's also part of the deal.

"Also, to process refunds you need to have payment details." this is false, merchant gateways (in general, not all of them) can also execute refunds (or recurring payments) without you having any sensitive details but just that same transaction confirmation token they give you when the initial transaction was made, I've written code relating to these processes.

Well, in our shop [no longer open, was a micro-business] someone comes in for a refund, but doesn't have the receipt, there's no way to process a refund except to open the safe and get the receipt because you need to refund the same card and you don't know the card without keeping some record of it.

We've had transactions that failed to upload but were processed normally on the [mobile] card terminal, and we had to give the merchant services details to complete the processing of the transaction. Sometimes a transaction would fail during processing [cardholder not present (CNP), via phone] but we wouldn't realise until the phone was down, so in some cases we contacted the customer (our business required contact details, it couldn't run without them; this was pre-GDPR anyway). Other times the bank network would be out, so we'd be unable to process transactions without keeping customer data (temporarily).

>as most smallish customers can't or don't want to handle full PCI DSS compliance //

The banks were real bastards for this. Despite providing us mobile card terminals that don't connect to local network they required us to pay for PCI compliance audits of local equipment or pay a penalty amount [you could audit it yourself, took me about 8 hours of reading documentation to establish the protocol as they apparently didn't want us to do it but wanted us to pay instead]. The PCI stuff was basically a hidden-cost scam AFAICT.

> This sounds like one of the risks of doing international business. If you can't follow the laws then don't play.

Sure, but while technically correct, this comment doesn't add anything to the conversation. The question isn't whether or not GP should need to follow laws -- it's "what laws should we be passing, and what are the effects of those laws?"

It's in Europe's best interest to protect their citizens, given that it currently looks like ~40% of the market is more frightened of refusing a GDPR request then they are of leaking PII.

There are lots of ways the EU could address that problem -- harsher penalties, revising how IDs work across member states, releasing more resources for smaller businesses, clarifying more broadly that refusing a GDPR request because of lack of identification is OK. All of these directions have pros and cons.

Frankly, no one has the resources to do this reliably, and the identity theft consequences are potentially enormous.

It's fairly easy to get a reasonably convincing fake ID. High schoolers manage it all the time.

That seems weird, from what I see in Europe, ID forgery is quite rare; making a convincing fake ID is about as difficult (or more difficult) as making convincing fake money, as pretty much the same anti-counterfeiting measures are used; and carries about the same consequences as counterfeiting money. It's possible, but not cheap or widespread - there are a bunch of ways how you could get money or stuff with a fake ID, but it's very rare in crime statistics; it's more common to see real IDs (of e.g. homeless people) used in such fraud cases, or having an accomplice employee making fake contracts without IDs.

Perhaps it's the issue with the lack of a good centralized ID in USA so you have all kinds of different "ID-like" documents, and some of them are insecure?

There's also less motivation for teenagers getting fake IDs - I assume in USA the 21-year alcohol limit is a big driver; but here it's not that big of an issue, plus it's easier and cheaper for a teenager to buy e.g. heroin than a fake ID, and being caught using a counterfeit ID is a crime that risks geeting jail time while buying/possession of small amounts of drugs won't; so using a fake ID is difficult and risky, and so it happens not that often.

Fake IDs in EU don't really work, since anyone who really cares (banks, police, ...) will just read the info from the machine readable zone and run that against the relevant database. So EU IDs are more like a web-server session cookie, you can't just make one up.

There are online services who also provide this for a cost: https://www.idcheck.io

Those just analyze photos for photoshop artifacts for a CYA receipt. They don't verify that the ID info is real.

That's next to useless under identity fraud / attacks any more sophisticated than MS Paint level skills. You're severely underplaying how easy it is to fake documentation and the attacks it enables.

I had to verify my identity for an online service a while back. They used a third party company that has a mobile phone app essentially for video conferencing; you then call this company via the app and talk to them. They ask you to show your face and move around and to show your ID, including moving it around so they can check that the security hologram (this was an EU passport) is indeed one. So for this kind of check MS Paint skills would not be enough by far.

I guess they had no way of verifying that the ID info is real, but apparently this process was trustworthy enough for their client.

This sounds like something vulnerable to real-time deepfakes in the very near future.

Maybe, but you can say that about anything that is not in-person face-to-face communication along with physically handing over the passport for inspection. I think the process was pretty rigorous for the current state of the art, and infinitely better than the normal approach of mailing around PDFs into which I have pasted a scan of my signature.

Remember that a GDPR request is going to typically come electronically. You won't have a physical item to examine for all its anti-counterfeiting features - you're probably going to have a photograph from a mobile phone to look at.

To me it sounds a bit dubious that you can both have a valid reason for keeping personal information about someone and not have a valid way of verifying that you are actually communicating with them.

What sort of agreement can you enter with someone if you don't know who they are?

> To me it sounds a bit dubious that you can both have a valid reason for keeping personal information about someone and not have a valid way of verifying that you are actually communicating with them.

Suppose I run a matchmaking site that stores a real name, username, and sexual orientation for registered users.

To avoid over-collecting data, that's all I require. I don't need strong verification at this stage because there's little risk if someone creates a fraudulent account, and collecting strong verification can add other data security risks.

However, if someone demands the data already in the system, it's of a presumably real person. And revealing whether user X is gay can be very sensitive information.

I don't think that what you describe is incompatible with GDPR.

In general GDPR allows and requires you to use 'all reasonable measures to verify the identity', and in your particular scenario requiring the same authentication that you usually use would be considered reasonable, and it's likely the only possible reasonable measure - if what you say is all you store, then it's impossible to distinguish between two different John Smiths making such requests, and https://gdpr-info.eu/recitals/no-64/ recommends that you should not request more info just for the purpose of these requests.

In this scenario where the information was provided by the users themselves (if you had collected them otherwise from third parties, that'd be a very different issue) simply putting a link "download your data here" on your site for authenticated users would be a reasonable solution; and it matches https://gdpr-info.eu/recitals/no-63/ recommendation "Where possible, the controller should be able to provide remote access to a secure system which would provide the data subject with direct access to his or her personal data."

Yeah, there is some weird subtext to the argument, that for some reason account access shouldn't count as secure verification?

I guess this all hinges on the idea that to implement GDPR all you need to do is set up an email adress and handle all requests manually, only to then discover that: actually, identity management via plaintext email is a bit tricky.

Yeah, there is some weird subtext to the argument, that for some reason account access shouldn't count as secure verification?

It's not in dispute that account access using known good credentials would be reasonable verification. But people forget passwords or mistype email addresses or lose access to email accounts, and they still have legal rights as data subjects under the GDPR.

So, it also matters whether other forms of identification are acceptable. If you have some reasonable means of confirming someone's identity in response to a request under GDPR and you try to avoid using it because the person didn't follow your preferred method based on standard account credentials, it's not clear that regulators would accept that as reasonable. And any time the words "not clear" appear, they come with an implicit threat of severe penalties in GDPR world.

This does seem quite explicit - "If you have some reasonable means of confirming someone's identity in response to a request under GDPR" then you have to use them even if they're not your preferred means. In the scenario proposed above the company wouldn't have to confirm the identity only because they can't.

If someone loses their password and asks for their data under the GDPR it's an open question whether the site can simply say "sorry, there's no longer any way for us to verify you are who you say you are".

Ah, that's actually simple - the answer depends on whether that statement is true or not.

In the abovementioned case where only name (which is not unique) and password and sexual orientation is stored, and literally nothing else, you can say "sorry, we took all reasonable measures to verify your identity, and couldn't" because that's how it is.

However, if google or paypal or someone else who stores much more data says "sorry, there's no longer any way for us to verify you are who you say you are", then that's a lie (easily verifiable by the regulator), and that's not acceptable.

Is it? What paragraph makes it ambigious whether a company needs to do more than reasonable efforts establish if a request is legitimate?

Why would you need a real name? You shouldn't collect it.

So you say you store sexual orientation connected to a real name, that this information is sensitive, and that you have shoddy account security?

If someone wants to download account information they just have to log in and press the button on the appropriate page, and either get the data directly or else some special token to prove account ownership.

If account access is not secure enough, then what business do you have storing the information at all?

What sort of agreement can you enter with someone if you don't know who they are?

Have you ever walked into a shop, bought some chocolate with cash, and walked out?

There you go, legally binding contract of sale, yet the seller has no idea who the buyer was.

Oh all right, I grant you can enter into agreements that the immediately terminate without any need to establish identity.

I was hoever not making an argument by induction, so leaving out the trivial case is not crucial to it.

It might help if you gave a couple of example situations that people could answer for.

Remotely we generally use digital verification, my ID card has a secure chip that's usable for online authentication (available to third parties by redirect through a gov't website) and for e-signatures of digital documents; so I could send a GDPR request in a PDF where the recipient can verify that this indeed was signed by Name Surname ID123. However, things like this are still a bit fragmented between different EU countries, some harmonization would be really helpful for cross-border businesses and it will probably take many years.

What I'm probably saying is that the question "is a GDPR request-er providing valid ID" is solvable; it's not solvable easily (yet) but this BlackHat experiment shows that large companies already can do it internally and smaller companies probably can outsource it to someone who can do the required integrations/processes to match all the EU states.

If you can't follow the laws then don't play.

That's an unhelpful argument if there is no reasonable way to determine what the laws are and/or to comply with them.

> If you can't follow the laws then don't play.

This is the subtext of the GDPR. Bluntly, they only want HugeCos providing services on the internet, anyone worth fewer than around 10 digits can suck it.

This isn't limited to Europe, of course. Most governments are coming around to the idea that there are too many printing presses.