Validate the Origin HTTP header in the browser process.

Validate the Origin HTTP header in the browser process.

Web renderer processes should not be able to set the Origin header
to WebUI, Chrome App, or invalid origins.  (Note that Chrome App
origins may be allowed in some cases if they have guest processes
with accessible_resources.)

Most of these checks can be enforced by ChildProcessSecurityPolicy,
but we call out to ContentBrowserClient for the extension/app checks.

BUG=513502
TEST=Should only affect compromised renderer processes.

Committed: https://crrev.com/3710b238717b14967922263070cac76257a55ac5
Cr-Commit-Position: refs/heads/master@{#343778}

[Charlie Reis, 2015-08-14 18:55:25]

Patchset #7 (id:120001) has been deleted

[Charlie Reis, 2015-08-14 20:05:46]

creis@chromium.org changed reviewers:
+ nasko@chromium.org

[Charlie Reis, 2015-08-14 20:25:58]

creis@chromium.org changed reviewers:
+ lfg@chromium.org

[Charlie Reis, 2015-08-14 20:25:59]

Nasko, can you take a look?  This was trickier than I'd hoped, for a few
reasons: we can only look at the origin (not the full URL), it runs on the IO
thread, and Chrome App origins can legally show up in guest processes for
accessible_resources.

I've handled most of the checks in ChildProcessSecurityPolicy's CanCommitURL
(which we should be able to use for committed pages as well in a future CL). 
The app-specific stuff is checked in ContentBrowserClient::IsIllegalOrigin.

https://codereview.chromium.org/1270663002/diff/160001/chrome/browser/extensi...
File chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc
(right):

https://codereview.chromium.org/1270663002/diff/160001/chrome/browser/extensi...
chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc:232:
// itself, or by one if its guests if there are accessible_resources.
lfg@, can you review this part?  I'm allowing an app's origin for its guests if
the app has accessible resources.

https://codereview.chromium.org/1270663002/diff/160001/content/browser/securi...
File content/browser/security_exploit_browsertest.cc (right):

https://codereview.chromium.org/1270663002/diff/160001/content/browser/securi...
content/browser/security_exploit_browsertest.cc:352: bool
IsIllegalOrigin(content::ResourceContext* resource_context,
I wanted to test this in chrome/ with an actual app, but we aren't able to
create a ResourceHostMsg_Request IPC message outside content/.  Instead, I'm
simulating the embedder having an app system here.

https://codereview.chromium.org/1270663002/diff/160001/content/public/browser...
File content/public/browser/browser_message_filter.cc (right):

https://codereview.chromium.org/1270663002/diff/160001/content/public/browser...
content/public/browser/browser_message_filter.cc:193:
StopChildProcess(peer_process_.Handle());
I discussed this with Nick.  This is the approach used in
RenderProcessHostImpl::Shutdown, and it makes the Android try bots happy.

[nasko, 2015-08-14 22:14:43]

Overall looks good. Just a few minor nits and questions.

https://codereview.chromium.org/1270663002/diff/160001/chrome/browser/extensi...
File chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc
(right):

https://codereview.chromium.org/1270663002/diff/160001/chrome/browser/extensi...
chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc:189:
DCHECK_CURRENTLY_ON(BrowserThread::UI);
Thanks for adding this!

https://codereview.chromium.org/1270663002/diff/160001/content/browser/child_...
File content/browser/child_process_security_policy_impl.h (right):

https://codereview.chromium.org/1270663002/diff/160001/content/browser/child_...
content/browser/child_process_security_policy_impl.h:129: // Whether the process
is allowed to commit a page from the given URL. This is
nit: s/page/document/

https://codereview.chromium.org/1270663002/diff/160001/content/browser/child_...
content/browser/child_process_security_policy_impl.h:131: // that might lead to
cross-process navigations or ShellExecute (external to
nit: ShellExecute is a Windows specific API. This is related to external
protocol handlers, right? Why not state it that way, since it is already hinted
at in the parenthesized text?

https://codereview.chromium.org/1270663002/diff/160001/content/browser/child_...
File content/browser/child_process_security_policy_unittest.cc (right):

https://codereview.chromium.org/1270663002/diff/160001/content/browser/child_...
content/browser/child_process_security_policy_unittest.cc:202:
EXPECT_TRUE(p->CanCommitURL(kRendererID, GURL("about:BlAnK")));
Why not add a test case with capitalized letters in the "about" part?

https://codereview.chromium.org/1270663002/diff/160001/content/browser/loader...
File content/browser/loader/resource_dispatcher_host_impl.cc (right):

https://codereview.chromium.org/1270663002/diff/160001/content/browser/loader...
content/browser/loader/resource_dispatcher_host_impl.cc:304:
bad_message::ReceivedBadMessage(filter, bad_message::RDH_INVALID_ORIGIN);
nit: It will be good to be consistent in illegal vs invalid. It seems that the
bad_message constant is better off being RDH_ILLEGAL_ORIGIN, since illegal is a
superset of invalid.

https://codereview.chromium.org/1270663002/diff/160001/content/browser/securi...
File content/browser/security_exploit_browsertest.cc (right):

https://codereview.chromium.org/1270663002/diff/160001/content/browser/securi...
content/browser/security_exploit_browsertest.cc:115:
request.parent_render_frame_id = -1;
MSG_ROUTING_NONE?

https://codereview.chromium.org/1270663002/diff/160001/content/browser/securi...
content/browser/security_exploit_browsertest.cc:371: 
Shouldn't a test case exist for chrome-extension:// Origin header?

https://codereview.chromium.org/1270663002/diff/160001/content/public/browser...
File content/public/browser/content_browser_client.h (right):

https://codereview.chromium.org/1270663002/diff/160001/content/public/browser...
content/public/browser/content_browser_client.h:229: const GURL& origin);
Shouldn't we be using url::Origin if this is really an origin?

[Charlie Reis, 2015-08-14 23:23:32]

Thanks!

https://codereview.chromium.org/1270663002/diff/160001/chrome/browser/extensi...
File chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc
(right):

https://codereview.chromium.org/1270663002/diff/160001/chrome/browser/extensi...
chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc:189:
DCHECK_CURRENTLY_ON(BrowserThread::UI);
On 2015/08/14 22:14:42, nasko wrote:
> Thanks for adding this!

Acknowledged.

https://codereview.chromium.org/1270663002/diff/160001/content/browser/child_...
File content/browser/child_process_security_policy_impl.h (right):

https://codereview.chromium.org/1270663002/diff/160001/content/browser/child_...
content/browser/child_process_security_policy_impl.h:129: // Whether the process
is allowed to commit a page from the given URL. This is
On 2015/08/14 22:14:42, nasko wrote:
> nit: s/page/document/

Done.

https://codereview.chromium.org/1270663002/diff/160001/content/browser/child_...
content/browser/child_process_security_policy_impl.h:131: // that might lead to
cross-process navigations or ShellExecute (external to
On 2015/08/14 22:14:42, nasko wrote:
> nit: ShellExecute is a Windows specific API. This is related to external
> protocol handlers, right? Why not state it that way, since it is already
hinted
> at in the parenthesized text?

Done.

https://codereview.chromium.org/1270663002/diff/160001/content/browser/child_...
File content/browser/child_process_security_policy_unittest.cc (right):

https://codereview.chromium.org/1270663002/diff/160001/content/browser/child_...
content/browser/child_process_security_policy_unittest.cc:202:
EXPECT_TRUE(p->CanCommitURL(kRendererID, GURL("about:BlAnK")));
On 2015/08/14 22:14:43, nasko wrote:
> Why not add a test case with capitalized letters in the "about" part?

Done.

https://codereview.chromium.org/1270663002/diff/160001/content/browser/loader...
File content/browser/loader/resource_dispatcher_host_impl.cc (right):

https://codereview.chromium.org/1270663002/diff/160001/content/browser/loader...
content/browser/loader/resource_dispatcher_host_impl.cc:304:
bad_message::ReceivedBadMessage(filter, bad_message::RDH_INVALID_ORIGIN);
On 2015/08/14 22:14:43, nasko wrote:
> nit: It will be good to be consistent in illegal vs invalid. It seems that the
> bad_message constant is better off being RDH_ILLEGAL_ORIGIN, since illegal is
a
> superset of invalid.

Done.  (I was trying to be consistent with other constants in bad_message, but
there's not a strong reason to do that.)

https://codereview.chromium.org/1270663002/diff/160001/content/browser/securi...
File content/browser/security_exploit_browsertest.cc (right):

https://codereview.chromium.org/1270663002/diff/160001/content/browser/securi...
content/browser/security_exploit_browsertest.cc:115:
request.parent_render_frame_id = -1;
On 2015/08/14 22:14:43, nasko wrote:
> MSG_ROUTING_NONE?

The docs say to use -1:
https://code.google.com/p/chromium/codesearch#chromium/src/content/common/res...
(I got this from resource_dispatcher_host_unittest.cc.)

https://codereview.chromium.org/1270663002/diff/160001/content/browser/securi...
content/browser/security_exploit_browsertest.cc:371: 
On 2015/08/14 22:14:43, nasko wrote:
> Shouldn't a test case exist for chrome-extension:// Origin header?

Sadly I can't, since chrome-extension:// doesn't exist in content/ and this IPC
message can't be created outside content.  :(  See my CL comment above about
simulating it with the embedder_isolated_origin_msg.

https://codereview.chromium.org/1270663002/diff/160001/content/public/browser...
File content/public/browser/content_browser_client.h (right):

https://codereview.chromium.org/1270663002/diff/160001/content/public/browser...
content/public/browser/content_browser_client.h:229: const GURL& origin);
On 2015/08/14 22:14:43, nasko wrote:
> Shouldn't we be using url::Origin if this is really an origin?

I debated that, but the value starts as a string (from the HTTP header) and gets
consumed as a GURL (in GetExtensionOrAppByURL).  We would end up with several
non-trivial conversions: string -> GURL -> url::Origin -> GURL.

It may make sense to revisit this as url::Origin gets more widely used, but we
may just want to leave it for now.

[nasko, 2015-08-14 23:36:42]

LGTM

https://codereview.chromium.org/1270663002/diff/160001/content/browser/securi...
File content/browser/security_exploit_browsertest.cc (right):

https://codereview.chromium.org/1270663002/diff/160001/content/browser/securi...
content/browser/security_exploit_browsertest.cc:115:
request.parent_render_frame_id = -1;
On 2015/08/14 23:23:32, Charlie Reis wrote:
> On 2015/08/14 22:14:43, nasko wrote:
> > MSG_ROUTING_NONE?
> 
> The docs say to use -1:
>
https://code.google.com/p/chromium/codesearch#chromium/src/content/common/res...
> (I got this from resource_dispatcher_host_unittest.cc.)

Acknowledged.

https://codereview.chromium.org/1270663002/diff/160001/content/browser/securi...
content/browser/security_exploit_browsertest.cc:371: 
On 2015/08/14 23:23:32, Charlie Reis wrote:
> On 2015/08/14 22:14:43, nasko wrote:
> > Shouldn't a test case exist for chrome-extension:// Origin header?
> 
> Sadly I can't, since chrome-extension:// doesn't exist in content/ and this
IPC
> message can't be created outside content.  :(  See my CL comment above about
> simulating it with the embedder_isolated_origin_msg.

Might be useful to put that/similar comment in the test itself, so it is clear
why it isn't tested.

I also wonder if it is possible to just manufacture an IPC message that is
identical to ResourceHostMsg_RequestResource in the
chrome_security_exploit_browsertest.cc, but that will probably be more complex
and need to keep things in sync, so probably not worth doing.

https://codereview.chromium.org/1270663002/diff/160001/content/public/browser...
File content/public/browser/content_browser_client.h (right):

https://codereview.chromium.org/1270663002/diff/160001/content/public/browser...
content/public/browser/content_browser_client.h:229: const GURL& origin);
On 2015/08/14 23:23:32, Charlie Reis wrote:
> On 2015/08/14 22:14:43, nasko wrote:
> > Shouldn't we be using url::Origin if this is really an origin?
> 
> I debated that, but the value starts as a string (from the HTTP header) and
gets
> consumed as a GURL (in GetExtensionOrAppByURL).  We would end up with several
> non-trivial conversions: string -> GURL -> url::Origin -> GURL.
> 
> It may make sense to revisit this as url::Origin gets more widely used, but we
> may just want to leave it for now.

Acknowledged.

[Charlie Reis, 2015-08-17 18:32:21]

https://codereview.chromium.org/1270663002/diff/160001/content/browser/securi...
File content/browser/security_exploit_browsertest.cc (right):

https://codereview.chromium.org/1270663002/diff/160001/content/browser/securi...
content/browser/security_exploit_browsertest.cc:371: 
On 2015/08/14 23:36:41, nasko wrote:
> On 2015/08/14 23:23:32, Charlie Reis wrote:
> > On 2015/08/14 22:14:43, nasko wrote:
> > > Shouldn't a test case exist for chrome-extension:// Origin header?
> > 
> > Sadly I can't, since chrome-extension:// doesn't exist in content/ and this
> IPC
> > message can't be created outside content.  :(  See my CL comment above about
> > simulating it with the embedder_isolated_origin_msg.
> 
> Might be useful to put that/similar comment in the test itself, so it is clear
> why it isn't tested.

Done.

> 
> I also wonder if it is possible to just manufacture an IPC message that is
> identical to ResourceHostMsg_RequestResource in the
> chrome_security_exploit_browsertest.cc, but that will probably be more complex
> and need to keep things in sync, so probably not worth doing. 

Yeah, Nick and I had a long chat about this.  You could imagine exposing a
public test utility to manufacture certain IPCs outside content/, but that
wouldn't scale very well if we end up needing it for lots of IPCs.

[Charlie Reis, 2015-08-17 18:37:30]

creis@chromium.org changed reviewers:
+ isherman@chromium.org, kalman@chromium.org

[Charlie Reis, 2015-08-17 18:37:30]

@kalman: Can you review chrome_content_browser_client_extensions_part.* for
extension OWNERS?

@lfg: Can you review the webview guest logic in
chrome_content_browser_client_extensions_part.cc?

@isherman: Can you review histograms.xml?

https://codereview.chromium.org/1270663002/diff/200001/chrome/browser/extensi...
File chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc
(right):

https://codereview.chromium.org/1270663002/diff/200001/chrome/browser/extensi...
chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc:223:
// (If the extension was recently uninstalled, the tab would have closed.)
@kalman: Is this a safe assumption?  I'd like to kill renderer processes if they
claim to be making an XHR from a chrome-extension:// URL that isn't installed.

[Ilya Sherman, 2015-08-17 18:47:03]

histograms.xml lgtm

[lfg, 2015-08-17 19:01:54]

https://codereview.chromium.org/1270663002/diff/160001/chrome/browser/extensi...
File chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc
(right):

https://codereview.chromium.org/1270663002/diff/160001/chrome/browser/extensi...
chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc:232:
// itself, or by one if its guests if there are accessible_resources.
On 2015/08/14 20:25:59, Charlie Reis wrote:
> lfg@, can you review this part?  I'm allowing an app's origin for its guests
if
> the app has accessible resources.

lgtm.

[not at google - send to devlin, 2015-08-17 19:42:50]

https://codereview.chromium.org/1270663002/diff/200001/chrome/browser/extensi...
File chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc
(right):

https://codereview.chromium.org/1270663002/diff/200001/chrome/browser/extensi...
chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc:223:
// (If the extension was recently uninstalled, the tab would have closed.)
On 2015/08/17 18:37:30, Charlie Reis wrote:
> @kalman: Is this a safe assumption?  I'd like to kill renderer processes if
they
> claim to be making an XHR from a chrome-extension:// URL that isn't installed.

Modulo race conditions (content API != tabbed UI probably) yes this should be
fine... though I believe right now there is a bug where it can happen with
service workers (https://code.google.com/p/chromium/issues/detail?id=519326).

you also might want to double-check that XHR from content scripts don't get
checked here. I know that blink treats these as coming from the extension's
origin (and adds host permissions accordingly) but I don't know whether it
filters all the way up here.

if XHR is even affected by this.

https://codereview.chromium.org/1270663002/diff/200001/chrome/browser/extensi...
chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc:232:
// itself, or by one if its guests if there are accessible_resources.
TODO(creis): Remove the platform_app restriction once site isolation is in place
for all extensions.

?

in fact once site isolation is in place, the rest of this method can basically
be

return process_map.Contains(extension->id(), child_process_id);

?

https://codereview.chromium.org/1270663002/diff/200001/chrome/browser/extensi...
chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc:237:
// no accessible resources, this is illegal.
Platform apps shouldn't even have accessible resources:

https://code.google.com/p/chromium/codesearch#chromium/src/extensions/common/...

the exception being component platform apps - which means that the only way this
block will continue is if this platform app is a component platform app.

https://codereview.chromium.org/1270663002/diff/200001/chrome/browser/extensi...
chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc:238:
if (!extension->GetManifestData(manifest_keys::kWebviewAccessibleResources))
A better check is 
WebAccessibleResourcesInfo::HasWebAccessibleResources(extension).

https://codereview.chromium.org/1270663002/diff/200001/chrome/browser/extensi...
chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc:242:
// process is a guest of the app.
I don't follow this.

[Charlie Reis, 2015-08-17 19:49:59]

https://codereview.chromium.org/1270663002/diff/200001/chrome/browser/extensi...
File chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc
(right):

https://codereview.chromium.org/1270663002/diff/200001/chrome/browser/extensi...
chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc:223:
// (If the extension was recently uninstalled, the tab would have closed.)
On 2015/08/17 19:42:50, kalman wrote:
> On 2015/08/17 18:37:30, Charlie Reis wrote:
> > @kalman: Is this a safe assumption?  I'd like to kill renderer processes if
> they
> > claim to be making an XHR from a chrome-extension:// URL that isn't
installed.
> 
> Modulo race conditions (content API != tabbed UI probably) yes this should be
> fine... though I believe right now there is a bug where it can happen with
> service workers (https://code.google.com/p/chromium/issues/detail?id=519326).

Hmm, I'll check with Devlin about this.  Thanks.

> 
> you also might want to double-check that XHR from content scripts don't get
> checked here. I know that blink treats these as coming from the extension's
> origin (and adds host permissions accordingly) but I don't know whether it
> filters all the way up here.
> 

Whoa.  I did not realize that, though I don't think it should cause a problem. 
We only say it's illegal if the chrome-extension ID isn't installed or is a
platform app (which can't use content scripts).

> if XHR is even affected by this.

Yep, this is used for XHRs.

https://codereview.chromium.org/1270663002/diff/200001/chrome/browser/extensi...
chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc:232:
// itself, or by one if its guests if there are accessible_resources.
On 2015/08/17 19:42:50, kalman wrote:
> TODO(creis): Remove the platform_app restriction once site isolation is in
place
> for all extensions.
> 
> ?
> 
> in fact once site isolation is in place, the rest of this method can basically
> be
> 
> return process_map.Contains(extension->id(), child_process_id);
> 
> ?

I don't think this is true.

Platform apps have a different type of accessible resource that their guest
processes are allowed to request.  That's what the checks below are for (not web
accessible resources).

See "Accessing packaged resources" on
https://developer.chrome.com/apps/tags/webview.  (This is what I had lfg@
reviewing.)

[lfg, 2015-08-17 19:51:35]

https://codereview.chromium.org/1270663002/diff/200001/chrome/browser/extensi...
File chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc
(right):

https://codereview.chromium.org/1270663002/diff/200001/chrome/browser/extensi...
chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc:237:
// no accessible resources, this is illegal.
On 2015/08/17 19:42:50, kalman wrote:
> Platform apps shouldn't even have accessible resources:
> 
>
https://code.google.com/p/chromium/codesearch#chromium/src/extensions/common/...
> 
> the exception being component platform apps - which means that the only way
this
> block will continue is if this platform app is a component platform app.

The check is for webview-accessible resources (i.e. chrome-extension://
resources loaded inside a <webview> guest process).

[not at google - send to devlin, 2015-08-17 20:13:29]

https://codereview.chromium.org/1270663002/diff/200001/chrome/browser/extensi...
File chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc
(right):

https://codereview.chromium.org/1270663002/diff/200001/chrome/browser/extensi...
chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc:232:
// itself, or by one if its guests if there are accessible_resources.
On 2015/08/17 19:49:59, Charlie Reis wrote:
> On 2015/08/17 19:42:50, kalman wrote:
> > TODO(creis): Remove the platform_app restriction once site isolation is in
> place
> > for all extensions.
> > 
> > ?
> > 
> > in fact once site isolation is in place, the rest of this method can
basically
> > be
> > 
> > return process_map.Contains(extension->id(), child_process_id);
> > 
> > ?
> 
> I don't think this is true.
> 
> Platform apps have a different type of accessible resource that their guest
> processes are allowed to request.  That's what the checks below are for (not
web
> accessible resources).
> 
> See "Accessing packaged resources" on
> https://developer.chrome.com/apps/tags/webview.  (This is what I had lfg@
> reviewing.)

Got it. I did read "webview accessible resources" as "web accessible resources".
I may have also been reading this CL wrong - as though it were a check for
processes that are allow to host a resource, rather than a check for resources a
process is allowed to request.

https://codereview.chromium.org/1270663002/diff/200001/chrome/browser/extensi...
chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc:234:
if (extension->is_platform_app() &&
I would prefer a check for "does this extension have access to the webview API"
not "is this extension a platform app" because there are extensions which are
whitelisted for webview, and there are platform apps which don't have webviews.
Maybe you could tighten the condition a bit in that case?

[Charlie Reis, 2015-08-17 21:19:59]

https://codereview.chromium.org/1270663002/diff/200001/chrome/browser/extensi...
File chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc
(right):

https://codereview.chromium.org/1270663002/diff/200001/chrome/browser/extensi...
chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc:234:
if (extension->is_platform_app() &&
On 2015/08/17 20:13:28, kalman wrote:
> I would prefer a check for "does this extension have access to the webview
API"
> not "is this extension a platform app" because there are extensions which are
> whitelisted for webview, and there are platform apps which don't have
webviews.
> Maybe you could tighten the condition a bit in that case?

Actually, platform apps are exactly what I'm trying to validate (for
https://crbug.com/513502).  Ideally, this check would catch any non-platform-app
process that claims to be making an XHR from a platform app.  Such a check would
imply that any XHR Origin header with a platform app's origin is actually being
made by the app and not by a compromised renderer process (which is the goal).

I had to add the exception for webview accessible resources because those can be
made from non-platform-app processes.  That weakens the security guarantee
slightly for platform apps with webviews and webview accessible resources, but
it's the best we can do. 

(In contrast, this logic is not trying to do any validation for general
extensions, whether they have webviews or not.)

[not at google - send to devlin, 2015-08-17 21:46:24]

ok, lgtm

[Charlie Reis, 2015-08-17 22:44:48]

The CQ bit was checked by creis@chromium.org

[Charlie Reis, 2015-08-17 22:44:49]

The patchset sent to the CQ was uploaded after l-g-t-m from nasko@chromium.org
Link to the patchset: https://codereview.chromium.org/1270663002/#ps200001
(title: "Update comment")

[commit-bot: I haz the power, 2015-08-17 22:45:15]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1270663002/200001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1270663002/200001

[commit-bot: I haz the power, 2015-08-18 00:12:25]

Committed patchset #10 (id:200001)

[commit-bot: I haz the power, 2015-08-18 00:13:07]

Patchset 10 (id:??) landed as
https://crrev.com/3710b238717b14967922263070cac76257a55ac5
Cr-Commit-Position: refs/heads/master@{#343778}