Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is a ridiculous response, and one which seems very ungrounded in the law. Dropbox made a mistake—a big one. They pushed bad code to production that allowed for unauthenticated account access.

But, they're still a startup. There's no SLA. They responded quickly, fixed the bug as soon as they caught it, and have been thorough in investigating any unauthorized access of accounts.

Why sue them? It's just going to disrupt a very good service. It's not going to help them recover (I'm sure they've already learned heavily from the mistake.)



> This is a ridiculous response, and one which seems very ungrounded in the law.

What is the basis of such assertion? Let the courts decide that if the basis is unfounded or not.

> But, they're still a startup.

This is no excuse, if you charge money for your services AND claim to be military grade secure with respect to data. https://www.dropbox.com/security

> There's no SLA. They responded quickly, fixed the bug as soon as they caught it, and have been thorough in investigating any unauthorized access of accounts.

They took 4 hours to know entire dropbox was accessible to everyone, and tried to sweep the incident under the rug by not emailing the issue to users.

> Why sue them? It's just going to disrupt a very good service. It's not going to help them recover (I'm sure they've already learned heavily from the mistake.)

Because they are not entitled to be on the goodside of the user, which unacceptably bad handling of the situation. They, like everyone else, are not entitled to anything, other than what is contracted. You screw users, you get screwed. It is as simple as that.


Idd, being a startup is no excuse, how hard can it be to make a test case which tests if their authentication works?


>>they're still a startup

That sounds very troubling to me. When it comes to user data/privacy, how does being a startup vs a huge corporation make any difference?

Besides, a company with tens of millions of users and billion dollar valuation is not really a startup anyway, if at all that matters.

I love dropbox and use it every single day on so many devices, but I did feel violated by this fiasco.


If you see the OP, the woman behind the lawsuit seems angry that she had to find out about it in the news rather than with Dropbox informing her. That is a serious mistake and one that Dropbox should take heat for. Bugs happen but not communicating to users was a deliberate move.


She was not mailed because there was no access to her account or did I read it wrong that everyone whose account was accessed was mailed?

What should they have told her? "Someone could have accessed your account in the last few hours due to a bug, but that didn't happen. Nothing to worry about!"


They are not shy to advertise the security and privacy of the service, it would be an honest move to communicate the risks, too.


Yes.


I completely agree. Dropbox made a huge mistake. Dropbox is run by humans, and humans make mistakes, that's life. But when it came to communicate the issue they screwed up IMHO. I shouldn't need to subscribe to their blog RSS to know this kind of stuff.

They should have mailed everyone, encouraging users to change their passwords right away while they investigated the issue.


I see the run by humans argument a lot, but what you need to keep in mind is that a company is NOT a human. No one's suing the individual employees here, but a company. There is a massive difference.

By their nature companies are entirely selfish (especially companies with outside investment) and unless you're going to hold the humans within a company individually responsible for a companies douchebaggery then by the same logic you also shouldn't give the company a break because it's run by humans.


Why change their passwords? Isn't that FUD?


Yes and no :-) What else could a user do once damage is done? (before they started investigating, but after the fix was pushed)


The important thing about this bug is that it allowed log-ins without passwords. No passwords were compromised. Therefor, asking users to change their passwords would have been FUD, as well as making it more difficult to identify which users were affected by the person exploiting the bug (if almost every user logs in during 4 hours, you're going to have a lot of trouble identifying the <100 accounts who were accessed by the attacker).


...they're still a startup...

What? Is this an excuse? They charge money for the service and they will pay for their mistakes.


Yes, they'll pay for this mistake through bad press and lost customers.

A punitive lawsuit isn't going to improve anything in terms of making sure they don't do it again.


>>A punitive lawsuit isn't going to improve anything in terms of making sure they don't do it again.

What's stopping us to say the exact thing in defense of any xyz alleged offender?


How do you know? (Note that the point of a punitive lawsuit is not only to encourage the culprit not to do it again, but also to encourage other potential culprits not to do it again.)

I guess the answer is "because it was just a mistake", but (1) not informing their customers promptly when they found they'd made a disastrous security screwup wasn't just a mistake, and (2) since they themselves say they're improving their procedures in response to the incident, it seems clear that there are things they could have done that would have either avoided the just-a-mistake or mitigated its consequences.


Lawsuit is also a good tool so scare others from just trying to do something useful—just in case someone sues on the first mistake.


They won't lost customers if they don't tell them about the problems. The bad press is this, right here.


Even though I don't like frivolous lawsuits, it's way too early to say there's no legal basis for the claim.


>But, they're still a startup

So what?

Aww... the cute widdle startup gets the bar lowered for them because we love startups here on HN?




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

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

Search: