Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add more privacy details around when beacons can be sent #55

Closed
wants to merge 2 commits into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 17 additions & 6 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -307,14 +307,22 @@ However, it may break existing means that users have of blocking beaconing -
since the browser itself sends beacons **behind the scenes** (so to speak),
special support may be needed to allow extension authors to block the sending (or registering) of beacons.

Specifically, beacons will have the following privacy requirements:
Specifically, pending beacons will have the following privacy requirements:

* Follow third-party cookie rules for beacons.
* Post-unload beacons are not sent if background sync is disabled for a site.
* [#30] Beacons must not leak navigation history to the network provider that it should not know.
* If network changes after a page is navigated away, i.e. put into bfcache, the beacon should not be sent through the new network;
If the page is then restored from bfcache, the beacon can be sent.
* If this is difficult to achieve, consider just force sending out all beacons on navigating away.
* The timing when the beacons can be sent must be taken care of:
* Before navigating away (or document being fully unloaded), beacons are **sendable**.
* [On navigating away][navigating-away], all beacons are **sendable** no matter what other states the browser has, (e.g. BackgroundSync is on or off).
* If beacons don't meet the **sendable** requirement after navigating away (see below), consider sending all of them out earlier at this moment if handling them later is difficult, such that they won't be dropped silently.
* [After navigating away][navigating-away] (or document discarded or bfcached):
* If [BackgroundSync] is on
* beacons are **sendable** over the same network as the one before navigating away.
* If [BackgroundSync] is off:
* Beacons are **sendable** if there is another open document (tab/frame/etc) with [the same storage partitioning key][StorageKey] as the current document's one.
* [#30] Beacons are **sendable** over the same network as the one before navigating away.
* Beacons are **non-sendable** if none of the above conditions is met. **non-sendable** beacons might be delayed until navigating back, or might be forced sending earlier on navigating away.
* Beacons can change from **sendable** to **non-sendable**. In this case, beacons can only be delayed or be silently dropped.
* If this is difficult to achieve, consider just force sending out all beacons on navigating away.
* [#27] Beacons must be sent over HTTPS.
* [#34]\[TBD\] Crash Recovery related (if implemented):
* Delete pending beacons for a site if a user clears site data.
Expand All @@ -329,6 +337,9 @@ Specifically, beacons will have the following privacy requirements:
[#30]: https://github.com/WICG/pending-beacon/issues/30
[#34]: https://github.com/WICG/pending-beacon/issues/34
[bfcache]: https://web.dev/bfcache/
[BackgroundSync]: https://github.com/WICG/pending-beacon/issues/3#issuecomment-1284164794
[StorageKey]: https://github.com/WICG/pending-beacon/issues/3#issuecomment-1286031505
[navigating-away]: https://github.com/WICG/pending-beacon/issues/3#issuecomment-1286397825

## Security Considerations

Expand Down