[Push API] Web push subscription age affects delivery rates

[Marco Colli]

Hello!

I think that this study that I have published needs your attention:
https://blog.pushpad.xyz/2018/09/web-push-subscription-age-affects-delivery-rates/

Your opinion would be greatly appreciated.
Also, are you aware of any strategies that are being implemented in
browsers or push services (e.g. FCM, Autopush) in order to mark inactive
subscriptions as expired?


Thanks
Marco Colli

[Marcos Caceres]

Hi Marco,

Post by Marco Colli
Hello!
https://blog.pushpad.xyz/2018/09/web-push-subscription-age-affects-delivery-rates/
Your opinion would be greatly appreciated.
Also, are you aware of any strategies that are being implemented in browsers or push services (e.g. FCM, Autopush) in order to mark inactive subscriptions as expired?

(Not an expert on this at all… but your study does raise interesting questions)

Notable things:

"It is important that all browsers properly notify their push service when a subscription is deactivated / refreshed, otherwise the old subscription cannot be marked as expired in a promptly manner. The standard says “MUST”, so it is correct. However we still have doubts about possible buggy behaviors in the implementations, for example in case of poor internet connectivity.”

We should check if we have web platform tests for this.

“There is a feature described by the Push API that would solve this scenario, ensuring the eventual removal of old subscriptions: indeed a push subscription can have an expirationTime associated to it. However that attribute is optional and no current browser uses that: Chrome and Opera set it to null, while Firefox doesn’t support it.”

We should enquire why this is not getting supported. It might be worth filing a bug:
https://github.com/w3c/push-api

“It would also be useful if all browsers could set an expirationTime on all generated subscriptions.”

Could be good. Folks more involved could probably propose a reasonable default… like 1 year.

As above, could you please file a bug:
https://github.com/w3c/push-api

[Marco Colli]

Thanks Marcos for the reply. I have posted the issue:
https://github.com/w3c/push-api/issues/302

Post by Marcos Caceres
Hi Marco,

Post by Marco Colli
Hello!

https://blog.pushpad.xyz/2018/09/web-push-subscription-age-affects-delivery-rates/

Post by Marco Colli
Your opinion would be greatly appreciated.
Also, are you aware of any strategies that are being implemented in

browsers or push services (e.g. FCM, Autopush) in order to mark inactive
subscriptions as expired?
(Not an expert on this at all
 but your study does raise interesting
questions)
"It is important that all browsers properly notify their push service when
a subscription is deactivated / refreshed, otherwise the old subscription
cannot be marked as expired in a promptly manner. The standard says “MUST”,
so it is correct. However we still have doubts about possible buggy
behaviors in the implementations, for example in case of poor internet
connectivity.”
We should check if we have web platform tests for this.
“There is a feature described by the Push API that would solve this
scenario, ensuring the eventual removal of old subscriptions: indeed a push
subscription can have an expirationTime associated to it. However that
attribute is optional and no current browser uses that: Chrome and Opera
set it to null, while Firefox doesn’t support it.”
https://github.com/w3c/push-api
“It would also be useful if all browsers could set an expirationTime on
all generated subscriptions.”
Could be good. Folks more involved could probably propose a reasonable
default
 like 1 year.
https://github.com/w3c/push-api

[Marcos Caceres]

Post by Marco Colli
https://github.com/w3c/push-api/issues/302

Thanks, Marco (cool name, btw! ;)).

Will try to get this discussed at our upcoming face to face meeting later in October. It may take a little time to get a response from the editors, but please be sure that we are tracking all issues and appreciate research you’ve done.

[Marco Colli]

Hello!

https://github.com/w3c/push-api/issues/302

Will try to get this discussed at our upcoming face to face meeting later

Post by Marcos Caceres
in October.

Are there any updates on this?

This issue is really a pain... valid subscriptions (that return successful
status codes) have such low delivery rates due to this problem and it is
difficult to explain that to customers (not to talk about competitors that
show the sending rates as if they were the delivery rates...). Also it
doesn't really make sense that the number of inactive subscriptions (that
belong to abandoned devices and browsers) grows constantly over time.

Please consider my suggestion:
https://github.com/w3c/push-api/issues/302

This is also relevant for privacy, because it would allow us to delete
unused subscriptions together with all the associated data.


Marco Colli
https://pushpad.xyz

Post by Marcos Caceres

Post by Marco Colli
https://github.com/w3c/push-api/issues/302

Thanks, Marco (cool name, btw! ;)).
Will try to get this discussed at our upcoming face to face meeting later
in October. It may take a little time to get a response from the editors,
but please be sure that we are tracking all issues and appreciate research
you’ve done.

[Marcos Caceres]

Hi Marco,

Post by Marco Colli
Are there any updates on this?
This issue is really a pain... valid subscriptions (that return successful status codes) have such low delivery rates due to this problem and it is difficult to explain that to customers (not to talk about competitors that show the sending rates as if they were the delivery rates...). Also it doesn't really make sense that the number of inactive subscriptions (that belong to abandoned devices and browsers) grows constantly over time.
https://github.com/w3c/push-api/issues/302
This is also relevant for privacy, because it would allow us to delete unused subscriptions together with all the associated data.

I see Martin already responded in the bug. Martin is spot on tho: you need to be lobbying browser makers directly to get this changed by filing bugs in their respective issue trackers.

Even if we change the spec, it doesn't mean it will be reflected in implementations any time soon - so we would still need to go through the browsers.

Sorry for making you do additional work here, but affecting this change will take some time. I'll try to help in the bug by making sure the right people get pinged, so at least implementers are aware.

But please do file bugs if you can and keep pushing for this. I think we all agree that you are correct: this is an annoyance to end-users, so should be fixed.

[Marco Colli]

Hi Marcos,

thanks for the reply!

I understand that this can take some time, but changing the spec means that
eventually everyone will benefit from a reliable technology. In the
meantime we have provided a workaround
<https://blog.pushpad.xyz/2018/09/targeting-only-recently-active-users-can-increase-delivery-rate-of-web-push-notifications/>
to our customers, but that is clearly a patch... the right place to fix
this problem is the spec / browser.

Post by Marcos Caceres
Hi Marco,

Post by Marco Colli
Are there any updates on this?
This issue is really a pain... valid subscriptions (that return

successful status codes) have such low delivery rates due to this problem
and it is difficult to explain that to customers (not to talk about
competitors that show the sending rates as if they were the delivery
rates...). Also it doesn't really make sense that the number of inactive
subscriptions (that belong to abandoned devices and browsers) grows
constantly over time.

Post by Marco Colli
https://github.com/w3c/push-api/issues/302
This is also relevant for privacy, because it would allow us to delete

unused subscriptions together with all the associated data.
I see Martin already responded in the bug. Martin is spot on tho: you need
to be lobbying browser makers directly to get this changed by filing bugs
in their respective issue trackers.
Even if we change the spec, it doesn't mean it will be reflected in
implementations any time soon - so we would still need to go through the
browsers.
Sorry for making you do additional work here, but affecting this change
will take some time. I'll try to help in the bug by making sure the right
people get pinged, so at least implementers are aware.
But please do file bugs if you can and keep pushing for this. I think we
all agree that you are correct: this is an annoyance to end-users, so
should be fixed.