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

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 <kit@mozilla.com> wrote:

> 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 <jconlin@mozilla.com> wrote:
> > 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.
> >
> > _______________________________________________
> > Webpush mailing list
> > Webpush@ietf.org
> > https://www.ietf.org/mailman/listinfo/webpush
> >
>