Currently, the implementation of RenderProcessHost::FilterURL rewrites any incoming URL that is not valid for the process into "about:blank". This was chosen as we cannot completely ignore IPC messages in the case of invalid URLs, so rewriting using something that should be "safe" was implemented.
This rewriting logic, however, makes it a bit harder to diagnose failures and determine whether about:blank commits for example were result of failure detected in FilterURL or just a regular about:blank navigation. Since the latter has numerous edge cases and implies lots of special handling, it will be useful to distinguish somehow failures from successes.
In general, when we block content from loading, such as failing CSP check or XFO check, we replace the URL with "data:," which is an opaque origin, so it is inaccessible from other documents. We should try to do the same with FilterURL, as there isn't as much special casing for data: URLs as there are for about:blank.
We can also do an incremental first step of appending a reference fragment to the about:blank URL generated by FilterURL, so it can be diagnosed more easily in bug and crash reports.
Comment 1 by bugdroid1@chromium.org
, Oct 29