Non-Browser Vendor Supplied Push Server Support

[msporny]

Hi all,

We (Digital Bazaar, W3C Member company) will soon be using the Web Push API in production, so first off, thanks for this feature/functionality. It's great and enabled us to deploy our digital wallet products to mobile using the Web Platform instead of native apps.

I've read through every issue that I could find relating to push service registration and note that the push service that one uses effectively boils down to either Google's servers or Mozilla's servers. While I understand the desire to get this deployed in a way that's easy for Web Developers, that the Push Notifications go through servers that we don't control is a problem for some of our more security conscious customers. We do realize that payloads can be encrypted, but we'd rather just run a Web Push service ourselves (again, it ticks a box for our customers).

My understanding is that there is no intention to support a more decentralized model for the Web Push servers and one MUST depend on the centralized Google or Mozilla servers. I haven't been involved in Web Standards for long, just over a decade, but I can't think of any other Web Platform spec that requires proprietary services (other than EME) to operate.

Has the thinking of this changed lately? If so, is there a timeline for supporting non-browser vendor supplied Push server services?

[beverloo]

Hi Manu, exciting to hear that you'll soon be rolling out support for Web Push!

Mobile devices were the primary motivation for the Push API. They come with a series of unique constraints, notably that they're battery powered. They also usually come with built-in push services that are available to every application installed on the device. By enabling multiple applications to share a connection instead of each establishing their own, a very substantial amount of power can be saved. (Networking, specifically the radio on a mobile device, tends to be the largest contributor to battery usage after the screen.)

The Push API exists to enable web applications to benefit from this connection.

We've decided against supporting a bring-your-own-push-service model because establishing multiple connections goes against the goals of the Push API. It has a significant negative impact on the user (by draining their battery faster), and is, in fact, very hard to impossible to support on various mobile platforms.

As you note, this comes with important privacy and security considerations. For that reason the Push API goes hand-in-hand with the Web Push Protocol (RFC8030) standardized at the IETF. It specifically designates the intermediaries —the push services— as untrusted. In effect, we require end-to-end encryption for messages, and give you some other tools such as message padding to even hide things like the length of your payload.

[martinthomson]

This is a very common question. Peter captured this well. RFC 8030 is careful to describe the same constraints.

[msporny]

@beverloo @martinthomson While I can understand some of the technical reasons, note that going through a single set of servers, even if the data is encrypted, enables data mining and creates privacy issues. For example, one of our use cases is retailers pushing digital offers (coupons, sales, etc.) to their loyalty customers. When, where, and to whom this data is pushed from and to, even if it is encrypted, has economic value to competitors in the marketplace.

So, the answer can't be as simple as "just encrypt the payload", because the delivery information cannot be encrypted.

I'm at IETF 98 in Chicago this week and I'll check in with a couple of folks, including one of the editors of the WebRTC spec, wrt. numbers on battery/radio usage for the Web Push Protocol (as well as other protocols).

Even selection among a set of bounded push servers would be better than not having the ability to select at all.

[Solzhenitsyn]

Hi Manu, Please see Previous discussions

The good news is GCM/FCM Firecast has provided a browser agnostic API for talking to the leading feature-rich push-message provider in the market. This is truly revolutionary and, IMHO, with herald the demise of Mozilla's autopush effort

FYI I have also lobbied the European Commissioner regarding the anti-competitive practices of bundling push functionality with Web Browsers even more so than it has with Search Engines that can at least be overridden. Press release

For your security requirements I agree that letting a marketing competitor (and push service provider) know your customers and activity is unacceptable and makes a mockery of the half-pregnant " It specifically designates the intermediaries —the push services— as untrusted."

[Solzhenitsyn]

Manu this is the letter I sent to the European Commission requesting intervention in the current anti-competitive push-service market: -

From: Richard's Hotmail Sent: Monday, July 18, 2016 7:54 PM To: 'comp-greffe-antitrust@ec.europa.eu' Subject: Re: Competition Case - 40099 Google Android

Further to the above case currently before the European Commission ( http://ec.europa.eu/competition/elojade/isef/case_details.cfm?proc_code=1_40099 ), I wish to bring to your attention to what, in my view, is potentially a far more egregious example of Google's abuse of market dominance in the Android market place.

Unlike the "search service" referenced in the original case before the Commission, my complaint deals with the deployment of Google's "push notification service" Google-Cloud-Messaging (GCM), or as it has recently been rebadged, Firebase-Cloud-Messaging (FCM).

Whereas a Search Service can be easily changed via a user-selectable browser Option, the choice of Push Service for all Android Chrome, Opera, and Samsung/Android browser users is mandated to be Google's GCM Push Service. This bundling of services is hidden from the users' view and incapable of modification on the 3 browsers mentioned. (For an example of a browser that does facilitate a choice of Push Service, please see Mozilla's Firefox. The Firefox Configuration Editor (about:config page) currently permits the user to select a different push service via the services.push.serverURL parameter)

With GCM's monopoly of exclusive deployment to the 3 most popular Android Web Browsers, access to the Push Service market is hindered for all other Push Service providers, especially if they do not also happen to be browser manufacturers. Thus they are excluded by Google from the opportunity of competing on price, service, or features.

Additional points of relevance: - [1] The specifications dealing with plug-and-play standards for browsers and Push Notification Services are: -- Client https://www.w3.org/TR/push-api/ -- Server https://tools.ietf.org/html/draft-ietf-webpush-protocol-07
[2] Any interim opinion or decision from the Commission would be quite timely as Microsoft is currently implementing the Push API for its own Edge browser. As with Google's GCM on Android, Microsoft's Azure Notification Hubs should not be permitted to monopolize the Push Service market on Windows/Edge. [3] I have no knowledge of any business relationships that Opera and/or Samsung have with Google regarding their deployment of GCM clients, or why Samsung have self-limited their Push Service target-market to "only for Samsung services (Samsung Apps, Samsung Link, Samsung Wallet, Samsung Pay, etc.)" [4] Push Notification functionality, in its current form, is very new to the browser world but destined for ubiquitous HTML5 Web App deployment. We must ensure that competition can thrive. [5] I do not envisage that Google wrote specific or individual GCM APIs for Samsung and Opera. Therefore I see no reason why this GCM API cannot be made available to Firefox users as well. As much as one Chrome user may choose to use Mozilla's Autopush Notification Service, another browser user may wish to use GCM for their Firefox notifications.

Please don't hesitate to contact me if should you require clarification of additional information.

Please also note that the above is purely my personal opinion. I trust you'll agree that it merits further investigation.

Regards, Richard Maher

™ All trademarks are the property of their respective owners.

[beverloo]

@msporny Sure, I'd love to hear about your findings. From experience, establishing a connection with a push service is not hard - maintaining the connection on a variety of devices, network conditions and carrier networks is.

@Solzhenitsyn I believe that we've repeatedly asked you to leave our repositories alone. Please take your concerns elsewhere. /cc @LJWatson @sideshowbarker

[buhrmi]

@beverloo I can't find anything in RFC8030 where it specifically designates push services as untrusted. At least that aspect of argumentation appears rather baseless.

[martinthomson]

@buhrmi, this is pretty extensively discussed in the Security Considerations section of RFC 8030: https://tools.ietf.org/html/rfc8030#section-8.1