Hacker News Reader

Comment by kolencherry | Hacker News Reader

Hey folks, we've published a post with more details on the incident here: https://www.twilio.com/blog/incident-report-taskrouter-js-sd...

(I work for Twilio)

View on HN

Thanks for posting this. I'm really impressed with the transparency Twilio showed in actually admitting to having such a silly, silly bucket policy. Not impressed that it was there in the first place; but that should go without saying.

This incident report should really put to bed all of the "It's AWS's fault for making things so complex" complaints. (To be clear, it won't... but it should.)

Even a cursory look at that bucket policy should tell you something named "Allow Public Read" should NOT be associated with anything named 'Put'. This takes 0 AWS knowledge to figure out.

Really not impressed with the obligatory "really impressed with transparency" pat-on-the-back under every incident report for a big corp screw-up that provides any details at all.

And stating to the press the clearly malicious payload is "non-malicious" (assuming TFA didn't lie about Twilio's statement)? That's ridiculous.

Even if the payload was not malicious when they looked, it could change at any time. I don't see how that can be confidently labeled non-malicious.

When talking about screw-ups on AWS, public incident reports try to obfuscate and spin the Hell out of issues that boil down to "really, really stupid configuration issue".

They owned it. That is more than can be said about other large incident reports that I've seen regarding AWS.

Reply on news.ycombinator.com