3 ms·
I disagree. I think users should be aware of any breakage up front, and center. We encourage drivers to recognize warning signs in the operation of their vehicl
by zlg_codes 3y ago
I disagree. I think users should be aware of any breakage up front, and center. We encourage drivers to recognize warning signs in the operation of their vehicles; we should do the same with browsers. Hiding information from the user is not ethical.
Then again, I also think people should be taught better than to hop on the Web without any training or knowledge. Computers and illiteracy go together about as well as books go with illiteracy. It takes effort to be computer literate, and hiding the information will make that journey to literacy more daunting than it needs to be.
- sopooneo 3y agoMy personal inclinations agree with yours, I think. I prefer as much detail as possible up front. Which is why I hate the vagueness of my dashboard's "check engine" light*. However, I bet automakers do that not just so the display is cheaper/simpler, but because most drivers are not interested in anything more detailed (or scary). * Which for me has almost always just meant some oil change "timer" was up, not even that any meter detected my oil was wearing out.
- rurcliped 3y agoYears ago, many decisions to hide error details were a cargo cult reaction to CVE-2012-4929. To review, CVE-2012-4929 works like this: 1. the attacker can see (but not decrypt) the victim's TLS traffic to example.com 2. an attacker-controlled website makes the victim send many different invalid requests to example.com, each of which gets an error message 3. some data in each request is attacker-controlled, but authentication data in headers is filled in by the victim's browser 4. example.com compresses response data before encrypting it 5. because repetitions affect compression, the response size is smallest when the authentication data matches part of the attacker-controlled data 6. after enough requests, the attacker knows the authentication data to login to example.com as the victim One workaround for CVE-2012-4929 was to set up the server so that an error message never depended on the request data. Before CVE-2012-4929 was announced, people thought it was sufficient to sanitize the error message (i.e., avoid XSS) but CVE-2012-4929 prompted a shift toward producing exactly the same error message for all invalid requests. (Not sure, but I think this was the original motivation for Google's famous "That's an error. That's all we know." messages.) There were better CVE-2012-4929 defenses later, but the cargo cult had already formed. (Some subset of) a generation of developers believed that customized error messages were Very Bad because they enabled account takeover.
- zlg_codes 3y agoI've thought about alternative dashboards as an option, that show rpm, piston firing stats, or other small details that, when looked at in aggregate, can diagnose a lot of consumer-serviceable issues.