Update SSL error "detail" strings

Update SSL error "detail" strings

Glen and Alex suggested putting all of the "detail" strings for overridable errors into the following format:

This server could not prove that it is example.com; <INSERT SHORT REASON HERE>. This may be caused by a misconfiguration or an attacker intercepting your connection.

BUG=

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=284867

[felt, 2014-07-18 23:48:06]

WDYT?

[Ryan Sleevi, 2014-07-18 23:56:34]

This seems a step back for the expired/not yet valid case.

I also hate Rietveld for comparing (effective) strings.

https://codereview.chromium.org/404923002/diff/20001/chrome/app/chromium_stri...
File chrome/app/chromium_strings.grd (left):

https://codereview.chromium.org/404923002/diff/20001/chrome/app/chromium_stri...
chrome/app/chromium_strings.grd:270: </message>
Why are these nuked?

[felt, 2014-07-19 00:03:53]

On 2014/07/18 23:56:34, Ryan Sleevi wrote:
> This seems a step back for the expired/not yet valid case.

To make this easier...

---------------------

EXPIRED
Old:
You attempted to reach &lt;strong&gt;<ph
name="DOMAIN">$1<ex>paypal.com</ex></ph>&lt;/strong&gt;, but the server
presented an expired certificate. No information is available to indicate
whether that certificate has been compromised since its expiration. This means
Chromium cannot guarantee that you are communicating with &lt;strong&gt;<ph
name="DOMAIN2">$2<ex>paypal.com</ex></ph>&lt;/strong&gt; and not an attacker.
Your computer's clock is currently set to <ph name="CURRENT_TIME">$3<ex>Monday,
July 18th, 2012 12:31PM</ex></ph>. Does that look right? If not, you should
correct the error and refresh this page.

New:
This server could not prove that it is <ph
name="DOMAIN">&lt;strong&gt;$1<ex>paypal.com</ex>&lt;/strong&gt;</ph>; its
security certificate has expired. This may be caused by a misconfiguration or an
attacker intercepting your connection.

NOT YET VALID
Old:
You attempted to reach &lt;strong&gt;<ph
name="DOMAIN">$1<ex>paypal.com</ex></ph>&lt;/strong&gt;, but the server
presented a certificate that is not yet valid. No information is available to
indicate whether that certificate can be trusted. Chromium cannot reliably
guarantee that you are communicating with &lt;strong&gt;<ph
name="DOMAIN2">$2<ex>paypal.com</ex></ph>&lt;/strong&gt; and not a attacker.
Your computer's clock is currently set to <ph name="CURRENT_TIME">$3<ex>Monday,
July 18th, 2012 12:31PM</ex></ph>. Does that look right? If not, you should
correct your system's clock and then refresh this page.

New:
This server could not prove that it is <ph
name="DOMAIN">&lt;strong&gt;$1<ex>paypal.com</ex>&lt;/strong&gt;</ph>; its
security certificate is supposedly from the future. This may be caused by a
misconfiguration or an attacker intercepting your connection.

---------------------

Are you referring to the fact that the old version has a string about the
current clock time? If we think the expired case is caused by a bad clock, we
replace the primary paragraph with a string saying that you need to fix the
clock. (And palmer is working on making that even better.) For the not-yet-valid
case, we don't have a good heuristic in place... so I could add that sentence to
the end for that case. Do you think that would improve it?

> 
> I also hate Rietveld for comparing (effective) strings.
> 
>
https://codereview.chromium.org/404923002/diff/20001/chrome/app/chromium_stri...
> File chrome/app/chromium_strings.grd (left):
> 
>
https://codereview.chromium.org/404923002/diff/20001/chrome/app/chromium_stri...
> chrome/app/chromium_strings.grd:270: </message>
> Why are these nuked?

[felt, 2014-07-19 00:04:22]

https://codereview.chromium.org/404923002/diff/20001/chrome/app/chromium_stri...
File chrome/app/chromium_strings.grd (left):

https://codereview.chromium.org/404923002/diff/20001/chrome/app/chromium_stri...
chrome/app/chromium_strings.grd:270: </message>
On 2014/07/18 23:56:34, Ryan Sleevi wrote:
> Why are these nuked?

Not nuked, the new strings do not use "Chromium"/"Chrome" so they moved files.

[Ryan Sleevi, 2014-07-19 00:05:38]

On 2014/07/19 00:03:53, felt wrote:
> Are you referring to the fact that the old version has a string about the
> current clock time? If we think the expired case is caused by a bad clock, we
> replace the primary paragraph with a string saying that you need to fix the
> clock. (And palmer is working on making that even better.) For the
not-yet-valid
> case, we don't have a good heuristic in place... so I could add that sentence
to
> the end for that case. Do you think that would improve it?

Thanks, that's the context I was missing. I thought these were your just-added
strings that you were replacing.

As long as we still effectively show the user clock time, SGTM and LGTM.

