Reporting: Plumb into RenderFrame via Mojo

content/common/net/reporting.mojom

+// Copyright 2017 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.
+
+module content.mojom;
+
+import "mojo/common/values.mojom";
+import "url/mojo/url.mojom";
+
+interface ReportingServiceProxy {
+  // Attempts to queue a report using the Reporting API.

[Rick Byers, 2017/05/19 20:35:02]

What's the implications of "attempt" here?  I.e. in what ways can this fail, and
should we perhaps be exposing those failure down to blink?

[dcheng, 2017/05/22 09:30:38]

I guess this is a web spec somewhere, might be nice to link it.

+  //
+  // |url| is the URL that generated the report.
+  //
+  // |group| is the endpoint group that should receive the report. This should
+  // be configured for the feature using Reporting by the site that generated
+  // the report.
+  //
+  // |type| is the type of report (for example, "csp" or "hpkp"). This should be
+  // set to a fixed value by the feature using Reporting.

[dcheng, 2017/05/22 09:30:38]

Is something that could be represented as an enum, or is it mostly controlled by
web content?

[Julia Tuttle, 2017/05/22 14:30:41]

It could be an enum, I guess -- it is controlled by web specs (e.g. csp would
specify type "csp" for all reports), but not by web content, so we'd have an
enum entry for each Reporting feature that can send reports from the renderer.

Would that be preferable?

[dcheng, 2017/05/22 21:24:37]

Hmmm, I think so: in general we prefer to pass more structured types over ipc
rather than strings and then try to constrain the value of the strings.

+  //
+  // |body| is the body. It can be any valid Value.

[Rick Byers, 2017/05/19 20:35:02]

I was assuming this would be a string, not a base::Value.  But maybe base::Value
is better, so giving this a try sounds good to me.  But if we end up having
trouble properly converting a JS dictionary to a base::Value, would it be too
hard to change this to a JSON-serialized string instead?

In particular I'm thinking of possible minor spec conformance issues.  I think
the ReportingObserver spec will probably end up implying that running
JSON.stringify on the body object supplied to the observer would produce EXACTLY
the same JSON string that is included in the report body (there's been some
debate in the past from Mozilla folks about being precise around JSON here - eg.
so failure conditions are handled identically by different browsers).

[Julia Tuttle, 2017/05/22 14:30:41]

It wouldn't be super difficult to make this a JSON string, but I'd end up
parsing it on the browser side and then reserializing it along with other
reports when it's sent, so I can't promise it will be identical in the upload.

+  QueueReport(url.mojom.Url url,
+              string group,
+              string type,
+              mojo.common.mojom.Value body);
+};