Change connection info strings (e.g. SHA-1 cert warnings) to be more clear.

Change connection info strings (e.g. SHA-1 cert warnings) to be more
clear to developers.

This commit includes 5 changes that make OIB connection info strings
more clear to developers (and advanced users). Since it has become
impractical to target "normal" users with these strings, the focus is on
using exact terminology instead of "friendly" alternatives. This should
help developers to understand the page's issues at a glance:

https://docs.google.com/document/d/1YgavRvC7_6PoOYHjUuKQL1Mlc718z7F1AnTNGrM92W4/edit#heading=h.kldzb7b775ri

Changes in this commit:

1. The identity section explicitly mentions when an error was caused by
   SHA-1 in the certificate chain, instead of referencing "outdated
   security settings" (there are no such settings apart from SHA-1
   signatures right now). (https://crbug.com/437466)

2. Mentions of "public audit records" have been replaced with mentions
   of "Certificate Transparency". The phrase "Public audit records" was
   hinting at the implications of CT, but a full understanding the
   string requires knowledge of CT.
   Also, the mention of CT has been split into a separate sentence. The
   presence of "but" had a strong but incorrect implication that this
   affects the lock icon (which will not be the case for non-EV sites in
   the near future).

3. The phrase "modern cryptography" is now "modern cipher suite" in
   order to distinguish the kind of cryptography in question. (Similarly
   for "obsolete cryptography".) This technically doesn't mention the
   protocol; however, the main problem usually lies with the cipher
   suite rather than the protocol, and all the cipher suites we
   currently consider good require TLS 1.2 (or, say, QUIC) as a
   prerequisite.

4. Mixed content message: Instead of "However", the sentence now starts
   with "Further" so that it still makes sense when the protocol/cipher
   suite is obsolete (https://crbug.com/434617).

5. The "SHA1 for message authentication" string (for ciphers with a MAC)
   now displays SHA1 as HMAC-SHA1, to be more suggestive that this a
   different use of SHA-1 than for cert signatures. (Similarly for other
   TLS MACs.)

Design constraint: In order to make this change as simple as possible,
the code logic has not been touched. The string contents have been
changed, but all strings keep their identifiers and semantics. Also,
these changes are definitely meant as a band-aid. In the medium-long
term, the plan is to remove the connection tab from the OIB and offer
the information in DevTools. (However, we have yet to decide on a plan
to supplant it on mobile.)

Test pages:
#1: https://sha1.badssl.com/
#2:
  - DV, no SCT: https://garron.net/
  - DV, SCT: https://embed.ct.digicert.com/
  - EV, no SCT: https://www.mozilla.org/
  - EV, SCT: https://www.bankofamerica.com/
#3:
  - "modern": https://garron.net/
  - "obsolete": https://rc4.badssl.com/
#4: https://mixed.badssl.com/
#5: https://rc4.badssl.com/

Note that this commit roughly coincides with the reintroduction of
connection info on Android:
- https://crbug.com/425158#c41
- https://chromium.googlesource.com/chromium/src/+/f21c52aeafa701b18ed505347ee0e7a7d07e5d53
Android Chrome users haven't been able to access this information for
the last half year, and will see these new strings directly.

BUG=461045, 434617, 437466
TEST=Visit the test pages (listed above).

Committed: https://crrev.com/46bd40a1b93154cc62dbda84f7f446c47f575cde
Cr-Commit-Position: refs/heads/master@{#328502}

[lgarron, 2015-04-29 02:57:34]

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

[lgarron, 2015-04-29 02:57:35]

Starting with Enamel folks. Here's a strawman.

[lgarron, 2015-04-29 03:52:32]

Patchset #2 (id:20001) has been deleted

[palmer, 2015-04-30 00:30:19]

LGTM, with arguable nits.

https://codereview.chromium.org/1109283003/diff/1/chrome/app/chromium_strings...
File chrome/app/chromium_strings.grd (right):

https://codereview.chromium.org/1109283003/diff/1/chrome/app/chromium_strings...
chrome/app/chromium_strings.grd:614: The certificate chain for this website
contains at least one certificate that was signed using an outdated algorithm
(SHA-1). This website should upgrade its certificates to avoid a downgraded lock
icon.
Maybe "... (SHA-1 with RSA encryption)." to be more exact? To further reduce
confusion between this and HMAC-SHA1 as the MAC in the TLS ciphersuite.

On the other hand, it's longer. But on the third hand, that makes it more
searchable. I leave it up to you. :)

https://codereview.chromium.org/1109283003/diff/1/chrome/app/generated_resour...
File chrome/app/generated_resources.grd (right):

https://codereview.chromium.org/1109283003/diff/1/chrome/app/generated_resour...
chrome/app/generated_resources.grd:9709: +        The identity of this website
has been verified by <ph name="ISSUER">$1<ex>VeriSign</ex></ph>. The certificate
has a signed certificate timestamp, but it cannot be verified.
"...but Chrome cannot verify it."

https://codereview.chromium.org/1109283003/diff/1/chrome/app/generated_resour...
chrome/app/generated_resources.grd:9730: +        The identity of <ph
name="ORGANIZATION">$1<ex>Google</ex></ph> at <ph name="LOCALITY">$2<ex>Mountain
View, CA US</ex></ph> has been verified by <ph
name="ISSUER">$3<ex>VeriSign</ex></ph>. The certificate has a signed certificate
timestamp, but it cannot be verified.
"...but Chrome cannot verify it."

https://codereview.chromium.org/1109283003/diff/1/chrome/app/generated_resour...
chrome/app/generated_resources.grd:9757: +        Your connection to <ph
name="DOMAIN">$1<ex>www.google.com</ex></ph> is encrypted with an obsolete
protocol or cipher suite.
Maybe "deprecated" instead of "obsolete"? Truly obsolete things, we just remove
outright. (E.g. export-grade ciphers, MD5 with RSA encryption for certificate
signatures, et c.).

[lgarron, 2015-04-30 00:58:32]

https://codereview.chromium.org/1109283003/diff/1/chrome/app/chromium_strings...
File chrome/app/chromium_strings.grd (right):

https://codereview.chromium.org/1109283003/diff/1/chrome/app/chromium_strings...
chrome/app/chromium_strings.grd:614: The certificate chain for this website
contains at least one certificate that was signed using an outdated algorithm
(SHA-1). This website should upgrade its certificates to avoid a downgraded lock
icon.
On 2015/04/30 00:30:19, palmer wrote:
> Maybe "... (SHA-1 with RSA encryption)." to be more exact? To further reduce
> confusion between this and HMAC-SHA1 as the MAC in the TLS ciphersuite.
> 
> On the other hand, it's longer. But on the third hand, that makes it more
> searchable. I leave it up to you. :)

Done.

I agree that more exact and explicit is definitely better at this point (and it
doesn't make the paragraph *much* longer in this case).

https://codereview.chromium.org/1109283003/diff/1/chrome/app/generated_resour...
File chrome/app/generated_resources.grd (right):

https://codereview.chromium.org/1109283003/diff/1/chrome/app/generated_resour...
chrome/app/generated_resources.grd:9709: +        The identity of this website
has been verified by <ph name="ISSUER">$1<ex>VeriSign</ex></ph>. The certificate
has a signed certificate timestamp, but it cannot be verified.
On 2015/04/30 00:30:19, palmer wrote:
> "...but Chrome cannot verify it."

I actually wanted to do this, but that would require moving these strings to
chromium_strings.grd.

In order to keep this change as minimal as possible (in case we might possibly
be able to merge it, but also to make it as easy as possible to understand for
anyone looking at it in the future), I left them here and compromised by using
the passive voice.
Would you still strongly prefer the change if it involves moving a string across
files move?

https://codereview.chromium.org/1109283003/diff/1/chrome/app/generated_resour...
chrome/app/generated_resources.grd:9730: +        The identity of <ph
name="ORGANIZATION">$1<ex>Google</ex></ph> at <ph name="LOCALITY">$2<ex>Mountain
View, CA US</ex></ph> has been verified by <ph
name="ISSUER">$3<ex>VeriSign</ex></ph>. The certificate has a signed certificate
timestamp, but it cannot be verified.
On 2015/04/30 00:30:19, palmer wrote:
> "...but Chrome cannot verify it."

(Same as above.)

https://codereview.chromium.org/1109283003/diff/1/chrome/app/generated_resour...
chrome/app/generated_resources.grd:9757: +        Your connection to <ph
name="DOMAIN">$1<ex>www.google.com</ex></ph> is encrypted with an obsolete
protocol or cipher suite.
On 2015/04/30 00:30:19, palmer wrote:
> Maybe "deprecated" instead of "obsolete"? Truly obsolete things, we just
remove
> outright. (E.g. export-grade ciphers, MD5 with RSA encryption for certificate
> signatures, et c.).

Good point. Done.

[palmer, 2015-04-30 01:01:50]

Keeping the change small is a fine trade-off. SGTM.

[lgarron, 2015-04-30 01:02:21]

https://codereview.chromium.org/1109283003/diff/1/chrome/app/generated_resour...
File chrome/app/generated_resources.grd (right):

https://codereview.chromium.org/1109283003/diff/1/chrome/app/generated_resour...
chrome/app/generated_resources.grd:9757: +        Your connection to <ph
name="DOMAIN">$1<ex>www.google.com</ex></ph> is encrypted with an obsolete
protocol or cipher suite.
On 2015/04/30 at 00:58:32, lgarron wrote:
> On 2015/04/30 00:30:19, palmer wrote:
> > Maybe "deprecated" instead of "obsolete"? Truly obsolete things, we just
remove
> > outright. (E.g. export-grade ciphers, MD5 with RSA encryption for
certificate
> > signatures, et c.).
> 
> Good point. Done.

I'm wondering: is there a way we can say "this doesn't affect the lock icon"
without contradicting ourselves ("your site has a problem, but it's not *really*
a problem")?

"... is encrypted with an obsolete protocol or cipher suite (which may become
unsupported in the future)."?

[felt, 2015-04-30 02:17:44]

hey lucas, small nit: can you wrap your descriptions to 80char in the future?
descriptions are hard to read when they are 15" wide

[felt, 2015-04-30 02:22:28]

https://codereview.chromium.org/1109283003/diff/40001/chrome/app/generated_re...
File chrome/app/generated_resources.grd (right):

https://codereview.chromium.org/1109283003/diff/40001/chrome/app/generated_re...
chrome/app/generated_resources.grd:9709: +        The identity of this website
has been verified by <ph name="ISSUER">$1<ex>VeriSign</ex></ph>. The certificate
has a signed certificate timestamp, but it cannot be verified.
"It's been verified by X, ... but it cannot be verified." I think the confusion
stems from the "it" possibly binding to several things (identity? certificate?
SCT?).

https://codereview.chromium.org/1109283003/diff/40001/chrome/app/generated_re...
chrome/app/generated_resources.grd:9712: +        The identity of this website
has been verified by <ph name="ISSUER">$1<ex>VeriSign</ex></ph>. The certificate
has a signed certificate timestamp, but it failed verification.
Same here and more below. What is "it"? The cert, the SCT?

[lgarron, 2015-04-30 04:50:13]

On 2015/04/30 at 02:22:28, felt wrote:
>
https://codereview.chromium.org/1109283003/diff/40001/chrome/app/generated_re...
> File chrome/app/generated_resources.grd (right):
> 
>
https://codereview.chromium.org/1109283003/diff/40001/chrome/app/generated_re...
> chrome/app/generated_resources.grd:9709: +        The identity of this website
has been verified by <ph name="ISSUER">$1<ex>VeriSign</ex></ph>. The certificate
has a signed certificate timestamp, but it cannot be verified.
> "It's been verified by X, ... but it cannot be verified." I think the
confusion stems from the "it" possibly binding to several things (identity?
certificate? SCT?).
> 
>
https://codereview.chromium.org/1109283003/diff/40001/chrome/app/generated_re...
> chrome/app/generated_resources.grd:9712: +        The identity of this website
has been verified by <ph name="ISSUER">$1<ex>VeriSign</ex></ph>. The certificate
has a signed certificate timestamp, but it failed verification.
> Same here and more below. What is "it"? The cert, the SCT?

See if you think patch #3 is sufficient. For the error cases, I've explicitly
referenced the SCT instead of "it".


I'm happy to wrap my comments manually if that's the standard. Is there
somewhere I can read up on practices like this?
(All my browsers and editors and terminals seem perfectly readable to me with
default wrapping. We're presumably not as concerned with emailability, so I
don't know what I should be worried about in this situation. In your case, is it
that you browse using large windows by default, and crrev doesn't limit the
width of the description div?)

[felt, 2015-04-30 04:56:43]

On 2015/04/30 04:50:13, lgarron wrote:
> On 2015/04/30 at 02:22:28, felt wrote:
> >
>
https://codereview.chromium.org/1109283003/diff/40001/chrome/app/generated_re...
> > File chrome/app/generated_resources.grd (right):
> > 
> >
>
https://codereview.chromium.org/1109283003/diff/40001/chrome/app/generated_re...
> > chrome/app/generated_resources.grd:9709: +        The identity of this
website
> has been verified by <ph name="ISSUER">$1<ex>VeriSign</ex></ph>. The
certificate
> has a signed certificate timestamp, but it cannot be verified.
> > "It's been verified by X, ... but it cannot be verified." I think the
> confusion stems from the "it" possibly binding to several things (identity?
> certificate? SCT?).
> > 
> >
>
https://codereview.chromium.org/1109283003/diff/40001/chrome/app/generated_re...
> > chrome/app/generated_resources.grd:9712: +        The identity of this
website
> has been verified by <ph name="ISSUER">$1<ex>VeriSign</ex></ph>. The
certificate
> has a signed certificate timestamp, but it failed verification.
> > Same here and more below. What is "it"? The cert, the SCT?
> 
> See if you think patch #3 is sufficient. For the error cases, I've explicitly
> referenced the SCT instead of "it".
> 
> 
> I'm happy to wrap my comments manually if that's the standard. Is there
> somewhere I can read up on practices like this?
> (All my browsers and editors and terminals seem perfectly readable to me with
> default wrapping. We're presumably not as concerned with emailability, so I
> don't know what I should be worried about in this situation. In your case, is
it
> that you browse using large windows by default, and crrev doesn't limit the
> width of the description div?)

It is the standard. 'git cl upload' provides a line at the top that's 80char
that's meant to serve as a guide. You can see more info e.g. here:
https://groups.google.com/a/chromium.org/forum/#!searchin/chromium-dev/Git-fr...

[felt, 2015-04-30 04:58:00]

lgtm, I agree that adding the SCT bit clears it up.

[Ryan Sleevi, 2015-04-30 05:53:59]

rsleevi@chromium.org changed reviewers:
+ rsleevi@chromium.org

[Ryan Sleevi, 2015-04-30 05:54:00]

Your net changes will get reverted the next time we re-run the script - they are
automatically generated tables, as the header says

[Ryan Sleevi, 2015-04-30 05:56:33]

https://codereview.chromium.org/1109283003/diff/60001/chrome/app/chromium_str...
File chrome/app/chromium_strings.grd (right):

https://codereview.chromium.org/1109283003/diff/60001/chrome/app/chromium_str...
chrome/app/chromium_strings.grd:614: The certificate chain for this website
contains at least one certificate that was signed using an outdated algorithm
(SHA-1 with RSA encryption). This website should upgrade its certificates to
avoid a downgraded lock icon.
This really makes it just seem like a capricious, unilateral decision "oh, we
took away the lock" - without any imparting as to why.

Instead of communicating "Hey, your site may break in 7 months", it seems like
we are now just saying " eh, whatever, no lock icon, nbd"

[Ryan Sleevi, 2015-04-30 05:59:55]

https://codereview.chromium.org/1109283003/diff/60001/chrome/app/generated_re...
File chrome/app/generated_resources.grd (left):

https://codereview.chromium.org/1109283003/diff/60001/chrome/app/generated_re...
chrome/app/generated_resources.grd:9713: </message>
This is not technically accurate.

A single SCT failure *won't* cause this, but the new language suggests just
that. And that there is only one, when there are always AT LEAST two.

https://codereview.chromium.org/1109283003/diff/60001/chrome/app/generated_re...
File chrome/app/generated_resources.grd (right):

https://codereview.chromium.org/1109283003/diff/60001/chrome/app/generated_re...
chrome/app/generated_resources.grd:9727: +        The identity of <ph
name="ORGANIZATION">$1<ex>Google</ex></ph> at <ph name="LOCALITY">$2<ex>Mountain
View, CA US</ex></ph> has been verified by <ph
name="ISSUER">$3<ex>VeriSign</ex></ph>. The certificate has a valid signed
certificate timestamp.
This is not correct either.

[lgarron, 2015-04-30 20:59:08]

Thanks for pointing out the regeneration comment, but
ssl_cipher_suite_names_generate.go doesn't appear to be in the Chromium repo
anymore (and Go code isn't allowed in the repo, right?).
Who runs ssl_cipher_suite_names_generate.go and where is it stored?

https://codereview.chromium.org/1109283003/diff/60001/chrome/app/chromium_str...
File chrome/app/chromium_strings.grd (right):

https://codereview.chromium.org/1109283003/diff/60001/chrome/app/chromium_str...
chrome/app/chromium_strings.grd:614: The certificate chain for this website
contains at least one certificate that was signed using an outdated algorithm
(SHA-1 with RSA encryption). This website should upgrade its certificates to
avoid a downgraded lock icon.
On 2015/04/30 at 05:56:33, Ryan Sleevi wrote:
> This really makes it just seem like a capricious, unilateral decision "oh, we
took away the lock" - without any imparting as to why.
> 
> Instead of communicating "Hey, your site may break in 7 months", it seems like
we are now just saying " eh, whatever, no lock icon, nbd"

In the email, you said we should say more actionable things. :-P
Enough people already think our stance is "no lock icon, nbd". Except first
they're confused because they're not sure what causes the lock icon.

If you really don't like the emphasis on the lock icon, how about just leaving
it out? "This website should upgrade its certificates."

https://codereview.chromium.org/1109283003/diff/60001/chrome/app/generated_re...
File chrome/app/generated_resources.grd (left):

https://codereview.chromium.org/1109283003/diff/60001/chrome/app/generated_re...
chrome/app/generated_resources.grd:9713: </message>
On 2015/04/30 at 05:59:55, Ryan Sleevi wrote:
> This is not technically accurate.
> 
> A single SCT failure *won't* cause this, but the new language suggests just
that. And that there is only one, when there are always AT LEAST two.

I was under the impression that a cert needed to be logged in three independent
logs, but servers only needed to send one SCT.
I just read up on it (http://www.certificate-transparency.org/faq and
http://www.certificate-transparency.org/certificate-transparency-in-chrome)

How's the latest patch, referring to (potentially/probably) multiple SCTs?

[Ryan Sleevi, 2015-04-30 21:15:56]

rsleevi@chromium.org changed reviewers:
+ davidben@chromium.org

[Ryan Sleevi, 2015-04-30 21:15:57]

David knows where the go script is located.

The go script uses the IANA database for TLS ciphersuites. So if your argument
is that you want "maximum technical precision" with "easy Googling", then I
mean, using the IANA names seems to fit both of those constraints, and the
HMAC-SHA1 change doesn't. So that's why it's important to clarify the problems
to solve, rather than describe the proposed solutions :)

https://codereview.chromium.org/1109283003/diff/80001/chrome/app/chromium_str...
File chrome/app/chromium_strings.grd (right):

https://codereview.chromium.org/1109283003/diff/80001/chrome/app/chromium_str...
chrome/app/chromium_strings.grd:614: The certificate chain for this website
contains at least one certificate that was signed using an outdated algorithm
(SHA-1 with RSA encryption). This website should upgrade its certificates to
avoid a downgraded lock icon.
I'm still not keen on the second sentence here, as I think presenting
"downgraded lock icon" is the wrong message, organizationally, to be sending.

I don't think we want to use UI as a threat, and I don't think we have, but I
think that's what this communicates, albeit unintentionally.

In my ideal world, you'd simply drop the second sentence. The first provides a
sufficient technical explanation of "why". I don't think a one sentence
explanation of "what" (to do) is fair to users or site operators, and it seems
like the main point of concern is "why"

To the first sentence, this is technically wrong. It also covers ECDSA with
SHA-1.


To that end, you could strengthen the "why" even further and say
"The certificate chain that identifies this website contains at least one
certificate that was signed using an insecure signature algorithm based on
SHA-1. Support for SHA-1 algorithms will be removed in the future, preventing
access to this site."

Or something to that end. Again though, I think the second sentence is overkill
for this dialog.

https://codereview.chromium.org/1109283003/diff/80001/chrome/app/generated_re...
File chrome/app/generated_resources.grd (right):

https://codereview.chromium.org/1109283003/diff/80001/chrome/app/generated_re...
chrome/app/generated_resources.grd:9703: +        The identity of this website
has been verified by <ph name="ISSUER">$1<ex>VeriSign</ex></ph>. The certificate
does not have signed certificate timestamps.
Do we have any complaints/concerns/questions from users about these strings? I
only know of one complaint, and that was from a CA.

If you're wanting to escalate from "Care about users" to "Care about developers"
(something I'm still mixed on, as that has been antithetical to much of Chrome's
design philosophy - c.f. the lack of options, the lack of about:config, the
intentional lack of extensions that par with Firefox), then I think it might be
better to simply say

"The identity of this website has been verified by blah, but has not been
cross-checked with Certificate Transparency."

I find the above string gross and disgusting, but less so than what's proposed.
So I mean, I'm grumpy all around, to be clear. I don't want to use a word like
"verified" or "validated" with Certificate Transparency, because that's not what
it does. Saying "publicly disclosed via Certificate Transparency" is more
accurate, but seems equally vague.

It's still unclear what problem you're trying to solve by changing these
strings, so as a reviewer, it's hard to evaluate whether these proposed changes
actually solve that problem. I have no doubt that you're trying to solve one,
but that's still unclear to me :)

[davidben, 2015-04-30 21:26:31]

I'm not sure that Go script even exists anymore. Pretty sure we've just been
editing the file by hand now. :-(

https://codereview.chromium.org/1109283003/diff/80001/chrome/app/generated_re...
File chrome/app/generated_resources.grd (right):

https://codereview.chromium.org/1109283003/diff/80001/chrome/app/generated_re...
chrome/app/generated_resources.grd:9703: +        The identity of this website
has been verified by <ph name="ISSUER">$1<ex>VeriSign</ex></ph>. The certificate
does not have signed certificate timestamps.
On 2015/04/30 21:15:56, Ryan Sleevi wrote:
> Do we have any complaints/concerns/questions from users about these strings? I
> only know of one complaint, and that was from a CA.
> 
> If you're wanting to escalate from "Care about users" to "Care about
developers"
> (something I'm still mixed on, as that has been antithetical to much of
Chrome's
> design philosophy - c.f. the lack of options, the lack of about:config, the
> intentional lack of extensions that par with Firefox), then I think it might
be
> better to simply say
> 
> "The identity of this website has been verified by blah, but has not been
> cross-checked with Certificate Transparency."
> 
> I find the above string gross and disgusting, but less so than what's
proposed.
> So I mean, I'm grumpy all around, to be clear. I don't want to use a word like
> "verified" or "validated" with Certificate Transparency, because that's not
what
> it does. Saying "publicly disclosed via Certificate Transparency" is more
> accurate, but seems equally vague.
> 
> It's still unclear what problem you're trying to solve by changing these
> strings, so as a reviewer, it's hard to evaluate whether these proposed
changes
> actually solve that problem. I have no doubt that you're trying to solve one,
> but that's still unclear to me :)

+1 that "signed certificate timestamps" is an unhelpfully opaque message. The
complaint Ryan cites isn't even resolved by this change (and I don't think it's
worth doing anything about that because it was a really silly technicality).

https://codereview.chromium.org/1109283003/diff/80001/chrome/app/generated_re...
chrome/app/generated_resources.grd:9754: +        Your connection to <ph
name="DOMAIN">$1<ex>www.google.com</ex></ph> is encrypted with a modern protocol
and cipher suite.
This message doesn't currently have anything to do with the protocol in us. If
you're going for accuracy, "modern cipher suite" is better. That logic is only
conditioned on the cipher suite and not the TLS version. The TLS version only
figures in at all just because 1.2 is when the AEADs come in. TLS 1.2 + CBC mode
is no less broken than TLS 1.1 + CBC. (1.1 vs 1.0 CBC does have a difference,
but the CBC modes are all around terrible and we haven't distinguished those
thus far and do record-splitting anyway.)

https://codereview.chromium.org/1109283003/diff/80001/chrome/app/generated_re...
chrome/app/generated_resources.grd:9757: +        Your connection to <ph
name="DOMAIN">$1<ex>www.google.com</ex></ph> is encrypted with a deprecated
protocol or cipher suite.
"deprecated" elsewhere in Chrome has usually referred to things we have imminent
plans to remove. We do not have imminent plans to remove CBC mode ciphers as
their use is too high.

[lgarron, 2015-04-30 22:48:42]

Here are my goals:
https://docs.google.com/document/d/1YgavRvC7_6PoOYHjUuKQL1Mlc718z7F1AnTNGrM92...

This is for DevTools, but I'm trying to make a few string-only OIB changes in
line with these goals.

https://codereview.chromium.org/1109283003/diff/80001/chrome/app/generated_re...
File chrome/app/generated_resources.grd (right):

https://codereview.chromium.org/1109283003/diff/80001/chrome/app/generated_re...
chrome/app/generated_resources.grd:9703: +        The identity of this website
has been verified by <ph name="ISSUER">$1<ex>VeriSign</ex></ph>. The certificate
does not have signed certificate timestamps.
On 2015/04/30 at 21:26:31, David Benjamin wrote:
> On 2015/04/30 21:15:56, Ryan Sleevi wrote:
> > Do we have any complaints/concerns/questions from users about these strings?
I
> > only know of one complaint, and that was from a CA.
> > 
> > If you're wanting to escalate from "Care about users" to "Care about
developers"
> > (something I'm still mixed on, as that has been antithetical to much of
Chrome's
> > design philosophy - c.f. the lack of options, the lack of about:config, the
> > intentional lack of extensions that par with Firefox), then I think it might
be
> > better to simply say
> > 
> > "The identity of this website has been verified by blah, but has not been
> > cross-checked with Certificate Transparency."
> > 
> > I find the above string gross and disgusting, but less so than what's
proposed.
> > So I mean, I'm grumpy all around, to be clear. I don't want to use a word
like
> > "verified" or "validated" with Certificate Transparency, because that's not
what
> > it does. Saying "publicly disclosed via Certificate Transparency" is more
> > accurate, but seems equally vague.
> > 
> > It's still unclear what problem you're trying to solve by changing these
> > strings, so as a reviewer, it's hard to evaluate whether these proposed
changes
> > actually solve that problem. I have no doubt that you're trying to solve
one,
> > but that's still unclear to me :)
> 
> +1 that "signed certificate timestamps" is an unhelpfully opaque message. The
complaint Ryan cites isn't even resolved by this change (and I don't think it's
worth doing anything about that because it was a really silly technicality).

First-order issue: I've seen people take the "but" in the sentence to mean that
this affects the lock icon. Even just splitting this into two sentences sounds
better to me.

If you'd like a complaint, here's a complaint: I still personally don't really
know if "public audit records" refers to the CT logs or the SCTs (and I know
more about CT than most web devs who will eventually have to deal with this). As
far as I have seen, Chrome is only place to use this phrase in a browser-side
context. I would just like this string to talk about what is actually going on
instead of using a euphemism.

https://codereview.chromium.org/1109283003/diff/80001/chrome/app/generated_re...
chrome/app/generated_resources.grd:9754: +        Your connection to <ph
name="DOMAIN">$1<ex>www.google.com</ex></ph> is encrypted with a modern protocol
and cipher suite.
On 2015/04/30 at 21:26:31, David Benjamin wrote:
> This message doesn't currently have anything to do with the protocol in us. If
you're going for accuracy, "modern cipher suite" is better. That logic is only
conditioned on the cipher suite and not the TLS version. The TLS version only
figures in at all just because 1.2 is when the AEADs come in. TLS 1.2 + CBC mode
is no less broken than TLS 1.1 + CBC. (1.1 vs 1.0 CBC does have a difference,
but the CBC modes are all around terrible and we haven't distinguished those
thus far and do record-splitting anyway.)

Our logic actually checks the TLS version explicitly (even if it's redundant/an
optimization/a sanity check):
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/ui/...

I'd prefer being clear that TLS 1.2 is also part of this, but either sounds fine
to me.

https://codereview.chromium.org/1109283003/diff/80001/chrome/app/generated_re...
chrome/app/generated_resources.grd:9757: +        Your connection to <ph
name="DOMAIN">$1<ex>www.google.com</ex></ph> is encrypted with a deprecated
protocol or cipher suite.
On 2015/04/30 at 21:26:30, David Benjamin wrote:
> "deprecated" elsewhere in Chrome has usually referred to things we have
imminent plans to remove. We do not have imminent plans to remove CBC mode
ciphers as their use is too high.

And "obsolete" usually means it's gone. :-P
Got a better word (that isn't going to lead to more discussion)? "old"?
"outdated"?

[davidben, 2015-04-30 23:19:29]

https://codereview.chromium.org/1109283003/diff/80001/chrome/app/generated_re...
File chrome/app/generated_resources.grd (right):

https://codereview.chromium.org/1109283003/diff/80001/chrome/app/generated_re...
chrome/app/generated_resources.grd:9703: +        The identity of this website
has been verified by <ph name="ISSUER">$1<ex>VeriSign</ex></ph>. The certificate
does not have signed certificate timestamps.
On 2015/04/30 22:48:42, lgarron wrote:
> On 2015/04/30 at 21:26:31, David Benjamin wrote:
> > On 2015/04/30 21:15:56, Ryan Sleevi wrote:
> > > Do we have any complaints/concerns/questions from users about these
strings?
> I
> > > only know of one complaint, and that was from a CA.
> > > 
> > > If you're wanting to escalate from "Care about users" to "Care about
> developers"
> > > (something I'm still mixed on, as that has been antithetical to much of
> Chrome's
> > > design philosophy - c.f. the lack of options, the lack of about:config,
the
> > > intentional lack of extensions that par with Firefox), then I think it
might
> be
> > > better to simply say
> > > 
> > > "The identity of this website has been verified by blah, but has not been
> > > cross-checked with Certificate Transparency."
> > > 
> > > I find the above string gross and disgusting, but less so than what's
> proposed.
> > > So I mean, I'm grumpy all around, to be clear. I don't want to use a word
> like
> > > "verified" or "validated" with Certificate Transparency, because that's
not
> what
> > > it does. Saying "publicly disclosed via Certificate Transparency" is more
> > > accurate, but seems equally vague.
> > > 
> > > It's still unclear what problem you're trying to solve by changing these
> > > strings, so as a reviewer, it's hard to evaluate whether these proposed
> changes
> > > actually solve that problem. I have no doubt that you're trying to solve
> one,
> > > but that's still unclear to me :)
> > 
> > +1 that "signed certificate timestamps" is an unhelpfully opaque message.
The
> complaint Ryan cites isn't even resolved by this change (and I don't think
it's
> worth doing anything about that because it was a really silly technicality).
> 
> First-order issue: I've seen people take the "but" in the sentence to mean
that
> this affects the lock icon. Even just splitting this into two sentences sounds
> better to me.

*shrug* Two sentences SGTM.

> If you'd like a complaint, here's a complaint: I still personally don't really
> know if "public audit records" refers to the CT logs or the SCTs (and I know
> more about CT than most web devs who will eventually have to deal with this).
As
> far as I have seen, Chrome is only place to use this phrase in a browser-side
> context. I would just like this string to talk about what is actually going on
> instead of using a euphemism.

I'm not sure what the certificate having a CT log would even mean. The
certificate presents a proof that it has been publicly audited in a log. That
proof is in the form of an SCT. Signed certificate timestamps is an overly
technical term I think.

We don't say "The identity of this website has been verified by verifying a
signature by its public key (as verified by VeriSign) on key exchange material
in the TLS handshake", even though that signature check is actually the critical
step in proving the site's validity. :-P

It's pretty natural that Chrome would be the only place that uses the phrase in
a browser considering that no other browser has CT.

https://codereview.chromium.org/1109283003/diff/80001/chrome/app/generated_re...
chrome/app/generated_resources.grd:9754: +        Your connection to <ph
name="DOMAIN">$1<ex>www.google.com</ex></ph> is encrypted with a modern protocol
and cipher suite.
On 2015/04/30 22:48:42, lgarron wrote:
> On 2015/04/30 at 21:26:31, David Benjamin wrote:
> > This message doesn't currently have anything to do with the protocol in us.
If
> you're going for accuracy, "modern cipher suite" is better. That logic is only
> conditioned on the cipher suite and not the TLS version. The TLS version only
> figures in at all just because 1.2 is when the AEADs come in. TLS 1.2 + CBC
mode
> is no less broken than TLS 1.1 + CBC. (1.1 vs 1.0 CBC does have a difference,
> but the CBC modes are all around terrible and we haven't distinguished those
> thus far and do record-splitting anyway.)
> 
> Our logic actually checks the TLS version explicitly (even if it's
redundant/an
> optimization/a sanity check):
>
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/ui/...
> 
> I'd prefer being clear that TLS 1.2 is also part of this, but either sounds
fine
> to me.

Interesting. Talking about versions is, I think, undesirable as it complicates
the story once TLS 1.3 exists (for the same reason I objected to the FAQ
wording, though that one was more misleading). We don't really have any reason
yet to demote TLS 1.2 once TLS 1.3 (or 2.0 if they end up calling it that)
exists and is implemented. Certainly it'd be nice to get rid of it someday like
anything else, and there's a few things that can be improved upon from 1.2 like
SKX signatures. But we don't have any imminent security need yet. The CBC modes
are different because they are known to be really terrible.

(Oh, another wrench to throw into the mix if you're going for nitpicky technical
accuracy this time is that these words are also used for QUIC which doesn't
really call them cipher suites. You don't even negotiate suites in QUIC; you
negotiate each piece individually.)

https://codereview.chromium.org/1109283003/diff/80001/chrome/app/generated_re...
chrome/app/generated_resources.grd:9757: +        Your connection to <ph
name="DOMAIN">$1<ex>www.google.com</ex></ph> is encrypted with a deprecated
protocol or cipher suite.
On 2015/04/30 22:48:42, lgarron wrote:
> On 2015/04/30 at 21:26:30, David Benjamin wrote:
> > "deprecated" elsewhere in Chrome has usually referred to things we have
> imminent plans to remove. We do not have imminent plans to remove CBC mode
> ciphers as their use is too high.
> 
> And "obsolete" usually means it's gone. :-P

Hrm. That's true, we did use that word for SSL 3. But I think it's more
important that we not confuse deprecation wording as those are the cases where
we expect non-zero usage (hence yellow icon for now) and we actively want to
drive the numbers down. Something we've outright removed, we've already
considered the breakage numbers to be acceptable.

> Got a better word (that isn't going to lead to more discussion)? "old"?
> "outdated"?

I dunno, weak? They are weak. That's why we don't like them. outdated seems
reasonable too.

[lgarron, 2015-05-01 00:29:11]

rsleevi@: How's the latest version?


felt@: linewrap4u!

[Ryan Sleevi, 2015-05-01 00:32:22]

On 2015/05/01 00:29:11, lgarron wrote:
> rsleevi@: How's the latest version?

Did you forget to upload?

[lgarron, 2015-05-01 00:35:17]

Apparently. Patch #5 is up now.

[Ryan Sleevi, 2015-05-01 01:01:28]

Works for me. I left a few more options in case you wanted to revisit the CT
thing, but your changes look fine too.

I'll hold off with the stamp just in case you want another round of
review/changes.

https://codereview.chromium.org/1109283003/diff/100001/chrome/app/chromium_st...
File chrome/app/chromium_strings.grd (right):

https://codereview.chromium.org/1109283003/diff/100001/chrome/app/chromium_st...
chrome/app/chromium_strings.grd:614: The certificate chain for this website
contains at least one certificate that was signed using an insecure signature
algorithm based on SHA-1.
I know I said insecure, but after reading David's remarks, maybe "weak",
"outdated", "deprecated", "obsolete" are all better.

I can live with insecure. But I can also give ground to softening things, since
we've said it's not "insecure" (e.g. blocked) until 2016/2017.

https://codereview.chromium.org/1109283003/diff/100001/chrome/app/generated_r...
File chrome/app/generated_resources.grd (right):

https://codereview.chromium.org/1109283003/diff/100001/chrome/app/generated_r...
chrome/app/generated_resources.grd:9703: +        The identity of this website
has been verified by <ph name="ISSUER">$1<ex>VeriSign</ex></ph>. It does not
have public audit records.
I suspect if you really want to find alternative language, here's _an_
alternative, although I suspect CAs will dislike it even more, even if it too is
technically accurate.

NO_CT
"The identity of this website has been verified by blah. This cannot be
independently confirmed using Certificate Transparency."
likewise,
CT_VERIFIED
"The identity of this website has been verified by blah. This can be
independently confirmed using Certificate Transparency."
CT_UNVERIFIED
"The identity of this website has been verified by blah. This may not be able to
be independently confirmed using Certificate Transparency, as the proof is from
an unknown party." 
CT_INVALID
"The identity of this website has been verified by blah. This cannot be
independently confirmed using Certificate Transparency, as the proof is
corrupted."


All of those feel way long, but hey, it gives you something more explainable.

Alternatively, on the more technical side
NO_CT
"The identity of this website has been verified by blah. No signed certificate
timestamps were provided that could publicly confirm this."
CT_VERIFIED
"The identity of this website has been verified by blah. Signed certificate
timestamps were provided that publicly confirm this."
CT_UNVERIFIED
"The identity of this website has been verified by blah. Signed certificate
timestamps were provided to publicly confirm this, but by logs that are not
recognized or trusted."
CT_INVALID
"The identity of this website has been verified by blah. Signed certificate
timestamps were provided to publicly confirm this, but they were not valid."

If we bark up that bikeshed, it might help to talk to the CT team to figure out
the wording idioms to best use for consistent messaging (since that helps your
'search scoring').

I'm happy to leave those changes as minor though, but I didn't want you to feel
like your concerns were unaddressed or unappreciated.

[lgarron, 2015-05-01 04:46:31]

I don't know if we've defined them anywhere, but my interpretations of the terms
are:

- weak: has significant flaws (e.g. SHA-1 has [1] RC4 has... several attacks[2])
- outdated: there is something better you should really use instead
- deprecated: explicitly on the way out (e.g. affecting lock icon)
- obsolete: gone

In terms of Chrome treatment, I would place RC4/CBC as weak and outdated (but
too popular to deprecate quite yet), SHA-1 as deprecated, and SSLv3 as obsolete.

I've updated the CL with a patch that uses "outdated cipher suite" and
"deprecated signature algorithm".

[1] https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html
[2] http://en.wikipedia.org/wiki/RC4#Security


Thanks for offering those two variants for SCTs, Ryan. I think the mention of
Certificate Transparency is a good idea, since that is the phrase we want
everyone to be familiar with.
I'd like to avoid another round to discussions by keeping that change out of
this CL, but I'll send out a quick email about a possible follow-up CL.

[lgarron, 2015-05-01 04:47:31]

Patchset #6 (id:120001) has been deleted

[lgarron, 2015-05-01 23:12:08]

I think I've addressed everyone's comments. felt@, palmer@, rsleevi@: Could you
take one more look at the current version?

[Ryan Sleevi, 2015-05-01 23:50:49]

https://codereview.chromium.org/1109283003/diff/160001/chrome/app/generated_r...
File chrome/app/generated_resources.grd (right):

https://codereview.chromium.org/1109283003/diff/160001/chrome/app/generated_r...
chrome/app/generated_resources.grd:9709: +        The identity of this website
has been verified by <ph name="ISSUER">$1<ex>VeriSign</ex></ph>; it claims to
have public audit records, but the records cannot be verified.
Mentioned on chat, but I think knowing that we're going to change all of these
strings "shortly" anyways, there's no reason to change them now. Either we can
wait on these changes until that thread ends (which I can't imagine will be more
than a day, two tops), or you can land the change w/o these changes.

I'm just not keen for unnecessary churn in the file; it feels like trying to
rush this change before the conversation has settled. Even though
well-intentioned/motivated, I'd rather get those issues sorted so we can
holistically deal with these strings. It won't make anyone cry tears to have the
comma here or the but there for a few more days.

[felt, 2015-05-02 00:00:30]

https://codereview.chromium.org/1109283003/diff/160001/chrome/app/generated_r...
File chrome/app/generated_resources.grd (right):

https://codereview.chromium.org/1109283003/diff/160001/chrome/app/generated_r...
chrome/app/generated_resources.grd:9709: +        The identity of this website
has been verified by <ph name="ISSUER">$1<ex>VeriSign</ex></ph>; it claims to
have public audit records, but the records cannot be verified.
On 2015/05/01 23:50:49, Ryan Sleevi wrote:
> Mentioned on chat, but I think knowing that we're going to change all of these
> strings "shortly" anyways, there's no reason to change them now. Either we can
> wait on these changes until that thread ends (which I can't imagine will be
more
> than a day, two tops), or you can land the change w/o these changes.
> 
> I'm just not keen for unnecessary churn in the file; it feels like trying to
> rush this change before the conversation has settled. Even though
> well-intentioned/motivated, I'd rather get those issues sorted so we can
> holistically deal with these strings. It won't make anyone cry tears to have
the
> comma here or the but there for a few more days.

These strings are not perfect, but they are strictly better than what we have
right now. We won't have the DevTools stuff for 1-3 more milestones, and we
should put our bikeshedding effort into the DevTools strings. Unless you see
something actually wrong with these, we should go ahead and make the minor
improvement where we can.

[Ryan Sleevi, 2015-05-02 00:02:19]

On 2015/05/02 00:00:30, felt wrote:
> These strings are not perfect, but they are strictly better than what we have
> right now. We won't have the DevTools stuff for 1-3 more milestones, and we
> should put our bikeshedding effort into the DevTools strings. Unless you see
> something actually wrong with these, we should go ahead and make the minor
> improvement where we can.

This wasn't about DevTools stuff. This was about the email thread that's
literally within inches of finalizing these strings substantially. I don't see
the harm in waiting a day for that discussion to finish and then updating this
CL to reflect those strings. If this is truly urgent enough to fix, then I don't
see the problem in removing the changes from this CL, since we know that the
strings in this CL won't be used, so why bother changing them now?

[felt, 2015-05-02 00:04:27]

On 2015/05/02 00:02:19, Ryan Sleevi wrote:
> On 2015/05/02 00:00:30, felt wrote:
> > These strings are not perfect, but they are strictly better than what we
have
> > right now. We won't have the DevTools stuff for 1-3 more milestones, and we
> > should put our bikeshedding effort into the DevTools strings. Unless you see
> > something actually wrong with these, we should go ahead and make the minor
> > improvement where we can.
> 
> This wasn't about DevTools stuff. This was about the email thread that's
> literally within inches of finalizing these strings substantially. I don't see
> the harm in waiting a day for that discussion to finish and then updating this
> CL to reflect those strings. If this is truly urgent enough to fix, then I
don't
> see the problem in removing the changes from this CL, since we know that the
> strings in this CL won't be used, so why bother changing them now?

Ohhh, I misunderstood: I thought you meant that you wanted to wait for the full
DevTools discussion to happen (...in like 3 months). OK, yes, let's wait a day
or two for that discussion to resolve.

[lgarron, 2015-05-05 22:18:32]

I've updated the strings based on the email with CT folks. There are no more
expected revisions at this point. :-P

rsleevi@, felt@, palmer@: Could you take a final look?

Thanks,
»Lucas

[Ryan Sleevi, 2015-05-05 23:21:17]

lgtm

https://codereview.chromium.org/1109283003/diff/180001/chrome/app/generated_r...
File chrome/app/generated_resources.grd (right):

https://codereview.chromium.org/1109283003/diff/180001/chrome/app/generated_r...
chrome/app/generated_resources.grd:9757: +        Your connection to <ph
name="DOMAIN">$1<ex>www.google.com</ex></ph> is encrypted using an outdated
cipher suite.
Is there a reason this was changed to "outdated" from "obsolete"? Both are true,
but obsolete seems to carry with it stronger connotations, which is good.

[lgarron, 2015-05-05 23:31:24]

On 2015/05/05 at 23:21:17, rsleevi wrote:
> lgtm
> 
>
https://codereview.chromium.org/1109283003/diff/180001/chrome/app/generated_r...
> File chrome/app/generated_resources.grd (right):
> 
>
https://codereview.chromium.org/1109283003/diff/180001/chrome/app/generated_r...
> chrome/app/generated_resources.grd:9757: +        Your connection to <ph
name="DOMAIN">$1<ex>www.google.com</ex></ph> is encrypted using an outdated
cipher suite.
> Is there a reason this was changed to "outdated" from "obsolete"? Both are
true, but obsolete seems to carry with it stronger connotations, which is good.

As I mentioned above, Chrome has not obsoleted them (nor deprecated them enough
to affect the lock icon).
If we have more exact meanings for "obsolete" and the other terms, I'd be happy
to align with them.

[Ryan Sleevi, 2015-05-05 23:37:58]

On 2015/05/05 23:31:24, lgarron wrote:
> As I mentioned above, Chrome has not obsoleted them (nor deprecated them
enough
> to affect the lock icon).
> If we have more exact meanings for "obsolete" and the other terms, I'd be
happy
> to align with them.

I'm not sure I understand why we can't state factually accurate information
simply because the UI state isn't there.

I mean, I'd happily send a CL to change the lock icon (and see last year's
discussion about EV status'). I appreciate the sensitivity, but at the same
time, we won't ever obsolete them until we recognize them as obsolete - it's a
bit of a chicken/egg problem :)

[Ryan Sleevi, 2015-05-05 23:40:54]

On 2015/05/01 04:46:31, lgarron wrote:
> I don't know if we've defined them anywhere, but my interpretations of the
terms
> are:
> 
> - weak: has significant flaws (e.g. SHA-1 has [1] RC4 has... several
attacks[2])
> - outdated: there is something better you should really use instead
> - deprecated: explicitly on the way out (e.g. affecting lock icon)
> - obsolete: gone
> 
> In terms of Chrome treatment, I would place RC4/CBC as weak and outdated (but
> too popular to deprecate quite yet), SHA-1 as deprecated, and SSLv3 as
obsolete.

We haven't defined them, and I'm not sure I'd bite on that terminology being
good for users.

I'd rather define it in what we want to communicate to the user for action.
Using your above definitions, we wouldn't ever show obsolete for cipher suites,
so I don't think it's a good ontology.

[palmer, 2015-05-05 23:43:23]

LGTM.

[lgarron, 2015-05-06 00:46:47]

On 2015/05/05 at 23:43:23, palmer wrote:
> LGTM.

Alright, if we don't have a good standard for "outdated" vs. "obsolete", then
that removes my motivation for the change.
The current OIB string uses "obsolete", and smaller change == good. I've changed
the word back to "obsolete".

[lgarron, 2015-05-06 00:54:52]

The CQ bit was checked by lgarron@chromium.org

[lgarron, 2015-05-06 00:54:52]

The patchset sent to the CQ was uploaded after l-g-t-m from felt@chromium.org,
palmer@chromium.org, rsleevi@chromium.org
Link to the patchset: https://codereview.chromium.org/1109283003/#ps200001
(title: "Change outdated (cipher quites) to obsolete.")

[commit-bot: I haz the power, 2015-05-06 00:55:58]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1109283003/200001

[lgarron, 2015-05-06 01:13:47]

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

[lgarron, 2015-05-06 01:13:48]

The patchset sent to the CQ was uploaded after l-g-t-m from palmer@chromium.org,
felt@chromium.org, rsleevi@chromium.org
Link to the patchset: https://codereview.chromium.org/1109283003/#ps240001
(title: "Update unit test.")

[commit-bot: I haz the power, 2015-05-06 01:14:21]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1109283003/240001

[lgarron, 2015-05-06 01:14:46]

Patchset #10 (id:220001) has been deleted

[commit-bot: I haz the power, 2015-05-06 02:18:15]

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

[commit-bot: I haz the power, 2015-05-06 02:18:16]

Dry run: This issue passed the CQ dry run.

[lgarron, 2015-05-06 08:05:10]

The CQ bit was checked by lgarron@chromium.org

[commit-bot: I haz the power, 2015-05-06 08:05:30]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1109283003/240001

[commit-bot: I haz the power, 2015-05-06 08:08:46]

Committed patchset #10 (id:240001)

[commit-bot: I haz the power, 2015-05-06 08:09:47]

Patchset 10 (id:??) landed as
https://crrev.com/46bd40a1b93154cc62dbda84f7f446c47f575cde
Cr-Commit-Position: refs/heads/master@{#328502}

[lgarron, 2015-05-15 23:13:39]

On 2015/05/06 08:09:47, I haz the power (commit-bot) wrote:
> Patchset 10 (id:??) landed as
> https://crrev.com/46bd40a1b93154cc62dbda84f7f446c47f575cde
> Cr-Commit-Position: refs/heads/master@{#328502}

For the record, this CL missed the Chrome string file. That part landed here:
https://codereview.chromium.org/1131123002/