Add an error page for resources blocked via XSS Auditor.

Add an error page for resources blocked via XSS Auditor.

Currently, when the XSS Auditor blocks a page, we render a lovely white
rectangle for the user. This, though calming and serene, is not terribly
informative.

This patch wires XSS Auditor blocks up to the general error page
mechanism, giving users some clue as to what's going on.

BUG=654794
Committed: https://crrev.com/b5a70d6b91eeabba6752f56cf9d79b8eb57fcf8c
Cr-Commit-Position: refs/heads/master@{#434375}

[Mike West, 2016-10-17 11:24:24]

The CQ bit was checked by mkwst@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-17 11:24:43]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-17 11:32:39]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-17 11:32:40]

Dry run: Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[Mike West, 2016-10-20 11:49:26]

mkwst@chromium.org changed reviewers:
+ tsepez@chromium.org

[Mike West, 2016-10-20 11:49:27]

Hey Tom, I'm trying to add an error page to the auditor's blocking mechanism so
that users see something reasonable. This patch seems to get into a loop, as the
error page seems to contain data reflected from the ostensible URL (the original
URL is still committed, and the original URL is contained in a JSON blob).

Any ideas about how to approach this? :)

[Tom Sepez, 2016-10-20 16:39:51]

On 2016/10/20 11:49:27, Mike West wrote:
> Hey Tom, I'm trying to add an error page to the auditor's blocking mechanism
so
> that users see something reasonable. This patch seems to get into a loop, as
the
> error page seems to contain data reflected from the ostensible URL (the
original
> URL is still committed, and the original URL is contained in a JSON blob).
> 
> Any ideas about how to approach this? :)

We've been leery about adding this, since we don't want to spook the user, and
we worry about injecting content into an origin -- any botch and now we've got a
universal XSS across the web by triggering the auditor.

[Tom Sepez, 2016-10-20 18:26:58]

https://codereview.chromium.org/2425663002/diff/1/content/renderer/render_fra...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/2425663002/diff/1/content/renderer/render_fra...
content/renderer/render_frame_impl.cc:2493: WebString::fromUTF8("UTF-8"),
GURL(kUnreachableWebDataURL),
Maybe truncate the ? and # portions of the url?

[Tom Sepez, 2016-10-20 18:28:10]

> Maybe truncate the ? and # portions of the url?
Also, prolly path, just an origin?

[Mike West, 2016-10-21 07:30:16]

On 2016/10/20 at 16:39:51, tsepez wrote:
> On 2016/10/20 11:49:27, Mike West wrote:
> > Hey Tom, I'm trying to add an error page to the auditor's blocking mechanism
so
> > that users see something reasonable. This patch seems to get into a loop, as
the
> > error page seems to contain data reflected from the ostensible URL (the
original
> > URL is still committed, and the original URL is contained in a JSON blob).
> > 
> > Any ideas about how to approach this? :)
> 
> We've been leery about adding this, since we don't want to spook the user, and
we worry about injecting content into an origin -- any botch and now we've got a
universal XSS across the web by triggering the auditor.

Well, the error page is committed into a unique origin; I don't think UXSS is an
issue today, but I agree that it increases the risk that it becomes an issue
tomorrow.

Hrm. Error pages are also causing problems for XFO moving up to the browser, for
similar reasons: see the discussion at
https://codereview.chromium.org/2321503002.

[Mike West, 2016-10-24 09:27:59]

The CQ bit was checked by mkwst@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-24 09:28:19]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Mike West, 2016-10-24 09:57:08]

The CQ bit was checked by mkwst@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-24 09:57:23]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Mike West, 2016-10-24 09:59:04]

Description was changed from

==========
WIP: Add an error page for resources blocked via XSS Auditor.

BUG=
==========

to

==========
Add an error page for resources blocked via XSS Auditor.

Currently, when the XSS Auditor blocks a page, we render a lovely white
rectangle for the user. This, though calming and serene, is not terribly
informative.

