Repository navigation
Syncing on a different network #107
Description
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.
Activity
mkruisselbrink commentedon Oct 28, 2015
Yes, this is described in https://slightlyoff.github.io/BackgroundSync/spec/#history-leaking.
mkruisselbrink commentedon Oct 28, 2015
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.
martinthomson commentedon Oct 28, 2015
The question here is whether we want to do anything about the problem. Acknowledging its existence is a nice start, of course.
jkarlin commentedon Nov 11, 2015
@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).
annevk commentedon Nov 11, 2015
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.
jkarlin commentedon Nov 11, 2015
That seems like an edge case to me. You'd have to be using the evil site offline shortly before a flight.
annevk commentedon Nov 11, 2015
You have to be offline in order to schedule synchronization? Still doesn't really seem that implausible given the way airport wifi works.
jkarlin commentedon Nov 11, 2015
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).
clelland commentedon Nov 17, 2015
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?
simonbrown commentedon Nov 22, 2015
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.
mkruisselbrink commentedon Nov 23, 2015
@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.
fwadnjar commentedon Oct 24, 2023
reporting.md
fwadnjar commentedon Oct 24, 2023
1777700643