CCing alexmos@ who's done more thinking about error pages than I have. There's probably a good argument to be made that error pages and interstitials should be considered part of the browser UI, and shouldn't be subject to restrictions places by their embedders.

I agree that it would be reasonable to exclude error pages and interstitials from CSP restrictions enforced by their embedders.  

Charlie, Nasko, and I discussed error pages in another context yesterday, and Nasko had an interesting proposal to invent a chrome-error:// scheme that error pages will use to commit.  We can use the virtual URL mechanism to still show the right thing to the user (and maybe handle the reloads properly?), and once interstitials are refactored, they can also use this scheme to commit.  Presumably, if we have this, we could just exclude chrome-error:// from CSP enforcement the same way that this is done for chrome-extension:// today to fix this, and we won't need hacks to tell apart the error page data: URL from all other data: URLs.  

Charlie pointed out that in the early days, something like this was done, but with a chrome://chromewebdata URL.  That had security problems due to using a chrome:// URL that committed in regular processes, so it was changed to a data: URL (I believe this was  issue 117230  - Charlie can correct me if that's wrong).  But perhaps we can avoid those kinds of problems again by using a separate, non-privileged scheme.  Mike - any thoughts on this?

I'm not an expert on navigation, but I think it's worth noting that reloads will have to reload the original URL, and re-post if necessary (Showing a confirmation dialog).  I'm not familiar with "the virtual URL mechanism", just wanted to make sure it supports those two things.

All of these cases are handled already today, so they will likely remain working, as long as we keep the same mechanism around. My proposal was to change the scheme on the committed error pages to something that is not possible to encounter on the web and is not privileged in Chrome's context.

I don't think we should prevent error pages from enforcing policy (it actually seems valuable for them to lock themselves down), but I do think we should probably exclude `chrome-error://` from inheriting policy from its parent/opener. That would actually magically be taken care of by changing the scheme from `data:` to `chrome-error:`, actually, as it would no longer match the condition in https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/Document.cpp?rcl=2dab99eb614d76c0446b46538515f13a77319408&l=5590 :)

Mike mentioned this bug after I told him we're seeing some CSP violations for data:text/html,chromewebdata URIs in our production apps.

JFYI it looks like this is indeed the cause of these violations:
https://arturjanc.com/csp-chromewebdata.html -- the framed error page inherits the CSP, as Nick suggested.

+Nasko for a question: is `chrome-error://` going to happen? If so, great! This will be magically solved!

If not, it might be worth some time to hack in a solution, as aaj@ tells me that the CSP errors are causing some strife on internal projects.

chrome-error:// is definitely not on our radar for Q3 and possibly not even Q4. If anyone is interested in helping move it forward, please let me know and we will be happy to provide guidance and design help.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/71f48559772345f1005a0e24eb27b01feada9439

commit 71f48559772345f1005a0e24eb27b01feada9439
Author: Alex Moshchuk <alexmos@chromium.org>
Date: Wed Aug 16 16:20:00 2017

Change error pages to use a new chrome-error:// scheme.

This CL changes error pages to use chrome-error://chromewebdata/
instead of data:text/html,chromewebdata.

This has the benefit that error pages won't inherit CSP from their
parent/opener.  Previously, when a page defined a CSP and then ended
up loading an error page in a subframe, the error page might've been
broken by the parent's CSP, since, for example, it needs to execute
inline scripts.  This could result in the error page not showing up
correctly and/or false CSP reports being sent.

The new scheme is marked as secure and as requiring an opaque origin
to match previous behavior.

Web pages used to be able to directly load the error URL, which just
showed up as "chromewebdata".  With this change, navigating to the
error URL would bring up the external protocol dialog instead, so this
CL prevents renderers from directly navigating to or redirecting to
error URLs.

Additionally, chrome-error:// is registered as a display-isolated
scheme, so that regular web pages can't embed the error URL in an
iframe or image, and as a scheme that does not allow javascript URL
manipulation, which is consistent with other pages considered to be
part of Chrome.  If either of these new restrictions ends up being
problematic, we should revisit them in
RenderThreadImpl::RegisterSchemes().