This patch wires XSS Auditor blocks up to the general error page
mechanism, giving users some clue as to what's going on.

BUG=654794
==========

[Mike West, 2016-10-24 10:41:20]

mkwst@chromium.org changed reviewers:
+ mmenke@chromium.org

[Mike West, 2016-10-24 10:41:21]

On 2016/10/21 at 07:30:16, Mike West wrote:
> > We've been leery about adding this, since we don't want to spook the user,
and we worry about injecting content into an origin -- any botch and now we've
got a universal XSS across the web by triggering the auditor.
> 
> Well, the error page is committed into a unique origin; I don't think UXSS is
an issue today, but I agree that it increases the risk that it becomes an issue
tomorrow.
> 
> Hrm. Error pages are also causing problems for XFO moving up to the browser,
for similar reasons: see the discussion at
https://codereview.chromium.org/2321503002.

tsepez@: Ok. This is less WIP than it was before. I'd appreciate you taking a
closer look, especially at //content/renderer and the Blink-side changes.

You'll note that despite your earlier comments, this patch doesn't alter the
committed URL. It turns out that doing so would break the "View Source"
mechanism that you suggested that you really wanted to keep (and I agree that
it's important from a developer perspective). I think that's safe to do, as the
error page is committed into a unique origin (via `kUnreachableWebDataURL` in
`RenderFrameImpl::loadErrorPage`), and escapes data correctly (via the existing
mechanism in `webui::AppendJsonHtml`, etc). The risk should be limited to what
we're already accepting by having an error page at all.

mmenke@: Would you mind taking a look at the new error code added to
`net_error_list.h`, as well as its usage in `//components/error_page`? (And if
you'd like to skim through the rest, please feel more than free!)

[Mike West, 2016-10-24 10:41:31]

Patchset #2 (id:20001) has been deleted

[Mike West, 2016-10-24 11:44:34]

The CQ bit was checked by mkwst@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-24 11:44:46]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Mike West, 2016-10-24 11:46:18]

https://codereview.chromium.org/2425663002/diff/60001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/http/tests/security/frameNavigation/xss-DENIED-top-navigation-without-user-gesture.html
(right):

https://codereview.chromium.org/2425663002/diff/60001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/security/frameNavigation/xss-DENIED-top-navigation-without-user-gesture.html:11:
//    internals.runtimeFlags.setFramebustingNeedsSameOriginOrUserGesture(true);
TODO(me): Delete these lines (oops).

The timing of this test changed because we're no longer synchronously loading in
`ScheduledPageBlock::fire`.

[commit-bot: I haz the power, 2016-10-24 14:16:42]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-24 14:16:43]

Dry run: Try jobs failed on following builders:
  android_arm64_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)

[mmenke, 2016-10-24 14:44:43]

mmenke@chromium.org changed reviewers:
+ edwardjung@chromium.org

[mmenke, 2016-10-24 14:44:43]

[+edwardjung] for new error code text.

https://codereview.chromium.org/2425663002/diff/60001/components/error_page_s...
File components/error_page_strings.grdp (right):

https://codereview.chromium.org/2425663002/diff/60001/components/error_page_s...
components/error_page_strings.grdp:264: This page may contain maliciously
injected script.
"a maliciously injected script." or "maliciously injected scripts."

Should we include more detail here?  The network stack team will be getting
reports of this error, and I have absolutely no clue what this means was the
actual problem.  A clearer error code would also work...What auditor?

[edwardjung, 2016-10-24 16:00:25]

On 2016/10/24 14:44:43, mmenke wrote:
> [+edwardjung] for new error code text.

Hi Mike, could you fill out go/chrome-neterror-strings for this new error. I'll
route the string through the UI review folks. Thanks.

[Mike West, 2016-10-24 19:39:02]

On 2016/10/24 at 14:44:43, mmenke wrote:
> [+edwardjung] for new error code text.
> 
>
https://codereview.chromium.org/2425663002/diff/60001/components/error_page_s...
> File components/error_page_strings.grdp (right):
> 
>
https://codereview.chromium.org/2425663002/diff/60001/components/error_page_s...
> components/error_page_strings.grdp:264: This page may contain maliciously
injected script.
> "a maliciously injected script." or "maliciously injected scripts."
> 
> Should we include more detail here?  The network stack team will be getting
reports of this error