[felt, 2014-07-19 00:24:03]

On 2014/07/19 00:05:38, Ryan Sleevi wrote:
> On 2014/07/19 00:03:53, felt wrote:
> > Are you referring to the fact that the old version has a string about the
> > current clock time? If we think the expired case is caused by a bad clock,
we
> > replace the primary paragraph with a string saying that you need to fix the
> > clock. (And palmer is working on making that even better.) For the
> not-yet-valid
> > case, we don't have a good heuristic in place... so I could add that
sentence
> to
> > the end for that case. Do you think that would improve it?
> 
> Thanks, that's the context I was missing. I thought these were your just-added
> strings that you were replacing.

This updates the "details" text which is the additional paragraph hidden under
the "Advanced" link.

> 
> As long as we still effectively show the user clock time, SGTM and LGTM.

We should still always show user clock time, although I said it backwards
before. If we think the **not yet valid** case is caused by a bad clock, we
replace the primary paragraph. We don't have any heuristic like that in place
for **expired**, so I updated the string to keep the date/time in the details
paragraph.

[palmer, 2014-07-21 19:02:57]

> This server could not prove that it is <ph
> name="DOMAIN">&lt;strong&gt;$1<ex>paypal.com</ex>&lt;/strong&gt;</ph>; its
> security certificate has expired. This may be caused by a misconfiguration or
an
> attacker intercepting your connection.

How about:

The server presented a security certificate for <ph
name="DOMAIN">&lt;strong&gt;$1<ex>paypal.com</ex>&lt;/strong&gt;</ph> which
expired &lt;strong&gt;<ph name="DAYS_EXPIRED">$2<ex>100</ex></ph> days
ago&lt;/strong&gt;. The server might be misconfigured, or the server might be an
impostor.

That of course implies calculating and populating the # days expired.

> This server could not prove that it is <ph
> name="DOMAIN">&lt;strong&gt;$1<ex>paypal.com</ex>&lt;/strong&gt;</ph>; its
> security certificate is supposedly from the future. This may be caused by a
> misconfiguration or an attacker intercepting your connection.

Similarly, how about:

The server presented a security certificate for <ph
name="DOMAIN">&lt;strong&gt;$1<ex>paypal.com</ex>&lt;/strong&gt;</ph> which will
not be valid until &lt;strong&gt;<ph
name="DAYS_BEFORE_VALID">$2<ex>100</ex></ph> days from now&lt;/strong&gt;. The
server might be misconfigured, or the server might be an impostor.

[felt, 2014-07-21 19:13:11]

On 2014/07/21 19:02:57, Chromium Palmer wrote:
> > This server could not prove that it is <ph
> > name="DOMAIN">&lt;strong&gt;$1<ex>paypal.com</ex>&lt;/strong&gt;</ph>; its
> > security certificate has expired. This may be caused by a misconfiguration
or
> an
> > attacker intercepting your connection.
> 
> How about:
> 
> The server presented a security certificate for <ph
> name="DOMAIN">&lt;strong&gt;$1<ex>paypal.com</ex>&lt;/strong&gt;</ph> which
> expired &lt;strong&gt;<ph name="DAYS_EXPIRED">$2<ex>100</ex></ph> days
> ago&lt;/strong&gt;. The server might be misconfigured, or the server might be
an
> impostor.
> 
> That of course implies calculating and populating the # days expired.
> 
> > This server could not prove that it is <ph
> > name="DOMAIN">&lt;strong&gt;$1<ex>paypal.com</ex>&lt;/strong&gt;</ph>; its
> > security certificate is supposedly from the future. This may be caused by a
> > misconfiguration or an attacker intercepting your connection.
> 
> Similarly, how about:
> 
> The server presented a security certificate for <ph
> name="DOMAIN">&lt;strong&gt;$1<ex>paypal.com</ex>&lt;/strong&gt;</ph> which
will
> not be valid until &lt;strong&gt;<ph
> name="DAYS_BEFORE_VALID">$2<ex>100</ex></ph> days from now&lt;/strong&gt;. The
> server might be misconfigured, or the server might be an impostor.

Hmm, so Sleevi asked me to add the date/time like this for the expired case:

This server could not prove that it is <ph
name="DOMAIN">&lt;strong&gt;$1<ex>paypal.com</ex>&lt;/strong&gt;</ph>; its
security certificate has expired. This may be caused by a misconfiguration or an
attacker intercepting your connection. Your computer's clock is currently set to
<ph name="CURRENT_TIME">$2<ex>Monday, July 18th, 2012 12:31PM</ex></ph>. Does
that look right? If not, you should correct your system's clock and then refresh
this page.

Do you think we should cut the clock part?

[palmer, 2014-07-21 19:54:23]

> Do you think we should cut the clock part?

Oh no; I think we should have it for both expired and not-yet-valid. But in a
2nd paragraph.

[Ryan Sleevi, 2014-07-21 20:04:23]

