Disappearing messages people!

Security is much more effective and adopted when it is simple. My understanding is that SELinux is not.

This means not only will fewer people use it and more people turn it off if something doesn’t work, it means more people are at risk of misconfiguring their system to allow something they didn’t intend to.

This is somewhat mitigated from the fact that, from my experience, Linux Security Modules cant ever make you less secure than without it. But it still can provide a false sense of security if you misconfigure it.

Here is a good article showing what I am referring to, and providing a solid security tool: BSD pledge/unveil on Linux.

Depends on the environment surrounding the door, as well as the environment surrounding the computer.

Some people simply care less about their computer security. The debate stops there. Security operates on a foundation of what you want to secure.

By comparing two environments of someone’s life you know little about, you are commenting from ignorance.

True.

Though, you are probably going to have a much easier time implementing a change to your code that is present in a company’s published code, than you would trying to reverse-engineer a binary.

Sharing of the code I would consider “giving back” in it of itself.

It can be done if you mess with the initramfs.

The kernel starts everything else by unpacking an archive containing a minimal environment to set stuff up for later. Such as loading needed kernel modules, decrypting your drive, etc. It then launches, by default, the /init program (mines a shell script).

That program is PID 1. If it dies, your kernel will panic.

After it finishes setup, it execs your actual /sbin/init. These means it dies, and that program (systemd, openrc, dinit, runit, etc) becomes PID 1. If an issue happens, both could fail to execute and the kernel will loop forever.

These applications likely know they can get away with it, as people classify them as “too important” to uninstall.

The solution is to make them wrong: To uninstall. Who woulda thunk.

expired cert…

Yes. Bad example. Pick any other number of examples. You can probably put a useful time range.

Best option for the business

Already commented on that. They believe it to be so, I don’t agree with that choice.

You can design your software for tech gurus…

It doesn’t have to be either or. Error messages can have a baseline of mild computer knowledge, and stretch up to people who know what they are doing. You can cater to both.

Useless boiler plate error message

It doesn’t have to be utterly useless. Just because you can’t fix anything from where you are doesn’t mean you can’t benefit. If the error is deemed unfixable for customers, give a timeframe of when it should be fixed and the intended course of action (what should they do if its not back up soon and they need it to be up). Useless is a choice, but its also subjective. You may find “Something went wrong. Try again later” as not useless. I deem it so.

you are not going to fix the issue

Unfounded assertion. I have fixed server-client issues before as the client. Let me repeat it: I have fixed server-client issues as the client. There are of course issues I can’t fix

I think our disconnect partly comes from the fact that I am discussing this from a point of view of server operators being fallible. If in theory they always know what is fixable only on the server and never make a mistake in that regard, then we fall back to make a useless error message more useful. But they do make mistakes (or are purposefully hiding information so you don’t know how to get around the error). The Linux example. It would be very easy to justify that in the same way that companies could justify a useless error message for something which could actually be fixed. How many people are going to look at the initframfs logs and know how to chroot in, edit the initramfs init script, and then rebuild the cpio and shove it in boot? Probably less than those that don’t.

You could use this as a justification to hide it completely, but also harm those that could fix it, and also harm error reporting as the users machines just don’t boot the distro. I disagree with this decision.

PS

if that affected ChatGPTs popularity, I couldn’t tell.

So I’ll round it all off with this: improve the error messages as a whole. Add contact information, time till likely fix, course of action (try again later is vague crap). The messages feel like an unhelpful wall, the error equivalent of a chatbot responding to your pleads for support. Also, you might not always be correct in whether something is fixable or not. You could add the detailed error information near the bottom, if people don’t need it then no harm. If people do then its useful. Not adding it and then it being of use could be worse than adding it and it just never being necessary.

I think this topic is wrung out dry.

There is no time frame for these kinds of errors

If I was are able to isolate the issue to, for example, expired certs, I could absolutely give you a ballpark answer on how long it should take/when it might be back up. It doesn’t need to be very precise, but I have accessed websites only to be shown an error with zero idea whether this is a multi-day event or something I can wait five minutes and it be fixed.

…they are written by designers…

Cooperation with a developer would help here.

They are written for the broadest audience

If you write only for a child, your usefulness ceiling is that of what a child could understand. You could have your obvious boilerplate message, and then under that provide more information.

…not easily construed as derogatory or malicious in any language.

I feel as if this is a simple problem to avoid.

We have to design systems as if every user is incompetent…

See the bottom of this post

there is almost nothing you can do when you hit an error like this.

If the company believes so, then write that part in. Otherwise, it isn’t stated that such is the case. It would be one more sentence on the boilerplate section.

