Remember user decisions on invalid certificates behind a flag

chrome/common/pref_names.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "chrome/common/pref_names.h"
 
 #include "base/basictypes.h"
 #include "chrome/common/pref_font_webkit_names.h"
 
 namespace prefs {
@@ skipping 1243 matching lines @@
 
 // Prefs for SSLConfigServicePref.
 const char kCertRevocationCheckingEnabled[] = "ssl.rev_checking.enabled";
 const char kCertRevocationCheckingRequiredLocalAnchors[] =
     "ssl.rev_checking.required_for_local_anchors";
 const char kSSLVersionMin[] = "ssl.version_min";
 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";
 
 // Boolean that specifies whether or not crash reporting and metrics reporting
 // are sent over the network for analysis.
 const char kMetricsReportingEnabled[] =
     "user_experience_metrics.reporting_enabled";
 
 // Boolean that specifies whether or not crash reports are sent
 // over the network for analysis.
@@ skipping 1025 matching lines @@
 // "mapped_title" entries, detailing the bookmark target URL (if any), the title
 // given by the PartnerBookmarksProvider and either the user-visible renamed
 // title or an empty string if the bookmark node was removed.
 const char kPartnerBookmarkMappings[] = "partnerbookmarks.mappings";
 #endif
 
 // Whether DNS Quick Check is disabled in proxy resolution.
 const char kQuickCheckEnabled[] = "proxy.quick_check_enabled";
 
 }  // namespace prefs