Re: [Webpush] Major change to encryption

[Martin Thomson <[e-mail]>]

On 2 November 2016 at 15:02, JR Conlin <[e-mail]> wrote:
> I'm a bit confused about that. For "native" networks, push servers have
> pretty wide tolerances for how much data that they can send over their
> pipes. Going between services, I can definitely understand, since you're
> held to the limits of the provider system. (APNs limits to about 2K, so
> users are kinda screwed worse.) Of course, with "bridged" systems like
> those, you still have to deal with the host system, so "headers" aren't
> free. You still have to encode the data into the body of the message in some
> fashion, which eats into the available amount.
>
> Worst of all, is that those bridged systems are also unreliable for hosts of
> reasons and then you're re-implementing TCP with one hand tied behind your
> back.
>
> Granted, I've got a pretty limited viewpoint, so I'm sure I'm missing
> something obvious.


If you intend to implement this over APNS, then you are stuck, I
agree.  Unless you fragment (and reassembly is ugly).

In the end, the point is to create a consistent experience for users
of the API, we need to pick a point that works.  Currently, the keys
go into the "overhead" bucket: stuff that the push service has to wear
above the 4k message size.  Moving the key into the message is just
moving things around, but it does mean that users of the API get even
less space to play with than before.

I guess you could say that we're stealing 21 octets already, why not make it 85?