# Consent and service workers: the background sync that outlives the banner

Source: https://cookiebastion.com/blog/2026-10-11-consent-service-workers-background-sync.html

[Home](../index.md) / [Blog](index.md) / Consent and service workers: the background sync that outlives the banner


Published 2026-10-11

Your consent wrapper does its job in the page: the user clicks reject, the tag manager holds back the analytics tags, and the network tab goes quiet. Then the service worker wakes up. Registered months ago, running in its own thread outside the page lifecycle, it fires a background sync, uploads the queued events, and goes back to sleep. Nothing in the page's consent logic ever saw it happen, because consent wrappers live in the document and service workers deliberately do not.

## Why service workers escape consent tooling

Consent management platforms operate by controlling script execution in the page: blocking tags, gating SDK initialization, and wrapping APIs like fetch or XMLHttpRequest. A service worker runs in a separate global scope with its own network access through the Fetch API inside the worker. Monkey-patching fetch in the window does nothing to the worker's fetch. Blocking a tag in the tag manager does nothing to code that was installed directly and syncs on its own schedule.

The practical exposures cluster in three features. Background Sync lets a worker defer network requests until connectivity returns, which analytics SDKs use to guarantee event delivery even if the user closes the tab. Push notifications require a worker, and many push providers piggyback engagement analytics onto the push registration. Periodic Background Sync, where supported, lets the worker wake on a timer and phone home with fresh data. Each of these is legitimate technology; each becomes a consent problem the moment it transmits identifiers or behavioral data without a live, revocable choice behind it.

## The reject path nobody implemented

Here is the scenario that fails audits: the user rejects tracking, the banner records the choice, and the service worker keeps its registration, its cache, and its sync queue. Weeks later it syncs a batch of events collected before the rejection, or worse, continues collecting through push-related pings. The site's consent records say "rejected." The network says otherwise. When a regulator or a sharp-eyed user compares the two, the explanation "the service worker is separate from our consent tool" is not a defense; it is an admission.

Unregistering the worker on reject is the blunt fix, and it is often the right one for marketing workers. But workers also serve legitimate first-party functions like offline support, and nuking the whole registration degrades the product. The mature pattern is consent-aware workers: the worker checks a consent state store (IndexedDB or a dedicated cache entry) before any network call, and the banner's choice handler updates that store and messages the worker to flush or drop its queues. The worker becomes a consent citizen instead of a consent exile.

## What to audit this week

Open your site, then check what workers are registered and what they do. Read the worker source for sync, push, and periodic sync registrations, and trace what data each transmission carries. Then test the reject path end to end: reject in the banner, then watch the worker's network activity over the next hour, not just the page's. If anything fires that the user's choice should have stopped, you have found work that belongs in this sprint. Document the worker inventory alongside your cookie inventory, because the next auditor will ask about both.

## Get a free consent audit of your website

[Free consent audit](mailto:hello@cookiebastion.com?subject=Free%20consent%20audit%20-%20cookiebastion.com)

## Frequently asked questions

### What is Google Consent Mode and how does it relate to our banner?

Consent Mode is a Google framework that adjusts how its tags behave based on the consent state your banner supplies. Your banner remains the source of the visitor's choice; Consent Mode is the mechanism that passes that choice to Google's tags.

### Can we load advertising tags before the visitor answers the banner?

No, not for the categories that require consent. Tags must wait for the recorded choice, and pre-loading them while the banner is undecided is one of the most common audit failures. Default the consent state to denied and update it only on an actual choice.

### Does our banner need to block social media embeds?

Yes, until the visitor consents to the relevant category. Embedded videos and social plugins contact third parties on load, which is a disclosure before consent. The standard fix is a click-to-load placeholder that only fetches the embed after consent.