Adjust HTTP-bad console messages

chrome/browser/ssl/chrome_security_state_model_client.cc

Index: chrome/browser/ssl/chrome_security_state_model_client.cc
diff --git a/chrome/browser/ssl/chrome_security_state_model_client.cc b/chrome/browser/ssl/chrome_security_state_model_client.cc
index 0a2c80e27980fea3438838515c75000043be03c5..2532eef7d3a69ae068e9b3a9c80225a84ab496fc 100644
--- a/chrome/browser/ssl/chrome_security_state_model_client.cc
+++ b/chrome/browser/ssl/chrome_security_state_model_client.cc
@@ -338,9 +338,20 @@ void ChromeSecurityStateModelClient::VisibleSSLStateChanged() {
       security_state::SecurityStateModel::HTTP_SHOW_WARNING) {

[elawrence, 2016/10/20 17:18:29]

Is the reason that we don't check displayed_private_user_data_input_on_http here
that the only way we light up HTTP_SHOW_WARNING today is when that's set? If so,
will this change in the future? 

Should we assert that expectation e.g.
DCHECK(displayed_private_user_data_input_on_http)?

[estark, 2016/10/20 17:45:03]

It initially seemed redundant to me, but I think you're right that we should
check it to be future-proof. Now I'm early-returning if
displayed_private_user_data_input_on_http is false.

     web_contents_->GetMainFrame()->AddMessageToConsole(
         content::CONSOLE_MESSAGE_LEVEL_WARNING,
-        "In Chrome M56 (Jan 2017), this page will be marked "
-        "as \"not secure\" in the URL bar. For more "
-        "information, see https://goo.gl/zmWq3m");
+        "This page includes a password or credit card input over HTTP. A "

[elawrence, 2016/10/20 17:18:29]

I worry that "over HTTP" is unnecessarily specific; maybe "in a non-secure
context" to cover cases of an HTTPS iframe hosted by a
HTTP/FTP/FILE/DATA-sourced page?

[estark, 2016/10/20 17:45:03]

Done.

+        "warning has been added to the URL bar. For more information, see "
+        "https://goo.gl/zmWq3m. For feedback, please use "

[elawrence, 2016/10/20 17:18:29]

What kind of "feedback" are we looking for here? Leaving it open could well mean
the bug immediately gets spammed with all manner of junk and we have to close it
for comments?

As I understand things from EmilySch, we're going to point the goo.gl link at
the Developer Guidance doc, and we can update that to include the link to the
CRBug?

[estark, 2016/10/20 17:45:03]

So you mean that we should delete the bug link because the goo.gl link will link
to it? If so, done.

+        "https://crbug.com/578317");
+    logged_http_warning_on_current_navigation_ = true;
+  } else if (security_info.security_level ==
+                 security_state::SecurityStateModel::NONE &&
+             security_info.displayed_private_user_data_input_on_http) {
+    web_contents_->GetMainFrame()->AddMessageToConsole(
+        content::CONSOLE_MESSAGE_LEVEL_WARNING,
+        "This page includes a password or credit card input over HTTP. A "
+        "warning will be added to the URL bar in Chrome 56 (Jan 2017). For "
+        "more information, see https://goo.gl/zmWq3m. For feedback, please use "
+        "https://crbug.com/578317");
     logged_http_warning_on_current_navigation_ = true;
   }
 }