On 2014/07/21 19:54:23, Chromium Palmer wrote:
> > Do you think we should cut the clock part?
> 
> Oh no; I think we should have it for both expired and not-yet-valid. But in a
> 2nd paragraph.

And I think the bike shed should be purple!

More importantly, I think the date serves a much better purpose than days
expired, in that it's generally recognizable to check the clock, but harder to
do the mental math.

If I'd guess, palmer@, you're trying to optimize for the case where a cert has
(very recently) expired, and thus probably benign, whereas I'm trying to
optimize for the case where the clock is wrong.

To be honest, I don't know which is more prevalent, but I suspect we could find
out ;)

In the interim, I suspect the shed could be pink or blue, but I think, whichever
we did, it'd be without data and with gut instinct. Which I defer to felt@ on

[palmer, 2014-07-21 22:44:47]

> More importantly, I think the date serves a much better purpose than days
> expired, in that it's generally recognizable to check the clock, but harder to
> do the mental math.

Precisely because it's harder to do the mental math, we should show how many
days expired (in addition to the current time as determined by the system's
clock).

> If I'd guess, palmer@, you're trying to optimize for the case where a cert has
> (very recently) expired, and thus probably benign, whereas I'm trying to
> optimize for the case where the clock is wrong.

Right; note also that we have a distinct warning now for when we know the clock
is definitely wrong.

> To be honest, I don't know which is more prevalent, but I suspect we could
find
> out ;)

I think one of the interns added UMA counters?

[felt, 2014-07-21 23:02:08]

On 2014/07/21 22:44:47, Chromium Palmer wrote:
> > More importantly, I think the date serves a much better purpose than days
> > expired, in that it's generally recognizable to check the clock, but harder
to
> > do the mental math.
> 
> Precisely because it's harder to do the mental math, we should show how many
> days expired (in addition to the current time as determined by the system's
> clock).
> 
> > If I'd guess, palmer@, you're trying to optimize for the case where a cert
has
> > (very recently) expired, and thus probably benign, whereas I'm trying to
> > optimize for the case where the clock is wrong.

We don't have that for the "expired" case because it's hard to disambiguate
between:
- Clock is in the future, so build time is in the distant past
- Chrome hasn't been updated for a long time, so build time is in the distant
past

> 
> Right; note also that we have a distinct warning now for when we know the
clock
> is definitely wrong.
> 
> > To be honest, I don't know which is more prevalent, but I suspect we could
> find
> > out ;)
> 
> I think one of the interns added UMA counters?

Indeed, I added some and Radhika added more. Don't have data yet tho.

[felt, 2014-07-22 02:33:10]

On 2014/07/21 23:02:08, felt wrote:
> On 2014/07/21 22:44:47, Chromium Palmer wrote:
> > > More importantly, I think the date serves a much better purpose than days
> > > expired, in that it's generally recognizable to check the clock, but
harder
> to
> > > do the mental math.
> > 
> > Precisely because it's harder to do the mental math, we should show how many
> > days expired (in addition to the current time as determined by the system's
> > clock).
> > 
> > > If I'd guess, palmer@, you're trying to optimize for the case where a cert
> has
> > > (very recently) expired, and thus probably benign, whereas I'm trying to
> > > optimize for the case where the clock is wrong.
> 
> We don't have that for the "expired" case because it's hard to disambiguate
> between:
> - Clock is in the future, so build time is in the distant past
> - Chrome hasn't been updated for a long time, so build time is in the distant
> past
> 
> > 
> > Right; note also that we have a distinct warning now for when we know the
> clock
> > is definitely wrong.
> > 
> > > To be honest, I don't know which is more prevalent, but I suspect we could
> > find
> > > out ;)
> > 
> > I think one of the interns added UMA counters?
> 
> Indeed, I added some and Radhika added more. Don't have data yet tho.

OK, I updated it to include the number of days as well.

Palmer, you should figure out a way for us to automatically flag when the date
is set in the future, so that we can remove the date from the string. :)

[palmer, 2014-07-23 00:24:30]

> [...] it's hard to disambiguate between:
> - Clock is in the future, so build time is in the distant past
> - Chrome hasn't been updated for a long time, so build time is in the distant
> past

To a certain extent, those are similar in that they are both fatally bad and the
user really, really needs to fix it on their end before they browse much more.

TransportSecurityState::IsBuildTimely sets 10 weeks as its cut-off; we could
move that function to a more general place and re-use it?

Anyway, this CL LGTM. We can improve more later!

[felt, 2014-07-23 00:26:44]

The CQ bit was checked by felt@chromium.org

[commit-bot: I haz the power, 2014-07-23 00:27:50]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/felt@chromium.org/404923002/80001

[commit-bot: I haz the power, 2014-07-23 03:46:16]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  win_chromium_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_rel/buil...)

[commit-bot: I haz the power, 2014-07-23 06:38:22]

Change committed as 284867