Allowing unsanitized messages on DOMExceptions

[Richard Stotz]

Hi platform-architecture-dev,

I'm in the team developing NativeIO, a new low-level storage API. As file errors can expose platform-specific information, I would be interested in allowing unsanitized messages (exposed only to the DevTools console) for non-security errors as proposed in this CL. 

Context

• NativeIO Explainer: https://github.com/fivedots/nativeio-explainer
• Design doc for error messages in NativeIO

Early adopters of NativeIO have indicated that detailed error reporting would be very valuable to them. However, some useful errors like TOO_MANY_OPENED and INVALID_OPERATION are thrown in different, OS-specific situations. Using unsanitized messages in DOMExceptions would let me inform a developer of bugs during development, without revealing unnecessary host information to the website. +Mike West and +Victor Costan therefore suggested using unsanitized messages for other DOMExceptions would improve usability of the API without sacrificing privacy. I believe that allowing this change would also benefit other low-level APIs dealing with networking or GPU functionalities.

Please let me know what your thoughts/concerns are, which will help us finalize the design. Thanks!

Richard

--

Richard Stotz | Google Germany GmbH | Erika-Mann-Str. 33 | 80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde. 

     

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

[Yang Guo]

I'm sure I misunderstood something. But wouldn't unsanitized DOMExceptions be catchable from JS and therefore a privacy risk?

Yang

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAHTsK6Ut-N_nsTEjR%3DdZRHO7AHW5fsoAd%2BU7stBu5eE5%3DipLEA%40mail.gmail.com.

[Kentaro Hara]

IIUC the proposal is to expose the unsanitized messages only to the DevTools console, not to JS. Then the messages are exposed only to a local environment.

If my understanding is correct, LGTM.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAFSTc_geBTpJPVPunEmXOu4OrBLsjum6vQXWLJPxdmcz%2BcMZaw%40mail.gmail.com.

--

Kentaro Hara, Tokyo

[Kouhei Ueno]

+core/script OWNERS FYI since we've been touching the error message sanitization code a lot.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jxS-%2B--eVuSY2x_twSq0NWr06do9ax0Cw3dRiXhvW5MMQ%40mail.gmail.com.

--

kouhei

[Mike West]

Yang,

I believe Richard is talking about the `sanitized_message_` and `unsanitized_message_` members of DOMException (https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/dom/dom_exception.h;drc=5dded7a9a36ef8d678424ee17cc07213c50a1dc2;l=49). `sanitized_message_` is exposed to JavaScript via the `message` accessor, while `unsanitized_message_` can be accessed via the (not-web-exposed) `MessageForConsole()` method.

