Subject: [Webpush] User Agents should return a list of supported encryption content types

From: JR Conlin <[email-masked]>
Date: Wed, 19 Apr 2017 13:44:13 -0700

Recently, a bug filed against a webpush subscription library highlighted a
shortcoming.

https://github.com/web-push-libs/web-push-php/issues/48#issuecomment-295416292

Currently, there are two in production encryption content types, "aesgcm"
and "aes128gcm". The "voice of authority" about what types of accepted
content types is the UA. The sorts of allowed encryption is not
communicated to the subscription update provider.

I would like to propose that the returned PublishSubscription object <
https://developer.mozilla.org/en-US/docs/Web/API/PushSubscription>
"options" object be modified to include a "contenttypes" list of allowed
ECE content types. (e.g. ['aesgcm', 'aes128gcm']) This method would also
allow future content types to be relayed. If no "contenttypes" field is
present, then the provider must assume "aesgcm" encoding, to allow for
older UAs.

This field would also help indicate "updated" UAs which can take advantage
of the newer draft specifications.

My apologies if this is the wrong group. WebPush and ECE span several and
this is a case where they overlap. I will happily repost to the appropriate
group.

---

From: Kit Cambridge <[email-masked]>
Date: Wed, 19 Apr 2017 13:55:51 -0700

This could be handled transparently by the push server, too. A client
registering with the push server would indicate which schemes it
supports. When the app server tries to send a message, the push server
can check if the "Content-Encoding" is supported for that client, and
immediately reject the message with a 400 if not.

WDYT?

Cheers,
- kit

On Wed, Apr 19, 2017 at 1:44 PM, JR Conlin <[email-masked]> wrote:
> content types is the UA. The sorts of allowed encryption is not communicated
> to the subscription update provider.
>
> I would like to propose that the returned PublishSubscription object
> <https://developer.mozilla.org/en-US/docs/Web/API/PushSubscription>
> "options" object be modified to include a "contenttypes" list of allowed ECE
> content types. (e.g. ['aesgcm', 'aes128gcm']) This method would also allow
> future content types to be relayed. If no "contenttypes" field is present,
> then the provider must assume "aesgcm" encoding, to allow for older UAs.
>
> _______________________________________________
> Webpush mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webpush
>

---

From: JR Conlin <[email-masked]>
Date: Wed, 19 Apr 2017 14:13:39 -0700

The problems with that approach are:

1) it's reactive. The subscription provider must repeatedly re-encode and
retry a message, potentially for each UA (which could require millions of
retransmits)

2) it's non-authoritative. The push server either is told or must guess the
state of an individual client. This means that it must track known UAs
(since a message can be stored for later retrieval by the UA). Having the
"source of truth" specify what's allowed and what's not at the time of
subscription, ensures that the most accurate data is provided.

Honestly, this is a coordination point between two parties. I'm not sure
introducing a third is a good idea.

On Wed, Apr 19, 2017 at 1:55 PM, Kit Cambridge <[email-masked]> wrote:

> ECE

---

From: Kit Cambridge <[email-masked]>
Date: Wed, 19 Apr 2017 14:41:37 -0700

> retry a message, potentially for each UA (which could require millions of

That's a good point, and we've already seen that many app servers will keep
trying to deliver to expired subscriptions. Based on that, I suspect the
more likely outcome is those messages will get dropped on the floor instead
of resent. Realistically, app servers will need to keep using "aesgcm",
until "aes128gcm" is supported in all browsers and encryption libraries.
Once "aesgcm" usage is low enough, we can remove it entirely.

> 2) it's non-authoritative. The push server either is told or must guess
> the state of an individual client. This means that it must track known UAs

I don't follow, apologies. For Autopush, we already keep client info in the
router table: its UAID, last connect time, and whether it uses Web Push,
Simple Push, FCM, or APNs. We need to look this up regardless of whether we
store or immediately deliver the message. It's not clear to me why we'd
need to guess, or who the third party is. I think I'm missing something,
though. Could you please elaborate?

Cheers,
- kit

---

From: JR Conlin <[email-masked]>
Date: Wed, 19 Apr 2017 14:55:22 -0700

On Wed, Apr 19, 2017 at 2:41 PM, Kit Cambridge <[email-masked]> wrote:

> I don't follow, apologies. For Autopush, we already keep client info in
> the router table: its UAID, last connect time, and whether it uses Web
> Push, Simple Push, FCM, or APNs. We need to look this up regardless of
> whether we store or immediately deliver the message. It's not clear to me
> why we'd need to guess, or who the third party is. I think I'm missing
> something, though. Could you please elaborate?
>

​Certainly. It's true that for our server, we do track the state of a
previously connected UA for up to 30 days. (If a UA has not connected in 30
days, we consider that UA to be "unavailable" and reject messages.) The
problem is that the client would still need to inform the push server which
content types it supported, much the same as it would need to tell the
subscription provider. ​

The crux of this is that the Push Service is the "third party". It doesn't
care what the encryption format is, since it just passes the data on. The
two parties of interest in this case are the User Agent (which is
responsible for decoding the final message) and the Subscription Provider
(which is responsible for encoding the message). The Push Service may do
some minimal, superficial checks of the message it's carrying, in order to
reduce the traffic costs to the UA, but it cannot do a full check since
that would presumably require deciphering the message.

That's why I feel it's best to keep the pertinent information in the
exchange between the UA and the subscriber directly, much like how the
public key comes from the UA and not the Push Server.

---

From: JR Conlin <[email-masked]>
Date: Wed, 19 Apr 2017 15:44:30 -0700

And I've just realized that I have mislabled it as "contenttypes" instead
of "contentencodings".

---

From: Martin Thomson <[email-masked]>
Date: Thu, 20 Apr 2017 10:14:28 +1000

I think that JR's proposed solution works best (no need for
intermediation of the information via the push service, immediate
availability of the information, etc...).

As a procedural matter, this is the wrong place to discuss the API.
I'd recommend opening an issue (or a pull request, but that's only for
the brave) against the API: https://github.com/w3c/push-api

(As an aside, this isn't a per-subscription property, so I'd probably
angle for a FrozenArray<DOMString> property on PushManager.  That way,
an application can know whether or not to even bother creating a
subscription. There's also a separate question about whether we also
use this to signal support for empty messages, which have no content
coding.)

On 20 April 2017 at 08:44, JR Conlin <[email-masked]> wrote:
> And I've just realized that I have mislabled it as "contenttypes" instead of
> "contentencodings".
>
>>> the router table: its UAID, last connect time, and whether it uses Web Push,
>>> store or immediately deliver the message. It's not clear to me why we'd need
>>> to guess, or who the third party is. I think I'm missing something, though.
>>> Could you please elaborate?
>>
>>
>>
>> Certainly. It's true that for our server, we do track the state of a
>> subscription provider.
>> reduce the traffic costs to the UA, but it cannot do a full check since that
>> would presumably require deciphering the message.
>>