chrome/app/generated_resources.grd

Index: chrome/app/generated_resources.grd
diff --git a/chrome/app/generated_resources.grd b/chrome/app/generated_resources.grd
index 6795059ef633f73ed735031aba6110f150ec1518..7cc2c56e6beff6853aef729db42b050bbeeee498 100644
--- a/chrome/app/generated_resources.grd
+++ b/chrome/app/generated_resources.grd
@@ -9203,6 +9203,16 @@ Keep your key file in a safe place. You will need it to create new versions of y
         SSL protocol error.
       </message>
 
+      <message name="IDS_ERRORPAGES_HEADING_SSL_NEEDS_MORE_FALLBACK" desc="Heading in the error page for SSL fallback errors.">
+        SSL server probably obsolete.
+      </message>
+      <message name="IDS_ERRORPAGES_SUMMARY_SSL_NEEDS_MORE_FALLBACK" desc="Summary in the error page for SSL fallback errors.">
+        Chrome was unable to make an acceptably secure connection to the server. Chrome has workarounds to deal with old and buggy HTTPS servers and the most extreme of these workarounds does appear to have been able to make a connection to this server, which is why Chrome may have conected to it previously. However, new research has found that this workaround causes significant security problems for all Chrome users and thus it has been disabled. It is possible, for the moment, to reenable this workaround by adding the command line flag --ssl-version-fallback-min=ssl3. However, you should fix the server promptly because this may not be supported forever.

[felt, 2014/10/01 02:22:18]

These strings have the product name in them, so they need to be put in the
appropriate product string files (chromium_strings.grd and
google_chrome_strings.grd).

[agl, 2014/10/01 21:10:53]

There seem to be lots of uses of "Chrome" and placeholders for it in this file.
However, localized_error.cc doesn't allow a placeholder for Chrome to be
included so I've reworked the message to avoid using the product name.

[felt, 2014/10/01 21:28:10]

The placeholder method is the deprecated way. Instead, don't put any string in
generated_resources.grd. Instead put the strings in the two other files I
mentioned: one that says "Chrome" and the other that says "Chromium." It will
automatically select the right string for you.

[felt, 2014/10/01 21:29:08]

For example take a look at how IDS_SSL_CLOCK_ERROR was defined.

[agl, 2014/10/01 23:02:39]

None of the other error messages phrase it as "Chrome was unable...". They all
say "Unable to...". Since I've changed this error message to match, Chrome isn't
mentioned any longer, which makes it easy.

+      </message>

[felt, 2014/10/01 02:22:18]

That's a pretty long paragraph, and I'm not sure the details are really going to
matter. What about something simpler, like:

<ph>foo.com</ph>'s server is outdated and buggy. As a result, Chrome couldn't
set up a secure communication to <ph>foo.com</ph>. If you don't care about a
secure connection, you can add the command line flag
--ssl-version-fallback-min=ssl3 to connect to the website insecurely.

(Although I question why we're promoting this command line flag in the error, do
we really want people to use it?)

[mmenke, 2014/10/01 02:23:50]

+1 to *not* suggesting the command line flag.  That just seems like a raelly bad
idea.  Also, remember these messages are used on ChromeOS, Android, and iOS....

[agl, 2014/10/01 21:10:53]

Have removed mention of the command line flag in the message. The Learn More
link still directs people to the crbug.com link where we can hopefully help them
out.

It's unclear whether we'll actually be able to make this change stick so, for
now, it's tuned towards people on dev and beta channels and getting useful
feedback.

[felt, 2014/10/01 21:40:32]

If it's meant for developers, I'd recommend making it more technically precise
(instead of vague things like "workarounds") and using Finch to explicitly gate
it to the canary and dev channels. If it's meant for users (beta+) I think we
need user-understandable strings assuming "regular" people will end up seeing
this at some point.

[agl, 2014/10/01 23:02:39]

It's aimed at the later, although there's a significant risk that we'll find out
that we can't get away with this and need to revert during Beta.

I think the current wording is sufficiently friendly. I feel that your suggested
wording (above) doesn't cover question that I expect in users minds: "this
worked last week, why did you break it?". But, if you think you have a better
way to communicate that, please go ahead. (There's no rush on this change, we
can't make it public at the moment anyway.)

[felt, 2014/10/01 23:13:54]

My feedback is that the following things are confusing:

* "There exist workarounds to deal with old and buggy HTTPS servers" -- Is this
indirectly implying that foo.com's server is old and buggy? If so, it would be
more straightforward to just say that directly.
* What is a workaround supposed to mean here?
* What is an "acceptably secure" connection? Why not just a "secure connection"?
* What is research? Who did this research? 

Here's another suggestion (just to give an idea of what I mean, you don't have
to use this text):

"Unable to connect securely to the server. The server is outdated and buggy.
This website may have worked previously, but Chrome has stopped accepting
out-of-date server connections for your safety."

+      <message name="IDS_ERRORPAGES_DETAILS_SSL_NEEDS_MORE_FALLBACK" desc="The error message displayed for SSL protocol errors.">
+        An SSLv3 fallback was able to handshake with the server but we no longer accept SSLv3 fallbacks due to new attacks against the protocol. The server needs to be updated to support a minimum of TLS 1.0 and preferably TLS 1.2.
+      </message>
+
       <message name="IDS_ERRORPAGES_HEADING_PINNING_FAILURE" desc="Title of the error page for a certificate which doesn't match the built-in pins for that name">
         Incorrect certificate for host.
       </message>