If the customer would authorize this disclosure then we can discuss it publicly.
Otherwise, as much as it pains us to get negative feedback, whether or not it is deserved, it is beyond our control as the privacy of our customers is the most important issue at stake in a public discussion.
Now, can a lawyer come in and discuss whether or not this can serve as authorization such that DO can't be sued?
I've been nothing but impressed with DO, right now there seems to be a misunderstanding and OP is not providing full details nor is he allowing DO to discuss what happened.
If he truly cared about others not using DO he'd allow it to be discussed, but it does seem like OP is hiding some fact...
So now I'm left with great service and product vs 1 guy who seems like he did something shady and got caught. Maybe it was an accident and maybe there is a way forward, but only if he brings to light the details of his actions.
Edit: Plus now you delete your post where you hint at your DDoS (by mistake or not) does not add up to your favor: http://i.imgur.com/1pxIxiN.png
One user sent me a bill for $10,000 after I cut 'em off for running a spam cannon, for lost business. I mean, I'd say 90% chance that they were just incompetent sysadmins trying to run wordpress and they got compromised, but ground truth was that they were sending out rather a lot of spam.
I sent a few notices before and after shutting them down, but their mail was hosted on the down VPS, so they never got it. Man, they were angry.
Dealing with stuff like this is the hardest part, I think, of running a low-cost (and thus low support expectation) VPS service. (one of the advantages, I think, of a high-touch service is that if you are paying me to manage your VPS, well, if it gets compromised, well, first it's my job to see to it that it doesn't get compromised, but if it does, it becomes my job to clean up the mess, bring up a new host, restore from pre-compromise backups, etc... - you get to be the hero rather than the bad guy.)
Key here, I think, is setting expectations; setting expectations is harder than you think, though. I've got a bunch of random copy on my front page... which is probably the wrong way to do it. But the customer needs to know ahead of time what is going to happen if they start spewing spam or participating in a DoS... and the customer needs to understand that they are going to get shut down even if it was an accident.
This problem is made oh so much worse by this massive influx of developers without sysadmin skills who should properly be on a more managed (or PAAS) solution who are moving to VPSs because they are so cheap.
Isn't this why most competent hosts request/require a secondary contact e-mail, not hosted by them?
Enforcing that requirement would be... non-trivial, though. I mean, I could look at the MX records for the domain in question, but those quite often don't point at the final delivery servers.
Still, I should at least make that a rule, even if I don't enforce it.
edit: Also note, even when you contact folks successfully, sometimes they refuse to deal with it, as, well, properly dealing with a compromise involves formatting and re-installing, then restoring from a backup taken before the thing was compromised. Most people at this level are unwilling to go through the effort, meaning that they will remain compromised for as long as you leave them on your system.
Often I'll setup a new domain for them, with the old domain read-only, so they can pick through the data. More than half the time, within 24 hours, they are compromised again.
"You might not get notified when shit hits the fan" seems like some natural enforcement :-P
Is that because they don't upgrade their software in response to being compromised?
Recovering from a competent compromise is... more complex than that. You pretty much have gotta read all the code you move from the old (compromised) system to the new system. As part of that, you want to minimize the code you move from the compromised to the new system; so you should re-install as much as you can from scratch, then move over your custom stuff, one file at a time, after reading it carefully.
If you have a good pre-compromise backup, and you have some idea of where the hole was and that hole was in one of the packages/support libraries, and that hole has been patched, then you can restore and upgrade.
As I'm running a no-support service, I'm not digging in deeply enough to tell you exactly what happened, but I believe that in most cases, users are just copying over their documentroot wholesale, and at best upgrading over the top of the (possibly compromised) copy, which quite often won't help you.
If they don't have a know-good local copy of the code to upgrade the stock components of and redeploy on a fresh VM that just sounds like asking for trouble.
What do you do with such customers? If you "fire" the repeat offenders would you say it's been worth the forum backlash from them (which this story seems like an attempt at so far)?
I also strongly select for customers who have some sysadmin experience (e.g. I turned someone away this morning who wanted a VPS but didn't want to authenticate with an OpenSSH public key) which helps a lot (but also vastly decreases my customer base.)
Worst case is when someone knowledgeable setup someone else on my service, then broke off contact; I'm now expected to step in and essentially be their sysadmin for $12/month. - That's the problem with unsophisticated users in a unsupported environment; they don't know enough to know if the problem is a hardware problem (which really is my responsibility) or a configuration on their own VPS.
but yeah, occasionally I get someone really, really angry. It's no fun.
My least favorite part of the job is firing customers who are the /target/ of DDoS attacks. I mean, if the attack is smaller than my pipe, I can tolerate it, but I've had customers hit with 10 gigabit+ attacks. Few providers can deal with that, so you are forced to get rid of the customer; It's really sad and messed up, because sometimes it's not even the customer's fault. Someone on the internet who controls a botnet doesn't like them. It's not fair that you finish the job, but there often isn't a whole lot of choice in the matter.
I have a whole lot less sympathy for people who allow their domains to be compromised and used in those attacks against other people.
My question is what do the apps do? That could easily be where the violation of the TOS is happening. Child porn? Fraud?
The lack of clarification is making the OP seem shady. Whats to hide?
As we (Blekko) get better at identifying and shutting down click fraud and other schemes to defraud advertisers a lot them end up being traced back to hosts in inexpensive hosting services. That is but one of many ways of having a machine on the Internet that generates cash for you. We ended up basically shutting out a couple of class Bs from an hosting service in the Ukraine for that reason, people can write us and get white-listed but in over 27,000 IP's not a single one was a legitimate user. Way too many people coming up with schemes to get some "free" extra cash.
Deleted comment
DigitalOcean is asking you for permission to discuss your case further publicly. Will you allow it or not?
edit: stop deleting your posts, you douche.