[Jmap] Re: Working group last call draft-ietf-jmap-webpush-vapid

[Phillip Tao <[e-mail]>]

My slight concern with 3(b) is that one reason you may want to rotate your key is that it was compromised. Knowingly continuing to use a key that's compromised seems a little odd, and it generally seems more prudent to immediately notify the user agent that they need to recreate their push subscriptions, so they don't receive fraudulent/dangerous push notifications. I wonder if this is why RFC 8292 chose to recommend that the application server prompt the client to create a new subscription.

Of course, key compromise is probably less likely for a JMAP server than a random website, and given that pushes right now just deliver state strings, the potential for abuse from a compromised key seems negligible. Still, in the future, is it imaginable that pushes may be extended to deliver carry more "abusable" data? If "push notification requires user-visible notification" becomes a de-facto standard behavior among platforms, it seems plausible that there may be an extension in the future that allows the server to specify what to display (maybe even directly providing text)?

On the concern with the user-visible notification, I wonder if platforms may require such user-visible notifications for web applications, but not necessarily for other application servers. Currently, because W3C's Push API is the largest actual use case of Web Push, I suspect that those two are conflated in many cases. For example, Apple has historically not required a user-visible notification for email push.

Finally, even if one or other platforms have this user-visible notification restriction, I still wonder if an immediate "renew your push subscription" push should still be an option. Perhaps some email providers will decide that's too annoying for users, but others may decide that a "Push notifications disabled, please open the app to re-enable" is perfectly acceptable. Or maybe a server wants to use a 3(b) approach for a day or so, but if the client still hasn't renewed after a day (perhaps the user never opened the app in that day, and so there were no API calls) then it really wants to let them know. So, should the draft define a mechanism for this to occur if the server chooses to, but as a MAY rather than a SHOULD/MUST?

- Phillip

> On Jul 25, 2024, at 10:12 PM, Neil Jenkins <neilj=[e-mail]> wrote:
> 
> On Fri, 26 Jul 2024, at 14:31, Phillip Tao wrote:
>> The only other thing I wonder about is that RFC 8292 Section 4.2 seems to say that the application server should proactively notify the user agent when rotating keys, "requesting the creation of a new subscription". That seems like a good idea? Rather than waiting for the client to suddenly and unknowingly stop receiving pushes until the next time it happens to issue some API request.
>> 
>> It seems like the JMAP server could push one last message with the old key that's like, "hey the VAPID key changed, please refetch the session and create a new push subscription", right before destroying that push subscription.
> 
> The trouble with this is Apple requires any push notification to show a user-visible notification <https://developer.apple.com/videos/play/wwdc2022/10098/?time=438> with web push (and other vendors may be similar). You could show something like "Push notifications disabled, please open the app to re-enable" but it's not the best experience! I think the best way to handle this is as I put in 3(b) in my previous email, so the server gives time for the client to re-register. They should in theory detect pretty quickly, given they'll find the sessionState change on their next API request.
> 
> Cheers,
> Neil.