Coding tip: Learn to read stuff
-
@DogsB Depends.
Perhaps @dkf couldn't an exception because it was required for the system to at all times.
-
@Kamil-Podlesak VAX VMS already had a logging system that had all of it: underlying error codes, engineer-friendly error identifiers (identical in logging and program source code), and human-readable logging including placeholders/parametrization.
-
@DogsB said in Coding tip: Learn to read stuff:
an exception
We've got something like them (this is C so no actual exceptions, and this is embedded so not much code space for exception handling either; we can do C++ only if we turn a lot of language features off) but they're saved for “this program actually cannot possibly make progress at this point” (e.g., a malloc failure during program startup). When you're instead interested in “we got this weird message off the network that we're going to throw away”, an exception is not really the best approach.
-
@Kamil-Podlesak said in Coding tip: Learn to read stuff:
error codes with parametrization
We do that, but by preprocessing our source code and postprocessing our logs. It's good; it lets us squeeze a lot more logging messages in without running out of either code space or log space.
-
@dkf said in Coding tip: Learn to read stuff:
@DogsB said in Coding tip: Learn to read stuff:
an exception
We've got something like them (this is C so no actual exceptions, and this is embedded so not much code space for exception handling either; we can do C++ only if we turn a lot of language features off) but they're saved for “this program actually cannot possibly make progress at this point” (e.g., a malloc failure during program startup). When you're instead interested in “we got this weird message off the network that we're going to throw away”, an exception is not really the best approach.
I knew a system.exit and a trolley face was needed for that post. My bad.
-
@DogsB said in Coding tip: Learn to read stuff:
system.exit
We're talking embedded, so the runtime is entirely custom.
-
@Zenith said in Coding tip: Learn to read stuff:
@Jaloopa The problem is that phony "security" training assumes that the only two options are "oops something happened" and a wide open system where knowing today's date is an all-access pass. If you design the system properly, you don't have to worry about providing a few parameters because they're not a vector for attack. If you don't, well, that's on you, not a "dangerous" error message.
@dangeRuss said in Coding tip: Learn to read stuff:
@Zenith said in Coding tip: Learn to read stuff:
drug out
Shirley you mean dragged out?
Ah yes, but providing less details is the difference between "oh yikes that bug could be bad" and "oh yikes someone just owned production".
In theory, yes, you should be able to provide as much information as you want to the end user. In actual practice, that information can give attackers just a little more info, maybe enough that they can find a way in. That's why the safe default is "oops something happened!" with plenty of logging in the back.
-
@sloosecannon Alas, I work with managers that think saying "risk" every other sentence makes them sound smart, even though they are able to neither understand nor quantify risk, so what I heard was "I don't understand what's happening so I'll just pretend that ignoring it is the only option because it's easy." If you know what you're doing, right now in handling the exception and otherwise designing the system at large, there's no danger in providing an appropriate level of information beyond "hur dur something teh happnd kthxbye."
Edit: Here's a concrete example. A few years back, my PayPal account "somehow" became unlinked from my bank. You know, the typical Indian "your settings are right where you left them" update. When I went to the site to link them back up, the error message I got back was literally "oops, something happened, try again later."
Naturally, I called PayPal. They sent me to the bank. Told me some lie about the bank rejecting connection attempts. The bank said no attempts had been made and sent me back to PayPal. You know what the problem was? PayPal had set a flag blocking my account from being connected to any bank. Completely silently and out of the blue of course. The problem would've never been solved no matter how many times I tried again later. That's not security; it's fucking retarded.
-
@Zenith said in Coding tip: Learn to read stuff:
@sloosecannon Alas, I work with managers that think saying "risk" every other sentence makes them sound smart, even though they are able to neither understand nor quantify risk, so what I heard was "I don't understand what's happening so I'll just pretend that ignoring it is the only option because it's easy." If you know what you're doing, right now in handling the exception and otherwise designing the system at large, there's no danger in providing an appropriate level of information beyond "hur dur something teh happnd kthxbye."
Edit: Here's a concrete example. A few years back, my PayPal account "somehow" became unlinked from my bank. You know, the typical Indian "your settings are right where you left them" update. When I went to the site to link them back up, the error message I got back was literally "oops, something happened, try again later."
Naturally, I called PayPal. They sent me to the bank. Told me some lie about the bank rejecting connection attempts. The bank said no attempts had been made and sent me back to PayPal. You know what the problem was? PayPal had set a flag blocking my account from being connected to any bank. Completely silently and out of the blue of course. The problem would've never been solved no matter how many times I tried again later. That's not security; it's fucking retarded.
And that is exactly the kind of situation where you should not provide any more information than "something weird happened".
Even saying "your account has been blocked" may not be a great idea.
You definitely shouldn't get a stack trace telling you where, deep in the system, your request failed...
-
@sloosecannon said in Coding tip: Learn to read stuff:
You definitely shouldn't get a stack trace telling you where, deep in the system, your request failed...
In most software, especially anything consumer facing, delivering a stack trace to the user is the wrong thing anyway. They won't be able to do anything with it (and won't report it).
-
@sloosecannon said in Coding tip: Learn to read stuff:
@Zenith said in Coding tip: Learn to read stuff:
@sloosecannon Alas, I work with managers that think saying "risk" every other sentence makes them sound smart, even though they are able to neither understand nor quantify risk, so what I heard was "I don't understand what's happening so I'll just pretend that ignoring it is the only option because it's easy." If you know what you're doing, right now in handling the exception and otherwise designing the system at large, there's no danger in providing an appropriate level of information beyond "hur dur something teh happnd kthxbye."
Edit: Here's a concrete example. A few years back, my PayPal account "somehow" became unlinked from my bank. You know, the typical Indian "your settings are right where you left them" update. When I went to the site to link them back up, the error message I got back was literally "oops, something happened, try again later."
Naturally, I called PayPal. They sent me to the bank. Told me some lie about the bank rejecting connection attempts. The bank said no attempts had been made and sent me back to PayPal. You know what the problem was? PayPal had set a flag blocking my account from being connected to any bank. Completely silently and out of the blue of course. The problem would've never been solved no matter how many times I tried again later. That's not security; it's fucking retarded.
And that is exactly the kind of situation where you should not provide any more information than "something weird happened".
Even saying "your account has been blocked" may not be a great idea.
Why not? Seems to me that's exactly the kind of information that should be provided to the user, as it gives them useful information to complain to Customer Service about. If @Zenith had known that from the beginning, the whole "it's the bank" / "it's not us so it must be PayPal" runaround could have been avoided.
-
@dkf said in Coding tip: Learn to read stuff:
@sloosecannon said in Coding tip: Learn to read stuff:
You definitely shouldn't get a stack trace telling you where, deep in the system, your request failed...
In most software, especially anything consumer facing, delivering a stack trace to the user is the wrong thing anyway. They won't be able to do anything with it (and won't report it).
That depends on the stack trace, system architecture, and message layout. A big red ASP.NET word salad stack trace with no UI hints/controls? Sure, that's less than useless. A stack trace that puts a human readable root cause out front with contact information or a help button? That's perfectly fine.
Edit: I used to have a system that showed roughly this to users:
Processing Error! [user name][datetime][some top level reference ID] Failed to delete file[8675309] because it was locked. Stack: Call to TopLevelFunction() failed. Call to MiddleLevelFunction() failed. Call to LastInHouseFunctionBeforeDependency() failed. Failed to delete file[8675309] because it was locked. [Print Out] [E-Mail Developers]Let's look at the components. First of all, there's the root cause, right up top. It was in a larger font, so the user could quickly focus on it. This is very useful because it tells the user what happened. They know they clicked "Delete All Files" and this told them one of the files had a problem. It's probably not a transient problem that will go away without intervention like a connectivity hiccup. Then there were buttons to contact the developers! You know, instead of "contact the mystery administrator" or nothing, both of which force the user to search for information that's usually hidden because nobody that writes buggy shit wants to be contacted for support. Lastly, there's the stack trace itself. Having this presented up front, either on paper or as the body of an e-mail (it was also, piece by piece, written to the log) was a real time saver.
There's no danger in telling the user what happened. Because there was no 17lb JScript file pointing to a JSON microservice endpoint that blindly deleted any document based on a number in some query string. But then maybe it was different because the developers supported this system, instead of dumping that responsibility on a "lower" caste of IT personnel. In my experience, that thoughtlessness is the root of so many problems.
-
@Zenith said in Coding tip: Learn to read stuff:
A stack trace that puts a human readable root cause out front with contact information or a help button? That's fine.
Still no. The core cause? Perhaps. The stack trace? Categorically no. That should be logged, not paraded around like an exotic mascot. Putting up a “report instance ID” so that users can report the specific problem to customer services, and they can find out WTF happened in this case, that's OK.
None of which makes Paypal's service better.
-
@dkf said in Coding tip: Learn to read stuff:
@Zenith said in Coding tip: Learn to read stuff:
A stack trace that puts a human readable root cause out front with contact information or a help button? That's fine.
Still no. The core cause? Perhaps. The stack trace? Categorically no. That should be logged, not paraded around like an exotic mascot. Putting up a “report instance ID” so that users can report the specific problem to customer services, and they can find out WTF happened in this case, that's OK.
None of which makes Paypal's service better.
Well I just don't agree. The systems that print "oops something happened" don't provide that reference ID or any direction towards a resolution. They waste a ton of user and support time by throwing transient errors (network connections), server side errors (we locked your account for some reason), and user errors (you can't link the same bank twice) into the same Sherlock Holmes Mystery of the Hidden Write-Only Log.
-
@Zenith yeah, but "oops, something happened" isn't what's being proposed. That's the other end of the spectrum to a complete stack trace, memory dump and full version of every component installed on the system. Somewhere in the middle, where a user readable cause and what the user can do to fix it (whether that's trying a different bank account, trying again in 30 seconds and hoping connectivity has been restored, or emailing support) is the holy grail
