Hacker News new | past | comments | ask | show | jobs | submit login

But he didn't buy anything. We can't extrapolate what happens to paying customers from the experience of a non-paying customers.

That being said, I definitely agree with your thoughts on insurance.




> But he didn't buy anything. We can't extrapolate what happens to paying customers from the experience of a non-paying customers.

So, if he had paid one cent (thus being a paying customer), you could extrapolate?

I don't see how the price is in any way relevant here. They promised to protect him, and they failed to do so. Claiming afterwards that the premium was too low isn't the way this works.

Also, I doubt that it actually was "for free". He may not have paid in money, but likely in the form of (at the time positive) PR, for example.


You're right the actual amount of money is not relevant. What is relevant is that the contract he signed with them is not the contract paying customers sign when they do business with Akamai.

Since we have no idea what was in the contract this guy signed and it's all speculation, this discussion is totally vacuous and pointless.

> They promised to protect him, and they failed to do so.

How do you know what they promised? They could have promised protection, or they could just as well told the guy "hey, here is some free caching for you, m'kay? No strings attached". Hell, it's possible he didn't even sign anything, and there wasn't a contract at all!

If he were a regular paying customer, I would make the assumption that the contract he signed is likely the same, or similar to the contract I would potentially sign, and this would put Akamai in a very bad light to me.

Since the contract this guy signed is not the contract I would sign, I cannot rationally infer any information from this incident, good or bad.

If Akamai emails me and offers me some free service, then yes, this information would be valuable and relevant. Until that day, I can't make any use of this information.


You are missing the point which is that Akamai can't handle this DDoS.

Do potential customers care if Krebs is a paying customer or not? He went with them as they offer this service which apparently doesn't work as well as advertised.


There is no indication that Akamai can, or can't handle the DDoS. The only information we have is that they are only not willing to do it anymore for this particular customer. There is no indication that they won't do it because they lack the technical capacity to do it. Just as well they might not do it because this thing is financially disadvantageous to them.

As a potential paying customer, what they can and can't do is covered by their SLA, and that's all that matters. If they break their SLA they own the customer compensation. This incident is irrelevant.

Of course I don't actually know what kind of SLA and indemnification Akamai provides. Maybe it's bad. Then after analysing the contracts I would make an informed decision. These things are what I use to make decision, not random stories with no technical or business details on random blogs.


From what I've seen (quoted elsewhere in this thread) there isn't any significant penalty for Akamai if they are unable to mitigate, or choose to not mitigate, a DDoS attack. They might negotiate other terms, but I doubt it. DDoS mitigation is, by its very nature, a best-effort service, and reputation for not giving in to attackers is more important than any contract terms you're reasonably going to be able to get.


I haven't read anywhere that they failed. Isn't the timeline:

- Akamai mitigates attack just fine

- After the attack is over, Akamai does the cost/benefit analysis and decides to stop providing the free service.


The attack was ongoing when Akami gave Brian Krebs 2 hours to find alternate hosting.

The attack showed no signs of waning as the day wore on. Some indications suggest it may have grown stronger. At 4 pm, Akamai gave Krebs two hours' notice that it would no longer assume the considerable cost of defending KrebsOnSecurity.

http://arstechnica.com/security/2016/09/why-the-silencing-of...




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

Search: