Add a build flag to configure bundling of HSTS preload list

net/features.gni

Index: net/features.gni
diff --git a/net/features.gni b/net/features.gni
index 95c718ebadb7edb2a72d3363d3936374c4e4fb3b..c031e3fecdfbd72cde86c4b121c66ae50023ec2b 100644
--- a/net/features.gni
+++ b/net/features.gni
@@ -30,4 +30,13 @@ declare_args() {
 
   # Reporting not used on iOS.
   enable_reporting = !is_ios
+
+  # Whether transport security preload list should be included. This flag should
+  # not be changed without examining the risks and tradeoffs.
+  # HTTP strict transport security (HSTS) is defined in
+  # http://tools.ietf.org/html/ietf-websec-strict-transport-sec.
+  # Changing this flag to false will disable bundling of
+  # net/http/transport_security_state_static.json, which enforces domains-
+  # configured HSTS settings.
+  include_transport_security_state_preload_list = true

[Ryan Sleevi, 2017/07/07 16:45:13]

In looking at the flags, I see a mix between positive and negative flags.

Given we want this to be the 'default' state, do you think it makes sense to
rewrite this to be a negative (e.g. "exclude"), which may signal more clearly
the assumptions being made?

It's not a very strong argument, and if there's existing documentation that says
to prefer positive over negative (e.g. to avoid the double-negative of "exclude
= false"), do so - but just a thought.

[xunjieli, 2017/07/10 22:20:39]

I slightly prefer the exclude_* version because (as you said) it signals that
that including the list is the default state. I used that in the original patch
but changed to include_* as lgarron@ doesn't like double negatives
(https://codereview.chromium.org/2906633003/#msg22).

lgarron@: Do you feel strongly about keeping this as a positive flag?
 

 }