[throwawaykai]

Herokai here. Unfortunately we had no choice on the data retention front — once we’ve disconnected your database, we aren’t ALLOWED to hold your data for more than 30 days. That’s part of the data scrubbing protocol that we agree to when you sign up. We fought hard for 90+ days internally, but in the end couldn’t get over the issue that we’d be in violation of our contracts with customers.

[craigkerstiens]

Having worked at Heroku and had a large part in building Heroku Postgres I do not recall this explicit policy, and it seems very squirrelly to me. Maybe this came in as a policy in recent years and it is the case, but still seems like hiding behind a policy as opposed to doing right by customers.

You could easily block all incoming connections to the database. For a free database of 10k rows there were no SLAs, and you would still technically be hosting the database.

Even taking a dump and emailing it to me feels like a safer option here.

There were better answers here for sure. If the honest answer is we just didn't feel the effort was worth it for this class of users at least own that.

[tptacek]

Having been through a SOC2 audit: this wouldn't fly. It's on the checklist of issues that you get hit with regardless of what kind of company you are: when customer accounts are terminated, the data retention clock starts ticking.

You can pick an arbitrary time frame for retention, but whatever you pick, you have to communicate to users, and you can't just change it on a whim. Normal customers want this clock short. They don't want you to retain their stuff after they cancel.

[crote]

But this isn't an account termination. They deleted the data of an active account, without informing the user.

Why could they not turn it into a read-only database without access from the Heroku apps instead? Then it'd just be a routine change to the service offered, would it not?

[shkkmo]

The customer account wasn't terminated, the free DB being used by paid Dynos was deleted without any input from or notification to the customer.

I highly doubt normal customers want this clock short when the cancellation is not customer initiated.

[tptacek]

Data retention policies are written by compliance people, not product people, so distinctions like overt, deliberate cancellation and "cancellation for nonpayment" or "abandonment" or "discontinuation" usually aren't captured in them. I'm not saying it's great that Heroku deleted these databases; I'm saying: the description given upthread, that the databases were deleted because of contractual requirements, is super plausible.

[shkkmo]

Plausible, sure, but that doesn't mean it isn't a cop out. There are many things that Heroku could have done to prevent this, like delaying the disconnection when they don't have confirmed delivery of the notifications and/or when they are connected to paid dynos/accounts.

Thus didn't happen because of the contract, but because the people implementing this transition didn't give a crap.

[tptacek]

I'm just telling you that what the commenter upthread said rang true. I'm not offering an assessment of compliance regimes.

[Dylan16807]

If you start disconnecting the database, in the same way a user could (on most services?) to keep the database around and idle, there's no way that counts as any kind of deletion. So do that if you need to and you really want to give customers 90 days to react.

[mst]

It feels like it would've been better to have written things such that if it's attached to a still active account that's paying for other services things would be permitted to work a bit differently, but of course the relevant clauses will have been written long before anybody anticipated a new owner deciding to turn a bunch of things off, so under the circumstances at the time of writing it's unsurprising and not really the authors' fault that they didn't consider that.

