Adjust WebsiteSettings statuses for subresources with cert errors

Adjust WebsiteSettings statuses for subresources with cert errors

SSLPolicy and SecurityStateModel used to record subresources with
certificate errors as mixed content. As of
https://codereview.chromium.org/2226363002/, however, subresources with
cert errors are recorderded separately, in their own
|content_with_cert_errors_status| field on
SecurityStateModel::SecurityInfo.

This CL updates WebsiteSettings to warn the user when there are
subresources with cert errors on the page. Currently, WebsiteSettings
uses the same statuses as are used for mixed content, because the strings happen
to apply well to both types of insecure content. (I also renamed a few strings and
enums to make it more clear that they describe different types of insecure
subresources, not just mixed content.) In future, maybe we'd want to use different
strings to describe subresources with cert errors in WebsiteSettings,
but I think the mixed content strings work well enough for now.

(Other UI like DevTools will distinguish mixed content from subresources with
cert errors, which is one of the reasons that we separated the two into
|mixed_content_status| and |content_with_cert_errors_status|.)

For simplicity, WebsiteSettings ignores subresources with certificate
errors when the main resource was loaded with a certificate error. I
think that trying to distinguish subresource cert errors from cert
errors on the main resource is probably TMI for the average user.

BUG=634171
Committed: https://crrev.com/00e83f13e0edc9bc0d3df45cf25f96fc55149b2b
Cr-Commit-Position: refs/heads/master@{#413190}

[estark, 2016-08-15 14:32:16]

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

[commit-bot: I haz the power, 2016-08-15 14:32:29]

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

[estark, 2016-08-15 14:33:15]

Description was changed from

==========
Adjust WebsiteSettings statuses for subresources with cert errors

SSLPolicy and SecurityStateModel used to record subresources with
certificate errors as mixed content. As of
https://codereview.chromium.org/2226363002/, however, subresources with
cert errors are recorderded separately, in their own
|content_with_cert_errors_status| field on
SecurityStateModel::SecurityInfo.

This CL updates WebsiteSettings to warn the user when there are
subresources with cert errors on the page. Currently, WebsiteSettings
uses the same statuses, and thus the same strings and icons, as for
mixed content, because the strings happen to apply well to both types of
insecure content. (I also renamed a few strings and enums to make it
more clear that they describe different types of insecure subresources,
not just mixed content.) In future, maybe we'd want to use different
strings to describe subresources with cert errors in WebsiteSettings,
but I think the mixed content strings work well enough for now.

For simplicity, WebsiteSettings ignores subresources with certificate
errors when the main resource was loaded with a certificate error. I
think that trying to distinguish subresource cert errors from cert
errors on the main resource is probably TMI for the average user.

BUG=634171
==========

to

==========
Adjust WebsiteSettings statuses for subresources with cert errors

SSLPolicy and SecurityStateModel used to record subresources with
certificate errors as mixed content. As of
https://codereview.chromium.org/2226363002/, however, subresources with
cert errors are recorderded separately, in their own
|content_with_cert_errors_status| field on
SecurityStateModel::SecurityInfo.

This CL updates WebsiteSettings to warn the user when there are
subresources with cert errors on the page. Currently, WebsiteSettings
uses the same statuses as are used for mixed content, because the strings happen
to apply well to both types of insecure content. (I also renamed a few strings
and
enums to make it more clear that they describe different types of insecure
subresources, not just mixed content.) In future, maybe we'd want to use
different
strings to describe subresources with cert errors in WebsiteSettings,
but I think the mixed content strings work well enough for now.

For simplicity, WebsiteSettings ignores subresources with certificate
errors when the main resource was loaded with a certificate error. I
think that trying to distinguish subresource cert errors from cert
errors on the main resource is probably TMI for the average user.

BUG=634171
==========

[commit-bot: I haz the power, 2016-08-15 15:04:01]

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

[commit-bot: I haz the power, 2016-08-15 15:04:03]

Dry run: This issue passed the CQ dry run.

[estark, 2016-08-15 16:18:32]

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

[estark, 2016-08-15 16:18:33]

felt, PTAL?

[estark, 2016-08-16 13:18:25]

Description was changed from

==========
Adjust WebsiteSettings statuses for subresources with cert errors

SSLPolicy and SecurityStateModel used to record subresources with
certificate errors as mixed content. As of
https://codereview.chromium.org/2226363002/, however, subresources with
cert errors are recorderded separately, in their own
|content_with_cert_errors_status| field on
SecurityStateModel::SecurityInfo.

This CL updates WebsiteSettings to warn the user when there are
subresources with cert errors on the page. Currently, WebsiteSettings
uses the same statuses as are used for mixed content, because the strings happen
to apply well to both types of insecure content. (I also renamed a few strings
and
enums to make it more clear that they describe different types of insecure
subresources, not just mixed content.) In future, maybe we'd want to use
different
strings to describe subresources with cert errors in WebsiteSettings,
but I think the mixed content strings work well enough for now.

For simplicity, WebsiteSettings ignores subresources with certificate
errors when the main resource was loaded with a certificate error. I
think that trying to distinguish subresource cert errors from cert
errors on the main resource is probably TMI for the average user.

BUG=634171
==========

to

==========
Adjust WebsiteSettings statuses for subresources with cert errors

SSLPolicy and SecurityStateModel used to record subresources with
certificate errors as mixed content. As of
https://codereview.chromium.org/2226363002/, however, subresources with
cert errors are recorderded separately, in their own
|content_with_cert_errors_status| field on
SecurityStateModel::SecurityInfo.

This CL updates WebsiteSettings to warn the user when there are
subresources with cert errors on the page. Currently, WebsiteSettings
uses the same statuses as are used for mixed content, because the strings happen
to apply well to both types of insecure content. (I also renamed a few strings
and
enums to make it more clear that they describe different types of insecure
subresources, not just mixed content.) In future, maybe we'd want to use
different
strings to describe subresources with cert errors in WebsiteSettings,
but I think the mixed content strings work well enough for now.

(Other UI like DevTools will distinguish mixed content from subresources with
cert errors, which is one of the reasons that we separated the two into
|mixed_content_status| and |content_with_cert_errors_status|.)

For simplicity, WebsiteSettings ignores subresources with certificate
errors when the main resource was loaded with a certificate error. I
think that trying to distinguish subresource cert errors from cert
errors on the main resource is probably TMI for the average user.

BUG=634171
==========

[felt, 2016-08-18 20:40:55]

https://codereview.chromium.org/2244243002/diff/1/chrome/browser/ui/website_s...
File chrome/browser/ui/website_settings/website_settings.h (right):

https://codereview.chromium.org/2244243002/diff/1/chrome/browser/ui/website_s...
chrome/browser/ui/website_settings/website_settings.h:41:
SITE_CONNECTION_STATUS_INSECURE_CONTENT,  // Non-secure passive content.
nit: It is not clear anymore that this refers to subresources. That was obvious
for "mixed content", but now it isn't clear. Could you replace it with something
like SITE_CONNECTION_INSECURE_SUBRESOURCe?

https://codereview.chromium.org/2244243002/diff/1/chrome/browser/ui/website_s...
chrome/browser/ui/website_settings/website_settings.h:42:
SITE_CONNECTION_STATUS_INSECURE_SCRIPT,   // Non-secure active content.
To make sure I understand... mixed content & subresources with cert errors still
both share SITE_CONNECTION_STATUS_INSECURE_CONTENT and
SITE_CONNECTION_STATUS_INSECURE_SCRIPT? And you're just renaming to be clear it
applies to both?

[estark, 2016-08-19 12:54:44]

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

[commit-bot: I haz the power, 2016-08-19 12:55:03]

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

[estark, 2016-08-19 12:55:50]

https://codereview.chromium.org/2244243002/diff/1/chrome/browser/ui/website_s...
File chrome/browser/ui/website_settings/website_settings.h (right):

https://codereview.chromium.org/2244243002/diff/1/chrome/browser/ui/website_s...
chrome/browser/ui/website_settings/website_settings.h:41:
SITE_CONNECTION_STATUS_INSECURE_CONTENT,  // Non-secure passive content.
On 2016/08/18 20:40:55, felt wrote:
> nit: It is not clear anymore that this refers to subresources. That was
obvious
> for "mixed content", but now it isn't clear. Could you replace it with
something
> like SITE_CONNECTION_INSECURE_SUBRESOURCe?

Done.

https://codereview.chromium.org/2244243002/diff/1/chrome/browser/ui/website_s...
chrome/browser/ui/website_settings/website_settings.h:42:
SITE_CONNECTION_STATUS_INSECURE_SCRIPT,   // Non-secure active content.
On 2016/08/18 20:40:55, felt wrote:
> To make sure I understand... mixed content & subresources with cert errors
still
> both share SITE_CONNECTION_STATUS_INSECURE_CONTENT and
> SITE_CONNECTION_STATUS_INSECURE_SCRIPT? And you're just renaming to be clear
it
> applies to both?

Yes, that's right.

[felt, 2016-08-19 13:06:23]

lgtm

[commit-bot: I haz the power, 2016-08-19 14:32:45]

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

[commit-bot: I haz the power, 2016-08-19 14:32:46]

Dry run: This issue passed the CQ dry run.

[estark, 2016-08-19 18:18:23]

The CQ bit was checked by estark@chromium.org

[commit-bot: I haz the power, 2016-08-19 18:18: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-08-19 18:24:25]

Description was changed from

==========
Adjust WebsiteSettings statuses for subresources with cert errors

SSLPolicy and SecurityStateModel used to record subresources with
certificate errors as mixed content. As of
https://codereview.chromium.org/2226363002/, however, subresources with
cert errors are recorderded separately, in their own
|content_with_cert_errors_status| field on
SecurityStateModel::SecurityInfo.

This CL updates WebsiteSettings to warn the user when there are
subresources with cert errors on the page. Currently, WebsiteSettings
uses the same statuses as are used for mixed content, because the strings happen
to apply well to both types of insecure content. (I also renamed a few strings
and
enums to make it more clear that they describe different types of insecure
subresources, not just mixed content.) In future, maybe we'd want to use
different
strings to describe subresources with cert errors in WebsiteSettings,
but I think the mixed content strings work well enough for now.

(Other UI like DevTools will distinguish mixed content from subresources with
cert errors, which is one of the reasons that we separated the two into
|mixed_content_status| and |content_with_cert_errors_status|.)

For simplicity, WebsiteSettings ignores subresources with certificate
errors when the main resource was loaded with a certificate error. I
think that trying to distinguish subresource cert errors from cert
errors on the main resource is probably TMI for the average user.

BUG=634171
==========

to

==========
Adjust WebsiteSettings statuses for subresources with cert errors

SSLPolicy and SecurityStateModel used to record subresources with
certificate errors as mixed content. As of
https://codereview.chromium.org/2226363002/, however, subresources with
cert errors are recorderded separately, in their own
|content_with_cert_errors_status| field on
SecurityStateModel::SecurityInfo.

This CL updates WebsiteSettings to warn the user when there are
subresources with cert errors on the page. Currently, WebsiteSettings
uses the same statuses as are used for mixed content, because the strings happen
to apply well to both types of insecure content. (I also renamed a few strings
and
enums to make it more clear that they describe different types of insecure
subresources, not just mixed content.) In future, maybe we'd want to use
different
strings to describe subresources with cert errors in WebsiteSettings,
but I think the mixed content strings work well enough for now.

(Other UI like DevTools will distinguish mixed content from subresources with
cert errors, which is one of the reasons that we separated the two into
|mixed_content_status| and |content_with_cert_errors_status|.)

For simplicity, WebsiteSettings ignores subresources with certificate
errors when the main resource was loaded with a certificate error. I
think that trying to distinguish subresource cert errors from cert
errors on the main resource is probably TMI for the average user.

BUG=634171
==========

[commit-bot: I haz the power, 2016-08-19 18:24:26]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2016-08-19 18:28:02]

