search

w3c / push-api

Push API
https://w3c.github.io/push-api/
Other
145 stars 40 forks source link

Consider including `supportedContentEncodings` in the `PushSubscription` serializer #277

Closed ghost closed 7 years ago

ghost commented 7 years ago

This came up in web-push-libs/web-push#278. Since we plan to deprecate "aesgcm" eventually, and supportedContentEncodings is the same for every subscription, including them in the serializer might not make sense...but it could be a nice convenience.

martinthomson commented 7 years ago

The main problem with this is that it as a static, it isn't obvious that it will be folded in to the serialized form of a instance.

It's also not strictly a property of the subscription. Say that we deploy "rot13" tomorrow in Firefox, then we'll start to accept messages encrypted using "rot13" even if the subscription was created before "rot13" was deployed. Worse, when we back "rot13" out in a mad rush, the subscriptions created while it was present will be forever marked as being valid for use with "rot13", even if the browser has long since removed that capability.

That highlights an inherent flaw in the definition of supportContentEncodings, but I think that it's manageable as it is.

ghost commented 7 years ago

Say that we deploy "rot13" tomorrow in Firefox, then we'll start to accept messages encrypted using "rot13" even if the subscription was created before "rot13" was deployed.

That makes sense, I didn't think about the rollback case (or the upgrade case, if the browser comes to support a new encoding after the subscription is created). It could still be an issue if the app server stores the encodings alongside the subscription information, of course, but we won't condone that if we keep them separate.

Minishlink commented 7 years ago

Making it separate in the PushSubscription won't solve the issue of upgrades/rollback though, right ? App servers need to know what content encoding is supported by the browser for each subscription, so they have to store this info alongside the subscription in their database. On the contrary, if the supportedContentEncodings becomes part of PushSubscription, app servers won't have any work to do for the transition (for libraries that uses the JSON PushSubscription as an entry point).

martinthomson commented 7 years ago

@Minishlink, you are right in that there are still no guarantees, but that's just physics. The user agent can change without the application server ever having talked to it. What you need to rely on here is that browsers vendors won't capriciously change what they do. I think that we've a pretty good history of keeping the platform consistent: if people are using something, we don't like removing it.