Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
PSA: HelloFresh doesn't delete data when asked, only changes the email address
78 points by seasicksteve on May 26, 2022 | hide | past | favorite | 52 comments
Asking HelloFresh to delete your data will simply result in them changing the email address on your account to hellofreshcustomer-<customer id>@hellofresh.de

Your account showing your name, address, credit card, etc can still be accessed whilst the token stored in the cookie is still valid



I think it's pretty rare that a business is going to erase all record that a transaction ever occurred, particularly a transaction involving other people (merchants, gig workers). Rather they are going to erase your association with the transaction, by rewriting your account as a "tombstone" account with fake details. That's a pretty normal approach.


You have to show a pretty strong need to keep PII after a user has expressly withdrawn their permission for you to carry on processing it.

No, it's not uncommon to "tombstone" data, but when you do that, you should remove data you have no rights to any more. Order numbers, accounting, payments that sort of stuff is all fair game (for limited time), but the point here is it appears they're not deleting anything, they're just moving it to be inaccessible to the user.

They keep the data. And that's a) scummy and b) illegal in several jurisdictions.


If the records no longer contain PII, then they've arguably satisfied their duties under the law, haven't they? Has a court held otherwise?


But the records do.

> Your account showing your name, address, credit card, etc can still be accessed whilst the token stored in the cookie is still valid


They're also given time for the deletion to be fully complete -- backups etc.. That could apply here.


I think replacing the userid with an ID that isn’t reversible but keeps all the foreign key constraints is acceptable.


Correct for transaction data. Such data is owned by hello fresh and they need to keep it (for financial reporting, for instance).

However OP talked of master data. That should be removed when user asks to delete their account.


If it really keeps credit card details, that’s way more than just a tombstone.


(Asking out of ignorance, I don’t know how this works)

Suppose HelloFresh found out they should give you a refund after you deleted your account. Would they need the credit card to do that?


In your scenario are you suggesting that HelloFresh start sending people refunds unprompted? That doesn't exactly sound likely, but sure, they could stick a "Disclaimer: If you delete your details it may make it more difficult for us to refund you if we suddenly lose our minds and start inexplicably sending refunds to people unprompted".


In general, it’s not that strange to sell something then realize you can’t actually deliver it and make a refund. I guess HelloFresh is a little bit different from the average e-commerce business because they sell perishable food. But probably there’s some case where they would take some money then later decide to give it back.


They could mail a check.. oops now they need your mailing address

Or they could call you and ask.. oops now they need your phone number

etc


you only need the transaction details to call your payment gateway to do the refund, unless you are the payment gateway.


Encrypted archival of PII for a limited time, say a year. GDPR allows the storage for legal reasons.

A one way hash of PII, salted, stretched, this is enough to verify identity but also doesn't keep the PII directly (I know only 8 billion people on earth is not enough entropy. Still you make a legal effort and segregate it from your network)


Somehow this doesn't surprise me, they still want to be able to spam you with offers (I legit got a text today from Martha and Marley, I have not used them for 3+ years) and possibly sell your data to make more money.

