Delayed, background request w/o user's direct consent can be abused for user deanonimization and location tracking.
Example scenario:
User clicks a link on a bad actor's website where her identity is known. Link has ad click attribution properties.
Destination page, potentially controlled by the same bad actor, confirms attribution.
Next day, user browses from a different location.
UA sends a delayed ad attribution request to the bad actor.
Bad actor is able to link current user session with the previous one (based on ad attribution data) and learn user's new location (based on IP).
This is similar to https://wicg.github.io/BackgroundSync/spec/#location-tracking although less powerful since it only happens once (if UA doesn't implement retries*) and sends limited amount of data (potentially limiting it to only targeted attacks).
* Since retries would allow for prolonged tracking they should be implemented in a way that doesn't share ad attribution data with each attempt (e.g. by making a preflight request to confirm server availability before making the main request).
Delayed, background request w/o user's direct consent can be abused for user deanonimization and location tracking.
Example scenario:
This is similar to https://wicg.github.io/BackgroundSync/spec/#location-tracking although less powerful since it only happens once (if UA doesn't implement retries*) and sends limited amount of data (potentially limiting it to only targeted attacks).
*
Since retries would allow for prolonged tracking they should be implemented in a way that doesn't share ad attribution data with each attempt (e.g. by making a preflight request to confirm server availability before making the main request).