Would we also remove the PSL, which is also growing very fast?

I'm extremely uncomfortable with the idea of gutting features for Cronet because they don't make sense for a "non-browser", because that further makes it confusing to understanding the layering, policies, and decisions around //net. This sort of confusion is explicitly why Chrome leadership have said things like "//base is not meant to be a reusable library" - because the moment we're no longer to able to add or remove something because that's "What Chrome needs", the ability to maintain our velocity, quality, consistency, and understandability are gone.

WebSockets removal was consistent with the above due to delivering a Chrome browser on iOS. ICU removal was consistent, because we were doing so for Android. Removing the HSTS list does not seem consistent, and makes it harder to reason about security policies, guarantees, and assumptions.

I'm particularly sensitive about this as it relates to other security improvements, whether it be OCSP Stapling or Certificate Transparency, which is why I want to make sure we have a reasonable set of principles established, rather than treat these as one-offs and get death by a thousand papercuts.

I agree that gutting "non-browser" features left and right is a rather slippery slope to start sliding down. I do rather wish the relevant people had realized just how badly they were diving headfirst down that slope in starting Cronet, and probably now is a far better time to finally have that conversation rather than "never".

That said, I think losing the HSTS preload list is actually quite defensible. The preload list is more-or-less an extension of dynamic HSTS policy, as an attempt to solve the first visit problem. I think the consequences of disabling it are fairly clear and localized to HSTS's behavior.

In contrast, I would oppose disabling dynamic HSTS even though dynamic HSTS is also of no use for Cronet. That's a much more invasive thing.

Since we probably need to abstract away TransportSecurityState sources anyway for various other work, we could have the static one just be another source one could assemble together and then Cronet would just not include it. (In fact, some of Cronet's key pinning logic was done kinda hackishly[*], so that would also help with that.)

[*] It uses the dynamic HPKP code and assumes that it never persists anything because they never supplied a persister.


> Would we also remove the PSL, which is also growing very fast?

No. The PSL's semantics figure into how cookies work, which everything is sensitive to. I think the difference is that if we lose some entries in the PSL we actually were sensitive to, the consequences are catastrophic. If we lose some entries from the preload list, we'll "only" have the first-visit problem.

On a technical level, we already don't bundle the static-list for non-official builds, so it's largely not a technical problem, one of scope/design.

And my remarks about the PSL still stand. If the justification is "most of Cronet embedders only talk to a few endpoints", there's a clear argument to be made that 'their' copy of the PSL should only contain the endpoints they talk to (which could likely shave 99% of the PSL size).

Similarly, for Google, if we lose entries in the HSTS preload list for Google domains, the consequences *can* be catastrophic for user trust/security. So I don't buy the argument that the first-visit problem, precisely because there are a number of companies (Google and non-Google alike) that are in the HSTS preload list, but not serving the header.

But I agree that there's definitely a need to tweak how preloads are being handled (which is already being discussed for things like Expect-CT, Expect-OCSP, knock-out subdomains, enterprise policies for HSTS, etc). This is just one more justification for that cleanup, on a technical level, but there's still the policy principles to establish.

> we already don't bundle the static-list for non-official build

You sure? I believe we always bundle it but the pins only kick in when a number of conditions are set. (Notably, I'm not sure Cronet even makes an "official build".)

> in the HSTS preload list, but not serving the header.

Oh good point, I forgot about folks who weren't shipping the header at all.


I think it still makes sense to unship it from Cronet here because, ultimately, Cronet doesn't care about HSTS[*], but, sure, we can have someone weigh in on a policy decision.

[*] Cllleeaaarly we should tie the "don't ship HSTS preload" flag with some flag that hard-disables all ability to bypass certificate errors, rather than relying on Cronet not calling ContinueDespiteLastError or whatever. :-)

Oh, you're right, because we've coupled things like Expect-CT, there's no way for the code to be Dead-Code-Eliminated now. That's an even more compelling argument to split up the preload format.

And to be clear, I think there's a distinction between "hard-disable certificate errors" and "force SSL". We want both behaviours; the former we can force with API change, but the latter we can't. We 'could' defer the latter to the system (in the case of Android), by having Cronet enforce that EnableCleartextTraffic was always false in the bundle, but *shrug*

Assigning to Miriam to verify how much does HSTS list contribute to binary size of Cronet.

In a current Cronet build it's 100 KiB, up from 60 KiB a few months ago. That's about 4% of the total size of libcronet.so.

The latest update (https://codereview.chromium.org/2827883002) caused ~40KB binary increase for Cronet.

https://chromeperf.appspot.com/alerts?sortby=end_revision&sortdirection=down&sheriff=Cronet%20Perf%20Sheriff

Deleted: sizes.png 95.9 KB

	sizes.png 95.9 KB View Download

I had a quick look because the generation of the data is now automatic and I wanted to make sure the generator is working correctly.

This increase is a result of the natural growth of the preload list, it went from 24929 entries to 29035 entries. The size increased from 220.05kb (70.798 bits per entry) to 256.81kb (70.760 bits per entry).

Other thoughts:

The vast majority of preloaded entries are HSTS + IncludeSubdomains. A new compact mode for these entries would reduce their size by 4 bits but would also increase the size of other entries by 1 bit. I ran an experiment (https://codereview.chromium.org/2906483003) and such a change decreases the size of the binary data by 5.73% which is ~14kb. This new format would use 66.712 bits per entry saving 4.048 bits per entry*.  Only limited savings in contrast with the list growth.

The list is going to continue to grow and the data structure is already fairly compact. Reducing its size significantly won't be easy. I think there were some ideas in the past that proposed experimenting with other data structures like (compressed) bloom filters.

Policy aside; it may now be technically possible to strip out (specific) entries on specific platforms by passing flags to the generator using conditionals in GN.

* This is more than the predicted (best-case) 4 bits per entry. This is because the binary structure also contains offsets which are written in a short form when the offset can be represented with 7 bits or less. Because the entries take up less bits this short form occurs more often. The current threshold of 7 bits is already optimal. Changing it to either 6 or 8 increases the size of the binary data.

Thanks martijin@. Adding a GN build flag might be the best way forward for Cronet. This list is currently ~10% of Cronet. I tried to add the flag in https://codereview.chromium.org/2906633003, but wasn't able to make it work. pauljensen@ started a thread with Cronet consumers to see if any of them depend on this preload list. 

Stripping the entire list probably won't work, there are some tests that expect certain domains to be preloaded and the decoder might not be able to handle a completely empty list (haven't tried it).

A compromise could be to mark certain entries in the list as "critical" and make a change to the generator so that only those entries are included if a flag is passed to it. That way cronet can ship with a limited set of preloaded domains (those used in tests and some other Google/non-Google domains?).

That would balance the security concerns raised earlier while still reducing Cronet's binary size.

> The latest update (https://codereview.chromium.org/2827883002) caused ~40KB binary increase for Cronet.

Sounds about the right amount.
Note that the size will hopefully go down due to pruning in the near future, but it will go back up until we decide to start shipping only a subset in the binary.

I think it would be a loss to cut out the entire preload list. If the size is a significant problem, I can accelerate either pruning it or marking entries as higher-priority.

Edit: Comment #14 said about as much. :-)

xunjieli@: I can't find a cronet mailing list; could you add me and Martijn to the thread?

My rough take is that the fallout of getting rid of this is fairly limited.

a) Cronet supports NetworkSecurityPolicy (https://bugs.chromium.org/p/chromium/issues/detail?id=474197) so can enforce that all connections are encrypted. Given that many Cronet embedders speak to a small number of encrypted domains, this could be used to help enforce the behavior.

b) I think we'd still end up persisting server-sent HSTS, so we'd only impact on-first-use (or on-expired) cases. Still a hole though, and one which the preload list was addressing.

c) Arguably we could provide a programmatic API for app embedders to specify separate preload lists.

Does Cronet persist server-sent HSTS? I thought it didn't. In fact, the implementation of Cronet's key pinning API, unless it's since been made less hacky, relies on Cronet *not* installing a TransportSecurityState persister.

Re#17. Pruning the preload list sounds good to me. One list contains the high priority ones and another contains the rest. 

Re#18. I added lgarron@ to the email thread. Sorry, Martijn, it is an internal mailing list.

Re#20. That's right. Cronet doesn't persist server-sent HSTS.

https://cs.chromium.org/chromium/src/components/cronet/android/cronet_url_request_context_adapter.cc?rcl=c290763a1b98e8c9815e87e326b13a314605bf98&l=671
  // Explicitly disable the persister for Cronet to avoid persistence of dynamic
  // HPKP. This is a safety measure ensuring that nobody enables the persistence
  // of HPKP by specifying transport_security_persister_path in the future.
  context_builder.set_transport_security_persister_path(base::FilePath());

The Google pinset is used by IsGooglePinnedHost() directly so you'd need to include at least that to get everything to compile. There are about 120 entries[1] that are needed for everything to build and pass tests, these take up ~1kb (9264 bits).

That leaves enough room to include additional higher-priority entries and still reduce the list's binary size by +95%.

[1] https://codereview.chromium.org/2901393005/patch/20001/30003

#20+#21: Is persisting HSTS something which shouldn't be done, or just hasn't been done?

On its own, I don't see any particular reason not to. However, it cannot be done without fixing this:
https://cs.chromium.org/chromium/src/components/cronet/android/cronet_url_request_context_adapter.cc?rcl=c17389344afd818f0d1ffd7bf02f1a2131fd1f07&l=784

We do *not* want those to be persisted, but AddHPKP is the API for adding new persisted entries. This only works right now because Cronet happens not to enable persistence. It probably should be fixed regardless as I only happened to remember this hack from the code review. (One option is to refactor TransportSecurityState to handle data from some interface, and then persistent vs. static vs. dynamic vs. app startup vs. admin policy vs. whatever would be an embedder decision.)

The one potential Cronet consumer that I thought might rely on the HSTS preload list, does not rely on the preload list.

> The Google pinset is used by IsGooglePinnedHost() directly so you'd need to
> include at least that to get everything to compile.

I removed IsGooglePinnedHost() in crrev.com/2914223002

martijn@ or lgarron@: could you help with splitting the preload list into essential ones and low-priority ones?   

The CL in comment #22 marks the minimal set of entries needed to build & pass all tests and could serve as a basis for an essentials list.

The inclusion of additional entries will have to be based on some policy and not for technical reasons. I'll leave that decision to lgarron/Google because the current list only ships as part of official Google builds.

https://codereview.chromium.org/2901393005

The tests can also be adjusted, or made to depend on build parameters. I imagine some of the entries they test were a bit arbitrary.

Thanks, martijn@. I will give it a try and send out a CL for review. 

My take is this is probably worth removing from Cronet, at least on Android.

Reasons why:
  - Binary size impact is large, and keeping Cronet compact is important for most consumers.
  - Cronet supports Android's cleartextTrafficPermitted configuration (https://developer.android.com/training/articles/security-config.html#CleartextTrafficPermitted). This is slightly different than HSTS in that requests to http://<domain> will fail rather than be redirected to https://<domain>, but will still ensure that the requests are https. The other caveat is that this is only on newer Android versions.
  - Many of the apps will have hardcoded https URLs that they go to. While there is some risk of mistakes here, it is less likely based on user input that prefers http or links on sites to http variants.
  - Dynamic HSTS is supported, with the caveat that it is not persisted.

Reasons why not:
  - Dynamic HSTS is not persisted, and also doesn't address the first use case that preload does.
  - Rather than a default set of preloads which works across all Cronet embedders, each embedder will have to configure whether cleartext is allowed.
  - cleartextAllowed config is less forgiving of client mistakes than HSTS preload.
  - cleartextAllowed config doesn't work on older versions of Android. My take is that an app which works across newer and older is still protected on older versions due to catching errors on newer versions.

I support exclusion of HSTS preloads from Cronet. Couple of thoughts:

- AFAIK Android platform network stack doesn't support HSTS preloads neither, so there is no functionality loss with Cronet usage.

- Even though cleartextAllowed flag doesn't work on older versions of Android, I agree that it is largely remedied by detecting failures during development testing on newer versions.

- Anticipated growth of preload list means that binary size pressure is likely continue to grow as well.


Does it make any sense to provide API to allow the app to supply its own HSTS preload list? 
This seems like a dangerous footgun, but are there any reasons to have it?

> Does it make any sense to provide API to allow the app to supply its own HSTS preload list? 

Forks of the preload list are already a problem, and I'm trying to unify them.
Historically, it also seems that exposing endpoints for web security configuration is messy – we should  have as few people as possible making their decision about how many domains to preload are "enough".


Anyhow, taking a step back: It seems that no one really wants to get rid of HSTS in Cronet because HSTS fundamentally doesn't belong there – removal is entirely motivated by size.

There is a rough long-term planidea build the top N domains into the binary and ship the rest through a component update for Chrome.
How small would the preload list need to be so that size is not an issue for Cronet?

> Does it make any sense to provide API to allow the app to supply its own HSTS preload list? 

I'm not sure such an API adds much value as apps can just provide https URLs rather than http URLs.  It seems overkill to have an app API and infrastructure that just adds "s"s to URLs...that are provided by the app.  HSTS makes a lot of sense when app users provide the URLs and site maintainers provide the HSTS list, but not when the same party is providing both the URLs to fetch and the URLs to HSTS.

> How small would the preload list need to be so that size is not an issue for Cronet?

I'm not a fan of forking the HSTS list, providing alternate HSTS lists or cutting down the HSTS list.  I think such a partial solution would cause more problems than good, e.g. someone notices HSTS works for one URL and unsafely assumes it works for all normal HSTS URLs and security disaster ensues.

> I'm not a fan of forking the HSTS list, providing alternate HSTS lists or cutting down the HSTS list.

Unfortunately, the alternative is either "ship everything in every build" or "ship nothing in every build". The former is causing problems like this, and the latter defeats the primary purpose of the preload list.

If you have any alternative ideas, we could use them at this point.

I liked the idea in comment #15 of using a build flag to control HSTS inclusion.

I agreed with pauljensen@. 
CL is at https://codereview.chromium.org/2906633003/. It's waiting for review.

> I liked the idea in comment #15 of using a build flag to control HSTS inclusion.

Would still prefer it if the Chrome/Cronet binary included a filtered subset of the preload list anyhow?

> Would still prefer it if the Chrome/Cronet binary included a filtered subset of the preload list anyhow?

Chrome should contain the complete list.  I prefer Cronet not contain any list, as per the second half of comment #34.

I'm not sure the second half of comment #34 follows. Different browsers already ship different variations of the list, and any observed HSTS effects could come from the header, which Cronet does process, with or without the preload.

The list is also not quite a no-op for applications that provide https URLs. If a site mistakenly redirects to an http URL, HSTS fixes this. Whether that's worth shipping such a giant list is another question. I do actually think it's reasonable to either omit or trim the list, but it's not quite zero value.

(There's also some Expect-CT preload stuff in there now. I'm not familiar on what that one does.)

Of course, removing the list also means Cronet must never ship an API to allow callers to bypass certificate errors. That is one of the biggest benefits of HSTS in the browser world where we're stuck with that click-through.

> Chrome should contain the complete list.

Chrome may not be able to contain the list in the near future. The list may grow to hundreds of thousands (or millions) of entries within the next year or two.

> Chrome may not be able to contain the list in the near future. The list may grow to hundreds of thousands (or millions) of entries within the next year or two.
Sounds reasonable to me. Whether Chrome chooses to ship the entire list in official binary is a different issue. Why is it blocking CL (https://codereview.chromium.org/2906633003/) ?

> Why is it blocking CL (https://codereview.chromium.org/2906633003/) ?

If a shortened list is acceptable, then I think we should implement that instead of adding a new (much less secure) configuration flag.

It was kind of an OKR for me this quarter to figure out, but it looks like I'll be doing it in Q3.

Can anyone provide me with a target maximum binary size for the preload list data to see if I can base a reasonable proposal around pruning to e.g. the top million sites?

I can't speak for Chrome. But for Cronet, having a shortened list is better than having the entire list, assuming that the shortened list won't grow arbitrarily large. Same as pauljensen@ in #39, I prefer Cronet contain no entries at all.

There are currently 29034 entries as of M61. The entries total 258KB in release build. Cronet is ~1-2MB in release build. 1% of that gives us 10-20KB. 10KB is enough for 1000 entries. Anything bigger than 1000 entries (or 1% of Cronet) is substantial from a binary size standpoint. 

I'm not sure Comment #34 is entirely accurate. The determination of this depends on what "Cronet" is intended for - and that's entirely ambiguous. If it is, for example, used in a chat application, then you very much want to ensure that a link to http://example.com/img.jpg is appropriately updated.

If the point is a 'general purpose networking', it's worth noting that on other platforms, HSTS is part of system services.

I'm also not entirely comfortable with the evaluation here, particularly in Comment #31. This largely evaluates the HSTS list from the perspective of Cronet, but doesn't consider the overall question about maintenance costs of maintaining additional build configurations (which can only be expressed by distinct buildbots), of which some configurations will be 'not supported' (and not part of the waterfall). Specifically, setting HSTS on Cronet would now move into the 'not supported configuration', even though it'd be a legal build configuration.

From a general code maintenance, it now becomes incumbent on every developer (which includes not just //net reviewers, but extends to those performing security reviews and feature evaluations) about the caveats on when certain invariants are true or not true. This is a cost that extends beyond the question of "does this feature sound right", and gets into the question of "Is this feature justified for the cost it brings, and the overall direction and goals of Chromium". If the answer is yes - that introducing this complexity into Chrome is worth it for Cronet - then so be it. But that seems to need to be the evaluation - is the code complexity, even incremental, aligned with the long-term goals and needs.

I'm encouraged by the discussion related about restricting that limit. Similarly, I'm encouraged by objective metrics for what size is appropriate. It sounds like 10-20KB is the target (which should be more than 1000 entries, in practice, but for reasons related moreso to the distinction between HPKP and HSTS, AIUI)

#31 is focused on "product" tradeoffs for HSTS and Cronet but not on
engineering overhead - correct that it was elided.

I'll trust folks who are more in the code to have more informed decisions
and make call on that aspect. However, even if it is a legal build
configuration, the current Cronet process automatically alerts on size
regressions and is tackled quickly. I would expect that an inadvertent
setting would get quickly caught. My rough guess is that this would be
easier to maintain than keeping a small subset list around, but that's a
wild-guess.

We (cbentzel, lgarron, mef, sleevi, xunjieli) met on June 27 to discuss this.

At a high-level we decided that it made sense to remove the HSTS preload for Cronet due to size as well as support for isCleartextPermitted.

There were open questions about how to remove support for it. In particular, using a feature flag was not seen as a great option due to concern about conceptual overhead. There was interest in making this a cronet only build config.

---
More detailed meeting notes:

From a product perspective, is it beneficial to remove the HSTS preload list from Cronet?
  * Answer: Yes. Saves 200-300KB of data, and isCleartextPermitted may address many of the needs for it.
  * Caveats: isCleartextPermitted only on newer Android, requires app developers to specify in manifests
  * On iOS, we don’t support ATS.
  * AI(mgersh?): See if isCleartextPermitted works on redirects or only initial requests.
  * AI(mef/xunjieli): See if concerns from cronet embedders.

How should we remove the preload list?
  * Answer: Likely do this with a Cronet-specific build configuration.
  * Concern about using feature flags for this - in general those are being disabled.
  * Need to be concerned about cognitive load, and not just enabling the feature on Cronet inadvertently, but disabling the feature on other platforms inadvertantly.
  * AI(mef/xunjieli): Talk to brettw about how to best accomplish this, likely in CL.


What about reducing the size of the preload list?
  * Answer: Might be interesting, not going to delay for it though. 
  * Analysis of top 1,000,000 domains showed only 2000 domains covered by list.
  * Current approach for preload list is about 8 bytes/domain, so 16KB to cover this.
  * At some threshold of size, supporting this may make sense.
  * But since not being actively worked on now, not going to delay decision on it.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/815ad5ba47f22bdfa7ac523048285e873a74aaac

commit 815ad5ba47f22bdfa7ac523048285e873a74aaac
Author: xunjieli <xunjieli@chromium.org>
Date: Tue Jul 18 15:51:35 2017

Add a build flag to configure bundling of HSTS preload list

This CL adds a build flag (INCLUDE_TRANSPORT_SECURITY_STATE_PRELOAD_LIST)
for //net embedders to configure whether to include the preload list
(~258KiB) in their binary.

BUG= 603597 

Review-Url: https://codereview.chromium.org/2906633003
Cr-Commit-Position: refs/heads/master@{#487486}

[modify] https://crrev.com/815ad5ba47f22bdfa7ac523048285e873a74aaac/net/BUILD.gn
[modify] https://crrev.com/815ad5ba47f22bdfa7ac523048285e873a74aaac/net/features.gni
[modify] https://crrev.com/815ad5ba47f22bdfa7ac523048285e873a74aaac/net/http/BUILD.gn
[modify] https://crrev.com/815ad5ba47f22bdfa7ac523048285e873a74aaac/net/http/http_security_headers_unittest.cc
[modify] https://crrev.com/815ad5ba47f22bdfa7ac523048285e873a74aaac/net/http/transport_security_state.cc
[add] https://crrev.com/815ad5ba47f22bdfa7ac523048285e873a74aaac/net/http/transport_security_state_source.cc
[modify] https://crrev.com/815ad5ba47f22bdfa7ac523048285e873a74aaac/net/http/transport_security_state_source.h
[modify] https://crrev.com/815ad5ba47f22bdfa7ac523048285e873a74aaac/net/http/transport_security_state_static.template
[modify] https://crrev.com/815ad5ba47f22bdfa7ac523048285e873a74aaac/net/http/transport_security_state_static_unittest.template
[add] https://crrev.com/815ad5ba47f22bdfa7ac523048285e873a74aaac/net/http/transport_security_state_static_unittest0.json
[modify] https://crrev.com/815ad5ba47f22bdfa7ac523048285e873a74aaac/net/http/transport_security_state_unittest.cc
[modify] https://crrev.com/815ad5ba47f22bdfa7ac523048285e873a74aaac/net/url_request/url_request_unittest.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/db32d2494d07110d282c283970d82174305936d1

commit db32d2494d07110d282c283970d82174305936d1
Author: Helen Li <xunjieli@chromium.org>
Date: Wed Jul 19 17:05:00 2017

[Cronet] use include_transport_security_state_preload_list=false on bots

This CL adds a build flag include_transport_security_state_preload_list=false
on Cronet bots. For more details please see the linked bug.

Bug:  603597 
Change-Id: I0b0a85a6c7d296bf5b94e4f17c38ed10ca38f9b0
Reviewed-on: https://chromium-review.googlesource.com/577592
Reviewed-by: Misha Efimov <mef@chromium.org>
Reviewed-by: John Budorick <jbudorick@chromium.org>
Commit-Queue: Helen Li <xunjieli@chromium.org>
Cr-Commit-Position: refs/heads/master@{#487891}
[modify] https://crrev.com/db32d2494d07110d282c283970d82174305936d1/components/cronet/tools/cr_cronet.py
[modify] https://crrev.com/db32d2494d07110d282c283970d82174305936d1/tools/mb/mb_config.pyl

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/chrome/ios_internal.git/+/a214432e8abe7c33bd5f1685476db9c0116399c4

commit a214432e8abe7c33bd5f1685476db9c0116399c4
Author: mef <mef@google.com>
Date: Wed Jul 19 22:48:31 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/277c0ac43676f083b34ec659733445e57790862e

commit 277c0ac43676f083b34ec659733445e57790862e
Author: Misha Efimov <mef@chromium.org>
Date: Thu Jul 20 15:31:21 2017

[Cronet] Use include_transport_security_state_preload_list=false on iOS

Bug:  603597 
Cq-Include-Trybots: master.tryserver.chromium.android:android_cronet_tester
Change-Id: Iac6d62d60df1bc56b26fbb9895af0282940bf5fb
Reviewed-on: https://chromium-review.googlesource.com/577956
Reviewed-by: Sylvain Defresne <sdefresne@chromium.org>
Reviewed-by: Helen Li <xunjieli@chromium.org>
Commit-Queue: Misha Efimov <mef@chromium.org>
Cr-Commit-Position: refs/heads/master@{#488253}
[modify] https://crrev.com/277c0ac43676f083b34ec659733445e57790862e/components/cronet/tools/package_ios.py
[modify] https://crrev.com/277c0ac43676f083b34ec659733445e57790862e/ios/build/bots/chromium.fyi/ios-simulator-cronet.json

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/tools/build/+/fe38657a166ce529e9da1294698d87caebce8f72

commit fe38657a166ce529e9da1294698d87caebce8f72
Author: Helen Li <xunjieli@chromium.org>
Date: Thu Jul 20 15:58:11 2017

[cronet] use include_transport_security_state_preload_list=false on internal bots

Bug:603597
Change-Id: I8e3833ac46f526170761da013439940b9a307c60
Reviewed-on: https://chromium-review.googlesource.com/578497
Commit-Queue: Helen Li <xunjieli@chromium.org>
Reviewed-by: John Budorick <jbudorick@chromium.org>

[modify] https://crrev.com/fe38657a166ce529e9da1294698d87caebce8f72/scripts/slave/recipe_modules/chromium_android/chromium_config.py
[modify] https://crrev.com/fe38657a166ce529e9da1294698d87caebce8f72/scripts/slave/recipe_modules/cronet/examples/full.expected/gn_test.json

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/chrome/ios_internal.git/+/0d8446529ee568cc9f145e6017e3c18555bc0628

commit 0d8446529ee568cc9f145e6017e3c18555bc0628
Author: mef <mef@google.com>
Date: Fri Jul 21 22:33:56 2017