Live data from Hacker News

What the Fastly outage can teach us about writing error messages

onlineornot.com

91–100 of 137 posts

Re: What the Fastly outage can teach us about writing error messages

#91
post #86

Earlier quoted context omitted.

This is considered a critical security vulnerability. [0] [0] https://owasp.org/www-project-top-ten/2017/A6_2017-Security_...

Not if it's open-source. Security by obfuscation is generally not a good option if you can avoid it.

If there are other vulnerabilities present, stack traces can be forced to dump all sorts of data like env variables and network information and maybe someone else's personal information.

I strongly urge everyone to hide their stack traces in production. This will reduce your application's attack surface.

Re: What the Fastly outage can teach us about writing error messages

#93

Unfortunately the majority of internet users aren't trained in the art of reading HTTP status codes I think the majority know what 404 is, and possibly 403, but I agree about the more obscure ones. That said, I don't think it's a bad idea to rely on the "default exception handling behaviour" that the majority of users, even non-computer-literate ones, will have: they'll retry a few times, see that it doesn't work, an…

I don’t off the top of my head remember that 506 is, that’s what ddg is for.

When fastly was broken and telling me that london was broken (lon3356 or something), that told me I could Reroute via Cleveland and have a chance of it working. It also made me comfortable it was a CDN error rather than a site error.

That’s far better than “oops something went wrong, we’re trying to fix it”

Re: What the Fastly outage can teach us about writing error messages

#94
post #92

Wow, the internet. It’s like my meetings where everyone feels entitled to expressing their opinion, splitting hairs on the most tangential aspects of the issue. Thanks god for coffee, and nice views out of the window

10 of our clients called and asked why they are paying us if the sites are not working today. I think a proper 503 browser message could help us a little?

Re: What the Fastly outage can teach us about writing error messages

#95
post #70

Earlier quoted context omitted.

"Service is experiencing increased error rates" - Error rates increased from 0 to 100%

Or 50% error rates in case one of two nodes is down and you keep calling the faulty node. But the faulty node should not be called in a well designed system.

But then you're serving 100% faulty.

Error rates (as alert thresholds and end user reporting) are a service thing, not a node thing.

Re: What the Fastly outage can teach us about writing error messages

#96

I have a particular dislike for Apple over this - I think they set a trend of unhelpful error messages tied to obscure codes back in the 1990s. Sadly they've been joined by Google. 'Something went wrong' could have come from the Sirius Cybernetics Corporation.

Your plastic pal is busy remembering how to be fun! Come back later, and go stick your head in a pig.

Re: What the Fastly outage can teach us about writing error messages

#98
post #97

Bullsh*t! 99% of users are only interested in accessing the content they requested. It either works, or it doesn't.

I tend to agree. But I also think that bad error messages are what has gotten there in the first place. People just click on OK on error messages without reading them, because they learned that it doesn't really matter if they read them most of the time.

Re: What the Fastly outage can teach us about writing error messages

#99

Ahhhh. I’ve spent countless hours debugging “Guru Meditation” errors from FreeRTOS on my ESP32 dev boards. I always wondered what the heck that meant. Turns out I was just not in on the joke.

> I’ve spent countless hours debugging

You are the guru. And you are meditating on the problem.

Re: What the Fastly outage can teach us about writing error messages

#100

Earlier quoted context omitted.

Showing the error itself only opens the provider to information disclosure - with the various automated infrastructure monitoring systems running on Fastly or CF they know when and where errors are happening with full traces that help them debug. > there's no reason that a good error message AND pertinent support information are mutually exclusive. show them both As the OP stated, there is quite literally nothing sup…

> Showing the error itself only opens the provider to information disclosure No offence but as an end user I really despise this attitude. Sure there might be automatic monitoring at a place like fastly, but even they can use help in tracking down the problem. Also, if the error is distinct people can put it into Google and call on the vast power on the Internet to help figure out how to fix it or work around it, esp…

It's a matter of information security. Error messages potentially disclose sensitive information on the internal workings of the service. Disclosing that information is a potential security vulnerability.

Also note that SE went down yesterday

Post reply on HN