It does bring up an interesting idea, how many people use unique emails for each company to track spam. If something like that was possible for shipped goods (wouldn't work well for food but that is the exception). I would gladly add a couple days of transit time and pay a bit to catch the companies selling my information.


If you don't need to use the second line for "Street Address", you might be able to repurpose it and put in a unique identifier for each entity you conduct business with. Might depend on your mail carrier being OK with putting a letter to "Apt 41723" in the only mailbox at the primary address.


Does the USPS Address Verification API reject such "modifications"?

https://www.usps.com/business/web-tools-apis/


Maybe. On one hand USPS might have a database of which buildings are multi-family homes and reject stuff like "unit 123" if it's not a multi-family/tenant building. However, I've also seen letters addressed to "basement" (for someone who's renting out the basement of a single family home) which seem to arrive fine so maybe they're not doing too aggressive filtering.


The OP linked the German version of hello fresh so likely moot.


I have been using catch-all for years! I have literally just worked on a mini project to automate it for all my family members with forwardemail.net using Terraform: https://github.com/politician/barissat-infra

Catch-all are working but still WIP for the primary domain part due to a bug with the Google workspace provider. https://github.com/politician/barissat-infra/issues/2


>It does bring up an interesting idea, how many people use unique emails for each company to track spam

Probably not a lot, but Apple's "Hide my Email" feature is now native to iOS and should in theory make this fairly easy to do. I do this _occasionally_ when signing up for new sites.


I had an online place (I can't recall which) that flagged a Hide My Email as invalid. That pissed me off and I left that site immediately.


I was very happy when that was added, I have started using it for anything I sign up for.

Doesn't fix everything that already has my email, but I am hoping it helps to expose companies that sell data more. It is hard to hide behind "well maybe you accidentally did it" when I don't think there is a way on iOS to use the same email in multiple places?


I've gotten to the point where signing up for anything is rare. I used to try out all types of tools to see if they help me work, or sign up for the "10% discount" at some new store.

But then you start to realize what happens to your info. If I buy running shorts from Nike I'll start getting junk mail from running and fitness brands to my home address. If I back something on Kickstarter I get spam coming from other Kickstarter campaigns.

Lately I've started reading privacy policies more than signing up. Here's something from Pelotons policy on what they collect:

> Voice and Likeness: Your visual image, likeness and voice recording (e.g., via photographs, video and/or CCTV) if you visit our studios and/or showrooms or participate in live studio classes. Additionally, Peloton fitness equipment and the Peloton App may contain a camera, microphone and voice control features. These features are in use only when activated by you, for example, to use the Peloton Guide, to take a Peloton user profile photo or to initiate or accept a video chat from another user and, for usage of the Peloton App, any device settings that you have activated.


You could probably add something like #23 to the end of your street address and still get it.

For gmail and fastmail, you can use jim+xyz@gmail.com and change the xyz for every new email signup.


I do that for gmail, but I've discovered that many sites will claim that xxx+yyy@gmail.com is not a valid email.

Also it would be very easy for a scummy site to just remove the +yyy part and the rest will still be a valid gmail address.


Plus selling addresses to other food services is probably as valuable as spamming themselves.


Right. For most (American) companies (I don’t know about GDPR-folks), “delete” means “hide from requesting user” not “remove data from internal system.”

Data is (at least a big part of) their business and they don’t further that end by removing data.

Of course it’s shitty, but it’s industry standard practice. It’s similar to the Facebook shadow profile you have when you don’t even have a Facebook account: you can ask them to delete your direct data, but they’ll never remove the implications they learned from that data.


Also, if they do delete it from "current db," they likely have years of backups. I find it difficult to believe someone like FB (or any other) would unarchive multiple terrabyte archives from storage, restore them (db, etc), delete the data, and rearchive them, for each daily/weekly/monthly/yearly backup my data is contained within.


I have no knowledge of how Facebook or anybody else does their backup deletion - but one way to accomplish this is to encrypt parts of the backups with a per user key, and delete the key when deletion is requested - tapes (or whatever) stay in cold storage but the data is irretrievable.


I don't doubt that's it but as also dev my first inclination is to soft delete most anything. Later do a real delete to avoid any mistakes.

Atlassian maybe could have used that ...


CCPA provides a handful of reasons that allow a business to maintain data even after you request to be deleted: https://cdp.cooley.com/ccpa-2018/#section-1798-105


Also worth noting that if you're using them to hit your 5:2 fast day calories, the nutritional information on their recipe cards is junk. They might have been accurate once upon a time, but I suspect they sub ingredients and suppliers out as the prices change. The "splash of oil" is hilarious. 100kcal a go.

Convenient and interesting as they are, you have to do your own maths and adjust portion sizes accordingly. By the time you've done that, it's easier to just cook something you're used to cooking @500kcal.

https://twitter.com/oliw/status/1490985345521172482


A [CTRL]+[F] for 'Pinterest' yielded no results.

They do the same, and you can check, go make an account with your e-mail, and then ask to delete it, they just change it to name@domain.com-wrongpleasefix

You can no longer log in and the account is still there.


Tumblr just added an deactivated- in front of the actual address IIRC.

Since I have an catchall for my own domain I received spam on those addresses after they lost customers data.


Is this "forever" or possibly a sort of soft delete pending something else?


This is generally standard practice for e-commerce companies, is it not?


It is common for companies to randomize all data containing PII. It's not common for them to obfuscate one data point and leave all the others alone.


An internal ID for a customer record is probably tied to the orders and other internal data. Deleting a record just breaks shit you might need for historical purposes.

It's better to disassociate the customer info and maintain the other links - unless there is an obligation to do so otherwise (unfamiliar with gdrp nuances)

Randomizing multiple foreign keys at the same time is interesting though. Is it really necessary if the company isn't intentionally being malicious trying to maintain and advertise to the requesting individual ?


Well that’s fresh. But if the user data is anonymized, it’s OK, right? I’m assuming there isn’t any other PII.


Well depends on how you define PII

> name, address, credit card, etc.


That is not news. That is how most of the industry works.


Sadly many companies do the same thing, violating the GDPR, even EU-based companies who know better.

I wonder if engineers who built and have knowledge of these systems could anonymously disclose/leak details of violations to a site pairing them with other engineers. The other engineers could submit a GDPR forget-me request, which the company wouldn't be able to fulfil, and then people could complain to the national regulators with specific instructions on how to find said not-actually-deleted information. Obviously it would violate non-disclosure agreements, but I'd imagine that would get companies to clean up their act fairly quickly, or at least it would if the national regulators had more teeth.


The lawyers we consulted said the biggest risk for a company without many individual customers was their own employees.

A disgruntled former employee makes a GDPR request, etc.


you can't instantly delete user data because of safety/liability reasons


Article 17 of the GDPR would disagree.

""" “The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay” if one of a number of conditions applies. “Undue delay” is considered to be about a month.

"""


30 days is not instant.

The only issue here is HelloFresh not properly telling its customers how long it takes for them to actually delete the data.


That doesn’t seem to contradict what the parent comment suggests.


Does that include data contained in their x years of backups?


What companies keep x years of backups (for any x > 1, possibly even ½)? I don’t think that’s worth much to any company. Better make sure your recent backups are good than spend effort on keeping such old backups around.

For accounting/tax purposes, you need data up to typically 7-ish years ago, but isn’t that data typically online nowadays so that it will end up in today’s backup?

Even if they still have the bits from an old backup, they should have thrown away its encryption key.


Yes, so it's important to distinguish between backups and archives.

If you're keeping data for years, it's an archive and not a backup.


One of the bizarre machinations that our legal team determined is that you should be able to delete your data and still be a customer. Which means retaining all sorts of billing information until you actually delete your account.

Did you try reaching out to HelloFresh about this? At our company all GDPR requests are manually serviced. You can likely get a human being to respond.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: