Add Rappor metrics for Safe Browsing and SSL interstitials.

Add Rappor metrics for Safe Browsing and SSL interstitials.  This reports the eTLD+1 of URL.  Later we'll add click-through and history state.

BUG=451646
Committed: https://crrev.com/07334abebc0cb4ff38c8a95aff30215dd7202ab8
Cr-Commit-Position: refs/heads/master@{#314596}

[Nathan Parker, 2015-01-28 16:37:03]

nparker@chromium.org changed reviewers:
+ asvitkine@chromium.org, felt@chromium.org, mattm@chromium.org

[Nathan Parker, 2015-01-28 16:37:03]

nparker@chromium.org changed required reviewers:
+ asvitkine@chromium.org, felt@chromium.org, mattm@chromium.org

[Nathan Parker, 2015-01-28 16:38:39]

If this approach looks reasonable, I'll rename s/uma_helper/metrics_helper/g in
this CL.

[Alexei Svitkine (slow), 2015-01-28 16:41:48]

asvitkine@chromium.org changed reviewers:
+ holte@chromium.org

[Alexei Svitkine (slow), 2015-01-28 16:41:48]

asvitkine@chromium.org changed required reviewers:
+ holte@chromium.org

[Alexei Svitkine (slow), 2015-01-28 16:41:49]

+holte

[Steven Holte, 2015-01-28 18:45:38]

The approach looks fine to me.

[felt, 2015-01-28 19:19:17]

https://codereview.chromium.org/872813003/diff/1/chrome/browser/interstitials...
File chrome/browser/interstitials/security_interstitial_uma_helper.cc (right):

https://codereview.chromium.org/872813003/diff/1/chrome/browser/interstitials...
chrome/browser/interstitials/security_interstitial_uma_helper.cc:67: if
(decision == SHOW) {
nit: can you make this a single if-statement until the TODO below is resolved,
at which point you can add a switch statement?

https://codereview.chromium.org/872813003/diff/1/chrome/browser/interstitials...
chrome/browser/interstitials/security_interstitial_uma_helper.cc:75:
"Interstitial." + rappor_prefix_ + ".Domain";
Do we really need to have both uma_prefix and rappor_prefix?

The way uma is put together is by concatenating "interstitial." + "phishing".
Couldn't you just use the same here?

https://codereview.chromium.org/872813003/diff/1/chrome/browser/interstitials...
File chrome/browser/interstitials/security_interstitial_uma_helper.h (right):

https://codereview.chromium.org/872813003/diff/1/chrome/browser/interstitials...
chrome/browser/interstitials/security_interstitial_uma_helper.h:50: //   url:
Full URL of page that triggered the interstitial
Does it matter whether it's the full URL or just the origin?

[Nathan Parker, 2015-01-29 01:36:02]

PTAL.  I can simplify the prefix code as described (toupper(..)), let me know if
you prefer that.

https://codereview.chromium.org/872813003/diff/1/chrome/browser/interstitials...
File chrome/browser/interstitials/security_interstitial_uma_helper.cc (right):

https://codereview.chromium.org/872813003/diff/1/chrome/browser/interstitials...
chrome/browser/interstitials/security_interstitial_uma_helper.cc:67: if
(decision == SHOW) {
On 2015/01/28 19:19:17, felt wrote:
> nit: can you make this a single if-statement until the TODO below is resolved,
> at which point you can add a switch statement?

Done.

https://codereview.chromium.org/872813003/diff/1/chrome/browser/interstitials...
chrome/browser/interstitials/security_interstitial_uma_helper.cc:75:
"Interstitial." + rappor_prefix_ + ".Domain";
On 2015/01/28 19:19:17, felt wrote:
> Do we really need to have both uma_prefix and rappor_prefix?
> 
> The way uma is put together is by concatenating "interstitial." + "phishing".
> Couldn't you just use the same here?

Unfortunately they have different capitalization.  We could toupper(prefix[0]),
but  that wouldn't properly camel-case any future prefixes w/ multiple words. 
I'm ok with punting on that problem for now if you like, to simplify the code.

https://codereview.chromium.org/872813003/diff/1/chrome/browser/interstitials...
File chrome/browser/interstitials/security_interstitial_uma_helper.h (right):

https://codereview.chromium.org/872813003/diff/1/chrome/browser/interstitials...
chrome/browser/interstitials/security_interstitial_uma_helper.h:50: //   url:
Full URL of page that triggered the interstitial
On 2015/01/28 19:19:17, felt wrote:
> Does it matter whether it's the full URL or just the origin?

Not currently, no, but I'd rather this code decide how to segment it.  That way
we could choose to start reporting the first path entry as well, w/o modifying
the callers.

Updated to make that more clear.

[Steven Holte, 2015-01-29 02:46:12]

https://codereview.chromium.org/872813003/diff/1/chrome/browser/interstitials...
File chrome/browser/interstitials/security_interstitial_uma_helper.cc (right):

https://codereview.chromium.org/872813003/diff/1/chrome/browser/interstitials...
chrome/browser/interstitials/security_interstitial_uma_helper.cc:75:
"Interstitial." + rappor_prefix_ + ".Domain";
On 2015/01/29 01:36:02, nparker wrote:
> On 2015/01/28 19:19:17, felt wrote:
> > Do we really need to have both uma_prefix and rappor_prefix?
> > 
> > The way uma is put together is by concatenating "interstitial." +
"phishing".
> > Couldn't you just use the same here?
> 
> Unfortunately they have different capitalization.  We could
toupper(prefix[0]),
> but  that wouldn't properly camel-case any future prefixes w/ multiple words. 
> I'm ok with punting on that problem for now if you like, to simplify the code.

I would lean towards being consistent with the related histograms over being
consistent with other Rappor metrics.

[felt, 2015-01-29 06:18:36]

https://codereview.chromium.org/872813003/diff/1/chrome/browser/interstitials...
File chrome/browser/interstitials/security_interstitial_uma_helper.h (right):

https://codereview.chromium.org/872813003/diff/1/chrome/browser/interstitials...
chrome/browser/interstitials/security_interstitial_uma_helper.h:50: //   url:
Full URL of page that triggered the interstitial
On 2015/01/29 01:36:02, nparker wrote:
> On 2015/01/28 19:19:17, felt wrote:
> > Does it matter whether it's the full URL or just the origin?
> 
> Not currently, no, but I'd rather this code decide how to segment it.  That
way
> we could choose to start reporting the first path entry as well, w/o modifying
> the callers.
> 
> Updated to make that more clear.

The history manager lookup only works on a per-origin basis, so when you get
history callbacks it will only be useful for an origin. So be careful here, you
don't want to end up comparing hostnames to origins later.

[Nathan Parker, 2015-01-30 00:39:51]

PTAL.  I adjusted the naming, and added SSL reporting.

https://codereview.chromium.org/872813003/diff/1/chrome/browser/interstitials...
File chrome/browser/interstitials/security_interstitial_uma_helper.cc (right):

https://codereview.chromium.org/872813003/diff/1/chrome/browser/interstitials...
chrome/browser/interstitials/security_interstitial_uma_helper.cc:75:
"Interstitial." + rappor_prefix_ + ".Domain";
On 2015/01/29 02:46:12, Steven Holte wrote:
> On 2015/01/29 01:36:02, nparker wrote:
> > On 2015/01/28 19:19:17, felt wrote:
> > > Do we really need to have both uma_prefix and rappor_prefix?
> > > 
> > > The way uma is put together is by concatenating "interstitial." +
> "phishing".
> > > Couldn't you just use the same here?
> > 
> > Unfortunately they have different capitalization.  We could
> toupper(prefix[0]),
> > but  that wouldn't properly camel-case any future prefixes w/ multiple
words. 
> > I'm ok with punting on that problem for now if you like, to simplify the
code.
> 
> I would lean towards being consistent with the related histograms over being
> consistent with other Rappor metrics.

In that case I'll user lowercase for both.  I'll update it in rappor.xml as
well.

Talking with felt@ and lgarron@, we agreed that SSL interstitials would be very
useful as well (e.g. if we see spike on dropbox.com, that's info we and they
don't have now).  I enabled that in this CL, and it additionaly requires
separating UMA/Rappor prefixes since we don't want Rappor metrics named
"ssl_overridable" and "ssl_nonoverridable" (that'd leak info).  So we can't keep
UMA and Rappor namespaces identical, but they're close.

https://codereview.chromium.org/872813003/diff/1/chrome/browser/interstitials...
File chrome/browser/interstitials/security_interstitial_uma_helper.h (right):

https://codereview.chromium.org/872813003/diff/1/chrome/browser/interstitials...
chrome/browser/interstitials/security_interstitial_uma_helper.h:50: //   url:
Full URL of page that triggered the interstitial
On 2015/01/29 06:18:36, felt wrote:
> On 2015/01/29 01:36:02, nparker wrote:
> > On 2015/01/28 19:19:17, felt wrote:
> > > Does it matter whether it's the full URL or just the origin?
> > 
> > Not currently, no, but I'd rather this code decide how to segment it.  That
> way
> > we could choose to start reporting the first path entry as well, w/o
modifying
> > the callers.
> > 
> > Updated to make that more clear.
> 
> The history manager lookup only works on a per-origin basis, so when you get
> history callbacks it will only be useful for an origin. So be careful here,
you
> don't want to end up comparing hostnames to origins later.

Ah, interesting point.  So to accurately report (later) the isInHistory+site
tuple, we'll need to either make a history lookup on eTLD+1 ("Is this eTLD+1 in
my history?"), or report the full origin via Rappor.  The latter would be
potentially a large space for Rappor to match against (scheme + port + full
host), and we'd lose sight of any domains that are generating many unique
subdomains.  I'll go with eTLD+1, and add a way to (at least approximately)
determine if that matches the history.

[Alexei Svitkine (slow), 2015-02-02 20:31:26]

lgtm

https://codereview.chromium.org/872813003/diff/60001/chrome/browser/ssl/ssl_b...
File chrome/browser/ssl/ssl_blocking_page.cc (right):

https://codereview.chromium.org/872813003/diff/60001/chrome/browser/ssl/ssl_b...
chrome/browser/ssl/ssl_blocking_page.cc:240: (interstitial_reason_ ==
SSL_REASON_BAD_CLOCK ? "" : "ssl");
Nit: "" -> std::string()

[Nathan Parker, 2015-02-02 21:51:18]

Fixed.  felt, mattm, and holte, any further comments?

https://codereview.chromium.org/872813003/diff/60001/chrome/browser/ssl/ssl_b...
File chrome/browser/ssl/ssl_blocking_page.cc (right):

https://codereview.chromium.org/872813003/diff/60001/chrome/browser/ssl/ssl_b...
chrome/browser/ssl/ssl_blocking_page.cc:240: (interstitial_reason_ ==
SSL_REASON_BAD_CLOCK ? "" : "ssl");
On 2015/02/02 20:31:25, asvitkine (slow this week) wrote:
> Nit: "" -> std::string()

Done.

[mattm, 2015-02-02 23:12:48]

lgtm

[Nathan Parker, 2015-02-02 23:59:20]

The CQ bit was checked by nparker@chromium.org

[commit-bot: I haz the power, 2015-02-03 00:00:33]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/872813003/100001

[commit-bot: I haz the power, 2015-02-03 00:00:35]

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

[commit-bot: I haz the power, 2015-02-03 00:00:36]

All required reviewers (with asterisk prefixes) have not yet approved this CL.

No LGTM from a valid reviewer yet. Only full committers are accepted.
Even if an LGTM may have been provided, it was from a non-committer,
_not_ a full super star committer.
See http://www.chromium.org/getting-involved/become-a-committer
Note that this has nothing to do with OWNERS files.

[Nathan Parker, 2015-02-03 00:05:20]

nparker@chromium.org changed required reviewers:
- holte@chromium.org

[Steven Holte, 2015-02-03 01:28:56]

lgtm

[Steven Holte, 2015-02-03 01:28:57]

lgtm

[felt, 2015-02-03 07:28:04]

Sorry for the delay.

https://codereview.chromium.org/872813003/diff/100001/chrome/browser/intersti...
File chrome/browser/interstitials/security_interstitial_metrics_helper.h
(right):

https://codereview.chromium.org/872813003/diff/100001/chrome/browser/intersti...
chrome/browser/interstitials/security_interstitial_metrics_helper.h:53: //      
        examples: "phishing", "ssl"
I'm a little uncomfortable about using a string status to determine whether
Rappor should be recorded or not. It feels brittle and like someone might get
this call wrong in the future by copying call sites and just putting the same
string in twice. Would it be a problem if we accidentally recorded Rappor
metrics for something we didn't mean to?

[Alexei Svitkine (slow), 2015-02-03 14:58:25]

https://codereview.chromium.org/872813003/diff/100001/chrome/browser/intersti...
File chrome/browser/interstitials/security_interstitial_metrics_helper.h
(right):

https://codereview.chromium.org/872813003/diff/100001/chrome/browser/intersti...
chrome/browser/interstitials/security_interstitial_metrics_helper.h:53: //      
        examples: "phishing", "ssl"
On 2015/02/03 07:28:04, felt wrote:
> I'm a little uncomfortable about using a string status to determine whether
> Rappor should be recorded or not. It feels brittle and like someone might get
> this call wrong in the future by copying call sites and just putting the same
> string in twice. Would it be a problem if we accidentally recorded Rappor
> metrics for something we didn't mean to?

Actually that's a good point.

If the prefixes will always be the same except in cases where we want to not log
RAPPOR, then I would prefer that there's a single prefix param and an enum that
specifies whether RAPPOR should be logged or not.

[Nathan Parker, 2015-02-03 21:01:01]

Updated per comments, and one additional mod:

I decided we shouldn't report on SHOW, since once we have grouping of Rappor
metrics we'll want the tuple [domain, inHistory, didClickThrough] reported only
on PROCEED or DONT_PROCEED.  The stream sampling won't work properly if we
report [domain] sometimes and the 3-tuple sometimes in the same client.  So I
fixed it.

PTAL

https://codereview.chromium.org/872813003/diff/100001/chrome/browser/intersti...
File chrome/browser/interstitials/security_interstitial_metrics_helper.h
(right):

https://codereview.chromium.org/872813003/diff/100001/chrome/browser/intersti...
chrome/browser/interstitials/security_interstitial_metrics_helper.h:53: //      
        examples: "phishing", "ssl"
On 2015/02/03 14:58:25, asvitkine (slow this week) wrote:
> On 2015/02/03 07:28:04, felt wrote:
> > I'm a little uncomfortable about using a string status to determine whether
> > Rappor should be recorded or not. It feels brittle and like someone might
get
> > this call wrong in the future by copying call sites and just putting the
same
> > string in twice. Would it be a problem if we accidentally recorded Rappor
> > metrics for something we didn't mean to?
> 
> Actually that's a good point.
> 
> If the prefixes will always be the same except in cases where we want to not
log
> RAPPOR, then I would prefer that there's a single prefix param and an enum
that
> specifies whether RAPPOR should be logged or not.

Sounds good.  I've made it far more explicit.

https://codereview.chromium.org/872813003/diff/100001/chrome/browser/intersti...
chrome/browser/interstitials/security_interstitial_metrics_helper.h:53: //      
        examples: "phishing", "ssl"
On 2015/02/03 07:28:04, felt wrote:
> I'm a little uncomfortable about using a string status to determine whether
> Rappor should be recorded or not. It feels brittle and like someone might get
> this call wrong in the future by copying call sites and just putting the same
> string in twice. Would it be a problem if we accidentally recorded Rappor
> metrics for something we didn't mean to?

That would just muddle the reports in this case (report domains that aren't
related to the problem).

[Alexei Svitkine (slow), 2015-02-03 22:04:03]

I would still prefer a separate enum param to specify whether RAPPOR should
be reported - with the same prefix string being used for both.

On Tue, Feb 3, 2015 at 4:01 PM, <nparker@chromium.org> wrote:

> Updated per comments, and one additional mod:
>
> I decided we shouldn't report on SHOW, since once we have grouping of
> Rappor
> metrics we'll want the tuple [domain, inHistory, didClickThrough] reported
> only
> on PROCEED or DONT_PROCEED.  The stream sampling won't work properly if we
> report [domain] sometimes and the 3-tuple sometimes in the same client.
> So I
> fixed it.
>
> PTAL
>
>
> https://codereview.chromium.org/872813003/diff/100001/
> chrome/browser/interstitials/security_interstitial_metrics_helper.h
> File chrome/browser/interstitials/security_interstitial_metrics_helper.h
> (right):
>
> https://codereview.chromium.org/872813003/diff/100001/
> chrome/browser/interstitials/security_interstitial_metrics_
> helper.h#newcode53
> chrome/browser/interstitials/security_interstitial_metrics_helper.h:53:
> //               examples: "phishing", "ssl"
> On 2015/02/03 14:58:25, asvitkine (slow this week) wrote:
>
>> On 2015/02/03 07:28:04, felt wrote:
>> > I'm a little uncomfortable about using a string status to determine
>>
> whether
>
>> > Rappor should be recorded or not. It feels brittle and like someone
>>
> might get
>
>> > this call wrong in the future by copying call sites and just putting
>>
> the same
>
>> > string in twice. Would it be a problem if we accidentally recorded
>>
> Rappor
>
>> > metrics for something we didn't mean to?
>>
>
>  Actually that's a good point.
>>
>
>  If the prefixes will always be the same except in cases where we want
>>
> to not log
>
>> RAPPOR, then I would prefer that there's a single prefix param and an
>>
> enum that
>
>> specifies whether RAPPOR should be logged or not.
>>
>
> Sounds good.  I've made it far more explicit.
>
> https://codereview.chromium.org/872813003/diff/100001/
> chrome/browser/interstitials/security_interstitial_metrics_
> helper.h#newcode53
> chrome/browser/interstitials/security_interstitial_metrics_helper.h:53:
> //               examples: "phishing", "ssl"
> On 2015/02/03 07:28:04, felt wrote:
>
>> I'm a little uncomfortable about using a string status to determine
>>
> whether
>
>> Rappor should be recorded or not. It feels brittle and like someone
>>
> might get
>
>> this call wrong in the future by copying call sites and just putting
>>
> the same
>
>> string in twice. Would it be a problem if we accidentally recorded
>>
> Rappor
>
>> metrics for something we didn't mean to?
>>
>
> That would just muddle the reports in this case (report domains that
> aren't related to the problem).
>
> https://codereview.chromium.org/872813003/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[chromium-reviews, 2015-02-03 22:14:48]

Unfortunately we need the UMA and Rappor prefixes to differ for SSL.
Existing UMA prefixes are "ssl_overriable" and "ssl_notoverridable."  If we
named the Rappor prefix with those, we'd be leaking to Rappor the fact that
a user visited a HSTS-protected site (which makes it easy to guess the
domain).  So we need the option for the prefixes to be different OR the
same.

On Tue, Feb 3, 2015 at 2:03 PM, Alexei Svitkine <asvitkine@chromium.org>
wrote:

> I would still prefer a separate enum param to specify whether RAPPOR
> should be reported - with the same prefix string being used for both.
>
> On Tue, Feb 3, 2015 at 4:01 PM, <nparker@chromium.org> wrote:
>
>> Updated per comments, and one additional mod:
>>
>> I decided we shouldn't report on SHOW, since once we have grouping of
>> Rappor
>> metrics we'll want the tuple [domain, inHistory, didClickThrough]
>> reported only
>> on PROCEED or DONT_PROCEED.  The stream sampling won't work properly if we
>> report [domain] sometimes and the 3-tuple sometimes in the same client.
>> So I
>> fixed it.
>>
>> PTAL
>>
>>
>> https://codereview.chromium.org/872813003/diff/100001/
>> chrome/browser/interstitials/security_interstitial_metrics_helper.h
>> File chrome/browser/interstitials/security_interstitial_metrics_helper.h
>> (right):
>>
>> https://codereview.chromium.org/872813003/diff/100001/
>> chrome/browser/interstitials/security_interstitial_metrics_
>> helper.h#newcode53
>> chrome/browser/interstitials/security_interstitial_metrics_helper.h:53:
>> //               examples: "phishing", "ssl"
>> On 2015/02/03 14:58:25, asvitkine (slow this week) wrote:
>>
>>> On 2015/02/03 07:28:04, felt wrote:
>>> > I'm a little uncomfortable about using a string status to determine
>>>
>> whether
>>
>>> > Rappor should be recorded or not. It feels brittle and like someone
>>>
>> might get
>>
>>> > this call wrong in the future by copying call sites and just putting
>>>
>> the same
>>
>>> > string in twice. Would it be a problem if we accidentally recorded
>>>
>> Rappor
>>
>>> > metrics for something we didn't mean to?
>>>
>>
>>  Actually that's a good point.
>>>
>>
>>  If the prefixes will always be the same except in cases where we want
>>>
>> to not log
>>
>>> RAPPOR, then I would prefer that there's a single prefix param and an
>>>
>> enum that
>>
>>> specifies whether RAPPOR should be logged or not.
>>>
>>
>> Sounds good.  I've made it far more explicit.
>>
>> https://codereview.chromium.org/872813003/diff/100001/
>> chrome/browser/interstitials/security_interstitial_metrics_
>> helper.h#newcode53
>> chrome/browser/interstitials/security_interstitial_metrics_helper.h:53:
>> //               examples: "phishing", "ssl"
>> On 2015/02/03 07:28:04, felt wrote:
>>
>>> I'm a little uncomfortable about using a string status to determine
>>>
>> whether
>>
>>> Rappor should be recorded or not. It feels brittle and like someone
>>>
>> might get
>>
>>> this call wrong in the future by copying call sites and just putting
>>>
>> the same
>>
>>> string in twice. Would it be a problem if we accidentally recorded
>>>
>> Rappor
>>
>>> metrics for something we didn't mean to?
>>>
>>
>> That would just muddle the reports in this case (report domains that
>> aren't related to the problem).
>>
>> https://codereview.chromium.org/872813003/
>>
>
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Alexei Svitkine (slow), 2015-02-03 22:17:27]

Ok, fair enough. Then re-LGTM.

[mattm, 2015-02-03 22:25:54]

https://codereview.chromium.org/872813003/diff/120001/chrome/browser/intersti...
File chrome/browser/interstitials/security_interstitial_metrics_helper.h
(right):

https://codereview.chromium.org/872813003/diff/120001/chrome/browser/intersti...
chrome/browser/interstitials/security_interstitial_metrics_helper.h:51:
MAX_RAPPOR_REPORTING
nit: max value isn't needed for this enum

[Nathan Parker, 2015-02-03 22:42:20]

New patchsets have been uploaded after l-g-t-m from asvitkine@chromium.org

[Nathan Parker, 2015-02-03 22:43:03]

Thank you for the reviews. Committing.

https://codereview.chromium.org/872813003/diff/120001/chrome/browser/intersti...
File chrome/browser/interstitials/security_interstitial_metrics_helper.h
(right):

https://codereview.chromium.org/872813003/diff/120001/chrome/browser/intersti...
chrome/browser/interstitials/security_interstitial_metrics_helper.h:51:
MAX_RAPPOR_REPORTING
On 2015/02/03 22:25:54, mattm wrote:
> nit: max value isn't needed for this enum

Done.

[Nathan Parker, 2015-02-03 22:43:10]

The CQ bit was checked by nparker@chromium.org

[Nathan Parker, 2015-02-03 22:44:32]

The CQ bit was unchecked by nparker@chromium.org

[commit-bot: I haz the power, 2015-02-03 22:44:33]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/872813003/140001

[commit-bot: I haz the power, 2015-02-03 22:44:37]

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

[commit-bot: I haz the power, 2015-02-03 22:44:38]

All required reviewers (with asterisk prefixes) have not yet approved this CL.

No LGTM from a valid reviewer yet. Only full committers are accepted.
Even if an LGTM may have been provided, it was from a non-committer,
_not_ a full super star committer.
See http://www.chromium.org/getting-involved/become-a-committer
Note that this has nothing to do with OWNERS files.

[Nathan Parker, 2015-02-03 22:44:59]

Oops, still missing LGTM from felt@

[felt, 2015-02-04 08:56:37]

lgtm

[Nathan Parker, 2015-02-04 17:11:49]

The CQ bit was checked by nparker@chromium.org

[commit-bot: I haz the power, 2015-02-04 17:12:23]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/872813003/140001

[commit-bot: I haz the power, 2015-02-04 18:03:30]

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

[commit-bot: I haz the power, 2015-02-04 18:03:31]

Try jobs failed on following builders:
  android_dbg_tests_recipe on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_dbg_tes...)

[Nathan Parker, 2015-02-04 18:15:57]

The CQ bit was checked by nparker@chromium.org

[commit-bot: I haz the power, 2015-02-04 18:16:32]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/872813003/140001

[commit-bot: I haz the power, 2015-02-04 18:48:04]

Committed patchset #8 (id:140001)

[commit-bot: I haz the power, 2015-02-04 18:49:59]

Patchset 8 (id:??) landed as
https://crrev.com/07334abebc0cb4ff38c8a95aff30215dd7202ab8
Cr-Commit-Position: refs/heads/master@{#314596}