CSP: Consider a flag to turn off console logging for Report-Only

[millisecond]

We are using a CSP-Report-Only header to watch ad network behavior on sites (not something that will ever move to a blocking header) and are really spamming our console with warnings.

Would be great if there was an option to turn off console reporting if the header was a "Report-Only" variant and report-uri was specified.

[jacobbednarz]

This sounds like a great idea! Definitely be interested in seeing something like this land in CSP3.

[jonathanKingston]

Isn't this more of a debug tools issue? For example if browsers implemented a way for developers to hide/filter the messages away from normal console.

The direction of all browsers seems to be heading towards having a security tab to see these types of messages for example.

Granted these messages can be noisy, confusing and could be improved but hiding them at a CSP level will prevent a developer from using them when he really needs to and remote logs are not indicative of an actual browser session that invariably gets pushed in front of you to fix.

[jacobbednarz]

Isn't this more of a debug tools issue? For example if browsers implemented a way for developers to hide/filter the messages away from normal console.

I'm not sure about others but Chrome already does but that doesn't solve the issue of removing the warnings away from the end user who may have no idea about what a CSP actually is. Perfect example of the confusion it can create 😛

The direction of all browsers seems to be heading towards having a security tab to see these types of messages for example.

That's a great start but the my aim here is the ability to have the CSP warnings only show for those need to see them (namely developers implementing it). Another nice solution would be to be able to toggle this on and off via an option but leave it unchecked by default.

[jonathanKingston]

Again seems an issue with developer tools too easy to access, this isn't something standards can solve either.

For me there seems to be only two rationales to remove the console warnings:

• Hide from users who may worry (Other consoles are just as much of an issue here)
• Hide from developers who are swamped

Both don't really feel like use cases which CSP should be looking at. Perhaps a note in the spec advising implementers on when to hide.

[jacobbednarz]

What about allowing a flag as a CSP directive to instruct developer tooling not to show the warnings? Without it, I feel the developer tools would need to do some rough regex checks to implement the hiding functionality (even if it was off by default).

[jonathanKingston]

What about allowing a flag as a CSP directive to instruct developer tooling not to show the warnings?

The use cases I mentioned above were regarding a flag, even then I think a 'global off' flag is a bad idea.

The problem is the spec actually doesn't require the user agent to even log to the console (except for unknown or unparsable CSP's).

For filtering, in terms of Firefox all errors go through a central method which could be modified to use a different console or adding parameters etc: https://dxr.mozilla.org/mozilla-central/source/dom/security/nsCSPUtils.cpp#81 last time I checked chromium source the errors were similar.

[mozfreddyb]

User interfaces in general is never specified in standards.
I also find your case very odd Controlling (or inspecting) loads via CSP sounds like a hack to me, not even an intended feature.
If you want to inspect requests, I suggest you start getting familiar with Service Workers.

[millisecond]

I don't see it as specifying user-interface details, but rather allowing the developer control of where logging goes. Right now the default without a URI is that it's user-agent only and I totally agree that beyond that should be a dev-tools issue.

But imagine that console.log was your only way to do server logging (by setting some HTTP header with a logging endpoint), but that you couldn't send a server log without it also showing up in the console. Would be frustrating for developers and confusing for users.

There are really two implicit booleans that have control here. clientLogging (always true) and serverLogging (true if URI present). Asking for control of the former, not how client logging is handled/displayed when it's on.

[jonathanKingston]

@millisecond it sounds like your issues are with logging in general which would be an issue for the Console spec.

The specific behaviour you are wanting to filter isn't standardised in CSP either so that would need to be ratified before additional behaviour like turning it off with a flag could happen (again I don't see the use case of doing so other than all console errors are an issue).

But imagine that console.log was your only way to do server logging (by setting some HTTP header with a logging endpoint), but that you couldn't send a server log without it also showing up in the console. Would be frustrating for developers and confusing for users.

It isn't as Freddy said you can write a service worker to log all content. Using violation reports to discover what third party scripts are doing without intent of ever blocking isn't really what CSP was designed for.

confusing for users

Users shouldn't be looking at dev tools, that is a bug in the browsers themselves (This is likely what Freddy means by interface).

[millisecond]

I don't see how Console-spec would help as we don't control the source of the logging.

Using violation reports to discover what third party scripts are doing without intent of ever blocking isn't really what CSP was designed for.

Some sites may use report-only for a day to discover problems and then transition to HTTPS, no big deal. Larger sites may take 12+ months and don't want to "give up" their console for that long.

I do get your point that you don't want to specify UI/UA behavior, but it does seem like we're stuck in an odd circular dependency graph. Browsers have semi-standardized on a UI behavior that's undesirable in some situations but can't get any more hints on the situation without a flag in the spec but the spec doesn't specify behavior to begin with.

[jonathanKingston]

I don't see them globally filtering console messages either by CSP however
that would be the group to involve if you wanted that.

However the usecase you outline is specific for CSP warnings but as
mentioned mostly that isn't standardised. There may be room for unifying
that behaviour amongst browsers.

Filtering messages on demand doesn't have security implications and as
mentioned is far more of a tooling and ux issue. If there were to be a
mechanism to filter the messages would need to be standard across browsers
first.

I think you would get more traction opening bugs with browsers to ask for
tooling changes.

Implementing CSP on big sites is far easier to do in a staging environment
first were you could apply the policy there first. Publishing to the web
with reporting on is likely to be crazy noisy for the logs otherwise. I
suspect other implementors on here will likely point you in the same
direction to rolling out CSP.

On Fri, 4 Mar 2016 19:11 millisecond, [email protected] wrote:

I don't see how Console-spec would help as we don't control the source of
the logging.

Using violation reports to discover what third party scripts are doing
without intent of ever blocking isn't really what CSP was designed for.

Some sites may use report-only for a day to discover problems and then
transition to HTTPS, no big deal. Larger sites may take 12+ months and
don't want to "give up" their console for that long.

I do get your point that you don't want to specify UI/UA behavior, but it
does seem like we're stuck in an odd circular dependency graph. Browsers
have semi-standardized on a UI behavior that's undesirable in some
situations but can't get any more hints on the situation without a flag in
the spec but the spec doesn't specify behavior to begin with.

—
Reply to this email directly or view it on GitHub
#508 (comment).

[swijckmans]

I'd love this too. We are seeing a significant amount of our support tickets relate to this. The alert itself is also confusing. While the alert starts with 'report-only' later it mentions 'blocked'. This is confusing visitors.

[saviour123]

Adding my voice to this. It would be great to disable console logging. A bool true or false directive inside the rules. Can we expedite action on this

[antosart]

As stated in other comments above, the CSP spec does not mandate user agent to log report violations to the console. I don't think that adding control for this in the CSP headers is a meaningful design.

I think those kind of controls should be decoupled from the CSP spec.

I would find reasonable to allow web developers more control on console logging. A separate header, or meta tag, or a separate javascript API for doing that would make sense to me. Something like X-Console-Logging: disable 'csp-report-only'; enable 'csp-report' 'deprecated-features'. I am not sure where a discussion about that should happen, but I don't think it makes sense to have this specifically for CSP.