Implement a skeleton version of Expect CT reports

chrome/browser/ssl/chrome_expect_ct_reporter.cc

Index: chrome/browser/ssl/chrome_expect_ct_reporter.cc
diff --git a/chrome/browser/ssl/chrome_expect_ct_reporter.cc b/chrome/browser/ssl/chrome_expect_ct_reporter.cc
new file mode 100644
index 0000000000000000000000000000000000000000..3adfe47975da42907cbbde12cf572459fb6b3701
--- /dev/null
+++ b/chrome/browser/ssl/chrome_expect_ct_reporter.cc
@@ -0,0 +1,27 @@
+// Copyright 2015 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/browser/ssl/chrome_expect_ct_reporter.h"
+
+#include <string>
+
+#include "net/url_request/certificate_report_sender.h"
+#include "net/url_request/url_request.h"
+#include "net/url_request/url_request_context.h"

[mmenke, 2016/03/07 18:28:08]

The last two includes are not currently used in this file, and I don't think the
url_request or the url_request_context is likely to be used by this class (The
certificate_report_sender will presumably be the thing using them).

[estark, 2016/03/08 02:36:06]

Done.

[estark, 2016/03/08 02:36:06]

Done.

+
+ChromeExpectCTReporter::ChromeExpectCTReporter(

[mmenke, 2016/03/07 18:28:08]

Is there going to be anything Chrome specific about this class?  It's currently
a chrome/browser class that links the
net::TransportSecurityState::ExpectCTReporter API with a
net::CertificateReportSender.

Given that those are both in net/, unless there's going to be some
Chrome-specific magic, seems like it belongs in there as well.  Unless it also
talks to Google server or something, though then I'd suggest putting the core
logic in net/, and adding an observer of some sort or something.

[estark, 2016/03/07 22:20:32]

I did it this way (ChromeExpectCTReporter instead of all the logic in //net)
because, initially, Expect CT is going to be a pretty Googley feature while it's
in a sort of prototype phase. We're not yet specifying or standardizing it any
remotely formal way, and initially, we're only going to allow reports to be sent
to Google servers (so that we can, for example, tweak the policies and reporting
logic without worrying about DoSing other site owners). I was thinking that
other embedders would probably not want this feature in its current immature
state, and the more report-building and -sending logic we include in //net, the
more wasteful this feature will be for them. So I was imagining that all the
logic would end up in //net as the feature "grows up" a little bit, but not
while it's in this rather Google-specific prototype phase. What do you think?

[mmenke, 2016/03/07 23:08:12]

Hrm...Then it seems a little weird that CertificateReportSender is in net/. 
Anyhow, if this is just to talk to Google, having it here makes sense.

[estark, 2016/03/08 02:36:06]

net::CertificateReportSender is used by other things as well, including HPKP
reporting (implemented entirely in //net) and Safe Browsing Extended Reporting
certificate reports (implemented in a component).

+    net::URLRequestContext* request_context)
+    : report_sender_(new net::CertificateReportSender(
+          request_context,
+          net::CertificateReportSender::DO_NOT_SEND_COOKIES)) {}
+
+ChromeExpectCTReporter::~ChromeExpectCTReporter() {}
+
+void ChromeExpectCTReporter::OnExpectCTFailed(
+    const net::HostPortPair& host_port_pair,
+    const GURL& report_uri,
+    const net::SSLInfo& ssl_info) {
+  // TODO(estark): build and send a report about the policy
+  // violation. https://crbug.com/568806
+}