background-sync
background-sync copied to clipboard
WICG
Syncing on a different network
Suppose a user moves between the closing of a page and the eventual delivery of a sync event. This potentially results in some application-related network activity on a different network than the one in which the user initiated the action. In addition to all the good things, this can have surprising consequences for users.
Yes, this is described in https://slightlyoff.github.io/BackgroundSync/spec/#history-leaking.
and the other paragraph in the privacy considerations section of course. It definitely is a potential problem, but not sure if there is much we can do about it.
The question here is whether we want to do anything about the problem. Acknowledging its existence is a nice start, of course.
@annevk @jakearchibald have been interested in this topic as well.
The risks seem low here. The new network knows only that you're talking to an origin, not the URLs of the origin or the content of the requests. The servers you speak to learn of your new IP address (and hence coarse location), but they had your coarse location before as well.
For users that don't like background sync, browsers could disable it via a preference or default-enabled permission. The permission could be per-origin for finer-grained control.
We could display a notification when the browser is operating in the background, and that's likely a good idea for long-running syncs (like uploading photos or videos) but doesn't make sense for short syncs that are likely to be more common (document syncs, content syncs, analytics) and harder to explain to the user.
We could restrict the sync event to networks that the users has connected to that origin on in the past, but that's a complex problem. How do you know what network you're on? What if you're on a VPN? It also somewhat defeats the purpose of background sync (e.g., I would have uploaded this email when you next got online, like you expected, but I don't know this network).
The servers you speak to learn of your new IP address (and hence coarse location), but they had your coarse location before as well.
Except if you just traveled across continents that can be very interesting information.
Perhaps if the network is different and the browsing context is no longer open the browser can ask the user in some manner.
That seems like an edge case to me. You'd have to be using the evil site offline shortly before a flight.
You have to be offline in order to schedule synchronization? Still doesn't really seem that implausible given the way airport wifi works.
You have to be offline in order to schedule synchronization?
No, but if you're online it will fire immediately. In the worst case an evil site will purposefully fail all of its sync attempts in order to keep getting your sync data until it runs out of time or attempts. It's up to the browser to determine how long the sync can run for (e.g., how many retry attempts it gets and how much time can elapse before dropping the request).
We could display a notification when the browser is operating in the background, and that's likely a good idea for long-running syncs (like uploading photos or videos) but doesn't make sense for short syncs that are likely to be more common (document syncs, content syncs, analytics) and harder to explain to the user.
There's no distinction at registration time between short syncs and long-running syncs -- and it might matter to the user what network even a usually-short task finishes on. What if the UA could choose to display a notification some amount of time after registration, if the device is still offline? Would a generic message like "2 web sites are waiting for the network to come back online to finish processing", plus the option for the user to cancel any or all of the waiting tasks, be sufficient to protect against this?
The user could load a page, switch network, and then perform an AJAX action, so don't see how the issue is specific to background sync. Admittedly it might be more common.
@simonbrown the difference is that in the situation you describe the page that would do the AJAX action would still be open, so hopefully users won't be surprised that the page is able to make network requests. In the background sync case (and other APIs like sendBeacon) requests can be made after the user explicitly closes the page. The concern here is that a user might assume a page they have explicitly closed is not going to be able to make any more network requests.