FWIW, you'll only be getting reports of this error in cases where we're
currently showing users a blank page after a flash of content. It's a bad
experience today; this seems like a strict improvement, whatever the string.

Also, we're talking about something like 0.0003% of page views, just for a sense
of scale.

> and I have absolutely no clue what this means was the actual problem.  A
clearer error code would also work...What auditor?

The XSS auditor in Blink, which basically parses through a page with a number of
varyingly clever heuristics to guess at whether or not content is being
reflected from the URL into the page. It's a defense in depth against cross-site
scripting attacks, which isn't something that is easy to explain to users.

I'm very open to suggestions regarding the string; it basically boils down to
"Chrome thinks bad things are happening, and isn't going to let you visit this
page.", which isn't terribly actionable. I'll fill out the form that edwardjung@
noted below.

[mmenke, 2016-10-24 19:42:14]

On 2016/10/24 19:39:02, Mike West wrote:
> On 2016/10/24 at 14:44:43, mmenke wrote:
> > [+edwardjung] for new error code text.
> > 
> >
>
https://codereview.chromium.org/2425663002/diff/60001/components/error_page_s...
> > File components/error_page_strings.grdp (right):
> > 
> >
>
https://codereview.chromium.org/2425663002/diff/60001/components/error_page_s...
> > components/error_page_strings.grdp:264: This page may contain maliciously
> injected script.
> > "a maliciously injected script." or "maliciously injected scripts."
> > 
> > Should we include more detail here?  The network stack team will be getting
> reports of this error
> 
> FWIW, you'll only be getting reports of this error in cases where we're
> currently showing users a blank page after a flash of content. It's a bad
> experience today; this seems like a strict improvement, whatever the string.
> 
> Also, we're talking about something like 0.0003% of page views, just for a
sense
> of scale.
> 
> > and I have absolutely no clue what this means was the actual problem.  A
> clearer error code would also work...What auditor?
> 
> The XSS auditor in Blink, which basically parses through a page with a number
of
> varyingly clever heuristics to guess at whether or not content is being
> reflected from the URL into the page. It's a defense in depth against
cross-site
> scripting attacks, which isn't something that is easy to explain to users.
> 
> I'm very open to suggestions regarding the string; it basically boils down to
> "Chrome thinks bad things are happening, and isn't going to let you visit this
> page.", which isn't terribly actionable. I'll fill out the form that
edwardjung@
> noted below.

Do we show something in the devtools console when this happens?

[Mike West, 2016-10-24 19:46:45]

On 2016/10/24 at 16:00:25, edwardjung wrote:
> On 2016/10/24 14:44:43, mmenke wrote:
> > [+edwardjung] for new error code text.
> 
> Hi Mike, could you fill out go/chrome-neterror-strings for this new error.
I'll route the string through the UI review folks. Thanks.

Filled out the form, thanks for the pointer!

[Mike West, 2016-10-25 05:03:55]