Description was changed from

==========
Adjust WebsiteSettings statuses for subresources with cert errors

SSLPolicy and SecurityStateModel used to record subresources with
certificate errors as mixed content. As of
https://codereview.chromium.org/2226363002/, however, subresources with
cert errors are recorderded separately, in their own
|content_with_cert_errors_status| field on
SecurityStateModel::SecurityInfo.

This CL updates WebsiteSettings to warn the user when there are
subresources with cert errors on the page. Currently, WebsiteSettings
uses the same statuses as are used for mixed content, because the strings happen
to apply well to both types of insecure content. (I also renamed a few strings
and
enums to make it more clear that they describe different types of insecure
subresources, not just mixed content.) In future, maybe we'd want to use
different
strings to describe subresources with cert errors in WebsiteSettings,
but I think the mixed content strings work well enough for now.

(Other UI like DevTools will distinguish mixed content from subresources with
cert errors, which is one of the reasons that we separated the two into
|mixed_content_status| and |content_with_cert_errors_status|.)

For simplicity, WebsiteSettings ignores subresources with certificate
errors when the main resource was loaded with a certificate error. I
think that trying to distinguish subresource cert errors from cert
errors on the main resource is probably TMI for the average user.

BUG=634171
==========

to

==========
Adjust WebsiteSettings statuses for subresources with cert errors

