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

[JR Conlin <[e-mail]>]

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

On Wed, Apr 19, 2017 at 2:55 PM, JR Conlin <[e-mail]> wrote:

>
> On Wed, Apr 19, 2017 at 2:41 PM, Kit Cambridge <[e-mail]> wrote:
>
>> 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.
>>>
>>
>> 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.
>