I had a vague thought for a moment about maybe being able to give customers the option to opt in to an updated set of terms that would've been better designed for the situation ... but since the original Tell HN author didn't get any emails about this at all, presumably they wouldn't've got that one either so even if (and given 'vague thought' I'm not claiming any particular level of 'good idea' to it) that had been done it presumably wouldn't've helped them anyway.

It seems to me the root problem here isn't so much the compliance initiated policies as a complete failure to take 'make sure people have been adequately warned' sufficiently seriously given the potential consequences.

Deeply unfortunate.

(read that last sentence in understated deadpan dry en_UK to get an appropriate read on just how impressed I'm not by the communications cockup)

[pas]

Compliance people are product people too (even if in disguise), and obviously (?) vice versa.

Silos lead to issues like this. Cross-functional teams cost more, etc.

[tptacek]

Not so much, no.

[Aeolun]

Of course it’s plausible. Literally anything to do with contracts or legal in a corp like Salesforce is plausible.

[arcticfox]

I don't think there's anything in SOC2 that says you can't have multiple tiers of deactivating an account. I think the crucial point here is that Salesforce is requesting the termination, not the customer, so any of their obligations to be responsive to customer data deletion requests are moot (unless the customer comes back and actually requests termination).

[smsm42]

Create a passphrase, derive the key, encrypt the data dump with the key, send the passphrase to the customer, delete the key. Presto, you can keep the data as long as you want without any privacy implications, since only the customer could decrypt it. Of course, this assumes working communication channel between the provider and the customer.

[CoastalCoder]

> Even taking a dump and emailing it to me feels like a safer option here.

I genuinely had to read this twice to get the intended meaning.

[yuubi]

as someone who doesn't use heroku, so disregard my opinion:

i'd probably prefer feces-by-email to surprise database deletion

[FPGAhacker]

There is a legal difference between a company policy and a contract with a customer.

[robryan]

Yeah ideally hold onto a backup for say a year, if the owner hasn't come and downloaded it after a year can then assume that they don't want it.

[johannes1234321]

It's not that easy. Those databases might contain personal information which is protected under different privacy laws like GDPR, HIPAA and others and Heroku/Salesforce can not simply store that for longer than agreed upon and Heroku cancelling the account enables the retention period as the customer agreed upon as part of the T&C.

[tuukkah]

The account was not cancelled.

[jbverschoor]

I wonder if you guys delete email addresses from people who ask to unsubscribe , or when I tell t you to delete my information, according to gdpr

Probably not, because it’s ” difficult “

[johannes1234321]

Many avoid it, but once they have to deal with a (ex-)customer's lawyer they learn what is even more difficult.

[inopinatus]

This sounds like the legal equivalent of looking the wrong way through a telescope.

Whoever fostered that naive interpretation was a nitwit. If they’re an actual lawyer, they promoted an intentional, mutually harmful unilateral reinterpretation of an agreement and should be sacked.

Cowering behind T&Cs like this is intellectual bankruptcy. There’s always another solution. The law is not a programming language.

[rurp]

If I'm understanding you correctly, the 30 day policy is one that Heroku chose to put in the contract. Engineering might have fought the terms, and yes they need to be followed once set, but it seems totally fair to blame Heroku for creating the limitation in the first place.

[mst]

When they were written, short sighted acquirers yeeting the free tier was likely not something the people writing the relevant clauses were even considering as a possibility, and honestly it's such a ridiculous decision from a commercial perspective that I find it hard to assign blame for not foreseeing it.

Plus, it would all likely have worked out fine if they'd emailed the customer a warning or three like they intended to do - it was the failure to do so combined with the failure to detect and remediate the initial failure that sent things down such a dark path here.

[fireworks]

Are you allowed to inform paying customers that you are going to do this? This is my primary complaint here. I don't understand how this oversight happened. This is going to cause an enormous amount of time and energy to recover from this.

[yamtaddle]

> Are you allowed to inform paying customers that you are going to do this?

I can't be the only one who's basically completely blind to emails from major companies, including SaaS providers, because they're so fucking spammy that the SNR is like 1:99. Notifying me by email, for one of these places, is functionally the same as not notifying me at all.

[EDIT] Sorry, didn't mean to imply the parent wasn't paying attention, just that I'd fully expect a very high percentage of their users to miss the warning in all the noise even if they emailed everyone—even if they emailed them a couple times, actually. That's the cost of every company sending out tons of "join our online seminar on [product]!" and "hey, look, it's our newsletter you never read!" and "it's time for our weekly TOS modification!" emails.

[function_seven]

> ...because they're so fucking spammy that the SNR is like 1:99.

This 1000x. I signed up for an SMS gateway service last year. Just for my own hobby use, nothing major. I gave them $10 to start service, and they charge like 2¢ or something per outgoing message.

They have like 180 different prices for 180 countries, territories, provinces, parishes, cantons, prefectures, etc. Every week one of those prices changes, and I get an email notifying me of that. I tried to turn those off in my preferences, but they refused. I can opt out of marketing, weekly digests, and "tips and tricks"; but I can't opt out of pricing notices.

So I added a rule on my end to hide those. I totally understand where they're coming from. They can't NOT give pricing change warnings. But at the same time, in the flood of constant notices, there may be something major I will miss.

It would be nice if they instead gave me the option to never spend more than $0.XX per message, and return an API error if an attempted send fails for price threshold violation. Then the spam wouldn't be needed.

[yamtaddle]

Shit, that'd even let them optimize their pricing. "If we double this rate, 25% of our customers will start erroring, but factoring in message volume of those customers and assuming they all leave us, it'll still be a 60% increase in revenue from this product."

[fireworks]

I'm not blind, they didn't send one. And they admitted to me that they did not send one.

[yamtaddle]

Well, that's even worse, of course.

[eptcyka]

That's a major failure on their part. I did get several nagging emails from them.

[ehPReth]

Even if they did send it, email isn't guaranteed. What if it went to spam or was otherwise mishandled or missed?

[edgyquant]

I use heroku at work at they definitely sent out a ton of emails. It also said they were going to delete them right above all third party plugins (even if you weren’t using their database service)

[mst]

Right, but in this case - as confirmed by Heroku when contacted - something went wrong at their end and the emails weren't sent in the first place.

The fact that the failure to send a single warning email to this particular customer wasn't both detected and considered a five alarm fire level bug under the circumstances is the thing that moved the decision to sunset the free tier from sad to disastrous for the user who posted the Tell HN in the first place.

[dboreham]

That's peak idiocy and the product of lawyers taking over the assylum.

[skissane]

> We fought hard for 90+ days internally, but in the end couldn’t get over the issue that we’d be in violation of our contracts with customers.

Contracts with some customers, surely? You could have the default be 90+ days, then those customers whose contracts specify a shorter timeframe get that shorter timeframe configured on their account instead. You could give the customer the choice at signup, and let them change it later using the settings console. If their contract doesn't specify a period, send them a notification that you will be changing it to 90+ days, but telling them they have the right to object if they disagree with that.

[dotancohen]

The phrase "aren't allowed" supposes some regulatory agency forbidding an action. When it's your own internal policy that contradicts the action, the proper term is "won't".

[ehPReth]

Every single executive in charge of this decision of how to handle precious customer data at Heroku feel be completely ashamed and take a long, hard look in the mirror.

[Cheezewheel]

No choice? That's just the way it is, it can't be helped? Did God himself come down and decree that Herokai *MUST* only hold data for 30 days? Did the FBI come in an threadten to charge your executives with sedition?

Yea, no. You decided to make the decision for contracts to be that way. The fact that you "fought hard" but that decided on the 30 day retention anyways means that clearly the opinions of engineers don't matter and that the company is completely captured by the lawyers and out of touch executives. It hardly inspires confidence.

It also doesn't at all address the fact that you failed to contact an apparently paying customer that their data was about to be nuked, contract or no.

[numpad0]

Using the fact that a customer was shown exit as the basis for destroying their assets don’t look great to me, at least on surface…

[mytailorisrich]

Please. You'd just need to ask if the customer is OK with 90 days instead of 30. Done.

The company has no commercial interest in doing that, though.

[porpoisemonkey]

It doesn't sound like this would have helped in this particular case since they were unable to contact the customer.

[mytailorisrich]

I was replying to a bullshit claim that they cannot retain for more than 30 days no matter what.

That's hiding behind the T&Cs instead of owning their decision not to even try because there is nothing in it for them.

[joemi]

So you're in favor of companies breaking their terms and conditions at will? I think that would cause quite a lot more outrage and problems.

[reaperducer]

So you're in favor of companies breaking their terms and conditions at will? I think that would cause quite a lot more outrage and problems.

Do you really never get e-mails from various companies every few weeks telling you that the terms of service have been updated?

I think I get one from eBay alone every other day.

[johannes1234321]

Those can not be compared that easily. There are many changes you can do easily. Changing data retention periods impacts guarantees customers may have given in compliance to privacy regulation like GDPR, HIPAA etc. and thus is a substantial change to the customers in areas with such regulation.

[mytailorisrich]

You did not read my comments, did you?

The T&Cs are an agreement between the parties. That agreement can be changed at any time if both parties agree. So they just need to ask.

[joemi]

But if they make an exception for one person, they're opening the doors to complaints and possibly even legal action from others who want the same change. So making an exception for one person isn't really making an exception for just one person. Instead, it's a large process that needs careful legal consideration.

[rurp]

Contracts can be amended when all parties agree on a change.

[joemi]

An exception for a single client might fly for a small company, but it's not really a _simple_ exception when you're a large company (like Saleforce). It needs careful legal consideration and possibly means changing the general T&C for everyone.

[jacobsenscott]

If you enable daily backup those are nuked too?

[csomar]

That would be interesting to learn. Backups will be just an additional surcharge rather than a "real backup strategy".