If my website is targeted for a DDoS attack after I have been paid for completing the website, and I get an angry phone call from the client regarding outage of service, what do I do?
It hasn't actually happened yet, but the idea haunts me.
If my website is targeted for a DDoS attack after I have been paid for completing the website, and I get an angry phone call from the client regarding outage of service, what do I do?
It hasn't actually happened yet, but the idea haunts me.
The following is all hypothetical:
First off you should NEVER sign a SLA in this case, or guarantee any uptime whatsoever. (you are delivering a website, not the service to host that)
Secondly, a hosting company should be used who can defend against a DoS attack in some way. (be aware of SLA's and their limitations)
You need to think of yourself in the same way a plumber does. The plumber is not responsible for your water service, just for leaks and work on the pipes. A DDoS would be like an over pressure on the water lines (like a 1000 times more than they are designed for) and the fact that the pipes break then is not the plumber's fault but the water company's. All the plumber can do is fix it after the water has been turned off.
As to liable, you can only be liable for things you know or should have known
I wouldn't try that in my country's court :-) Keep in mind all legal systems differ, so you should always wait till OP gives a precise legal context (and refer to jurisprudence and laws in that country) to answer a legal question.
– Steve Dodier-Lazaro May 20 '15 at 17:17As Lawri points out, for the most part the site being DDoSed is not your problem. It's up to the hosting provider to take the steps necessary to mitigate (not stop; there aren't really any ways to completely stop one) a DDoS attack.
Note the qualifier: "for the most part".
There is one responsibility you do have, at last as a professional designer, and that is to make as certain as possible that, should your site fail under a DDoS attack, it fails safe -- IE, suffers no data loss or corruption because of the flood of connections.
This is mostly an informal checklist to confirm your code is clean -- IE, database writes use transactions and are atomic, all input is properly validated before any of it is stored, database connections are properly closed on script termination, and so on; basically, once the flood waters recede the site should be back up and running without requiring any manual intervention.