send all console errors to the server?

[Ojan Vafai]

I don't know if this is the right list for this, but I wonder if it's worth exploring a mode for the web where all console logs also fire window.onerror. That way, web authors can detect errors in the wild and in new browsers.

Alternately, instead of a mode for window.onerror, this could be baked into the reporting API from day 1?

[Mike West]

One thing to be careful of here is that we've historically dumped sensitive information into console messages on the assumption that it was not web exposed. If we're going to start sending that data to the server, we'll need to audit existing messages for things like full, cross-origin URLs that the page wouldn't otherwise have access to.

That said, I like the idea of tying 'window.onerror' to the reporting API. We should be on much safer ground with exceptions, since those have been web-exposed from the beginning.

On Tue 20. Jun 2017 at 03:00, Ojan Vafai <oj...@chromium.org> wrote:

I don't know if this is the right list for this, but I wonder if it's worth exploring a mode for the web where all console logs also fire window.onerror. That way, web authors can detect errors in the wild and in new browsers.

Alternately, instead of a mode for window.onerror, this could be baked into the reporting API from day 1?

--
You received this message because you are subscribed to the Google Groups "platform-predictability" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-predicta...@chromium.org.
To post to this group, send email to platform-pr...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-predictability/CANMdWTtePanpX3cspHWO3zcpmJUU1cvadP09okRFQAeebexDmQ%40mail.gmail.com.

--

-mike

[PhistucK]

On Tue, Jun 20, 2017 at 9:26 AM, 'Mike West' via platform-predictability <platform-pr...@chromium.org> wrote:

One thing to be careful of here is that we've historically dumped sensitive information into console messages on the assumption that it was not web exposed. If we're going to start sending that data to the server, we'll need to audit existing messages for things like full, cross-origin URLs that the page wouldn't otherwise have access to.

​Not really different than overriding console.log (and friends). If you put scripts you do not trust on the page, it does not matter whether they hook into error events, or override console methods.​

☆PhistucK

[Mike West]

On Tue 20. Jun 2017 at 08:35, PhistucK <phis...@gmail.com> wrote:

On Tue, Jun 20, 2017 at 9:26 AM, 'Mike West' via platform-predictability <platform-predictability@chromium.org> wrote:

One thing to be careful of here is that we've historically dumped sensitive information into console messages on the assumption that it was not web exposed. If we're going to start sending that data to the server, we'll need to audit existing messages for things like full, cross-origin URLs that the page wouldn't otherwise have access to.

​Not really different than overriding console.log (and friends). If you put scripts you do not trust on the page, it does not matter whether they hook into error events, or override console methods.​

The major difference I'm concerned about comes when console messages are produced by the browser, not by the page itself. For example, `BindingSecurity::CanAccessWindow` throws a `SecurityError` with a sanitized message in the exception, and a more detailed message in the console. Exposing the former to script is fine, exposing the latter isn't.

I agree with you that exposing page-generated data to the page isn't as concerning, especially if it's opt-in in some way.

-mike

[PhistucK]

