Partial implementation of subscription restrictions.

content/public/common/content_push_subscription_options.h

+// Copyright 2016 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.
+
+#ifndef CONTENT_PUBLIC_COMMON_CONTENT_PUSH_SUBSCRIPTION_OPTIONS_H_
+#define CONTENT_PUBLIC_COMMON_CONTENT_PUSH_SUBSCRIPTION_OPTIONS_H_
+
+#include <string>
+
+#include "content/common/content_export.h"
+
+namespace content {
+
+// Structure to hold the options provided from the web app developer as
+// part of asking for a new push subscription.
+struct CONTENT_EXPORT ContentPushSubscriptionOptions {

[Peter Beverloo, 2016/02/17 16:15:35]

nit: no need to prefix with "Content", it's namespaced. (As is
blink::PushSubscriptionOptions, by the way.)

[harkness, 2016/02/18 10:45:14]

Done.

+  ContentPushSubscriptionOptions() {}
+  ~ContentPushSubscriptionOptions() {}
+
+  // Whether or not the app developer agrees to provide user visible
+  // notifications whenever they receive a push message.
+  bool user_visible_only;

[Peter Beverloo, 2016/02/17 16:15:35]

Please make sure that we assign default values to scalar members, right now
they'll be initialized with garbage.

(Either in the constructor's initialization list, or in-line in the class
declaration.)

[harkness, 2016/02/18 10:45:15]

Done.

+
+  // Whether the protocol for communicating with the GCM is using
+  // an ID for the app service or is using the app service's public key.
+  bool using_public_key;

[Peter Beverloo, 2016/02/17 16:15:35]

Why is it significant for the browser process to know this? This also relates to
the branch you have in push_messaging_message_filter.cc:280 - why would we store
them differently?

Theoretically a Web developer can pass the applicationServerKey in the
gcm_sender_id field of the manifest (which is of type string).

From the GCM point of view, we give it an opaque identifier. The //chrome layer
and the GCM Driver don't care whether this is a sender Id or a public key, it's
the server that verifies this.

This would change how we validate the input in the browser process a bit. Right
now we assume that whatever we get is valid and use it, but we can tighten that
up a little bit. The two options are:

  (1) A sender id, e.g. parseable as a number.
  (2) An application server key, which must be an uncompressed P-256 EC point of
65 bytes.

[harkness, 2016/02/18 10:45:14]

I was thinking that we would do verification also in the renderer process (I've
got a TODO in the code to add that check), but given that we don't trust that,
maybe a single check in the browser process is the better place. However, I do
think that it's useful to have this flag in the renderer process, because we can
skip loading the manifest entirely if the developer gives us an
applicationServerKey. 

[Peter Beverloo, 2016/02/18 11:39:43]

Yes, but why is this flag significant for that? The following implication will
exist anywhere in our renderer code:

|using_public_key == !options.applicationServerKey.isEmpty()|

If the value doesn't have to leave the renderer, I don't think we have to
include it in this file.

+
+  // The unique identifier of the application service which is used to
+  // verify the push message before delivery. This could either be an ID
+  // assigned by the developer console or the app server's public key.
+  std::string sender_info;
+};
+
+}  // namespace content
+
+#endif  // CONTENT_PUBLIC_COMMON_CONTENT_PUSH_SUBSCRIPTION_OPTIONS_H_