On 2016/10/24 at 19:42:14, mmenke wrote:
> On 2016/10/24 19:39:02, Mike West wrote:
> > On 2016/10/24 at 14:44:43, mmenke wrote:
> > > [+edwardjung] for new error code text.
> > > 
> > >
> >
https://codereview.chromium.org/2425663002/diff/60001/components/error_page_s...
> > > File components/error_page_strings.grdp (right):
> > > 
> > >
> >
https://codereview.chromium.org/2425663002/diff/60001/components/error_page_s...
> > > components/error_page_strings.grdp:264: This page may contain maliciously
> > injected script.
> > > "a maliciously injected script." or "maliciously injected scripts."
> > > 
> > > Should we include more detail here?  The network stack team will be
getting
> > reports of this error
> > 
> > FWIW, you'll only be getting reports of this error in cases where we're
> > currently showing users a blank page after a flash of content. It's a bad
> > experience today; this seems like a strict improvement, whatever the string.
> > 
> > Also, we're talking about something like 0.0003% of page views, just for a
sense
> > of scale.
> > 
> > > and I have absolutely no clue what this means was the actual problem.  A
> > clearer error code would also work...What auditor?
> > 
> > The XSS auditor in Blink, which basically parses through a page with a
number of
> > varyingly clever heuristics to guess at whether or not content is being
> > reflected from the URL into the page. It's a defense in depth against
cross-site
> > scripting attacks, which isn't something that is easy to explain to users.
> > 
> > I'm very open to suggestions regarding the string; it basically boils down
to
> > "Chrome thinks bad things are happening, and isn't going to let you visit
this
> > page.", which isn't terribly actionable. I'll fill out the form that
edwardjung@
> > noted below.
> 
> Do we show something in the devtools console when this happens?

Yes. Something like "The XSS Auditor blocked access to
'https://github.com/?xss=%3Cscript%20async=%22async%22%20crossorigin=%22anon…b4bdc543641613bfa8b656bc645b3942aba57ee556c38e900d94.js%22%3E%3C/script%3E'
because the source code of a script was found within the request. The server
sent an 'X-XSS-Protection' header requesting this behavior."

[mmenke, 2016-10-25 21:14:50]

On 2016/10/25 05:03:55, Mike West wrote:
> On 2016/10/24 at 19:42:14, mmenke wrote:
> > On 2016/10/24 19:39:02, Mike West wrote:
> > > On 2016/10/24 at 14:44:43, mmenke wrote:
> > > > [+edwardjung] for new error code text.
> > > > 
> > > >
> > >
>
https://codereview.chromium.org/2425663002/diff/60001/components/error_page_s...
> > > > File components/error_page_strings.grdp (right):
> > > > 
> > > >
> > >
>
https://codereview.chromium.org/2425663002/diff/60001/components/error_page_s...
> > > > components/error_page_strings.grdp:264: This page may contain
maliciously
> > > injected script.
> > > > "a maliciously injected script." or "maliciously injected scripts."
> > > > 
> > > > Should we include more detail here?  The network stack team will be
> getting
> > > reports of this error
> > > 
> > > FWIW, you'll only be getting reports of this error in cases where we're
> > > currently showing users a blank page after a flash of content. It's a bad
> > > experience today; this seems like a strict improvement, whatever the
string.
> > > 
> > > Also, we're talking about something like 0.0003% of page views, just for a
> sense
> > > of scale.
> > > 
> > > > and I have absolutely no clue what this means was the actual problem.  A
> > > clearer error code would also work...What auditor?
> > > 
> > > The XSS auditor in Blink, which basically parses through a page with a
> number of
> > > varyingly clever heuristics to guess at whether or not content is being
> > > reflected from the URL into the page. It's a defense in depth against
> cross-site
> > > scripting attacks, which isn't something that is easy to explain to users.
> > > 
> > > I'm very open to suggestions regarding the string; it basically boils down
> to
> > > "Chrome thinks bad things are happening, and isn't going to let you visit
> this
> > > page.", which isn't terribly actionable. I'll fill out the form that
> edwardjung@
> > > noted below.
> > 
> > Do we show something in the devtools console when this happens?
> 
> Yes. Something like "The XSS Auditor blocked access to
>
'https://github.com/?xss=%3Cscript%20async=%22async%22%20crossorigin=%22anon…b4bdc543641613bfa8b656bc645b3942aba57ee556c38e900d94.js%22%3E%3C/script%3E'
> because the source code of a script was found within the request. The server
> sent an 'X-XSS-Protection' header requesting this behavior."

Ok, that addresses my concern.  Do we have a label that should be used on the
tracker for the auditor?  If so, maybe make sure to include it in the comment in
net_error_list.h?  LGTM, but be sure to wait for UI signoff.

[Mike West, 2016-10-26 08:16:26]