This approach also LGTM, FWIW (though I'm biased since I introduced the mechanism in the first place for some cross-frame errors). It's probably worth our time to document this distinction somewhere, along with some principles about its usage.

-mike

[Yang Guo]

I see. That makes sense to me. And I see the unsanitized message is already exposed to DevTools console here.

Cheers,

Yang

[Hiroshige Hayashizaki]

> +core/script OWNERS FYI since we've been touching the error message sanitization code a lot.

We've been touching code around SanitizeScriptErrors (= #muted-errors) a lot, but DOMException unsanitized messages is a different thing (stemming from SecurityError message sanitization).

Anyway LGTM to the DOMException approach (based on the CL and Mike's description).

[Yuki Shiino]

I'm a bit skeptical about how and how much unsanitized messages will be useful.

If JS applications didn't handle errors, then unsanitized messages are printed on the console, and it should be useful.  However, if JS applications are well-designed and they elegantly handle errors, there will be no chance to see the unsanitized messages.

try {

  NativeIO.ThrowWithUnsanitizedMessage();

} catch (e) {

  // Nicely handle an error, e.g. show an error dialog to users, etc.

  // => |e| won't be printed on the console.

}

Of course, JS applications can print all exceptions to the console, but it's a huge pain isn't it?  Every catch block needs to have "console.error(e);".  JS applications cannot tell whether an exception contains an unsanitized message or not, except that SecurityError is likely to have it.

If the information in your unsanitized messages is so important and useful for debugging, isn't it simpler and better to just print it to the console unconditionally without using unsanitized messages?

IMHO, "Network" tab in DevTools is providing a much better experience.  I think that ideally we'd like to have the info included in "Network" tab or to have a new "Low Level I/O" tab (supposing that the info deserves a new tab).

Before moving on, I'd like to see a concrete use case of how unsanitized messages are useful (not an imaginative story).

Exception is a tool in programming languages, which lets you control something.  In this case, what JS developers would like to control?  If nothing, why do we like to use exceptions (with unsanitized messages)?  If there is something JS developers want to control, what's that?

Cheers,

Yuki Shiino

2020年9月16日(水) 16:55 Hiroshige Hayashizaki <hiro...@chromium.org>:

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAOaYce70YhWDSwMVPowS1c1Qe8oenRTHcBnKiSNpzEarw8%3DsGQ%40mail.gmail.com.

[Yutaka Hirano]

How sensitive are these information?

I'm confused because you say

> I would be interested in allowing unsanitized messages (exposed only to the DevTools console) for non-security errors as proposed in this CL. 

but I found the following sentence in the CL:

> This is useful when precise error messages might have security implications but are useful in local development.

Having a message that has security implications in renderer is already dangerous, no matter whether you reveal the message to scripts directly. We should expect that scripts can read arbitrary memory in the renderer, and I don't think the following statement in the design doc is true.

> Since these are not exposed to the website, they do not increase the attack surface as long as the renderer has not been fully compromised.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAN0uC_RtVa5z6PVYnXEF%2BNWSnJBi_RNy_NS5vWHaKvqheuJ6EQ%40mail.gmail.com.

[Victor Costan]

On Wed, Sep 16, 2020 at 8:51 AM Yutaka Hirano <yhi...@chromium.org> wrote:

How sensitive are these information?

There is a class of information that we expose to the renderer (say, for performance reasons) but don't want to share with JavaScript, to follow the principle of least privilege.

For example, when we pass file descriptors to the renderer, it can distinguish between a bunch of error cases, such as the file being used by another application vs an I/O error. Just because the renderer has access to this information doesn't mean we need to expose it to JS.

For this reason, I would really like to see us use unsanitized messages more.

    Victor

[Richard Stotz]

@yukishiino: Unsanitized messages are intended mostly for local debugging since they expose information that is somewhat sensitive. Even if most exceptions are caught by a well-written program eventually, this can be changed for local debugging (by printing some exceptions selectively), which makes it possible to see information that is not exposed otherwise. 

I agree that a full-fledged integration of our API into DevTools may provide a better experience for developers, but this comes with very significant development costs. Feedback from early adopters indicates that receiving messages to the console is enough to significantly improve their experience.

A concrete use case is a developer using NativeIO opening many files and eventually failing. This could be caused by insufficient memory, or too many open files for the process. Both are platform-specific, so we want to exercise caution when exposing them. On the other hand, the actual error gives important information to the developer. I believe that unsanitized messages are a good trade-off for this problem. 

@yhirano : Extending what pwnall@ said, I believe there is a difference between revealing something directly to the web and revealing it only after an attacker has performed a deliberate attack. In particular, I believe that fingerprinting efforts would be strongly disincentivized when requiring a deliberate attack. 

Best,

Richard

[Yuki Shiino]

2020年9月23日(水) 23:31 Richard Stotz <rs...@chromium.org>:

@yukishiino: Unsanitized messages are intended mostly for local debugging since they expose information that is somewhat sensitive. Even if most exceptions are caught by a well-written program eventually, this can be changed for local debugging (by printing some exceptions selectively), which makes it possible to see information that is not exposed otherwise. 

I agree that a full-fledged integration of our API into DevTools may provide a better experience for developers, but this comes with very significant development costs. Feedback from early adopters indicates that receiving messages to the console is enough to significantly improve their experience.

I think that this explanation doesn't answer my question.  I'm saying that you can print any messages to DevTools console without using unsanitized messages.  If you want, you can just write a message to DevTools.  Why do we prefer exceptions to simple logging to console?

A concrete use case is a developer using NativeIO opening many files and eventually failing. This could be caused by insufficient memory, or too many open files for the process. Both are platform-specific, so we want to exercise caution when exposing them. On the other hand, the actual error gives important information to the developer. I believe that unsanitized messages are a good trade-off for this problem. 

All this explains why you want logging messages on DevTools console.  This doesn't explain how exceptions are more useful and/or helpful than simple logging to console.

[Yutaka Hirano]

If you are fine with revealing the information to malicious web developers, then using the mechanism sounds reasonable.

Thanks,