Don't persist HPKP if PrivacyMode is enabled.

net/socket_stream/socket_stream.cc

Index: net/socket_stream/socket_stream.cc
diff --git a/net/socket_stream/socket_stream.cc b/net/socket_stream/socket_stream.cc
index dca994cbada9b69c30b60eeaa877196c9dcea692..6353df7818be6560f7c0b44c818279ca781b1d22 100644
--- a/net/socket_stream/socket_stream.cc
+++ b/net/socket_stream/socket_stream.cc
@@ -1306,9 +1306,12 @@ int SocketStream::HandleCertificateError(int result) {
   ssl_socket->GetSSLInfo(&ssl_info);
 
   TransportSecurityState::DomainState domain_state;
-  const bool fatal = context_->transport_security_state() &&
-      context_->transport_security_state()->GetDomainState(url_.host(),
+  const bool fatal =
+      context_->transport_security_state() &&
+      context_->transport_security_state()->GetDomainState(
+          url_.host(),
           SSLConfigService::IsSNIAvailable(context_->ssl_config_service()),
+          delegate_->CanGetCookies(this, url_),

[palmer, 2013/07/29 21:44:49]

This stops requests from *using* dynamic state in privacy mode; but really, all
we want to do is to stop dynamic state from being created and stored as a result
of requests made in privacy mode. That seems wrong to me, because it means that
if we by some chance had good dynamic state for example.com (user had visited
the site before not in privacy mode), but we were loading an iframe for (say) an
ad from example.com, that we would load that ad without the benefit of HSTS or
HPKP, or with outdated static HSTS/HPKP (!).

Right? Or am I confused again. That happens.

[Ryan Sleevi, 2013/08/06 22:32:11]

Are we sure that "url_" is correct here?

When looking at WebSockets, it seems it does some URL rewriting (see
https://code.google.com/p/chromium/codesearch#chromium/src/net/websockets/web...
), which this would be oblivious to.

[mef, 2013/08/09 17:04:05]

Hmm, the rewrite in WebSocketJob::GetURLForCookies() only seems to change the
schema, so it shouldn't affect result of CanGetCookies as that is based on
hostname pattern matching. 

[Ryan Sleevi, 2013/08/09 17:42:30]

That's what doesn't make sense - why rewrite the URL scheme (which effectively
changes the origin) if the cookie subsystem is going to ignore origin?

I'll readily admit that I didn't dig too far into this, other than noting that
the existing behaviour of SocketStream in the presence of WSS is to call
Delegate::CanGetCookies() with GetURLForCookies(), and that's a behaviour that
isn't matched here (as a WSS socket will layer atop this and get this default
behaviour)

I don't have a good answer, other than asking you to try to trace through and
see what the implications are, and if it's a bug that we should fix (either
CanGetCookies() doesn't need GetURLForCookies(), and that should be changed, or
we need to fix this code to be consistent). I just want to make sure we're
reliably giving the same URL to CanGetCookies(), whether for the TSS data or for
actual cookies.

Hopefully that makes sense?

           &domain_state) &&
       domain_state.ShouldSSLErrorsBeFatal();