Multiple registrations per origin/SW

[martinthomson]

I know that this was talked about previously, but I'd like to challenge that decision.

(I'm not clear whether the restriction is per origin or per service worker scope. I don't think that matters here.)

I have several reasons:

1. Origins can have multiple applications. Having them share a push notification registration is a significant burden on those applications. And even within those applications, separation of functions can be valuable. For example, an application as simple as gmail [sic] benefits from different notification channels for email, chat messages and calling, not to mention software update and a host of other things. Sure, the application can perform demux functions, but that creates a need for a centralized dispatcher: a function that the browser is performing anyway.
2. We have a request to support what GCM calls a collapse key. A function whereby only the last messages with the same key is delivered if a device is absent. This is much easier with the proposed protocol if multiple registrations (there, channels) can be created (it's basically a noop).
3. This has better privacy and security properties. A collapse key provides a way for the push server to identify correlation between unrelated events, which is unavoidable if you have the feature. However, with a special collapse key in addition to the registration, the push server is able to correlate un-collapsed messages for the same origin. Separate channels might still be activated by the same application server, revealing a correlation through the source IP of the push request, but that certainly isn't always the case. This also allows applications to more finely control disclosure of registration information.

[mvano]

In the current design, there can be one PushRegistration per ServiceWorkerRegistration.

1: Origins can have multiple applications, but usually they have different paths. Service worker scopes handle this. I see your point about having a centralized dispatcher inside a complex application. However, I don't see that as a big hurdle, given the complexity of the application I'm sure the engineers can handle it. They might want such a dispatcher anyway for other coordination reasons. I'm not yet convinced this requires a more complex API.

1. I'm not sure what you mean here. Collapse keys currently work just fine with GCM, which also use a single push registration.
2. Doesn't the problem of correlation go away with encryption? Or does it weaken encryption? Anyway, there are other, very explicit, signals for correlation in GCM such as sender_id, application_id, and api_key. This is for good reason, they are used to combat abuse like spam or DOS attacks. What system are you thinking of that does not do that? How does it fight abuse?

[martinthomson]

OK, that numbering is very confusing...

Origins can have multiple applications, but usually they have different paths. Service worker scopes handle this. I see your point about having a centralized dispatcher inside a complex application. However, I don't see that as a big hurdle, given the complexity of the application I'm sure the engineers can handle it. They might want such a dispatcher anyway for other coordination reasons. I'm not yet convinced this requires a more complex API.

I don't consider this especially important, but it is a marginal advantage.

Creating an unnecessary dependency on URL structure is a bad idea in my opinion. But evidently I've been unable to convince anyone at Google of that point.

I'm not sure what you mean here. Collapse keys currently work just fine with GCM, which also use a single push registration.

The proposed protocol effectively has a fixed collapse key for each registration (or channel). Only one message is "stored" for a given channel, making the channel equivalent to a single, fixed collapse key.

Given this property, it's easier to create more channels than it is to add the feature in some other way. This is the main reason.

Doesn't the problem of correlation go away with encryption? Or does it weaken encryption? Anyway, there are other, very explicit, signals for correlation in GCM such as sender_id, application_id, and api_key. This is for good reason, they are used to combat abuse like spam or DOS attacks. What system are you thinking of that does not do that? How does it fight abuse?

The adversary here is GCM (and its ilk). We've basically eliminated most other adversaries, giving them only traffic analysis to determine where messages are coming from and going to.

GCM isn't going to get much from the web application any more. All it has are signals from the device. Otherwise, there is no advantage to the open web.

The mechanisms that a push server can use to fight abuse are obviously more limited than they might have been with full access to message content. The push server can't look to see that messages it is forwarding are all replayed, it can't authenticate applications, it can't even correlate very well. But it can identify message volume from particular application and to particular devices. The former is perhaps trickier (DDoS issues are particularly nasty). And the latter is part of it's main responsibility. That is, the push server is there - at least in part - to shield devices from network noise.

I don't know what will be signaled to GCM from Chrome when a push registration is created, but there is some information available there. It could include origin - the moral equivalent of application_id, I suppose - but I'd rather this not be leaked if it isn't needed, and I'd argue that it's not. A potential enhancement is to have the device place restrictions on who can use the registration, but that would require API changes too.

Don't underestimate the value of selective disclosure when it comes to control. If you are receiving push messages from multiple different entities, then being able to selectively control access to the push server by giving each entity a different endpoint can be quite powerful. For instance, revocation is easier to handle.

[costinm]

GCM supports multiple senders because quite a few apps needed this feature, it's typical for larger applications/organizations where sending happens from different servers for different features of the app. The way it multi-sender works in GCM currently doesn't fit well with encryption and key rotations.

I would suggest allowing the API to specify some parameters to the register() method and not mandate single registration/sender, it would make the protocol future-proof and allow developers to take advantage of optional features.

[mvano]

Is the idea here that you don't want multiple senders to share the same single registration? Could you elaborate a bit on why that is a problem? I can see e.g. abuse filters blocking one registration but not the other.

[costinm]

Yes, the problem is that it's desirable to be able to rotate and update any
authorization token. If multiple senders ( in different organizations
or even companies ) share the same registration it creates coordination
problems - all of them share the same credentials.

Also if multiple senders are used it's good to know which sender sent a
message. You may have an app receiving
weather updates from a company, and account updates from a different one.
It's good for each entity to authenticate
with different credentials, and to know who sent the message (and that the
sender was verified).

It is relatively common use case - GCM for example doesn't do it very well
right now, it allows multiple senders but has a single
registration ID for all.

On Tue, Oct 21, 2014 at 9:46 AM, Michael van Ouwerkerk <
notifications@github.com> wrote:

Is the idea here that you don't want multiple senders to share the same
single registration? Could you elaborate a bit on why that is a problem? I
can see e.g. abuse filters blocking one registration but not the other.

—
Reply to this email directly or view it on GitHub
#71 (comment).

[mvano]

I'm convinced, it sounds like there are some use cases for having multiple subscriptions per webapp. A bad workaround is to share the subscription with multiple senders. A less bad workaround is to install a service worker for each sender, in order to acquire separate push subscriptions. A better API would be to support having multiple subscription per service worker.

[johnmellor]

Supporting multiple subscriptions per service worker can be backwards compatible with the existing spec, if we just add an optional subscription_name parameter to subscribe() and getSubscription().

[martinthomson]

Presumably the event needs the same name treatment. It can default to the empty string, I guess.

[martinthomson]

This has been OBE.