bathos
commented
5 years ago It’s intended for specialized use cases. It would impact traces in tools like Bugsnag and Sentry. If used correctly, it could improve them; it would reduce noise from internals. The tricky thing of course is that this is only true if the library code in question really doesn’t have bugs!
Consider for example a polyfill for a constructable IDL interface Foo. Say this constructor’s signature accepts an arg, one of the IDL integer types. Coercing user input to that type might involve a deep stack of internal frames, and it could result in (deliberately) throwing a TypeError, or it could result in an error being thrown from invocation of arbitrary user code (e.g. obj.valueOf() call when casting to number). The frames concerned with this coercion aren’t where the bug is — the bug is in a line like new Foo(invalidArg). Normally the frame with that line could end up buried in the middle of a stack with library internals piled on top and externals down below. But with stack redaction, the correct line would end up at the top of the stack, just as it would have if Foo had been implemented natively.
(external 1:34 here points at new Event, not an internal arg type casting operation)
So that’s a pretty solid benefit, but it’s true that it could go south pretty badly if people used this in inappropriate situations.
I wonder if stack redaction would be better if it had two parts: one, the implementation hiding directive, but two, a requirement that the error in question gets expressly flagged as having been anticipated. This would reduce the odds of library authors accidentally making their own bugs untraceable, since they will know at what junctures they are invoking potentially untrusted code or code which expressly creates and throws new errors based on input.
try {
invokeUntrustedUserCode();
} catch (err) {
throw Error.wasAnticipated(err);
}(Spitballing ... probably not practical, I dunno, since it would probably need to occur in every single implementation-hidden function in the stack — ‘yes, I should be redacted’ — to work.)
misterdjules
BridgeAR
mmarchini
Hi!
I'm trying to understand the impact of this proposal on the use cases of operators of applications that rely on accurate stack traces to observe the behavior of their applications.
Since this proposal would allow developers to opt into a mode where stack traces would have some stack frames removed, I'm wondering whether the proposal is intended to provide an opt-in behavior in rare specific cases (e.g. a few functions out of all the dependencies of an application whose implementation details would reveal sensitive information) or in the common case (most if not all library code).
The following excerpt from the proposal text:
seems to indicate the latter, since "lik[ing] to refactor without fear of breaking consumers relying on their implementation details" seems like a common goal for developers.
If this proposal indeed intends to provide an opt-in behavior in the common case, what are your thoughts on its impact on tools like Sentry or any other stack trace collection tool? Would that potentially make them a lot less usable once this feature ships, or are there other mechanisms through which those tools would be able to collect complete stack traces even when developers opt into this behavior?
/cc @domenic @michaelficarra