Remember user decisions on invalid certificates behind a flag

chrome/common/pref_names.cc

Index: chrome/common/pref_names.cc
diff --git a/chrome/common/pref_names.cc b/chrome/common/pref_names.cc
index cdfe00384056b97dc14f989714eaa8cacc54cda8..030886963d05c34026c481db919f9799b0be6729 100644
--- a/chrome/common/pref_names.cc
+++ b/chrome/common/pref_names.cc
@@ -1261,6 +1261,10 @@ const char kSSLVersionMax[] = "ssl.version_max";
 const char kCipherSuiteBlacklist[] = "ssl.cipher_suites.blacklist";
 const char kDisableSSLRecordSplitting[] = "ssl.ssl_record_splitting.disabled";
 
+// Dictionary of dates when a site's SSL blocking interstitial was proceeded
+// through.
+const char kSSLBlockingBypassed[] = "ssl.ssl_blocking_bypassed";

[Ryan Sleevi, 2014/07/08 23:53:29]

Does seem wrong to store this in prefs, potentially for a lot of sites the user
visits.

We're having this same debate in //net land

Let's not forget, every pref you add blocks Chrome's startup - even from
starting up other threads. This is a Bad Thing. Separate storage - even if it's
just a single Flat File, but that can be loaded after start-up (and only on a
bad cert?) is a Good Thing.

[jww, 2014/07/11 00:08:41]

This was the model suggested by jschuh since it is a user choice. I think my two
thoughts as to why this is the right design is:
(a) This is not that common of a case. Most users will not have loads of these
sitting in their preferences.
(b) My understanding is that prefs will be improving quite a bit in the
not-too-distant future, so this should be less of an issue. I think they're
being reworking into a DB of some sort.

[Ryan Sleevi, 2014/07/11 00:48:49]

What do we do for content settings today - like which sites to enable images on
or disable them?

If that's prefs, then I can live with it.
If it's not (and I didn't think it was), we shouldn't be doing that here.

[jww, 2014/07/11 01:52:07]

These are all stored in preferences. For example, I'm looking at my profile's
preferences file right now, and it has entries for all the sites where I allow
plugins to run (since I block by default).

My understanding is that in the general case, content settings defaults to store
things in the preferences file; I'm not if, with content settings, you can back
it by anything else. At any rate, that's why they're working to improve the
preferences storage mechanism.

+
 // A boolean pref of the EULA accepted flag.
 const char kEulaAccepted[] = "EulaAccepted";