Add metrics to record TCP/UDP connections made from Flash

content/browser/renderer_host/pepper/pepper_udp_socket_message_filter.cc

Index: content/browser/renderer_host/pepper/pepper_udp_socket_message_filter.cc
diff --git a/content/browser/renderer_host/pepper/pepper_udp_socket_message_filter.cc b/content/browser/renderer_host/pepper/pepper_udp_socket_message_filter.cc
index dd177131a6f642dbd959179ca71bc7f2caeb0ab1..e1cd653d1a84395636e622ad6e46b61ec69a9a58 100644
--- a/content/browser/renderer_host/pepper/pepper_udp_socket_message_filter.cc
+++ b/content/browser/renderer_host/pepper/pepper_udp_socket_message_filter.cc
@@ -60,7 +60,8 @@ PepperUDPSocketMessageFilter::PepperUDPSocketMessageFilter(
     BrowserPpapiHostImpl* host,
     PP_Instance instance,
     bool private_api)
-    : socket_options_(0),
+    : host_(host),
+      socket_options_(0),
       rcvbuf_size_(0),
       sndbuf_size_(0),
       multicast_ttl_(0),
@@ -645,6 +646,9 @@ void PepperUDPSocketMessageFilter::SendBindReply(
     const ppapi::host::ReplyMessageContext& context,
     int32_t result,
     const PP_NetAddress_Private& addr) {
+  pepper_socket_utils::RecordFlashConnectMetric(
+      host_->GetPluginName(),
+      host_->GetPluginURLForInstance(resource_host()->pp_instance()));
   ppapi::host::ReplyMessageContext reply_context(context);

[raymes, 2015/05/11 06:44:21]

I'm not sure what you mean here? I'm not sure what the "effective origin" is :(
This is purely based on the URL where the .swf is served from. Is that the wrong
URL to use? Should we be checking all URLs in the frame hierarchy?

[jww, 2015/05/11 06:51:14]

In Blink, we do have a complex hierarchy traversal to determine what's a
priveleged context (see isPrivilegedContext:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...)

Unfortunately, I don't believe we have an equivalent calculation for the browser
process. sleevi@, should that be replicated for this?

[Ryan Sleevi, 2015/05/11 07:07:43]

Ultimately, that's what will decide API blocking behaviour, so I think we do.

That is, per spec, if an HTTP page is framing an HTTPS plugin, it *should* be
blocked. WebCrypto is the sole exception that only looks at the loading page
(and that's less than ideal)
Well, that's not the only way to solve it. Another would be to gather these
metrics on the renderer side.

I'm surprised the API security checks live in Blink - that seems to be a
violation of our "don't trust the renderer" security model. But gathering this
data in the renderer seems also viable to providing us quantifiable data.

[jww, 2015/05/11 22:58:03]

There are many Web-level API security checks that live in Blink (think all of
CSP, mixed content, etc.). We don't trust the renderer for any system level
security decisions, but we do trust the renderer for Web spec security
decisions.

In theory, we should and can move them out eventually, but that's an exceedingly
large undertaking, and in most cases only really meaningful once site isolation
exists.

   reply_context.params.set_result(result);
   SendReply(reply_context, PpapiPluginMsg_UDPSocket_BindReply(addr));