On 2016/10/25 at 21:14:50, mmenke wrote:
> > Yes. Something like "The XSS Auditor blocked access to
> >
'https://github.com/?xss=%3Cscript%20async=%22async%22%20crossorigin=%22anon…b4bdc543641613bfa8b656bc645b3942aba57ee556c38e900d94.js%22%3E%3C/script%3E'
> > because the source code of a script was found within the request. The server
> > sent an 'X-XSS-Protection' header requesting this behavior."
> 
> Ok, that addresses my concern.  Do we have a label that should be used on the
tracker for the auditor? 
> If so, maybe make sure to include it in the comment in net_error_list.h?

On `crbug.com`? It's wrapped up into `Blink>SecurityFeature`. I can rename the
error to include "XSS_AUDITOR" rather than just "AUDITOR", but I'm not sure what
else you'd like me to do for transparency there.

> LGTM, but be sure to wait for UI signoff.

Great, thanks!

tsepez@: WDYT? Are you still skeptical of the error page in general?

edwardjung@: Any feedback from UI folks? Or should I walk down the hall and sit
on Rachel's desk until she comes up with a wonderful string? :)

[Mike West, 2016-10-26 08:32:55]

The CQ bit was checked by mkwst@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-26 08:33:12]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-26 10:39:44]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-26 10:39:45]

Dry run: This issue passed the CQ dry run.

[Tom Sepez, 2016-10-28 16:45:58]

tsepez@chromium.org changed reviewers:
+ estark@chromium.org, lgarron@chromium.org, meacer@chromium.org

[Tom Sepez, 2016-10-28 16:45:59]

Adding a smattering of enamel folks ...

https://codereview.chromium.org/2425663002/diff/80001/components/error_page_s...
File components/error_page_strings.grdp (right):

https://codereview.chromium.org/2425663002/diff/80001/components/error_page_s...
components/error_page_strings.grdp:263: <message
name="IDS_ERRORPAGES_SUMMARY_BLOCKED_BY_XSS_AUDITOR" desc="Summary in the error
page when the XSS Auditor blocks a response.">
I don't think our users are likely to understand this, and will probably scare
them.  It doesn't provide an actionable next step. Let's see what enamel says.

[meacer, 2016-10-28 17:38:30]

https://codereview.chromium.org/2425663002/diff/80001/components/error_page_s...
File components/error_page_strings.grdp (right):

https://codereview.chromium.org/2425663002/diff/80001/components/error_page_s...
components/error_page_strings.grdp:263: <message
name="IDS_ERRORPAGES_SUMMARY_BLOCKED_BY_XSS_AUDITOR" desc="Summary in the error
page when the XSS Auditor blocks a response.">
On 2016/10/28 16:45:59, Tom Sepez wrote:
> I don't think our users are likely to understand this, and will probably scare
> them.  It doesn't provide an actionable next step. Let's see what enamel says.
> 

(Not official Enamel™ stance) I tend to agree with Tom, and a console message
associated with a blank page sounds a tad better. It's also in line with other
security related headers (e.g. X-Frame-Options blocking the iframe and
displaying a blank page)

I'm worried that some clever attacker will trigger this and use it for social
engineering in the future. (Your Google is infected, click here to upgrade it!)

[Tom Sepez, 2016-10-28 20:02:09]

> I'm worried that some clever attacker will trigger this and use it for social
> engineering in the future. (Your Google is infected, click here to upgrade
it!)

Right, so we can't blame the web site, even though it may be vulnerable.
Nor do we want to take the blame ourselves, though it may be our false positive.
About the only thing that can be implicated is the URL itself:

"Chrome declined to show the page because a portion of the URL was suspicious."

[Mike West, 2016-11-03 13:18:17]

Thanks for taking a look; I was briefly OOO, so apologies for the delayed
response.

On 2016/10/28 at 17:38:30, meacer wrote:
> (Not official Enamel™ stance) I tend to agree with Tom, and a console message
associated with a blank page sounds a tad better. It's also in line with other
security related headers (e.g. X-Frame-Options blocking the iframe and
displaying a blank page)

