Issue: Change Source of Push Service and Privacy Issues

[maxpassion]

1. There are internationalization issues regarding to the unclear availability of existing push services globally.
   The current spec relies on a browser having a single source for all push messages. It is better for the browser to have the ability to change the source of push service in case there is no availability of certain push service.

2. Also, there could be a privacy issue, if browser has to pass all the messages through one push service.

[beverloo]

Hi Max—could you point to the language that limits a user agent to a single push service? There is no need for a user agent to be limited to a single push service. I know of at least one UA that uses a different push service for particular countries.

We do restrict a Service Worker to an individual subscription, so it's not possible to have subscriptions with multiple push services for given specific Service Worker at once. If the user agent sees a need to switch, they could send a pushsubscriptionchange event with updated information.

Could you elaborate on the privacy issue? We require the payloads of all push messages to be encrypted, in a model where the push service explicitly is not trusted. (And thus cannot read the message's contents.) You're right that certain meta-data such as frequency and timing of messages will be known by the push service, but that's almost impossible to prevent.

[kepengli]

I am new to the Working Group. Please forgive me if I am wrong.

1. I think the issue is, whether the User Agent can subscribe multiple push services at the same time or not? If the User Agent can subscribe more than one Push Services, is it possible that the subscribed multiple Push Services can interact in some way, e.g. avoid to push the same messges?

2. About privacy issues, the Push Service knows what Application Servers the User Agent has subscibed, the Push Service already knows the user privacy, e.g. user wants to subcribe to some adult contents, and he does not want this to be known by others. Also, some Application Servers may not encrypt the push messages, in this way, Push Service can get the payloads of the push messages.

Thanks,
Kepeng

[beverloo]

Hi Kepeng,

I think the issue is, whether the User Agent can subscribe multiple push services at the same time or not? If the User Agent can subscribe more than one Push Services, is it possible that the subscribed multiple Push Services can interact in some way, e.g. avoid to push the same messges?

Neither the W3C Push API nor the IETF Web Push Protocol provide support for this sort of coordination. Is this a theoretic case, or are you aware of a user agent that's specifically looking to support this functionality?

About privacy issues, the Push Service knows what Application Servers the User Agent has subscibed, the Push Service already knows the user privacy, e.g. user wants to subcribe to some adult contents, and he does not want this to be known by others. Also, some Application Servers may not encrypt the push messages, in this way, Push Service can get the payloads of the push messages.

It's true that the Push Service could derive the source of a message by looking up the source's IP address, or the provided contact information in the VAPID JWT header. The ability to have subscriptions with multiple Push Services doesn't change that however, it just moves the problem to another actor.

The Push API mandates use of encryption for messages that include a payload. Even if the developer includes an unencrypted payload, it will never reach their JavaScript code.

[chaals]

@beverloo wrote:

The ability to have subscriptions with multiple Push Services doesn't change that however, it just moves the problem to another actor.

Sure. But it seems to me that not having a choice of actors is a pretty major limitation. While an app developer does not have access to the payloads, having a mandated pathway for messages seems like a pretty significant opportunity on the part of whoever controls that pathway to collect user metadata, and a pretty central point of attack for a malicious third party.

I understand there is a trade-off in terms of user interface design, and power consumption, but I'm not convinced that the architectural choice to sacrifice a lot of control over privacy is the right one.

[martinthomson]

There is choice here in the same way that there is choice of user agent. Sites don't have this choice, but then they don't choose the user agent either.

A user agent could offer a choice of push service. Firefox does, at least in theory: the push service is configurable and the source code for the service is open source (it doesn't use RFC 8030 which reduces the utility somewhat). You can imagine all sorts of schemes for managing this on a more granular basis, with certain sites getting subscriptions that route through different services. But that's still a user agent function, not a characteristic of the API.

[beverloo]

I uploaded #287 with a clarification about the implications of the user agent being responsible for selecting the push service.

[chaals]

see also #293 ...

[marcoscaceres]

Closing as answered.