Embedding Content without any Tracking or User Identification

Third-party embed

It’s completely valid to add third-party embeds to your site, but there’s a catch — cookies.

You have no control over the cookies a third-party embed sets or how it uses them later. That means you can’t guarantee they’re not tracking your users. Even if a given embed seems safe now, nothing stops it from changing behaviour later.

Consider a scenario where a Google Form is embedded into two distinct web applications, like this:

the form is filled out — but not submitted — in one application. Then, it’s reopened in the other, and surprisingly, all the input is still there. The form’s state is preserved across both apps.

Why does this happen?‍

Because the cookies don’t belong to your app — they belong to Google. More specifically, they’re tied to the docs.google.com domain and are treated by the browser as third-party cookies.

In practical terms, this means that even though the form’s cookies were created while the user interacted with the first web application, those same cookies were available in the second one. Why? Because browsers manage cookies by domain. As long as both apps embed content from docs.google.com, the browser reuses the same cookie data—across sites, without your control.

While this example shows cookies being used to retain form state, the same approach can be extended to tracking user activity across multiple websites.

What are possible solutions to fix it?

1. Disable third-party cookies completely. The solution has a couple of drawbacks: a) it relies on user action — a web application can’t disable them on its own; b) the third-party embed may not function properly without access to its cookies.
2. Clear cookies using Clear-Site-Data header (https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Clear-Site-Data). The main drawback of this approach is timing — it can be tricky to determine the right moment to trigger it. And importantly, it requires direct changes to the application code.
3. Ask a vendor of a third-party embed to use Cookies-Having Independent-Partitioned-State (https://developer.mozilla.org/en-US/docs/Web/Privacy/Guides/Privacy_sandbox/Partitioned_cookies). The obvious challenge here is that the change must be made in an external application you don’t control. On top of that, CHIPS is currently only supported in Chrome, limiting its effectiveness across browsers.

None of these solutions are perfect — but luckily, there’s a simpler and faster alternative!

Virtual Webfuse browser session with a randomised domain

Instead of embedding Google Forms directly, you can load them through a Webfuse Virtual Browser Session. This approach isolates third-party cookies and protects user privacy.

One way to launch such a session is by generating a magic link, which creates a fully virtualized session with its own randomized domain.

To do this:

• a Webfuse space has to be created;

• REST API key has to be generated;
• the option called URL mangling should be turned on.

After all these actions are done a magic link is ready to be created.

Now, use the same magic link in both web applications to launch the Google Form inside Webfuse Virtual Browser Sessions.
Each app will open the form within its own isolated, randomized domain — ensuring third-party cookies from docs.google.com remain sandboxed and can't leak between sessions.

This way, even though both apps embed the same form, the form’s state — and its cookies — stay separate. No cross-app tracking. No surprises.

Voilà!

As mentioned earlier, this behavior is possible because Webfuse modifies and randomizes the domain of the embedded Google Form when URL Mangling is turned on. This prevents the browser from treating the form as a third-party embed tied to docs.google.com.

Google forms executed in the first session got the following domain:

and the following domain in the second session:

Although the cookies set within virtual browser sessions are considered third-party, they aren’t shared across sessions — because each one runs under a unique, randomized domain. This isolation ensures that the form state in one session isn’t accessible in another.

So, it was shown that using Webfuse a user can not be identified by tracking third party cookies, but there are other ways to identify a user, for example checking various fingerprints, such as User-Agent, TLS, canvas rendering and many others.

To help mitigate these risks, Webfuse offers several privacy-focused features:

• It can set a default User-Agent string for all sessions.
• It can block access to detailed information about the client’s device.
• It can overwrite or strip certain HTTP request headers to reduce fingerprinting surface.

But not everything can be masked and if a user’s interests on a web are revealed then web pages might start spamming with advertisements. In this case Webfuse can offer an extension which blocks both ads and analytical tools.

Webfuse extensions are similar to browser extensions although they are not the same.

Let’s consider how a simple Webfuse extension can be created for filtering ads out.

Extension creation starts with creating a `manifest.json` file.

where inject_adblock.js is JS which is injected into an existing web application when it’s loaded and adblock_bkg.js is a JS worker which contains ads blocking logic.

Since the extension has to intercept HTTP requests and as there is the only way to do that from a web-page is to use Service Worker, therefore that’s exactly what inject_adblock.js does.

The background worker adblock_bkg.js uses the https://github.com/talmobi/ad-block-js library and https://easylist.to/ list to match ads URLs.

where 'adblock-rules.js' contains EasyList rules:

The service worker adblock.js intercepts HTTP requests and sends a message to a background worker to check a URL.

Now it’s time to register the extension in a Webfuse space.

Now let’s execute, for example cnn.com in a Webfuse session and see what requests will be blocked.

So, as it was shown the extension works and does its job, but let also summarise pros and cons of this approach.

Pros:

• The extension is installed per a Webfuse session and not per a browser. When a session is started the extension is already in place and no user interaction is needed to install it, which would be the case if it was a browser extension.

Cons:

• The service worker can be registered from a web-page itself therefore the extension has to inject JS into the page and initialise the service worker every time the page is loaded.