Yeah, a sanitized message will have to be exposed. Yet another string in some cases. :(

☆PhistucK

[Simon Pieters]

On Tue, 20 Jun 2017 08:26:29 +0200, 'Mike West' via
platform-predictability <platform-pr...@chromium.org> wrote:

> One thing to be careful of here is that we've historically dumped
> sensitive
> information into console messages on the assumption that it was not web
> exposed. If we're going to start sending that data to the server, we'll
> need to audit existing messages for things like full, cross-origin URLs
> that the page wouldn't otherwise have access to.
>
> That said, I like the idea of tying 'window.onerror' to the reporting
> API.
> We should be on much safer ground with exceptions, since those have been
> web-exposed from the beginning.

This is my concern as well. For example, see the warning in
https://html.spec.whatwg.org/multipage/web-sockets.html#closeWebSocket --
the console is allowed to contain detailed information about why a
connection failed, but it must not be exposed to script.

Also see these threads about using window.onerror for deprecations and
interventions:

https://github.com/whatwg/html/issues/1841
https://github.com/WICG/reporting/issues/27

--
Simon Pieters
Opera Software

[Rick Byers]

Yeah I figured there was no getting around having to audit the warnings and expand them to reporting on a case-by-case basis (in a way that blink developers can reason about the different privacy implications in the code).  Perhaps after we have the basic deprecation/intervention cases working via reporting we should do such an audit and at least pick out the highest value ones.  Perhaps we should spec some "generic warning" report that has absolutely no semantics?  I'm not sure how much we'd need to worry about volume issues or swamping out the key signals we're trying to send etc, but definitely worth digging into - just doesn't seem simple to me.

On Tue, Jun 20, 2017 at 8:57 AM, Simon Pieters <sim...@opera.com> wrote:

--
You received this message because you are subscribed to the Google Groups "platform-predictability" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-predictability+unsubscr...@chromium.org.
To post to this group, send email to platform-predictability@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-predictability/op.y14t9o0jidj3kv%40simons-mbp.lan.

[PhistucK]

For expanding the scope of the error event, perhaps EventListenerOptions can be utilized (propose to add a boolean or enum field that expands the scope)?

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-predictability/CAFUtAY_zhq7bQ9_CA3M7pctW%3DUvyprt_SXTz%3DfJiWyHoGrQsvw%40mail.gmail.com.

[Ojan Vafai]

Perhaps we could set a policy that new console logs default to being sent to reporting API and have a way to opt-out of that that we use for legacy things that we aren't confident can be done safely?

I think the more we get people tracking Reporing APIs on the server, the more reach we have in deprecating/intervening because people who are paying attention will be more likely to see that something is changing out from under them sooner. Today they have to be paying attention in the devtools console and they have to hit the issue locally.

On Tue, Jun 20, 2017 at 6:28 AM Rick Byers <rby...@chromium.org> wrote:

Yeah I figured there was no getting around having to audit the warnings and expand them to reporting on a case-by-case basis (in a way that blink developers can reason about the different privacy implications in the code).  Perhaps after we have the basic deprecation/intervention cases working via reporting we should do such an audit and at least pick out the highest value ones.  Perhaps we should spec some "generic warning" report that has absolutely no semantics?  I'm not sure how much we'd need to worry about volume issues or swamping out the key signals we're trying to send etc, but definitely worth digging into - just doesn't seem simple to me.

On Tue, Jun 20, 2017 at 8:57 AM, Simon Pieters <sim...@opera.com> wrote:

On Tue, 20 Jun 2017 08:26:29 +0200, 'Mike West' via platform-predictability <platform-pr...@chromium.org> wrote:

One thing to be careful of here is that we've historically dumped sensitive
information into console messages on the assumption that it was not web
exposed. If we're going to start sending that data to the server, we'll
need to audit existing messages for things like full, cross-origin URLs
that the page wouldn't otherwise have access to.

That said, I like the idea of tying 'window.onerror' to the reporting API.
We should be on much safer ground with exceptions, since those have been
web-exposed from the beginning.

This is my concern as well. For example, see the warning in https://html.spec.whatwg.org/multipage/web-sockets.html#closeWebSocket -- the console is allowed to contain detailed information about why a connection failed, but it must not be exposed to script.

Also see these threads about using window.onerror for deprecations and interventions:

https://github.com/whatwg/html/issues/1841
https://github.com/WICG/reporting/issues/27

--
Simon Pieters
Opera Software

--
You received this message because you are subscribed to the Google Groups "platform-predictability" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-predicta...@chromium.org.
To post to this group, send email to platform-pr...@chromium.org.

[Rick Byers]

Well we're definitely going to get all deprecation/intervention cases included and ensure there's a consistent coding pattern.  Are there non-deprecation/intervention cases that you're concerned with?

On Fri, Jun 23, 2017 at 3:07 PM, Ojan Vafai <oj...@chromium.org> wrote:

Perhaps we could set a policy that new console logs default to being sent to reporting API and have a way to opt-out of that that we use for legacy things that we aren't confident can be done safely?

I think the more we get people tracking Reporing APIs on the server, the more reach we have in deprecating/intervening because people who are paying attention will be more likely to see that something is changing out from under them sooner. Today they have to be paying attention in the devtools console and they have to hit the issue locally.

On Tue, Jun 20, 2017 at 6:28 AM Rick Byers <rby...@chromium.org> wrote:

Yeah I figured there was no getting around having to audit the warnings and expand them to reporting on a case-by-case basis (in a way that blink developers can reason about the different privacy implications in the code).  Perhaps after we have the basic deprecation/intervention cases working via reporting we should do such an audit and at least pick out the highest value ones.  Perhaps we should spec some "generic warning" report that has absolutely no semantics?  I'm not sure how much we'd need to worry about volume issues or swamping out the key signals we're trying to send etc, but definitely worth digging into - just doesn't seem simple to me.

On Tue, Jun 20, 2017 at 8:57 AM, Simon Pieters <sim...@opera.com> wrote:

On Tue, 20 Jun 2017 08:26:29 +0200, 'Mike West' via platform-predictability <platform-predictability@chromium.org> wrote:

One thing to be careful of here is that we've historically dumped sensitive
information into console messages on the assumption that it was not web
exposed. If we're going to start sending that data to the server, we'll
need to audit existing messages for things like full, cross-origin URLs
that the page wouldn't otherwise have access to.

That said, I like the idea of tying 'window.onerror' to the reporting API.
We should be on much safer ground with exceptions, since those have been
web-exposed from the beginning.

This is my concern as well. For example, see the warning in https://html.spec.whatwg.org/multipage/web-sockets.html#closeWebSocket -- the console is allowed to contain detailed information about why a connection failed, but it must not be exposed to script.

Also see these threads about using window.onerror for deprecations and interventions:

https://github.com/whatwg/html/issues/1841
https://github.com/WICG/reporting/issues/27

--
Simon Pieters
Opera Software

--
You received this message because you are subscribed to the Google Groups "platform-predictability" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-predictability+unsub...@chromium.org.
To post to this group, send email to platform-predictability@chromium.org.