In the future, it's possible to further utilize the host/path portion
of the URL to identify different kinds of error pages.

Bug: 703801
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
Change-Id: I45fa0aa157523450c33c6464f96414ff742e8604
Reviewed-on: https://chromium-review.googlesource.com/580169
Reviewed-by: Matt Menke <mmenke@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Charlie Reis (OOO Aug 17-24) <creis@chromium.org>
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Reviewed-by: Shuotao Gao <stgao@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#494809}
[modify] https://crrev.com/71f48559772345f1005a0e24eb27b01feada9439/chrome/browser/chrome_navigation_browsertest.cc
[modify] https://crrev.com/71f48559772345f1005a0e24eb27b01feada9439/chrome/browser/extensions/window_open_apitest.cc
[modify] https://crrev.com/71f48559772345f1005a0e24eb27b01feada9439/chrome/browser/net/errorpage_browsertest.cc
[modify] https://crrev.com/71f48559772345f1005a0e24eb27b01feada9439/chrome/test/chromedriver/chrome/navigation_tracker.cc
[modify] https://crrev.com/71f48559772345f1005a0e24eb27b01feada9439/chrome/test/chromedriver/test/run_py_tests.py
[modify] https://crrev.com/71f48559772345f1005a0e24eb27b01feada9439/chrome/test/chromedriver/window_commands.cc
[add] https://crrev.com/71f48559772345f1005a0e24eb27b01feada9439/chrome/test/data/empty_with_404.html
[add] https://crrev.com/71f48559772345f1005a0e24eb27b01feada9439/chrome/test/data/empty_with_404.html.mock-http-headers
[add] https://crrev.com/71f48559772345f1005a0e24eb27b01feada9439/chrome/test/data/page_with_csp_and_error_iframe.html
[modify] https://crrev.com/71f48559772345f1005a0e24eb27b01feada9439/content/browser/child_process_security_policy_impl.cc
[modify] https://crrev.com/71f48559772345f1005a0e24eb27b01feada9439/content/browser/child_process_security_policy_unittest.cc
[modify] https://crrev.com/71f48559772345f1005a0e24eb27b01feada9439/content/browser/frame_host/render_frame_host_impl.cc
[modify] https://crrev.com/71f48559772345f1005a0e24eb27b01feada9439/content/common/url_schemes.cc
[modify] https://crrev.com/71f48559772345f1005a0e24eb27b01feada9439/content/public/common/url_constants.cc
[modify] https://crrev.com/71f48559772345f1005a0e24eb27b01feada9439/content/public/common/url_constants.h
[modify] https://crrev.com/71f48559772345f1005a0e24eb27b01feada9439/content/renderer/render_thread_impl.cc
[modify] https://crrev.com/71f48559772345f1005a0e24eb27b01feada9439/third_party/WebKit/LayoutTests/inspector-protocol/page/frameNavigatedToUnreachableUrl-expected.txt
[modify] https://crrev.com/71f48559772345f1005a0e24eb27b01feada9439/third_party/WebKit/LayoutTests/inspector/console/console-context-selector-expected.txt
[modify] https://crrev.com/71f48559772345f1005a0e24eb27b01feada9439/third_party/WebKit/Source/core/exported/WebFrameTest.cpp

chrome-error://chromewebdata/ is already in stable. But this does not resolve the issue reported here. And new chrome-error: scheme also bypasses frame-src *.

Ah, okay, it was designed to bypass CSP...
Nice choice actually, it blocked an attack scenario.

Ha! You're right. We got sidetracked on Artur's https://arturjanc.com/csp-chromewebdata.html (which is fixed by `chrome-error:` pages), and forgot about `sandbox` flags, which we need to poke at to make sure they don't persist down into error frames.

Alex, do you have cycles to poke at that?