What if the filter came after the render?

[Sm00shed]

While testing, I noticed that YouTube always enforces 1x playback speed during ads – regardless of user settings. A small but reliable signal, detectable even with E2E encryption.

setInterval(() => {
  const ad = document.querySelector('.ad-showing');
  const video = document.querySelector('video');
  if (ad) console.log('AD DETECTED');
  else video.playbackRate = 2;
}, 500);

This led me to a different thought.

SSAI and server-side ad insertion exist and are actively used – content and ads arrive as a single stream. DNS blocking does not reach that.

Cromite already has a network filter and a cosmetic filter. What if the cosmetic filter applied only after the full render – after everything has loaded, everything has executed? The code is essentially already there.

What would change?

[Sm00shed]

Following up on my post from two weeks ago

Two weeks ago I posted a small observation about playback behavior as an entry point. But the actual idea goes further.

The direction ad delivery is heading

SSAI stitches ads directly into the stream server-side – content and ads arrive as one package. DNS blocking is blind to it. This is no longer an upcoming trend. Amazon AWS, Google Ad Manager and RTL are already actively using SSAI worldwide. Network-level blocking is becoming increasingly irrelevant as a result.

The two-layer idea

Layer 1 runs exactly like any other browser. All requests go through, JavaScript executes fully, ads are delivered, impressions are counted. From the outside the browser looks like one of millions of normal Chrome instances – nothing unusual to detect.

Layer 2 applies only after the DOM is fully rendered. It filters what the user actually sees. Ads were delivered – but never seen. Like a TV running in an empty room. No ad blocker detection can fire because nothing was blocked.

Why Cromite specifically

The cosmetic filter already exists and already touches the DOM. The question is only whether it could be applied later – after the full render rather than during. You already work deep in the renderer. And Issue #2721 shows you are actively thinking in this direction.

Whether that would be a timing problem or a solvable technical challenge – I honestly don't know. For static pages I suspect no issue. For dynamic pages like YouTube probably yes.

Finally

This idea feels bigger than a single project – SponsorBlock, uBlock Origin, yt-dlp, ungoogled-chromium, Cromite – all fighting separately against the same problem. Maybe there is a common path.

I'm curious about your thoughts – whatever direction they go.

---

P.S. I meant to keep this to 5 minutes. Ended up at 15. 7 is the compromise – sorry.