Note that I also would like that to show an error. :)

In general, we do give users actionable error messages, but there are
exceptions: consider HSTS, for instance, which leads you to
chrome://interstitials/ssl?overridable=0&strict_enforcement=1, which offers
"Reload" (~guaranteed to be useless).

> I'm worried that some clever attacker will trigger this and use it for social
engineering in the future. (Your Google is infected, click here to upgrade it!)

This seems non-unique? I mean, an attacker could point you to
`https://google.com.mikewest.org/` and say that the DNS failure is proof that
things are bad? I guess the claim is that an attacker can cause this page to
appear on someone else's origin?

[mmenke, 2016-11-03 13:35:43]

On 2016/11/03 13:18:17, Mike West wrote:
> Thanks for taking a look; I was briefly OOO, so apologies for the delayed
> response.
> 
> On 2016/10/28 at 17:38:30, meacer wrote:
> > (Not official Enamel™ stance) I tend to agree with Tom, and a console
message
> associated with a blank page sounds a tad better. It's also in line with other
> security related headers (e.g. X-Frame-Options blocking the iframe and
> displaying a blank page)
> 
> Note that I also would like that to show an error. :)
> 
> In general, we do give users actionable error messages, but there are
> exceptions: consider HSTS, for instance, which leads you to
> chrome://interstitials/ssl?overridable=0&strict_enforcement=1, which offers
> "Reload" (~guaranteed to be useless).
> 
> > I'm worried that some clever attacker will trigger this and use it for
social
> engineering in the future. (Your Google is infected, click here to upgrade
it!)
> 
> This seems non-unique? I mean, an attacker could point you to
> `https://google.com.mikewest.org/` and say that the DNS failure is proof that
> things are bad? I guess the claim is that an attacker can cause this page to
> appear on someone else's origin?

Also, without X-Frame-Options, they could show a real error page (Or one that
looked like a real error page) instead.  I don't see how the X-Frame-Options
case is any more of a concern?

[edwardjung, 2016-11-03 15:30:19]

Sorry for the hold up from the UX front, rachelis, Mike and I just met about
this error. From a UX point of view showing a blank page after possibly flashing
up the content is just a bad experience, so showing something would be
preferable and it seems fine to show a network error. 

However from the comments here, there are concerns about using the current
network error interstitial. Seems like we need a proper discussion with the
Enamel folks and find out what needs to be addressed in the current interstitial
in order to make it safe. If there are security issues with the current
interstitial then we should fix those anyway since we're serving a lot of them. 

I see Mike has started a thread with the Enamel folks already so we'll circle
back when decisions has been made. 

@mmenke would you like to be included in the discussions?


On 2016/11/03 13:35:43, mmenke (Busy Nov 2-3) wrote:
> On 2016/11/03 13:18:17, Mike West wrote:
> > Thanks for taking a look; I was briefly OOO, so apologies for the delayed
> > response.
> > 
> > On 2016/10/28 at 17:38:30, meacer wrote:
> > > (Not official Enamel™ stance) I tend to agree with Tom, and a console
> message
> > associated with a blank page sounds a tad better. It's also in line with
other
> > security related headers (e.g. X-Frame-Options blocking the iframe and
> > displaying a blank page)
> > 
> > Note that I also would like that to show an error. :)
> > 
> > In general, we do give users actionable error messages, but there are
> > exceptions: consider HSTS, for instance, which leads you to
> > chrome://interstitials/ssl?overridable=0&strict_enforcement=1, which offers
> > "Reload" (~guaranteed to be useless).
> > 
> > > I'm worried that some clever attacker will trigger this and use it for
> social
> > engineering in the future. (Your Google is infected, click here to upgrade
> it!)
> > 
> > This seems non-unique? I mean, an attacker could point you to
> > `https://google.com.mikewest.org/` and say that the DNS failure is proof
that
> > things are bad? I guess the claim is that an attacker can cause this page to
> > appear on someone else's origin?
> 
> Also, without X-Frame-Options, they could show a real error page (Or one that
> looked like a real error page) instead.  I don't see how the X-Frame-Options
> case is any more of a concern?

