DOCS · SECURITY

Threat model & security

See which adversary Dodge is built against, what a defense does and doesn't hide, and what isn't covered.

Just want to use Dodge? See install. New to video fingerprinting? Start with learn.

This page collects the security reasoning behind Dodge in one place: the adversary the framework assumes, what a defense hides from them, and what isn't in scope. If you are new to the attack, read how video fingerprinting works first.

The adversary Dodge is built against

Dodge targets one attacker: a passive observer on the network path between you and the video server. They can see the size and timing of every request and response you make, but not the contents. They hold a catalog of fingerprints they built by watching the same content themselves or downloading video metadata, and they match what they observe against it. Coffee shop neighbors, campus and workplace network admins, and ISPs are examples.

A defense reshapes the network traffic that particular observer sees. Everything below is about the gap between that goal and what a real deployment achieves.

What a defense does not hide

Even a well-designed defense working exactly as intended leaves several things visible:

That you are streaming video. The traffic is still a long sequence of segment-shaped downloads.
That you are using a defense. Defended traffic does not look like undefended traffic, and it is not meant to. An observer can tell.
(Possibly) how long you watched. Trailing padding can extend a session's apparent duration by a random or fixed amount, which hides its exact length, but a defended session is still recognizable as some defended session of some length.
Anything outside your video traffic. Dodge is not an anonymity tool. It does not disguise other network activity, and it does not hide your identity or location the way a VPN or Tor is meant to. Rather, Dodge is a complement to those tools.

The video server

Dodge runs entirely on the client. A defense reshapes requests from inside the player, so it needs no cooperation from the video server, and it assumes none. A provider doesn't have to provide extended manifests, expose any special byte range support, or change anything server-side for a viewer to defend a stream they're watching.

The server is treated as an honest-but-curious party. Dodge assumes that it serves the ranges a defense asks for faithfully and does nothing to actively mark traffic. It doesn't, for instance, coalesce or pad responses to reconstruct the original segment sizes, or manipulate timing in a way that identifies the stream. A server that actively works to undo the defense this way is outside what a client-side approach can counter; the adversary Dodge is built against is an observer on the network path, not the content provider.

The server is not, however, assumed benign. It receives every request directly, so a defense hides nothing about your viewing from the server itself: it sees which manifest and segments you fetch and can log them, it sees your IP address if you reach it over your own connection, and it can tie the session to your account if you're signed in. Addressing that is out of scope for Dodge and requires the usual tools: watch over a VPN or Tor so the server doesn't see your address, and without a user account so it has nothing to link the session to.

Anonymity sets

A defense built for one video in isolation can hide that video's size pattern, but it can't make the video look like another specific video. Doing that requires an anonymity set: a group of videos shaped so their defended traffic is mutually indistinguishable, leaving an observer who recognizes the pattern knowing only that you are watching one of the group.

However, an anonymity set only conceals which video within it you are watching. It does nothing about what the adversary can discern by other means: which page you're on, which content provider you're visiting, published view counts and similar attributes that indicate that certain videos in a set are far more likely to be watched than others, or repeat observations that can be intersected across sessions. Sets built by grouping similar videos are the most vulnerable to this; large, deliberately dissimilar sets hold up best.

How sets are constructed, why the constant-size defense yields an extensible one, and the full list of ways a set gets chipped away at are covered under choosing a defense.

Beyond the segment pattern

A defense shapes response sizes. That is the main signal, but it is not the only one, and careless deployments can undermine defenses if they don't consider other factors.

Request sizes. Requests are observable, too, and their sizes depend on the segment URL and the Range header. Dodge normalizes URL length via query parameters and headers, but that alone does not equalize request length, which is especially important for HTTP/2 and above as well as QUIC. Set paddingLengthBase and paddingLengthRandom to pad requests to a fixed wire size; see the settings reference for how to pick values.
Request timing. Dodge schedules cycles on a random walk rather than on the player's natural buffer-driven cadence. Each cycle waits scheduleWaitBase milliseconds plus a random offset of up to scheduleWaitRandom, so the spacing between requests no longer tracks how full the playback buffer is. Changing either value means re-running your evaluation to ensure nothing broke.
Player features that fetch outside the defense. Thumbnails, non-fragmented text tracks, XLink references, DRM, CMCD telemetry, content steering, and DVB reporting all generate traffic a defense does not shape. strictMode: 'max', which we highly recommend, rejects the first three and warns about the rest; see strict mode.
Where you seek. A defense shapes a playback session as a sequence of cycles, and a seek resumes at the first non-padding cycle that holds the segment you jumped to. The defended traffic pattern is not altered, but the jump is visible, and roughly where in the video you landed might be too (especially if you watch to the end). That can be a problem when the destination is predictable: always resuming at the same offset is a stable signal across sessions, and jumping straight to a scene an observer can locate in a copy of the video they have ties you to that video. An anonymity set does not help here, because where you seek is a behavioral factor.
Caches. A cache hit produces no request, so anything the browser can answer locally is a hole in the pattern the defense is meant to produce. Dodge gives a defended segment request a random value in its padding query parameter, and HTTP caches key on the full URL, so an ordinary browser cache cannot serve that request twice. Caches that key on something other than the URL are not covered: dash.js caches init segments by representation, though this is off by default and in the safe player. On a malicious page, a service worker can match with ignoreSearch and answer whatever the padding value is.

Failing closed: error handling

Dodge is engineered so that a broken defense stalls rather than playing undefended. If an extended manifest references a period, representation, or segment that doesn't resolve at request time, the player stalls. It does not skip the cycle or fall back to the ordinary dash.js pipeline, because that would bypass the defense and lead to exposure.

The one way to get around this is strictMode: false, which falls back per representation with no error. It exists for testing and should never be used in production: any representation the extended manifest doesn't cover plays through the undefended pipeline, with no warning at playback time. The four levels are documented in the settings reference.

The browser extension

The extension has its own trust boundaries: what it verifies about a page before swapping in the Dodge player, the build integrity check it performs, and the network lockdown applied to the safe player, which on a defending tab blocks every request except the page document and the video origin. That documentation is still being written and will be available here.