New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inactive push subscriptions should be removed #1295

Open
collimarco opened this Issue Sep 28, 2018 · 2 comments

Comments

Projects
None yet
2 participants
@collimarco

collimarco commented Sep 28, 2018

Does Autopush adopt any strategy to remove inactive push subscriptions?

For example, suppose that a browser or device is abandoned and thus it will never connect again to Autopush. Do you mark the endpoints as "expired" after some time of inactivity? Or the endpoints will last forever?

Based on data collected in the following study (that I have published), it seems that some push services don't remove all inactive subscriptions and this will create a steady decrement of delivery rates over time:

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

Basically it seems that some unused subscriptions will last forever because:

  • Autopush keeps returning 2xx codes for old, inactive subscriptions
  • Firefox does not provide expirationTime for push subscriptions

What is the expected behavior?
If a browser does not connect to Autopush for a long time, then its push subscriptions should be removed (and the push service should return 410 Gone to the application server)

What went wrong?
Data collected suggests that some push subscriptions last forever and are not removed by Autopush

@jrconlin

This comment has been minimized.

Member

jrconlin commented Sep 28, 2018

Hi Marco,

For desktop based notifications, autopush expires a given notification if a given User Agent Identifier (UAID) has not reconnected within two months or so. What actually happens is that we tender the record over to DynamoDB's Time To Live (TTL) system, and it's eventually cleaned up. There are some older records that don't have TTLs, or whose TTL is greater than the minimum clean up period TTL that DynamoDB enforces (24 months), and those don't get cleaned up.

For mobile users, it's a bit more complicated. We only ever see the remote client once, when it requests a new endpoint. We have to trust that when we send a new notification to the remote bridge system, it will notify us when a given user's subscription is no longer valid. When that happens, we clean up the record and return a 410.

We could sweep our data set and kill off legacy connections (old desktop subscriptions that are beyond the TTL), but we've determined it would be cost prohibitive for us to do so. We may revisit that decision in the future, but for now, it's just not in the budget.

And, again, mobile makes it hard because if you've got a very old, but active subscription, we'd prefer not killing it. One big reason is that if we kill the subscription on our side, there's no way for the remote client to know and recreate the subscription through us. (Again, we may revisit that in the future, but we don't currently have the resources to address it now.)

The data in your article pretty much confirms this, with that weird spike around 26 months or so. I'd expect that number to hold reasonably steady, since it consists of many "grandfathered" subscriptions.

I have absolutely no idea why you get those spikes every 6 months.

@collimarco

This comment has been minimized.

collimarco commented Oct 1, 2018

For desktop based notifications, autopush expires a given notification if a given User Agent Identifier (UAID) has not reconnected within two months or so

That is perfect.

For mobile users [...] We have to trust that when we send a new notification to the remote bridge system, it will notify us when a given user's subscription is no longer valid.

So basically when you get 410 from the bridge, then you return 410 to the application server... it makes sense. Then probably the problem for Firefox on Android relies in FCM.

I have posted a suggestion for the standard that should solve these kind of issues:
w3c/push-api#302

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment