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

[Kit Cambridge <[e-mail]>]

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

> 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)
>

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
> (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?

Cheers,
- kit