CSP3: Consider adding a 'no-console-log' directive

[april]

I use a CSP reporting endpoint and some libraries that do things blocked by CSP. It doesn't affect their functionality, but unfortunately every single page load pollutes the browser console with CSP errors.

I'm proposing that we add a no-console-log CSP directive that would disable this browser behavior.

[april]

Alternatively, it could work like this:

no-console-log img script style

In much the same way that require-sri-for functions.

[annevk]

I'd recommend filing an issue at https://github.com/whatwg/console/issues/new too to let the folks standardizing the console API know this is being considered.

[michaelficarra]

@april It would seem more appropriate for your console implementation to have a configuration option for this.

[april]

Here is my additional use case:

• I write a WebExtension that uses WebRequestBlocking to inject a more strict CSP than the site uses, or perhaps a CSP if the site has no CSP at all
• That WebExtension blocks the execution of JavaScript from some domains or the loading of images or the like
• Each of these blocked resources get logged to the console

There is no obvious way for a WebExtension to stop this excessive (and somewhat ugly) logging. Every browser that supports WebExtensions would need to have the ability to limit CSP errors on a per site basis in their console and the users would have to configure it. Or WebExtensions would need to be extended such that a piece of JavaScript could muck with what does or doesn't get logged. That's a pretty steep cliff to climb.

[domenic]

This does seem better as a browser extension API, as it does not affect functionality exposed to web developers (i.e. you could never write web platform tests for this).

You say that's a steep cliff to climb, but you don't seem to understand how steep a cliff it is to climb to fully specify something, and get it interoperably implemented across browsers.

[april]

I want to clarify that the WebExtension case is not my only use case. I've helped an insane number of sites get setup with CSP, and many of them use CSP reporting endpoints to track their errors, not the console.

For them, the significant amount of spam that appears -- especially when doing early CSP testing with Report-Only -- is a huge hassle to their developers. Sure, developers can disable Security-related entries from showing up in your console, but that breaks needed functionality for many of them.

Since CSP errors are bound to a site, it seems to me that they should have control over whether or not they're logged. If a site is aware of (unfixable) CSP errors due to various JavaScript frameworks, I don't see why they can't decide whether or not they're logged. They can control remote logging by not having a report-uri/report-to, so it seems reasonable that they should have control over local logging as well.

[michaelficarra]

@april The developer in your use case could disable just CSP errors in the console if that was an option of your console implementation. I still see no reason for the policy itself to control this. It's not the appropriate place.

[april]

You say that's a steep cliff to climb, but you don't seem to understand how steep a cliff it is to climb to fully specify something, and get it interoperably implemented across browsers.

I certainly think a WebExtension API that gives control over the console is appropriate, but there are a few reasons why it's a steep cliff:

• WebExtensions don't really have a governing body per se, which makes the standardization process a bit complicated
• Control over console logging as part of an API is likely to prove difficult because it would probably need to have a reasonably complicated permissions model
• There's added complexity when you have multiple WebExtensions binding to the same console permission
• Consoles themselves, although relatively similar across platforms, are still in the early stages of being standardized

Even with all that, a WebExtension API for the console logs still wouldn't allow a site owner to have control over their own logging.

@april The developer in your use case could disable just CSP errors in the console if that was an option of your console implementation. I still see no reason for the policy itself to control this. It's not the appropriate place.

For me personally, I can't just disable the Security tab, because I am often doing Security work unrelated to CSP. This requires me to frequently toggle the tab on and off and on and off.

My personal use aside, I get asked by sites very frequently if there is a way to disable X, Y, or Z CSP error, because they can't do anything about it. They get complaints from their developers about the error spam and don't want to have to tell their sometimes hundreds of developers to all disable Security logging.

They're also sometimes hesitant to deploy CSP because of the optics issue that having scary CSP errors causes. I know that seems a bit silly, but it's something I have been asked about on numerous occasions. It's a real-world concern that a lot of site operators have.

[april]

I should add that the amount of work required to implement no-console-log would be relatively low in comparison to the work required to add a whole new WebExtension API. It would mostly involve a small function and an if statement.

Not that this particular justification makes my idea right or wrong, of course. :)

[Zirro]

For me personally, I can't just disable the Security tab, because I am often doing Security work unrelated to CSP. This requires me to frequently toggle the tab on and off and on and off.

Would it not be more appropriate to implement granular filtering options in the console for developers to toggle? It seems like this could be addressed with a better UI. It should be possible to disable errors by category (such as CSP-related ones), rather than the whole security tab. As an otherwise happy Firefox user, I have often found the "all or nothing" approach of the current console to be frustrating during development.

I suppose it does not take care of the situation where these errors scare people, but could there really be that many people who would open the console and be scared to see an error there?

[ScottHelme]

This is becoming very problematic for a feature I'm currently running in beta on https://report-uri.com too. Imagine deploying this:

Content-Security-Policy-Report-Only: default-src 'none'; report-uri https://report-uri.com

This is a basic starting point for a site with no CSP and allows them to begin the process of identifying hosts they need to whitelist whilst avoiding missing any as a report will be sent for every asset on every page. This makes the console close to useless! It would be nice to turn this off, especially when you're in the early/testing stages of deploying CSP.

[april]

It's not just developers who have to deal with these errors. I have seen many websites that refuse to implement a part of CSP because they will (and have) gotten incorrect emails and bug submissions about CSP errors. I've have worked with sites that don't want to implement CSP because because of the console logging it generates again and again on every page load. It's a silly reason but I have had to deal with it multiple times.

It actively hinders CSP usage and wastes a lot of time. I personally run a bug bounty program and get bug submissions about CSP errors all the time.

Can you describe what use cases you would find it useful to see CSP errors caused by somebody else's website? As an extension developer myself, disabling logging would be a hugely helpful feature – I generate CSP policies in part by setting CSPRO: script-src 'none'; style-src 'none' and monitoring reports. This generates an outrageous amount of spam in the console and there is nothing I can do about it. You can disable security logging in your console, but it's pretty blunt and that blocks all other security logging.

Note that WebExtensions could strip out that directive as sent by a site if they wanted to.

[Zirro]

You can disable security logging in your console, but it's pretty blunt and that blocks all other security logging.

This part of the issue can be resolved by browsers implementing granular control in the console over which kinds of errors get logged. Moving away from the current all-or-nothing approach would be appreciated in other contexts as well.

[devd]

Can browsers disable the logging if the JavaScript catches the csp violation exception?

…

On Dec 31, 2017 11:41 AM, "Zirro" ***@***.***> wrote: You can disable security logging in your console, but it's pretty blunt and that blocks all other security logging. This part of the issue can be resolved by browsers implementing granular control over which kinds of errors get logged. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#217 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAIXGbo6PyvXPsKz53KES7uwegDztkFsks5tF-NegaJpZM4NeVmX> .