Overall this has to do with what you are optimizing for. Its clear to me that many businesses believe useless boilerplate error messages are most cost effective. If you want to be most cost-effective, then cutting corners on the error messages likely saves time with few financial downsides. But It doesn’t have to be this way.

Designing systems for the lowest person on the totem poll isn’t without downsides. I have used Linux systems that made the bootup hide all log messages. This means that people that can actually fix a broken system using the logs, are going to have a harder time, as you just hid away all the moving parts and complexity from the end user. Some machines I wouldn’t have been able to fix were it not for the detailed logs.

Or we could talk about privacy. Nearly everyone can use a computer. Great right!? But how many people actually understand the privacy implications of using a machine that is controlled by a closed source corporation. Of entering load of data into that machine? Very few.

You can design a system for idiots. But you don’t have to. There are things in life that have prerequisites. If someone comes over to my computer and asks “What’s that” on a kernel log output, I’ll ask them, “Do you know what a kernel is”. If they don’t, then I will tell them not to worry about it. My explanations are not for everyone. Neither are my software.

How is a user sending a support request containing the information: “Site not working. Error message: A surge in requests is overloading the server. Everyone is being ratelimited.” Any different from them just saying “Site not working.”?

If they were going to submit an issue for a problem that is already known, why would the error message significantly change the difficulty of dealing them?

The error is unnecessarily vague.

If the message is supposed to mean “There is an internal error that is of little use to you, so you can only wait while we fix it. Try again in 10 minutes.” Then say that. That tells me a developer made a conscious decision to classify the failure mode as one which I cannot fix. They are explaining to you what type of error they perceive it to be.

Instead we have “Something went wrong. Try again later.” which doesn’t say that directly. This could just be them designing their systems as though every user is incompetent, and denying you the information to fix the issue yourself.

You wouldn’t know, because it doesn’t just tell you directly.

I would appreciate the detailed error responses even if the developers don’t think it would be of use to them.

When a project has unexpected downtime, and they do a postmortem explaining exactly what part of their infrastructure failed, what steps they took to resolve it, and how they will prevent it in the future, that is great.

I appreciate transparency. Of course, to expect this from a large corporations is expecting a pig to fly, but detailed error messages are one more step away from “We are the cloud” and one step towards “We are real people providing a service which operates on server infrastructure consisting of…” Its transparent, down-to-earth, and respects people who do want to see behind the scenes.

One company I used even had a white paper explaining their infrastructure as a whole.

This all may not make you more money, but I prefer this to instead treating me with the bare minimum insight into the inner-workings.

These error messages are never (sic) used on data validation issues.

You are incorrect. I have had issues that were exactly that. Such as a password that was failing to be accepted and then giving generic error responses, which I then had to trial-and-error brute force to find which part of my password they weren’t allowing on the backend.

You stance might become easier to defend if you avoid absolutes.

By nature of software consisting of a client and a server, there are certainly errors that can be bypassed on the client side.

Server side software does not mean “there is literally no errors that are dependent on client input.” That’s ridiculous to think, but pervasive in this comment section it seems.

Do show a big scary error message. I would like to understand what is going on.

“Majority of software” source your claim.

If you use your computer as a bootloader for Google chrome, maybe. Local software and SASS both benefit from error messages because you cannot assume every error you can do nothing about.

An error about parsing my password and a stack trace? I can possibly deduce to limit the length, remove special characters, or add special characters and try again.

“Something went wrong.” is lazy and nontransparent.

Blanket “99%” statements are unfounded. I have had countless issues I was able to fix through error messages and some without.

Source your claim.

Same logic as “keep it closed source for security”.

Ridiculous take. I have debugged countless issues. Those that spit detailed error messages are typically far easier to debug than those that don’t.

For example, returning nothing but exit code 1 to indicate failure. This gives zero information about the reason behind the failure, and only could be acceptable if your program is so simple as to only have very few failure modes.

I have solved issues by cloning the source code and reading it to understand the issue.

Don’t relegate everyone to the same fate as those so utterly ignorant they can’t look up an error code.

As for the bugs you can’t fix? Why do you think Cloudflare tells you when its the website having an issue, and not your browser or them? Knowing the issue isn’t something you can change, avoids spending time trying to fix an issue that you have no control over.

People who can will write up a bug report anyway

And report what exactly? Your program gives zero information has to why it failed? Now you have dropped the responsibility of figuring that out from the code, which tends to know far more about its failure state, to someone observing from afar. Its inefficient and ridiculous.

I disagree with you across the board.

Its possible: Link

Or communicate that you aren’t listening. I would want to know, as the speaker, that my words are going in one ear and out the other.