Add new SecurityLevel for Http Bad state

Add new SecurityLevel for Http Bad state

This adds a new SecurityLevel, HTTP_SHOW_WARNING, for Http-Bad states.

At this point in time, HTTP_SHOW_WARNING is never set, nor is it
consumed anywhere. You should ONLY make use of it behind the HttpBad
flag. I'm adding it separately in a small CL since it's a dependency
for several of our other tasks.

BUG=647558
Committed: https://crrev.com/0e7efe19fc0d0eb8454ff0cc6e6962aa50d72cdc
Cr-Commit-Position: refs/heads/master@{#419640}

[felt, 2016-09-16 18:40:23]

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

[commit-bot: I haz the power, 2016-09-16 18:41:08]

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

[felt, 2016-09-16 18:53:14]

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

[commit-bot: I haz the power, 2016-09-16 18:53:42]

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

[felt, 2016-09-16 18:53:44]

Description was changed from

==========
Add new SecurityLevel for Http Bad state

This adds a new SecurityLevel, HTTP_WARNING, for Http-Bad states.

At this point in time, the SecurityLevel is never set, nor is it
consumed anywhere. You should ONLY make use of it behind the HttpBad
flag. I'm adding it separately in a small CL since it's a dependency
for several of our other tasks.

BUG=647558
==========

to

==========
Add new SecurityLevel for Http Bad state

This adds a new SecurityLevel, HTTP_WARNING, for Http-Bad states.

At this point in time, HTTP_WARNING is never set, nor is it
consumed anywhere. You should ONLY make use of it behind the HttpBad
flag. I'm adding it separately in a small CL since it's a dependency
for several of our other tasks.

BUG=647558
==========

[commit-bot: I haz the power, 2016-09-16 19:48:27]

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

[commit-bot: I haz the power, 2016-09-16 19:48:28]

Dry run: This issue passed the CQ dry run.

[felt, 2016-09-16 20:12:11]

felt@chromium.org changed reviewers:
+ estark@chromium.org

[felt, 2016-09-16 20:14:17]

felt@chromium.org changed reviewers:
+ lgarron@chromium.org

[felt, 2016-09-16 20:14:18]

estark, ptal?

-- this is meant to be a small CL so that we can tackle various things (UI
changes, populating the SSLStatus, etc.) that depend on it in parallel

-- I had a hard time trying to decide on what the name for the new level should
be, how do you feel about HTTP_WARNING? (cc'ing lgarron in case he has an
opinion too)

[lgarron, 2016-09-16 20:18:24]

WARNING used to mean something else, and still does (see
https://crrev.com/2329153002).

What exactly does it mean. Does it get used for for "verbose HTTP ⓘ" and
"verbose HTTP ▲" depending on a flag?

[felt, 2016-09-16 20:19:58]

On 2016/09/16 20:18:24, lgarron wrote:
> WARNING used to mean something else, and still does (see
> https://crrev.com/2329153002).

This one is named HTTP_WARNING to distinguish it from SECURITY_WARNING. Do you
think the names are too similar?

> 
> What exactly does it mean. Does it get used for for "verbose HTTP ⓘ" and
> "verbose HTTP ▲" depending on a flag?

It gets used for "verbose HTTP ⓘ" if the flag is set.

[estark, 2016-09-16 20:22:29]

lgtm

HTTP_WARNING seems fine to me... I can't think of anything better.

But I think you might also want to update getSecurityIconResource in
LocationBarLayout.java
(https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chr...)

[felt, 2016-09-16 22:49:46]

lgarron, are you satisfied or still think i should change it?

[lgarron, 2016-09-16 22:52:49]

On 2016/09/16 at 22:49:46, felt wrote:
> lgarron, are you satisfied or still think i should change it?

I guess I don't have any better ideas. :-/
Go ahead then. :-)

[felt, 2016-09-16 23:00:11]

felt@chromium.org changed reviewers:
+ pkasting@chromium.org, tedchoc@chromium.org

[felt, 2016-09-16 23:00:53]

pkasting, ptal at components/toolbar/
tedchoc, ptal at chrome/android/java/src/org/chromium/chrome/browser/omnibox/

thx

[Peter Kasting, 2016-09-19 18:38:22]

LGTM

https://codereview.chromium.org/2346063002/diff/40001/components/security_sta...
File components/security_state/security_state_model.h (right):

https://codereview.chromium.org/2346063002/diff/40001/components/security_sta...
components/security_state/security_state_model.h:43: // switches::kMarkHttpAs
flag! (https://crbug.com/647754)
Nit: Does this caution really belong here?  I'm worried about it getting left in
forever, and I'm wondering if its inclusion now really buys us much.  The
consequences for misuse are low (stuff doesn't work like you wanted) and the
people likely to misuse this are we folks implementing this stuff who know what
we're doing (this isn't broadly consumed).

https://codereview.chromium.org/2346063002/diff/40001/components/security_sta...
components/security_state/security_state_model.h:46: HTTP_WARNING,
Hmm.  These names seem worrisome, especially since "SECURITY_WARNING"
technically applies to all three "warnings about security".  Trying to think of
better ones.

HTTP_WARNING -> INSECURE_HTTP (to match the warning text more closely?)

SECURITY_WARNING -> OUTDATED_PROTOCOL (to match the comment there?  Or is this
used in other cases)?

SECURITY_POLICY_WARNING -> LOCAL_CERTIFICATE (same rationale)

[felt, 2016-09-19 18:54:09]

https://codereview.chromium.org/2346063002/diff/40001/components/security_sta...
File components/security_state/security_state_model.h (right):

https://codereview.chromium.org/2346063002/diff/40001/components/security_sta...
components/security_state/security_state_model.h:43: // switches::kMarkHttpAs
flag! (https://crbug.com/647754)
On 2016/09/19 18:38:21, Peter Kasting wrote:
> Nit: Does this caution really belong here?  I'm worried about it getting left
in
> forever, and I'm wondering if its inclusion now really buys us much.  The
> consequences for misuse are low (stuff doesn't work like you wanted) and the
> people likely to misuse this are we folks implementing this stuff who know
what
> we're doing (this isn't broadly consumed).

I'm afraid of someone randomly seeing it and trying to (mis)use it. What do you
think of that concern?

https://codereview.chromium.org/2346063002/diff/40001/components/security_sta...
components/security_state/security_state_model.h:46: HTTP_WARNING,
On 2016/09/19 18:38:21, Peter Kasting wrote:
> Hmm.  These names seem worrisome, especially since "SECURITY_WARNING"
> technically applies to all three "warnings about security".  Trying to think
of
> better ones.
> 
> HTTP_WARNING -> INSECURE_HTTP (to match the warning text more closely?)
> 
> SECURITY_WARNING -> OUTDATED_PROTOCOL (to match the comment there?  Or is this
> used in other cases)?
> 
> SECURITY_POLICY_WARNING -> LOCAL_CERTIFICATE (same rationale)

SECURITY_WARNING is being deprecated in another CL by lgarron. Given that, are
you still concerned?

[Peter Kasting, 2016-09-19 18:58:30]

https://codereview.chromium.org/2346063002/diff/40001/components/security_sta...
File components/security_state/security_state_model.h (right):

https://codereview.chromium.org/2346063002/diff/40001/components/security_sta...
components/security_state/security_state_model.h:43: // switches::kMarkHttpAs
flag! (https://crbug.com/647754)
On 2016/09/19 18:54:09, felt wrote:
> On 2016/09/19 18:38:21, Peter Kasting wrote:
> > Nit: Does this caution really belong here?  I'm worried about it getting
left
> in
> > forever, and I'm wondering if its inclusion now really buys us much.  The
> > consequences for misuse are low (stuff doesn't work like you wanted) and the
> > people likely to misuse this are we folks implementing this stuff who know
> what
> > we're doing (this isn't broadly consumed).
> 
> I'm afraid of someone randomly seeing it and trying to (mis)use it. What do
you
> think of that concern?

Why would someone randomly see it?  In what sort of way would they misuse it?

I'm not opposed to making misuse more difficult, but I'd like to understand the
nature of the theoretical misuse so we can figure out the best way to prevent
it.  I mean, maybe we need to tell people more about what this enum value means,
or how it should be displayed, or something, rather than just slapping a vague
warning on it.  Maybe the current warning just makes people guard their misuse
with a mis-check of this switch?

I would remove it if you don't have specific concerns about particular ways this
might be misused, though.

https://codereview.chromium.org/2346063002/diff/40001/components/security_sta...
components/security_state/security_state_model.h:46: HTTP_WARNING,
On 2016/09/19 18:54:09, felt wrote:
> On 2016/09/19 18:38:21, Peter Kasting wrote:
> > Hmm.  These names seem worrisome, especially since "SECURITY_WARNING"
> > technically applies to all three "warnings about security".  Trying to think
> of
> > better ones.
> > 
> > HTTP_WARNING -> INSECURE_HTTP (to match the warning text more closely?)
> > 
> > SECURITY_WARNING -> OUTDATED_PROTOCOL (to match the comment there?  Or is
this
> > used in other cases)?
> > 
> > SECURITY_POLICY_WARNING -> LOCAL_CERTIFICATE (same rationale)
> 
> SECURITY_WARNING is being deprecated in another CL by lgarron. Given that, are
> you still concerned?

If that were gone (does deprecated mean "removed"?), this would be significantly
better.  That said, I'd still like to improve the names as much as we can, if we
can.  I don't know whether you think my suggestions represent an improvement.

[felt, 2016-09-20 00:20:09]

https://codereview.chromium.org/2346063002/diff/40001/components/security_sta...
File components/security_state/security_state_model.h (right):

https://codereview.chromium.org/2346063002/diff/40001/components/security_sta...
components/security_state/security_state_model.h:43: // switches::kMarkHttpAs
flag! (https://crbug.com/647754)
On 2016/09/19 18:58:30, Peter Kasting wrote:
> On 2016/09/19 18:54:09, felt wrote:
> > On 2016/09/19 18:38:21, Peter Kasting wrote:
> > > Nit: Does this caution really belong here?  I'm worried about it getting
> left
> > in
> > > forever, and I'm wondering if its inclusion now really buys us much.  The
> > > consequences for misuse are low (stuff doesn't work like you wanted) and
the
> > > people likely to misuse this are we folks implementing this stuff who know
> > what
> > > we're doing (this isn't broadly consumed).
> > 
> > I'm afraid of someone randomly seeing it and trying to (mis)use it. What do
> you
> > think of that concern?
> 
> Why would someone randomly see it?  In what sort of way would they misuse it?
> 
> I'm not opposed to making misuse more difficult, but I'd like to understand
the
> nature of the theoretical misuse so we can figure out the best way to prevent
> it.  I mean, maybe we need to tell people more about what this enum value
means,
> or how it should be displayed, or something, rather than just slapping a vague
> warning on it.  Maybe the current warning just makes people guard their misuse
> with a mis-check of this switch?
> 
> I would remove it if you don't have specific concerns about particular ways
this
> might be misused, though.

Reworded, PTAL.

https://codereview.chromium.org/2346063002/diff/40001/components/security_sta...
components/security_state/security_state_model.h:46: HTTP_WARNING,
On 2016/09/19 18:58:30, Peter Kasting wrote:
> On 2016/09/19 18:54:09, felt wrote:
> > On 2016/09/19 18:38:21, Peter Kasting wrote:
> > > Hmm.  These names seem worrisome, especially since "SECURITY_WARNING"
> > > technically applies to all three "warnings about security".  Trying to
think
> > of
> > > better ones.
> > > 
> > > HTTP_WARNING -> INSECURE_HTTP (to match the warning text more closely?)
> > > 
> > > SECURITY_WARNING -> OUTDATED_PROTOCOL (to match the comment there?  Or is
> this
> > > used in other cases)?
> > > 
> > > SECURITY_POLICY_WARNING -> LOCAL_CERTIFICATE (same rationale)
> > 
> > SECURITY_WARNING is being deprecated in another CL by lgarron. Given that,
are
> > you still concerned?
> 
> If that were gone (does deprecated mean "removed"?), this would be
significantly
> better.  That said, I'd still like to improve the names as much as we can, if
we
> can.  I don't know whether you think my suggestions represent an improvement.

Lucas is removing SECURITY_WARNING completely, see
https://codereview.chromium.org/2329153002/diff/90001/components/security_sta....

I also agree that SECURITY_POLICY_WARNING is a terrible name. I'll refactor that
in a separate CL.

For this new state:
I don't like INSECURE_HTTP (HTTP is always insecure). And despite trying, I
can't think of anything better than HTTP_WARNING (an HTTP site where we show an
extra WARNING). My preference is to remove SECURITY_POLICY (as Lucas is doing),
rename SECURITY_POLICY_WARNING (as you suggest), and name this as HTTP_WARNING.

[Ted C, 2016-09-20 00:25:09]

On 2016/09/20 00:20:09, felt wrote:
>
https://codereview.chromium.org/2346063002/diff/40001/components/security_sta...
> File components/security_state/security_state_model.h (right):
> 
>
https://codereview.chromium.org/2346063002/diff/40001/components/security_sta...
> components/security_state/security_state_model.h:43: // switches::kMarkHttpAs
> flag! (https://crbug.com/647754)
> On 2016/09/19 18:58:30, Peter Kasting wrote:
> > On 2016/09/19 18:54:09, felt wrote:
> > > On 2016/09/19 18:38:21, Peter Kasting wrote:
> > > > Nit: Does this caution really belong here?  I'm worried about it getting
> > left
> > > in
> > > > forever, and I'm wondering if its inclusion now really buys us much. 
The
> > > > consequences for misuse are low (stuff doesn't work like you wanted) and
> the
> > > > people likely to misuse this are we folks implementing this stuff who
know
> > > what
> > > > we're doing (this isn't broadly consumed).
> > > 
> > > I'm afraid of someone randomly seeing it and trying to (mis)use it. What
do
> > you
> > > think of that concern?
> > 
> > Why would someone randomly see it?  In what sort of way would they misuse
it?
> > 
> > I'm not opposed to making misuse more difficult, but I'd like to understand
> the
> > nature of the theoretical misuse so we can figure out the best way to
prevent
> > it.  I mean, maybe we need to tell people more about what this enum value
> means,
> > or how it should be displayed, or something, rather than just slapping a
vague
> > warning on it.  Maybe the current warning just makes people guard their
misuse
> > with a mis-check of this switch?
> > 
> > I would remove it if you don't have specific concerns about particular ways
> this
> > might be misused, though.
> 
> Reworded, PTAL.
> 
>
https://codereview.chromium.org/2346063002/diff/40001/components/security_sta...
> components/security_state/security_state_model.h:46: HTTP_WARNING,
> On 2016/09/19 18:58:30, Peter Kasting wrote:
> > On 2016/09/19 18:54:09, felt wrote:
> > > On 2016/09/19 18:38:21, Peter Kasting wrote:
> > > > Hmm.  These names seem worrisome, especially since "SECURITY_WARNING"
> > > > technically applies to all three "warnings about security".  Trying to
> think
> > > of
> > > > better ones.
> > > > 
> > > > HTTP_WARNING -> INSECURE_HTTP (to match the warning text more closely?)
> > > > 
> > > > SECURITY_WARNING -> OUTDATED_PROTOCOL (to match the comment there?  Or
is
> > this
> > > > used in other cases)?
> > > > 
> > > > SECURITY_POLICY_WARNING -> LOCAL_CERTIFICATE (same rationale)
> > > 
> > > SECURITY_WARNING is being deprecated in another CL by lgarron. Given that,
> are
> > > you still concerned?
> > 
> > If that were gone (does deprecated mean "removed"?), this would be
> significantly
> > better.  That said, I'd still like to improve the names as much as we can,
if
> we
> > can.  I don't know whether you think my suggestions represent an
improvement.
> 
> Lucas is removing SECURITY_WARNING completely, see
>
https://codereview.chromium.org/2329153002/diff/90001/components/security_sta....
> 
> I also agree that SECURITY_POLICY_WARNING is a terrible name. I'll refactor
that
> in a separate CL.
> 
> For this new state:
> I don't like INSECURE_HTTP (HTTP is always insecure). And despite trying, I
> can't think of anything better than HTTP_WARNING (an HTTP site where we show
an
> extra WARNING). My preference is to remove SECURITY_POLICY (as Lucas is
doing),
> rename SECURITY_POLICY_WARNING (as you suggest), and name this as
HTTP_WARNING.

lgtm - LocationBarLayout.java

[Peter Kasting, 2016-09-20 00:50:06]

LGTM

https://codereview.chromium.org/2346063002/diff/40001/components/security_sta...
File components/security_state/security_state_model.h (right):

https://codereview.chromium.org/2346063002/diff/40001/components/security_sta...
components/security_state/security_state_model.h:46: HTTP_WARNING,
On 2016/09/20 00:20:09, felt wrote:
> On 2016/09/19 18:58:30, Peter Kasting wrote:
> > On 2016/09/19 18:54:09, felt wrote:
> > > On 2016/09/19 18:38:21, Peter Kasting wrote:
> > > > Hmm.  These names seem worrisome, especially since "SECURITY_WARNING"
> > > > technically applies to all three "warnings about security".  Trying to
> think
> > > of
> > > > better ones.
> > > > 
> > > > HTTP_WARNING -> INSECURE_HTTP (to match the warning text more closely?)
> > > > 
> > > > SECURITY_WARNING -> OUTDATED_PROTOCOL (to match the comment there?  Or
is
> > this
> > > > used in other cases)?
> > > > 
> > > > SECURITY_POLICY_WARNING -> LOCAL_CERTIFICATE (same rationale)
> > > 
> > > SECURITY_WARNING is being deprecated in another CL by lgarron. Given that,
> are
> > > you still concerned?
> > 
> > If that were gone (does deprecated mean "removed"?), this would be
> significantly
> > better.  That said, I'd still like to improve the names as much as we can,
if
> we
> > can.  I don't know whether you think my suggestions represent an
improvement.
> 
> Lucas is removing SECURITY_WARNING completely, see
>
https://codereview.chromium.org/2329153002/diff/90001/components/security_sta....

Yay.

> I also agree that SECURITY_POLICY_WARNING is a terrible name. I'll refactor
that
> in a separate CL.

Cool.

> For this new state:
> I don't like INSECURE_HTTP (HTTP is always insecure).

I knew that would be the counterargument :)

> And despite trying, I
> can't think of anything better than HTTP_WARNING (an HTTP site where we show
an
> extra WARNING).

HTTP_SHOWING_WARNING?
VISIBLY_INSECURE_HTTP?
HTTP_NOTIFY_INSECURE?

Not sure any of these are better.

https://codereview.chromium.org/2346063002/diff/60001/components/security_sta...
File components/security_state/security_state_model.h (right):

https://codereview.chromium.org/2346063002/diff/60001/components/security_sta...
components/security_state/security_state_model.h:44: // part of the Http Bad
rollout (https://crbug.com/647754).
OK... I'm still not really sure how this comment is helpful to me as a reader,
or how we're going to know to come back here and remove that at some point. 
When is this no longer applicable?  Clearly in ten years when this is fully
rolled out we won't need/want this comment, but what's the point before then
where it becomes useless?

What about something like this?

    // HTTP, in a case where we want to show a visible warning about the page's
    // lack of security.
    //
    // The criteria used to classify pages as NONE vs. HTTP_WARNING will change
    // over time.  Eventually, NONE Will be eliminated.  See crbug.com/647754.

[felt, 2016-09-20 01:09:56]

https://codereview.chromium.org/2346063002/diff/40001/components/security_sta...
File components/security_state/security_state_model.h (right):

https://codereview.chromium.org/2346063002/diff/40001/components/security_sta...
components/security_state/security_state_model.h:46: HTTP_WARNING,
On 2016/09/20 00:50:05, Peter Kasting wrote:
> On 2016/09/20 00:20:09, felt wrote:
> > On 2016/09/19 18:58:30, Peter Kasting wrote:
> > > On 2016/09/19 18:54:09, felt wrote:
> > > > On 2016/09/19 18:38:21, Peter Kasting wrote:
> > > > > Hmm.  These names seem worrisome, especially since "SECURITY_WARNING"
> > > > > technically applies to all three "warnings about security".  Trying to
> > think
> > > > of
> > > > > better ones.
> > > > > 
> > > > > HTTP_WARNING -> INSECURE_HTTP (to match the warning text more
closely?)
> > > > > 
> > > > > SECURITY_WARNING -> OUTDATED_PROTOCOL (to match the comment there?  Or
> is
> > > this
> > > > > used in other cases)?
> > > > > 
> > > > > SECURITY_POLICY_WARNING -> LOCAL_CERTIFICATE (same rationale)
> > > > 
> > > > SECURITY_WARNING is being deprecated in another CL by lgarron. Given
that,
> > are
> > > > you still concerned?
> > > 
> > > If that were gone (does deprecated mean "removed"?), this would be
> > significantly
> > > better.  That said, I'd still like to improve the names as much as we can,
> if
> > we
> > > can.  I don't know whether you think my suggestions represent an
> improvement.
> > 
> > Lucas is removing SECURITY_WARNING completely, see
> >
>
https://codereview.chromium.org/2329153002/diff/90001/components/security_sta....
> 
> Yay.
> 
> > I also agree that SECURITY_POLICY_WARNING is a terrible name. I'll refactor
> that
> > in a separate CL.
> 
> Cool.
> 
> > For this new state:
> > I don't like INSECURE_HTTP (HTTP is always insecure).
> 
> I knew that would be the counterargument :)
> 
> > And despite trying, I
> > can't think of anything better than HTTP_WARNING (an HTTP site where we show
> an
> > extra WARNING).
> 
> HTTP_SHOWING_WARNING?
> VISIBLY_INSECURE_HTTP?
> HTTP_NOTIFY_INSECURE?
> 
> Not sure any of these are better.

Sold on HTTP_SHOW_WARNING.

https://codereview.chromium.org/2346063002/diff/60001/components/security_sta...
File components/security_state/security_state_model.h (right):

https://codereview.chromium.org/2346063002/diff/60001/components/security_sta...
components/security_state/security_state_model.h:44: // part of the Http Bad
rollout (https://crbug.com/647754).
On 2016/09/20 00:50:05, Peter Kasting wrote:
> OK... I'm still not really sure how this comment is helpful to me as a reader,
> or how we're going to know to come back here and remove that at some point. 
> When is this no longer applicable?  Clearly in ten years when this is fully
> rolled out we won't need/want this comment, but what's the point before then
> where it becomes useless?
> 
> What about something like this?
> 
>     // HTTP, in a case where we want to show a visible warning about the
page's
>     // lack of security.
>     //
>     // The criteria used to classify pages as NONE vs. HTTP_WARNING will
change
>     // over time.  Eventually, NONE Will be eliminated.  See crbug.com/647754.

Done.

[felt, 2016-09-20 01:10:24]

Description was changed from

==========
Add new SecurityLevel for Http Bad state

This adds a new SecurityLevel, HTTP_WARNING, for Http-Bad states.

At this point in time, HTTP_WARNING is never set, nor is it
consumed anywhere. You should ONLY make use of it behind the HttpBad
flag. I'm adding it separately in a small CL since it's a dependency
for several of our other tasks.

BUG=647558
==========

to

==========
Add new SecurityLevel for Http Bad state

This adds a new SecurityLevel, HTTP_SHOW_WARNING, for Http-Bad states.

At this point in time, HTTP_SHOW_WARNING is never set, nor is it
consumed anywhere. You should ONLY make use of it behind the HttpBad
flag. I'm adding it separately in a small CL since it's a dependency
for several of our other tasks.

BUG=647558
==========

[felt, 2016-09-20 01:10:29]

The CQ bit was checked by felt@chromium.org

[felt, 2016-09-20 01:10:30]

The patchset sent to the CQ was uploaded after l-g-t-m from estark@chromium.org,
tedchoc@chromium.org, pkasting@chromium.org
Link to the patchset: https://codereview.chromium.org/2346063002/#ps80001
(title: "HTTP_WARNING -> HTTP_SHOW_WARNING")

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

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-09-20 01:52:14]

Description was changed from

==========
Add new SecurityLevel for Http Bad state

This adds a new SecurityLevel, HTTP_SHOW_WARNING, for Http-Bad states.

At this point in time, HTTP_SHOW_WARNING is never set, nor is it
consumed anywhere. You should ONLY make use of it behind the HttpBad
flag. I'm adding it separately in a small CL since it's a dependency
for several of our other tasks.

BUG=647558
==========

to

==========
Add new SecurityLevel for Http Bad state

This adds a new SecurityLevel, HTTP_SHOW_WARNING, for Http-Bad states.

At this point in time, HTTP_SHOW_WARNING is never set, nor is it
consumed anywhere. You should ONLY make use of it behind the HttpBad
flag. I'm adding it separately in a small CL since it's a dependency
for several of our other tasks.

BUG=647558
==========

[commit-bot: I haz the power, 2016-09-20 01:52:15]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2016-09-20 01:53:52]

Description was changed from

==========
Add new SecurityLevel for Http Bad state

This adds a new SecurityLevel, HTTP_SHOW_WARNING, for Http-Bad states.

At this point in time, HTTP_SHOW_WARNING is never set, nor is it
consumed anywhere. You should ONLY make use of it behind the HttpBad
flag. I'm adding it separately in a small CL since it's a dependency
for several of our other tasks.

BUG=647558
==========

to

==========
Add new SecurityLevel for Http Bad state

This adds a new SecurityLevel, HTTP_SHOW_WARNING, for Http-Bad states.

At this point in time, HTTP_SHOW_WARNING is never set, nor is it
consumed anywhere. You should ONLY make use of it behind the HttpBad
flag. I'm adding it separately in a small CL since it's a dependency
for several of our other tasks.

BUG=647558

Committed: https://crrev.com/0e7efe19fc0d0eb8454ff0cc6e6962aa50d72cdc
Cr-Commit-Position: refs/heads/master@{#419640}
==========

[commit-bot: I haz the power, 2016-09-20 01:53:53]

Patchset 5 (id:??) landed as
https://crrev.com/0e7efe19fc0d0eb8454ff0cc6e6962aa50d72cdc
Cr-Commit-Position: refs/heads/master@{#419640}