Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
april opened this issue May 17, 2017 · 21 comments
Closed

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

april opened this issue May 17, 2017 · 21 comments
Milestone

Comments

@april
Copy link
Contributor

@april april commented May 17, 2017

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

This comment has been minimized.

Copy link
Contributor Author

@april april commented May 17, 2017

Alternatively, it could work like this:

no-console-log img script style

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

@annevk

This comment has been minimized.

Copy link
Member

@annevk annevk commented May 18, 2017

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

This comment has been minimized.

Copy link
Contributor

@michaelficarra michaelficarra commented May 18, 2017

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

@april

This comment has been minimized.

Copy link
Contributor Author

@april april commented May 18, 2017

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 comment has been minimized.

Copy link

@domenic domenic commented May 18, 2017

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

This comment has been minimized.

Copy link
Contributor Author

@april april commented May 18, 2017

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

This comment has been minimized.

Copy link
Contributor

@michaelficarra michaelficarra commented May 18, 2017

@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

This comment has been minimized.

Copy link
Contributor Author

@april april commented May 18, 2017

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

This comment has been minimized.

Copy link
Contributor Author

@april april commented May 18, 2017

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

This comment has been minimized.

Copy link

@Zirro Zirro commented May 18, 2017

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 comment has been minimized.

Copy link

@ScottHelme ScottHelme commented Dec 31, 2017

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

This comment has been minimized.

Copy link
Contributor Author

@april april commented Dec 31, 2017

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

This comment has been minimized.

Copy link

@Zirro Zirro commented Dec 31, 2017

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

This comment has been minimized.

Copy link

@devd devd commented Dec 31, 2017

@ScottHelme

This comment has been minimized.

Copy link

@ScottHelme ScottHelme commented Dec 31, 2017

No, but I'd like to have that feature:

#255

@Keisial

This comment has been minimized.

Copy link

@Keisial Keisial commented Jan 8, 2018

Can you describe what use cases you would find it useful to see CSP errors caused by somebody else's website?

The case where you are helping that somebody to discover why X doesn't work. Eg. the kitty video is not shown because his CMS automatically applied a CSP policy which doesn't allow embedding youtube videos.

@borischen

This comment has been minimized.

Copy link

@borischen borischen commented Jun 11, 2018

I'd like to add my support to doing something like this or in some way providing a way to not show CSP errors in console, especially when in report-only, when it has no effect on the page.

Every person I've helped with CSP has had their dev/qa teams react with alarm, or loudly object to the logging in the console. A handful simply will not use CSP. I feel this is an under-appreciated impediment to adoption of a very valuable standard.

@michaelficarra

This comment has been minimized.

Copy link
Contributor

@michaelficarra michaelficarra commented Jun 11, 2018

@borischen Maybe you should petition the developers of your dev tools to add a feature for hiding CSP errors.

@borischen

This comment has been minimized.

Copy link

@borischen borischen commented Jun 11, 2018

@michaelficarra - The point of a standard would be so that one would not need to do that.

fyi

A master bug of improvements for ff: https://bugzilla.mozilla.org/show_bug.cgi?id=1242016
Was unable to find similar for Chrome, related is https://bugs.chromium.org/p/chromium/issues/detail?id=801198

@april

This comment has been minimized.

Copy link
Contributor Author

@april april commented Jun 12, 2018

Should I close this bug? It doesn't seem like there is any will to move on it. Like @borischen, I have found it to be a significant impediment to adoption in many organizations. Telling them that they can have all their developers uncheck the button for security logging hasn't exactly been warmly welcomed.

I've updated my WebExtensions that muck with CSP on the fly to simply notify users that their console will be spammed with hundreds to thousands of CSP errors.

@domfarolino

This comment has been minimized.

Copy link
Member

@domfarolino domfarolino commented Jun 12, 2018

I recommend closing this, as I think this is out-of-scope for the spec and something better handled by developer tools configuration as previously mentioned.

@april april closed this Jun 13, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.