In what circumstances is "delayed execution" acceptable on the web?

Some new web APIs allow for data to be transmitted and/or JavaScript to be
executed beyond the life of a window. Specifically:

http://w3c.github.io/beacon/ - allows the POSTing of data and "The User
Agent should make a best effort attempt to eventually transmit the data",
"including making multiple attempts to transmit the data in presence of
transient network or server errors".

The intent here is to allow things like analytics pings to succeed even if
the tab is closed before completion, or the user has zero connectivity at
the time.

https://wicg.github.io/BackgroundSync/spec/ - which is a lower-level
version of the above, providing a "sync" event in the service worker when
the user has connectivity (either now, or later). The sync event is allowed
to fire when the user has no windows open to the origin. The "sync" event
will only fire once per registration, the exception being if the developer
indicates failure of a sync, meaning the user agent may reschedule the sync
with some form of delay, or abandon the sync altogether.

The intent here is for all non-optional server communication to be done as
part of the sync event, so it survives navigation & connectivity issues.
Communication includes sending an email or chat message, or updating
preferences on a site.

Neither of these features require up-front user permission, although we
intend on giving background sync a default-on permission that can be
revoked. In ideal situations, both of these APIs will do what they need to
do during the lifetime of the page. Background sync places limitations on
execution time and retries of sync events, to prevent an evil developer
creating infinite background execution.

Anne has raised an issue on beacon https://github.com/w3c/beacon/issues/14
- given the potentially long delay between the user interacting with the
origin, and the data sending, does this reveal information about the user
they may not expect, eg rough location from their ip. Anne's suggested
solution is to cancel beacons if the network changes from the point of
registration. This would diminish the usefulness of beacon, and scupper one
of the primary use-cases of background sync (queuing things to send while
offline).

So we're looking for some advice. Is it reasonable to allow
beacon/background sync to perform a single, restricted background action
after the user has interacted with the origin. If not, are there obvious
restrictions that could be put in place that retain the intent of the APIs?