Subject: [Webpush] Single subscription for multiple apps.

From: Costin Manolache <[email-masked]>
Date: Mon, 15 Jun 2015 11:35:12 -0700

Hi,

We discussed in the past the problem with returning a different
'subscription resource' for each subscription, and than having the UA issue
a separate GET on each one.

I think the conclusion was that:

1. A push service can return the same subscription URL for all apps on a
UA, and
the UA will than make a single GET - and retrieve messages for each app.

2. Push services may use other more efficient protocols for communication
between UA and webpush service.

For 1, I don't see any way for the UA to know how to dispatch to each app.

This could be resolved with 2 changes:
- adding the push resource ( ex /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx ) to
the push promise in section 6.3. In this case, the webpush service can
return a unique subscription resource for all apps running in the UA.

- in subscribe, include a new header containing the subscription resource
associated with the UA.
A UA will get an initial subscription (associated with the UA as a whole ),
and this will be referenced in all subscription requests for apps running
in the UA.

Without those changes - I don't think it'll be possible ( or at least not
easy ) to have a scalable and efficient implementation. Please let me know
if I missed something - it is not critical for GCM ( since 2 is likely to
be used as an alternative). I'll open a separate thread for receipts -
which have a similar problem.

Costin

---

From: Martin Thomson <[email-masked]>
Date: Mon, 15 Jun 2015 12:48:31 -0700

On 15 June 2015 at 11:35, Costin Manolache <[email-masked]> wrote:
> 1. A push service can return the same subscription URL for all apps on a UA,
> and

This isn't right. We need to have a different subscription URL for
each application for privacy reasons alone.

The dispatch problem is easier to solve if each application has its
own subscription.

---

From: Costin Manolache <[email-masked]>
Date: Mon, 15 Jun 2015 14:02:04 -0700

On Mon, Jun 15, 2015 at 12:48 PM, Martin Thomson <[email-masked]>
wrote:

> UA,

The push resource needs to be different for privacy reasons - the one
sent to app servers.

The subscription resource is used by UA to talk with webpush service and
request
delivery - there is no extra privacy you can gain ( unless you use
different TCP connections for
each subscription - which is beyond unscalable ). The webpush service
obviously
can associate all subscriptions from a UA based on connection.

> The dispatch problem is easier to solve if each application has its

At significant cost - transferred bytes, time to connect - and more
important it greatly
increases the storage costs on the webpush service. Grouping all apps in a
UA (device) allows
a single transaction to check stored messages for all of them. With
different subscriptions you
would need one transaction for each subscription.

Assuming only 10 apps per UA - in one case you need one HTTP GET and 1 DB
lookup, in the second
you need 10 HTTP GETs and 10 DB lookups. And this is going to happen many
times, as
the UA may get disconnected - even if the UA doesn't receive any message.

Costin

---

From: Martin Thomson <[email-masked]>
Date: Mon, 15 Jun 2015 14:14:49 -0700

> would need one transaction for each subscription.

I see where you are at now.  This is the old cardinality question: one
subscription or many?

When we asked the question in Dallas, it seemed like we had one person
really strongly arguing for multiple independent subscriptions (Elio)
and a couple of lukewarm responses (yourself included).

The original design I had used a single request from a UA to pull down
information about multiple subscriptions.  We changed that after some
discussion, based on the previous.  It also turns out that the whole
acknowledgment design is cleaner as a result of the change.

Is the overhead significant enough to warrant a change?  I would have
thought that you could cheat on at the DB lookups and avoid some of
the overhead.

---

From: Costin Manolache <[email-masked]>
Date: Mon, 15 Jun 2015 14:34:37 -0700

> and a couple of lukewarm responses (yourself included).

My response was lukewarm in part because GCM is not affected (we're very
likely
to continue to use our binary protocol for efficiency - this part of the
protocol is
pretty orthogonal to the rest, only affects UA to webpush communication ),
 and I don't mind if the standard provides both options - in cases where a
UA
will have only 1-2 subscriptions it may be simpler, and maybe other provides
have better databases or more resources.

> thought that you could cheat on at the DB lookups and avoid some of

It is possible to avoid DB lookups only if there is a way to link the
various
app subscriptions with the UA.

And the network cost can be saved only if UA can make a single GET request
instead of 10 (or more). On mobile it matters - this is not one time, but
repeated
each time phone disconnects.

Costin