SSLPolicy and SecurityStateModel used to record subresources with
certificate errors as mixed content. As of
https://codereview.chromium.org/2226363002/, however, subresources with
cert errors are recorderded separately, in their own
|content_with_cert_errors_status| field on
SecurityStateModel::SecurityInfo.

This CL updates WebsiteSettings to warn the user when there are
subresources with cert errors on the page. Currently, WebsiteSettings
uses the same statuses as are used for mixed content, because the strings happen
to apply well to both types of insecure content. (I also renamed a few strings
and
enums to make it more clear that they describe different types of insecure
subresources, not just mixed content.) In future, maybe we'd want to use
different
strings to describe subresources with cert errors in WebsiteSettings,
but I think the mixed content strings work well enough for now.

(Other UI like DevTools will distinguish mixed content from subresources with
cert errors, which is one of the reasons that we separated the two into
|mixed_content_status| and |content_with_cert_errors_status|.)

For simplicity, WebsiteSettings ignores subresources with certificate
errors when the main resource was loaded with a certificate error. I
think that trying to distinguish subresource cert errors from cert
errors on the main resource is probably TMI for the average user.

BUG=634171

Committed: https://crrev.com/00e83f13e0edc9bc0d3df45cf25f96fc55149b2b
Cr-Commit-Position: refs/heads/master@{#413190}
==========

[commit-bot: I haz the power, 2016-08-19 18:28:02]

Patchset 3 (id:??) landed as
https://crrev.com/00e83f13e0edc9bc0d3df45cf25f96fc55149b2b
Cr-Commit-Position: refs/heads/master@{#413190}