You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Summary:
Push currently does not allow for endpoint data to be backed-up or restored. This is because each Push subscription is tied to a unique endpoint and set of encryption credentials. We should allow for Push to automatically restore endpoints on both mobile and desktop from a list of known subscription endpoints using the existing pushsubscriptionchange event.
Detailed Discussion:
Users don’t really care about how Push works internally. The thing that they want is that if they’ve asked a site to tell them something, they want to know when that something happens. Push was designed with a lot of privacy and anti-abuse built in, so only a given client knows what subscriptions a user may have.
Likewise, encryption is best if keys are unique. Shared keys runs the risk of exposure and of key entropy leakage. We also do not want key data stored in some accessible way outside of the user’s knowledge or control.
It may be preferred if Push were to create some exportable list of subscription endpoint URLs which could be used to “restore” subscriptions on some event. Mobile already performs a similar action where it “checks in” on a daily basis to confirm the set of subscriptions it has matches the set of subscriptions that the server has. These lists can differ due to a number of reasons. If those do not match, then the client will discard it’s set of subscriptions and (ideally) recreate the subscriptions for the registered apps informing them of the change using the pushsubscriptionchange event, which provides replacement Push subscription information to the registered app.
This behavior could be extended to Desktop, which could keep a list of subscription endpoints and automatically re-register those subscriptions based on some trigger event. Note that Push subscriptions are normally blocked for user confirmation for new User Agents, but we may be able to “bless” those endpoints during a restore event.
This would allow users to automatically “recover” subscriptions, as well as be able to “duplicate” an instance to a different machine reasonably seamlessly. (Subscriptions that require logins may still require additional work, but those could also be flagged for recovery action by the user.)
Summary:
Push currently does not allow for endpoint data to be backed-up or restored. This is because each Push subscription is tied to a unique endpoint and set of encryption credentials. We should allow for Push to automatically restore endpoints on both mobile and desktop from a list of known subscription endpoints using the existing
pushsubscriptionchange
event.Detailed Discussion:
Users don’t really care about how Push works internally. The thing that they want is that if they’ve asked a site to tell them something, they want to know when that something happens. Push was designed with a lot of privacy and anti-abuse built in, so only a given client knows what subscriptions a user may have.
Likewise, encryption is best if keys are unique. Shared keys runs the risk of exposure and of key entropy leakage. We also do not want key data stored in some accessible way outside of the user’s knowledge or control.
It may be preferred if Push were to create some exportable list of subscription endpoint URLs which could be used to “restore” subscriptions on some event. Mobile already performs a similar action where it “checks in” on a daily basis to confirm the set of subscriptions it has matches the set of subscriptions that the server has. These lists can differ due to a number of reasons. If those do not match, then the client will discard it’s set of subscriptions and (ideally) recreate the subscriptions for the registered apps informing them of the change using the
pushsubscriptionchange
event, which provides replacement Push subscription information to the registered app.This behavior could be extended to Desktop, which could keep a list of subscription endpoints and automatically re-register those subscriptions based on some trigger event. Note that Push subscriptions are normally blocked for user confirmation for new User Agents, but we may be able to “bless” those endpoints during a restore event.
This would allow users to automatically “recover” subscriptions, as well as be able to “duplicate” an instance to a different machine reasonably seamlessly. (Subscriptions that require logins may still require additional work, but those could also be flagged for recovery action by the user.)
┆Issue is synchronized with this Jira Task
The text was updated successfully, but these errors were encountered: