The discussion from #28 (comment) suggests that one of the privacy requirements around network change, as stated below, is too ambiguous:

Beacons are only sent over the same network that was active when the beacon was registered (e.g. > if the user goes offline and moves to a new network, discard pending beacons).

The foundamental privacy issue here is to prevent beacon from sending to fulfill the expectation that users expect a network cannot know about their previous navigation history when
(1) they have already left a page (either by closing a tab or by navigating away) AND
(2) they have already left the origin network

The following example is the same from the linked comment:

1. User is on network1 (e.g. mobile network)
2. User navigates to site1.com
3. site1.com creates and queues beacon1 on the page.
4. User navigates away from site1.com
   A. where site1.com is put into bfcache, and beacon1 is still pending.
   B. browser checks whether network has changed or not => No
5. User switches to network2 (e.g. office wifi), and thinks that network2 wouldn't know about the navigation history of site1.com
6. beacon1 is sent by browser via network2 (when either page evicted from bfcache or timeout/backgroundTimeout timer ends) => an unexpected behavior

Note that Step 5 can always happen after 4-B as the device's network change takes some time to propagate from OS to browser.

Proposed solution

The current proposal is to force the browser to send out all beacons when a page is no longer open, i.e.

• the user has navigated away from the current page
  • => handles forced sending before pagehide event is dispatched)
• the user has closed the current page
  • => already handled in the cases of tab closure/browser closure)

and replaces 4-B with sending out all beacons.

Cons

1. There can still be leak to network2 if a network change happens very quickly in between B & D
   A. navigating away
   B. browser forces sending out all beacon1 from network1
   C. (network changes to network2)
   D. The browser's network API actually sends out request constructed from beacon1.
2. This potentially makes backgroundTimeout unusable for "navigating away" use case, as the the time between this timers starts (i.e. page enters hidden state) and forced sending (i.e. page enters bfcache) can be very short. But it can still work when the page visibility change but navigation doesn't happen, e.g. switching to another tab.