[mmenke, 2016-11-03 16:04:49]

On 2016/11/03 15:30:19, edwardjung wrote:
> Sorry for the hold up from the UX front, rachelis, Mike and I just met about
> this error. From a UX point of view showing a blank page after possibly
flashing
> up the content is just a bad experience, so showing something would be
> preferable and it seems fine to show a network error. 
> 
> However from the comments here, there are concerns about using the current
> network error interstitial. Seems like we need a proper discussion with the
> Enamel folks and find out what needs to be addressed in the current
interstitial
> in order to make it safe. If there are security issues with the current
> interstitial then we should fix those anyway since we're serving a lot of
them. 
> 
> I see Mike has started a thread with the Enamel folks already so we'll circle
> back when decisions has been made. 
> 
> @mmenke would you like to be included in the discussions?

No, thanks - happy to defer to whatever everyone else decides on.

[Tom Sepez, 2016-11-03 16:22:54]

Another alternative would be to just stop rendering any more scripts/elements at
the point the reflection is detected and just show what you've got.  No idea
what the implications of this might be ...

[Mike West, 2016-11-10 13:23:58]

The CQ bit was checked by mkwst@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-10 13:24:14]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-10 15:05:42]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-10 15:05:44]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Mike West, 2016-11-11 13:07:14]

The CQ bit was checked by mkwst@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-11 13:07:30]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-11 15:42:14]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-11 15:42:16]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[Mike West, 2016-11-18 09:16:01]

The CQ bit was checked by mkwst@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-18 09:16:24]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-18 11:36:09]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-18 11:36:10]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Mike West, 2016-11-18 15:57:13]

The CQ bit was checked by mkwst@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-18 15:57:53]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[edwardjung, 2016-11-18 16:18:47]

https://codereview.chromium.org/2425663002/diff/180001/components/error_page_...
File components/error_page_strings.grdp (right):

https://codereview.chromium.org/2425663002/diff/180001/components/error_page_...
components/error_page_strings.grdp:110: Try <ph name="LINK">&lt;a
jsvalues="href:originURL;.jstdata:$this"
onmousedown="linkClicked(this.jstdata)"&gt;visiting the site's
homepage&lt;/a&gt;<ex>www.somewhere.com</ex></ph>
To make this clear for our translators this needs to be:

Try <ph name="BEGIN_LINK">&lt;a jsvalues="href:originURL;.jstdata:$this"
onmousedo
     wn="linkClicked(this.jstdata)"&gt;</ph>visiting the site's homepage<ph
name="END_LINK">&lt;/a&gt;<ex>www.somewhere.com</ex></ph>

As otherwise 'visiting the site's homepage' won't be translated.  See
IDS_ERRORPAGES_SUGGESTION_DIAGNOSE_STANDALONE as an another example.

Also since this is a standalone suggestion, not in a list, we end with a full
stop (period).

[commit-bot: I haz the power, 2016-11-18 18:09:19]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-18 18:09:20]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Mike West, 2016-11-23 08:27:49]

The CQ bit was checked by mkwst@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-23 08:27:55]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Mike West, 2016-11-23 08:31:34]

mkwst@chromium.org changed reviewers:
+ jochen@chromium.org
- estark@chromium.org, lgarron@chromium.org, meacer@chromium.org

[Mike West, 2016-11-23 08:31:35]

Thanks folks. Moving some people to CC to make things a little clearer...

edwardjung@: I've change the string as you suggested, WDYT?

jochen@: Would you mind reviewing the change to //content/renderer?

[commit-bot: I haz the power, 2016-11-23 09:57:17]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-23 09:57:19]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[jochen (gone - plz use gerrit), 2016-11-23 15:07:14]

lgtm

[edwardjung, 2016-11-23 21:33:13]

lgtm

