[Privacy] Time limit on retaining beacons for bfcache'd pages

[caraitto]

My understanding is that with the Declarative Beacon API, if a page is kept in the bfcache for an extended period of time, it's still eligible to send the beacon once the page is evicted from the bfcache, which might be a long time after the user has navigated away from the page.

Would it be possible to instead send the beacon for bfcache'd pages after they've been in the bfcache for a minute or so? I think the page would want to check when waking from the bfcache to see if the beacon was already sent or not (by checking the state field of the beacon from the explainer) -- if it's already sent, the page may want to create a new beacon (at its choice).

[caraitto]

Hi, friendly ping?

[clelland]

I think that this is what the pageHideTimeout setting is for -- pageHide is emitted when the page enters the bfcache, and that should start a timer for any beacons with pageHideTimeout set. If they aren't restored from cache by the time that timer expires, they will be sent at that time (rather than waiting until eviction)

[caraitto]

The explainer says:

For frozen pages that are never unfrozen, this should happen either when the frozen page is removed from memory (BFCache eviction), or after a developer-specified timeout (using the 'pageHideTimeout' described below).

I think the idea is the beacon is sent for whichever event happens first of the two? But, if the site doesn't set pageHideTimeout, what is the behavior? Also, can pageHideTimeout be arbitrarily large?

The pageHideTimeout behavior sounds like the behavior we want, but I think the explainer and spec should be updated to give default and maximum pageHideTimeout values to prevent sending beacons at bfcache eviction at some point long after the user has left the page.

[mingyc]

I think the idea is the beacon is sent for whichever event happens first of the two?

Yes

But, if the site doesn't set pageHideTimeout, what is the behavior?

The default behavior is specified in the pageHideTimeout section, i.e. If this is null when the page is hidden, the beacon will be sent on document discard (including eviction from the BFCache)

Also, can pageHideTimeout be arbitrarily large?

It is possible as there is currently no maximum.

maximum pageHideTimeout values to prevent sending beacons at bfcache eviction at some point long after the user has left the page.

I think users should specify pageHideTimeout if they don't want to wait too long.

[caraitto]

I think users should specify pageHideTimeout if they don't want to wait too long.

I agree, but for privacy, I think there should be a limit (imposed by the browser) on how long this duration can be that the web content cannot override. I think the spec and explainer should require such limits.

[clelland]

That sounds like a second issue, @caraitto (but correct me if I'm wrong)

The first issue I see is one of developer ergonomics. In order to have beacons sent in a timely manner, there should be a way to ensure that they are sent a short time after entering the bfcache. We have that, and it's pageHideTimeout. My understanding is that if that is set, and a page enters the cache, then one of three things can happen: (Whichever happens first wins)

• If the page is restored from the cache, the beacon is cancelled.
• If the page is evicted from the cache (which browsers will do after a short timeout; the cache is fairly short-lived in current imlementations), then the beacon is sent.
• If the page is still in the cache after pageHideTimeout ms, then the beacon will be sent (and will be in a 'sent' state if the page is subsequently restored)

The second issue you raise is a privacy concern, which I think is motivated by a "what if browser's didn't do that" question around the second point above. Currently there is a time limit set by browsers, which web content can't override (Chrome, for instance, has a 3 minute timer). But what if future browsers keep pages in the bfcache for an arbitrarily long time, and also developers don't choose to set a timeout on their own. Should we protect developers from that situation?

I feel that there could be an implementation note, certainly, that there should be some reasonable limit, if the user agent is capable of retaining cache entries indefinitely, and it warrants a section in the privacy section of the spec. I don't know if there's sufficient alignment between cache implementations to specify yet exactly what a hard limit needs to be.

[caraitto]

I feel that there could be an implementation note, certainly, that there should be some reasonable limit, if the user agent is capable of retaining cache entries indefinitely, and it warrants a section in the privacy section of the spec.

Yep, I think that's basically what I'd like to see -- I'll go ahead and send a PR (#5). I think 3 minutes might be OK, but I'd be less comfortable if it was over 10 minutes.

[mingyc]

This was re-discussed in #16 (comment):

• @philipwalton suggests that there are use cases longer than 10 minutes timeout
• @fergald mentions Mozilla's bfcache timeout is 45 minutes.

Maybe we should re-consider how long timeout limit should be.

[caraitto]

@fergald Continuing the discussion from #16 (comment) (seems like this is a better place to discuss):

I discussed the idea of allowing sending beacons after 10 minutes from the point a page entered the bfcache with some other Privacy / Security reviewers -- I think we're OK with this, even with frames (where the behavior introduced by beacons may not be polyfilable), because the frame site (say maps.company.com) is already able to transmit during network changes via the other tab (this is part of the general IP privacy problem).

We're also OK using eTLD+1 / First Party Sets for determining if another tab / frame is open from the same-site.

I'll update my PR -- my understanding is that if there isn't another site open with the page content, that the beacon will need to be sent within 10 minutes of entering the bfcache -- is that OK? If not, we'd need further discussion, since the privacy-wise, the API would be more like background sync (which requires a permission) -- but my understanding is that we're OK limiting to 10 minutes in the event that no other tab has a frame with the same site?

[mingyc]

1. If we lower the limit down to 10 minutes, some behavior of the API, i.e. sending on page/frame discard, will not be able to work on the browser that has longer bfcache limit (e.g. Mozilla is 45 minutes).

if there isn't another site open with the page content, that the beacon will need to be sent within 10 minutes of entering the bfcache -- is that OK? If not, we'd need further discussion, since the privacy-wise, the API would be more like background sync (which requires a permission)

2. Current design does respect background sync permission: Post-unload beacons are not sent if background sync is disabled for a site.
3. (Trying to summarize) After PR Lower the bfcache limit to 10 min. #41, for a beacon to live beyond the point of pagehide event:
   • Background Sync permission needs to be granted. Otherwise nothing will be sent and all beacons get dropped.
   • network must be the same (currently not able to ensure this, so the Chrome implementation just sends out on pagehide).
   • it has to be < 10 minutes after pagehide
   • if > 10 minutes after pagehide, there need to be other tab/frame opening the same site.
     • => Not quite sure about this as Update API spec in explainer to match latest discussion #16 (comment) suggests 10 min limit to when no tab is active.

Please correct if anything is wrong.

[caraitto]

2. Current design does respect background sync permission: Post-unload beacons are not sent if background sync is disabled for a site.

Oh -- this changes the privacy calculus significantly, I think, since the user explicitly allows the page to transmit when not active, barring that the transmission duration and frequency should be limited to avoid tracking [0].

I think we can remove the time limit requirements if the background sync permission is granted -- let me follow-up with some other reviewers offline.

...but, I'm not sure we want to encourage sites to ask for the background sync permission, just so they can send beacons, unless the user understands there is some clear user-focused benefit for enabling the permission (for instance, keeping content synced for offline use / startup speed boost from pre-loading). It seems to me there certainly are many sites that don't really need the background sync permission for their functionality, but they might still want to send metrics via beacons, and we want users to understand their personal risk / benefit tradeoff when granting permissions.

[0] https://wicg.github.io/background-sync/spec/#location-tracking

1. If we lower the limit down to 10 minutes, some behavior of the API, i.e. sending on page/frame discard, will not be able to work on the browser that has longer bfcache limit (e.g. Mozilla is 45 minutes).

Could the page go into bfcache, send the beacons 10 minutes later, and then somehow get restored after that? I think the page would need to be informed that beacons were sent while it was bfcached, in case it wants to try sending again.

if there isn't another site open with the page content, that the beacon will need to be sent within 10 minutes of entering the bfcache -- is that OK? If not, we'd need further discussion, since the privacy-wise, the API would be more like background sync (which requires a permission)

3. (Trying to summarize) After PR Lower the bfcache limit to 10 min. #41, for a beacon to live beyond the point of pagehide event:

   • Background Sync permission needs to be granted. Otherwise nothing will be sent and all beacons get dropped.
   • network must be the same (currently not able to ensure this, so the Chrome implementation just sends out on pagehide).
   • it has to be < 10 minutes after pagehide
   • if > 10 minutes after pagehide, there need to be other tab/frame opening the same site.

This SGTM (for the case where sync permission isn't granted -- I'm still following up offline on if we want to relax this when sync is granted). I assume "same site" means same eTLD+1, or in the same first party set.

[mingyc]

...since the user explicitly allows the page to transmit when not active
...but, I'm not sure we want to encourage sites to ask for the background sync permission, just so they can send beacons

Correct me if I am wrong, but at least in Chrome it looks like Background Sync is enabled by default for a normal user: the setting in chrome://settings/content/backgroundSync preselects the first item.

[caraitto]

My apologies, you're correct (I'm a little surprised by this) -- I discussed further offline, and everything you mentioned in #3 (comment) sounds correct (with exception of the question I asked about Mozilla's 45 minute time limit -- also, I'm checking if we really need to see if we're on the same network or not). So, background sync is required, and we still have the 10 min after bfcache limit, unless there's another frame of the same site (eTLD+1 / first party set).

[Sora2455]

Background Sync permission needs to be granted. Otherwise nothing will be sent and all beacons get dropped.

Quick clarification: if a site doesn't have the background sync permission, they register a pending beacon and the user closes the page, is the beacon:

1. Sent immediately
2. Never sent at all (making the API useless)

If it's the second, how does this work in browsers that haven't implemented background sync? And could this be called out early in the explainer so that web devs will know that they can't just replace their sendBeacon + unload combinations with pending beacons, as the explainer would otherwise imply?

[mingyc]

if a site doesn't have the background sync permission, they register a pending beacon and the user closes the page, is the beacon:

1. Sent immediately
2. Never sent at all (making the API useless)

The current Chrome implementation for Origin Trial is option 2: the browser never sends any beacons if a document is about to get destroyed for the document from a origin with BackgroundSync disabled. (If sendNow() is called manually or backgroundTimeout/timeout is set, beacon can still be sent)

I agree that this is not ideal.

Looking into the wording of the explainer

Post-unload beacons are not sent if background sync is disabled for a site.

and wording in BackgroundSync

Recently closed sites can finish sending and receiving data

I am not sure if we can interpret the above as "allowing to send beacons before unload is finished" to allow option 1. If so, maybe the API could still try to send those beacons out?

---

how does this work in browsers that haven't implemented background sync?

For the browsers that have not implemented BackgroundSync, one way to make this API work is to apply the current restrictions, i.e. shorter time limit, same network envrionment etc.

Need input from @caraitto, as I also hope that complying to BackgroundSync could give us more flexibility to send beacons anytime after pagehide/page closed, and help resolve network change issue (#30)

---

could this be called out early in the explainer so that web devs will know that they can't just replace their sendBeacon + unload combinations with pending beacons, as the explainer would otherwise imply?

I will update the explainer to call this out as suggested.

---

Adding some other network-leakage-related discussions:

• Reporting API - 9.1. Network Leakage:
  • Consider mitigations. For example, we could drop reports if we change from one network to another.
  • Recent comments from @clelland also suggests that Chrome just drops reports if network changes
• Background Sync - syncing on different network
• Fetch's spec doesn't mention BackgroundSync at all.

[caraitto]

@mingyc We've discussed some more -- there are 2 separate issues:

A

Another live instance of the same site is present in another tab, where same site means same eTLD+1 or same first party set. Here, we probably don't need the background sync permission, since the site is still active elsewhere. However, with frames, we might have to not transmit after navigate away / close if the network changed, since with the removal of third party cookies and storage partitioning, maps.company.com in a sub-frame has a separate identity from maps.company.com in a top-level frame. This requirement to not send the beacon after page close if the network changes only needs to apply if the live instance and bfcached instance belong to separate identities. For instance, these maps.company.com instances are each in separate identities:

top-level: foo.com, sub-frame: maps.company.com
top-level: bar.com, sub-frame: maps.company.com
top-level: maps.company.com

But, 2 instances of maps.company.com that are (top-level: foo.com, sub-frame: maps.company.com) would be in the same identity -- likewise, 2 top level maps.company.com instances would be same identity, and therefore could send even if the network changes.

(I believe intermediate parent frames aren't part of the identity key, just the top-level and current frame).

B

There is no other live instance of the same site. Transmitting beacons after navigating away from / closing the page will require the background sync permission. I'm waiting to hear from the permissions team what limits we'd like to set for this scenario.