Deleteduser.com —a $15 PII Magnet
136 points by fanf
136 points by fanf
If the entirety of your delete process is replacing an email address with something@deleteduser.com, not only are you doing the bare minimum, you are somehow doing something worse than the bare minimum — because you are willingly exposing PII to some random fella’s domain, and you weren’t doing that before.
At least in Europe, you would be breaking the law. GDPR is pretty clear on that; you have to delete all PII from your system.
Yeah this doesn't quite make sense to me. Why would any organization think that they should only overwrite the email address and not the rest of the PII?
My understanding of what’s going on is the deleted user was a recipient of emailed reports containing other people’s PII. So let’s say a hotel manager leaves the company and he was a recipient of reports containing guest names. Those guest names are not subject to the delete requirements.
I would expect replacing an email address with x@example.com would be good enough.
Not if you don't also delete their name, phone number, address etc. Clearly, some of these companies weren't and were probably breaking the law.
There are places where you are legally required to hold things like a name and an address, for e.g. tax reasons or something, which are of course exempt from the GDPR law anyway, but making sure those do not run out is a good.
In a less charitable reading of the GDPR, data you're required to hold for legal reasons has no business being available to your production systems other than for those purposes. If your main app can send out personal data after a user has requested deletion, you might still get slapped with a fine for not only mishandling but not deleting data properly. Because properly deleting data can also mean "putting the data you have to keep aside so it's better protected".
That's still a valid domain, with valid MX records. deleted_user@gdpr (no external domain) and marking the user as deleted so you don't waste time and money on the mailing process should be better
Or: supposing you're companyname.com, you set the email to USERID@deleteduser.companyname.com and stand up an SMTP server on that domain. Any mail that goes there is either an error on your part or spam, so with appropriate monitoring you can catch bugs around your deleted-user handling.
It's a domain set aside by the IETF for documentation and should not be used at all, and it should be easy enough to filter that address.
Sure, it would be as easy to filter as deleteduser.com, but then we have this post haha
You wouldn’t have this post because no one can buy the domain name and you can’t route email to it
But someone does own that domain (presumably under IETF auspices) and administrates it, which means information is leaking. Sure, an attacker couldn't register the domain, but GDPR doesn't have an exception that says "don't share personal information, unless you're sending it to an IETF-owned domain, then it's probably fine, don't worry about it".
example.com is registered to the IETF, you know, an organziation! Sure, there might be someone (or some team) that's responsible for the DNS records and such but ownership is to the organization! What personal information is being shared in this case? And as @altano states, you can't route email to that domain anyway.
I know, but there someone responsible for maintaining the server that the DNS records route to. (Well, presumably a team, I don't know the details - the point is that you still can't send random emails off to an organisation that you trust).
You're right that you can't route email to that domain, but I don't believe this is mandatory or specced-out behaviour, I believe this is just how IETF choose to implement their reference domain, and they could choose to change it that behaviour at any point. (It would be very surprising if they did, but stranger things have happened.) And even if there were a spec that managed that the example.com reference domain reject all emails, something could still go wrong and those emails could still end up (even temporarily) being sent to a real inbox that someone could look at.
I'm not necessarily saying the above is a likely occurrence, I'm saying that you don't get to offload your data security onto IETF and your assumptions about how their setup works. The whole point of regulations like GDPR is that as soon as you start handling personal user data, you take on full responsibility for that data and that means handling it properly - and if you're not using it any more, making sure it's properly deleted on your side, rather than wafting it around and hoping other people choose not to look at it.
If you really need to do the "overwrite the email, don't delete the record" approach, the suggestions elsewhere to either use a truly non-routable domain, or to use an internal domain dedicated to this case seem like significantly more sensible options. Although I still generally tend towards the idea the deletes should be deletes, and faffing about nulling out data in clever ways is just going to bite you in the behind, as it did in the cases described in this article.
Most forms will not accept 1st level domain in the email address...
Then go for deleted@deleted.invalid.
.invalid (like .example and .localhost) is designated to never end up in the root zone since 1999. That way it's a valid-looking email address that is defined invalid.
TIL invalid is special, what's the spec number for that?
EDIT: someone beat me to it: https://lobste.rs/s/muofgb/deleteduser_com_15_pii_magnet#c_wfwlil
Plenty of sites already don’t let me use my .email domain, but they’d allow “.ema” because they check if it’s 3 characters or less for some dumb resson
I've had a similar problem with my .rocks domain. Worse still, some shitty site my kids use decided to filter it after we signed up. So now I can't reset the kid's password.
At work we have an email account set up for this. We replace the user's email with deleted+<uuid>@<company>. Any emails sent end up in one of our inboxes.
I saw a discussion on the internet where someone mentioned that they deleted users in their app by overwriting their email addresses with $somethingRandom@deleteduser.com.
Not that I think this is a good way to delete data, but if you ever do something like this, a strictly better solution is to use an officially non-routable domain name like @example.com or @deleted.invalid.
example.com is not non-routable. Try opening it in a web browser.
I am pretty sure they mean routable MX records , given the topic of this thread. One can easily confirm there are no MX records for that domain : https://dns.google/query?name=example.com.&rr_type=MX&ecs= and it's a good thing because who would want to host a server that only accepts incoming emails forever?
Email is weird: “no MX records” means email uses the address records instead. There’s actually a null MX record on example.com which means it explicitly rejects all email.
Medium makes me grumpy. I was interested in this article, started reading it, and some javascript hid the article that I was reading, but failed to show whatever annoying modal it wanted to show me, so I couldn't dismiss it. I'm on a very slow and somewhat unreliable connection today, so that kind of stuff is more annoying than usual.
And CAPTCHAs don't seem to work well on this connection, so I can't get at the archive sites either.
I kind of got the gist of the article from the comments here plus the snippet I was able to read before Medium took it away to attempt to show whatever it was they wanted to show over the top of it. But I find it ironic that a piece about very user-hostile behavior was posted on a site that is itself so user-hostile.
Courtesy of an announcement on the orange site, just replace medium with scribe.rip and enjoy https://mike-sheward.scribe.rip/deleteduser-com-a-15-pii-magnet-c4396eb21061
It works with any of their hex suffixed urls, no need to use the vanity domain, if that's easier for you https://scribe.rip/deleteduser-com-a-15-pii-magnet-c4396eb21061
you can disable javascript (e.g. for all the websites in *.medium.com) and now it behaves! it’s really quite cool how a lot of annoyances of the modern internet are optional
I have the same issue with Medium - I use an extension to auto-click cookie banners, and I think it interacts badly with Medium's scripting.
I ended up reading this in another browser and it was worth it, unlike a lot of other content hosted on Medium.
You should be able to replace that with the uBlock Origin filterset(s) that hide cookie banners since the default is rejection.
It is always "surprising" and somewhat horrifying how naively some of these things are implemented by companies. I put surprising in quotes there because I am well aware how much of an afterthought many things are that shouldn't be in many companies.
I think naivety is only a smaller part of it. At least for companies that are for-profit, sure, maybe some new/junior folks on implementation teams may not know exactly how to adhere to specific data-related regulations...but for the most part, i think its merely that companies want to implement things in the cheapest way possible...so to add either specific details in advance (to properly guide the implementation team), or to conduct proper review/QA later on costs more money than the company wants to spend...So crappy stuff gets done. And, in some cases, companies even take it as a bet that they'd rather spend money on regulatory penalties if they even happen instead of fully paying for things to be done the right way. Basically, things tend to be implemented "wrong", less due to naivety and more because of capitalism. :-(
Oh yeah, that is what I hinted at with the afterthought remark. It just never is a priority for the people who get to make these calls.
While you're not wrong on any of it, I think this one is just a little bit subtle, and I can almost see how it'd happen to an organization that was attempting to behave reasonably.
By that, I mean that they actually are attempting to comply with the request to delete PII for the users they've been told to delete, and it's reasonably effective. As a thought experiment, say they had name, email, date of birth, postal address and account number for Joe Jones, the motel manager for a motel franchise, who's left the customer's company. They're overwriting all of those to all non-personal values. Everyone deleted becomes "Alan Smithee", born on 01/01/1991, with a postal address of 1060 W Addison St in Chicago, IL, and an account number of 12345. And their email gets changed to 1@deleteduser.com, 2@deleteduser.com, etc.
Absent other errors, that arguably satisfies the intent of deleting the things that could personally identify the user they were supposed to delete.
What seems to be happening here is that the system is continuing to send other users' personal details, like the dates of their hotel reservations, and their contact information, to 2@deleteduser.com. They weren't (necessarily) supposed to delete this other customer information. But because the people who planned the deletion didn't understand the model, private information for other customers or for the org in general is getting delivered to 1@deleteduser.com. Which happened until recently to be an unowned domain which someone has snapped up to collect personal information.
To me the interesting part of the story is that they're leaking other information because of the way they "deleted."
The gym begs the deleted user to rejoin them, by name.
They're all scary—and it's still bad that they're holding onto former customers' names—but this particular one is just so comically futile.
It appears that whoever is squatting on deleted.com right now may be raking in sensitive data: https://github.com/search?q=%40deleted.com&type=code
I wonder how many such domains exist and are either unowned (ripe for the picking) or are already being squatted by bad actors.
If you found that interesting, there was a similar issue where a German ministry used an unregistered test domain that was visible in public documents. A security researcher registered it and immediately got access to an internal government system. (That was only one of the issues he found.)
There was a presentation at 39C3 (in German), it's fun to watch: https://media.ccc.de/v/39c3-verlorene-domains-offene-turen-was-alte-behordendomains-verraten
I still don't understand why companies overwrite things instead of deleting the data. Are their data models really that brittle?
The author is continuing to update their fedi thredi with various tasty nuggets that aren’t mentioned in the blog post https://infosec.exchange/@SecureOwl/116404712213309413