[Mike West, 2016-11-24 10:02:06]

The CQ bit was checked by mkwst@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-24 10:02:32]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Mike West, 2016-11-24 11:40:44]

The CQ bit was unchecked by mkwst@chromium.org

[Mike West, 2016-11-24 11:40:48]

The CQ bit was checked by mkwst@chromium.org

[Mike West, 2016-11-24 11:40:48]

The patchset sent to the CQ was uploaded after l-g-t-m from mmenke@chromium.org,
edwardjung@chromium.org, jochen@chromium.org
Link to the patchset: https://codereview.chromium.org/2425663002/#ps220001
(title: "Test.")

[commit-bot: I haz the power, 2016-11-24 11:41:20]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-24 12:03:29]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-24 12:03:31]

Try jobs failed on following builders:
  blimp_linux_dbg on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build
URL)
  cast_shell_linux on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build
URL)
  chromeos_daisy_chromium_compile_only_ng on master.tryserver.chromium.linux
(JOB_TIMED_OUT, no build URL)
  chromeos_x86-generic_chromium_compile_only_ng on
master.tryserver.chromium.linux (JOB_TIMED_OUT, no build URL)
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_TIMED_OUT,
no build URL)
  linux_chromium_chromeos_compile_dbg_ng on master.tryserver.chromium.linux
(JOB_TIMED_OUT, no build URL)
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_TIMED_OUT, no build URL)
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux
(JOB_TIMED_OUT, no build URL)
  linux_chromium_clobber_rel_ng on master.tryserver.chromium.linux
(JOB_TIMED_OUT, no build URL)
  linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux
(JOB_TIMED_OUT, no build URL)
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_TIMED_OUT, no
build URL)

[Mike West, 2016-11-24 12:30:03]

The CQ bit was checked by mkwst@chromium.org

[commit-bot: I haz the power, 2016-11-24 12:30:23]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-24 13:42:48]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-24 13:42:50]

Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build
URL)

[Mike West, 2016-11-24 14:23:40]

The CQ bit was checked by mkwst@chromium.org

[commit-bot: I haz the power, 2016-11-24 14:24:19]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-24 16:52:56]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-24 16:52:58]

Try jobs failed on following builders:
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Mike West, 2016-11-24 16:55:40]

The CQ bit was checked by mkwst@chromium.org

[commit-bot: I haz the power, 2016-11-24 16:55:59]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-24 19:02:58]

CQ is committing da patch.

Bot data: {"patchset_id": 220001, "attempt_start_ts": 1480006540895290,
"parent_rev": "ec01b447f6fc21c887d1b3cf96be282700e1386d", "commit_rev":
"dafc01cd13129e5ac3d34085ce72d797d57c2e0d"}

[commit-bot: I haz the power, 2016-11-24 19:03:24]

Committed patchset #11 (id:220001)

[commit-bot: I haz the power, 2016-11-24 19:05:05]

Description was changed from

==========
Add an error page for resources blocked via XSS Auditor.

Currently, when the XSS Auditor blocks a page, we render a lovely white
rectangle for the user. This, though calming and serene, is not terribly
informative.

This patch wires XSS Auditor blocks up to the general error page
mechanism, giving users some clue as to what's going on.

BUG=654794
==========

to

==========
Add an error page for resources blocked via XSS Auditor.

Currently, when the XSS Auditor blocks a page, we render a lovely white
rectangle for the user. This, though calming and serene, is not terribly
informative.

This patch wires XSS Auditor blocks up to the general error page
mechanism, giving users some clue as to what's going on.

BUG=654794

Committed: https://crrev.com/b5a70d6b91eeabba6752f56cf9d79b8eb57fcf8c
Cr-Commit-Position: refs/heads/master@{#434375}
==========

[commit-bot: I haz the power, 2016-11-24 19:05:07]

Patchset 11 (id:??) landed as
https://crrev.com/b5a70d6b91eeabba6752f56cf9d79b8eb57fcf8c
Cr-Commit-Position: refs/heads/master@{#434375}