"Overall, of the 83 firms known to have held data... 24% supplied personal information without verifying the requester's identity."
Want someone else's personal data? No need to "hack into" any systems; just ask for it!
Even if someone were willing to send us "strong" ID, 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. At best, we could find an image of a passport/driving licence/whatever from that person's country and see if what they've sent us looks about right and matches any personal details we do have for the data subject.
Our disturbing conclusion was that if someone did ever send us certain types of request in connection with certain accounts, there might be no action we could safely take to resolve the situation that would definitely be lawful. If we get scammed by fake ID then we're breaking the law. If we don't accept ID that is real and comply with the subject request, we're also breaking the law.
Fortunately the affected services aren't doing anything particularly exciting or risky with personal data either, so it seems unlikely that any serious harm would come to anyone whatever happened in our case. However, the same basic issue surely affects many other data controllers/processors, and they won't necessarily be such unlikely targets as the research here shows. I haven't yet found any practical guidance from the regulators on what would be considered reasonable in this sort of situation.
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.
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?
This sounds like one of the risks of doing international business. If you can't follow the laws then don't play.
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.
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.
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.
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?
So they can identify users for purposes of complying with GDPR? (For example, to handle the data requests highlighted in this post.)
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."
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 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.
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.
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.)
"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.
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.
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.
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.
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? :-)
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.
It's fairly easy to get a reasonably convincing fake ID. High schoolers manage it all the time.
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.
What sort of agreement can you enter with someone if you don't know who they are?
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.
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."
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.
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.
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.
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?
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.
I was hoever not making an argument by induction, so leaving out the trivial case is not crucial to it.
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.
There are online services who also provide this for a cost: https://www.idcheck.io
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 guess they had no way of verifying that the ID info is real, but apparently this process was trustworthy enough for their client.
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.
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.
That's an unhelpful argument if there is no reasonable way to determine what the laws are and/or to comply with them.
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.
Amusing that legislation intended to improve privacy is normalising sending IDs to sites one doesn’t trust enough to keep one’s personal data.
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.
This is your personal opinion of how it should work, not GDPR.
If you tell someone requesting their own data under GDPR “tough luck, you lost your password,” that could invite remedies under the law.
This isn't black and white. It is legally ok to question the validity of GDPR data subject requests.
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.
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.
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.
I live in dread of subject access requests (and thankfully have only had one, and it happened to be really easy to verify).
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.
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.
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.
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.
So, when one train operator asked for a photocopy of a passport, he convinced it instead to accept a postmarked envelope addressed to the "victim".
A postmarked envelope? This is baffling to me.
You can have a plausible excuse for not having your passport - left at parent's house or accidentally in storage.
Driver's license - "I am a cyclist!"
Electricity bill - "My housemate pays all the bills!"
Bank statement - "I only do online banking!"
Electoral roll? - "Don't vote!"
But HR sent me a letter about an update to the company pension plan - will that do?
Yes! - sends through postmarked envelope picture. By that stage the confidence trick has succeeded so 'we know the guy and he is legit'.
You can get this far to get a mobile phone contract which counts as good as a utility bill in terms of supplementary proof of ID. This can then be used to get a deposit only bank account for 'savings'. This can then be just about enough ID to have almost created a person!!!
But with GDPR social engineering you can have it all so much easier.
There was so much panic about GDPR and purging every decent contact from the company newsletter list that no company thought through a thing about how to deal with GDPR information requests. Hubris at its finest.