Declarative Web Push: mutable field

[annevk]

As there was some pushback on this feature in #385 I thought I'd split it out separately for discussion. The reason we want mutable and the reason we'd like it to be part of the initial version of Declarative Web Push is because we think it offers robustness to web developers.

We'd like to end up in a world where when an end user opts into push message delivery, there's very little reason for those push messages to not arrive at their destination. Even when a lot of time has passed.

We also believe that websites like to have the ability to run JavaScript before a message is displayed to the end user.

However, as time goes on there's quite a bit of opportunity for user agents to remove website storage (and thus service workers) on behalf of the end user for a variety of reasons. In the current design that immediately influences the ability to show any kind of meaningful push message (as the service worker would have been fully responsible for that). In an alternative world with Declarative Web Push we can still deliver a meaningful message to the end user, even when the service worker was collected for one reason or another. We might not be able to make it mutable anymore (as the web developer wanted), but we'd at least be able to deliver something that the end user can act on.

Now if websites don't have the ability to get the equivalent of a push event with Declarative Web Push there's less incentive for them to start using it, which makes it harder for user agents to protect the interests of the end user. As such, we really feel mutable should be part of Declarative Web Push from day one and we should advocate for Declarative Web Push as a more robust means to deliver push messages to end users.

Now in our proposal mutable came with a pushnotification event, but there might also be ways to reuse the existing push event instead, if that would be more amenable.

cc @martinthomson @beverloo

[saschanaz]

We also believe that websites like to have the ability to run JavaScript before a message is displayed to the end user.

What's the current understanding of this need? Can you list some use cases?

[saschanaz]

However, as time goes on there's quite a bit of opportunity for user agents to remove website storage (and thus service workers)

This sounds like the expectation here is that clearing site data should exclude push notification. I think the current expectation is that clearing site data should remove everything for that site, and adding such exclusion could be confusing to users.

A browser can have an auto-cleanup for sites that haven't been visited a while and in that case such exclusion would help, but perhaps sites with push notification can just be excluded from such auto cleanup?

[annevk]

What's the current understanding of this need?

As I understand it this is expected functionality across most push platforms. It's why the push event exists.

This sounds like the expectation here is that clearing site data should exclude push notification.

Yes, we think that there are scenarios that call for that distinction and we think it's ultimately up to the user agent to make these tradeoffs. It might well make sense to remove X MiB of storage now and preserve a X KiB push registration for over a year, in the event that the push message ends up being really important. There's also a distinction here in terms of end user engagement. They explicitly opted into the push message, but did not necessarily consent to large amounts of storage being used.

[annevk]

Per an offline discussion with mt I'll be merging PushNotificationEvent into PushEvent. It's pretty straightforward to just keep a single event here and web developers can then branch on whether the notification field is null.

[saschanaz]

I figured that the discussion about mutable happened mostly in private emails instead of being public.

Our understanding about its use case is mostly for analytics than actual mutability, and in that case we would prefer declarative methods (something like <a ping>):

• to keep it battery efficient by not running JS
• to allow user agents to control it via user configuration.

Unless we find good use cases, our position currently inclines to be negative here.

[beverloo]

After having spoken to more developers, as well as having investigated more push event implementations, it's clear that JavaScript is predominantly needed for analytics (including, indirectly, for commercial purposes), and that there's little appetite from the ecosystem to change this.

We're very interested in any proposal that enables the resource consumption of push notifications to decrease—primarily processing costs, secondarily storage costs. Disassociating push subscriptions from service workers is appealing as it removes the need for push-only service workers, and including the notification's contents directly in the push message is great for developer ergonomics and flexibility.

However, given the above, the mutable attribute is very likely to negate much of the opportunity to decrease processing costs. The storage cost savings don't really apply to Chrome since we don't remove otherwise in-use service workers on behalf of the user. Something <a ping> or a beacon could be a good alternative to consider, ideally providing some flexibility on timing guarantees.

Because of that, our position should also be considered negative.

[annevk]

How would offering something like ping/beacons help if the ecosystem doesn't want to change away from JavaScript?

[saschanaz]

I read that as "they don't want to remove analytics" but more clarification would be good.

[annevk]

While we wait for an answer, I thought I'd try to once more explain why we think declarative plus mutable is necessary.

• Our platform experience with push has shown to us that purely declarative is not workable for many types of apps.
• Declarative push in combination with mutable, relative to imperative push, fully eliminates the possibility of intentional or accidental silent pushes. It removes the need for heuristics that will penalize a website for sending silent pushes as well. For that reason alone we think it's worth trying to move the entire ecosystem over to declarative push and therefore we want to make the opt-in as easy as possible.
• As stated before declarative push in combination with mutable allows for removal of the website's storage (including service workers) in certain scenarios where that may be necessary without impacting the website's ability to push an important message to the end user. (I don't really understand why this would not impact Chrome. What if the website went unused for over a year? Presumably there is some cutoff for non-persistent storage.) And note that even websites that go unused for that long might still need to deliver an important message, such as a government alarm service of some kind.
• Declarative push in combination with mutable indeed does not provide all the efficiency gains, but without mutable there's much less chance of adoption. With mutable you can adopt it from day 1 and easily polyfill in older user agents, slowly iterating towards a more declarative future.

[saschanaz]

Thank you for further explanation.

• Our platform experience with push has shown to us that purely declarative is not workable for many types of apps.

Can you elaborate how they would be blocked? Is an immediate callback absolutely needed or can that be delayed until user visits the website (via notification or just a usual visit), potentially with timestamps when they were shown? If it should be immediate, why?

For other three points I agree, but given we all know fully migrating away from a shipped feature is extremely hard, I'd like to at least make sure we can achieve the efficiency from day 1, as that would be the strongest reason why we would implement this.

[annevk]

Some need to be able to adjust the notification to be displayed based on information that is available locally, based on end user activity that might not have been synchronized with the server, for instance. I suspect an implementation could opt not to display the notification until the end user next visits the website, but that might defeat the purpose. Could still be an interesting enhancement to offer to end users though.

[saschanaz]

Thanks. A few more questions:

1. In the case you mentioned, what would be the expected behavior when there's no service worker to run push event for mutable, either because the user agent cleanup of site data or the subscription is via Window's PushManager?

2. App servers would be able to send a payload with empty placeholder values even for the required values, e.g.

   {
     "web_push": 8030,
     "notification": {
       "title": "placeholder",
       "navigate": "https://placeholder.com"
     },
     "mutable": true
   }

   (I filled everything with placeholder here, but in actual cases the servers would want to only pick certain fields for placeholder)

   And then the service worker would call registration.showNotification() based on the values it got from the local data. This would work as long as the site data is not cleanup by the user agent, but after that the user would either get no notification or a broken one. If no notification, mutable wouldn't grant any advantage over the current SW-based push subscription. Or if a broken notification with placeholders, the user would be surprised by the sudden breakage.

   Would there be a way to let the site data cleanup happen while still preserving the push behavior after that?

[annevk]

If you use mutable with the intent to replace the notification, it's expected that the declarative notification serves as a fallback notification, not as a template or placeholder notification. And that declarative notification will be shown when the service worker cannot be invoked.