index.htm

Media Cookie Broker

Delivers browser cookies to server-side software without giving it access to the browser profile.

Put together with AI using materials from my project and my edits.

AI-translated from Russian. Read the original.

Source code — Media Cookie Broker

Media Cookie Broker passes cookies from an ordinary browser to software running on a server without a graphical interface. Its primary use case is YouTube with yt-dlp: a person signs in through Chromium and manually refreshes the cookies in the broker, while a process on a Linux server receives them in a standard cookies.txt file.

The browser profile itself never moves to the server. The server-side software does not control Chromium or attempt to complete sign-in, CAPTCHA, or two-factor authentication on its own. When a session stops working, a person restores it in the browser and sends the cookies to the broker again.

How cookies reach the server

An unpacked Manifest V3 extension is installed in Chromium 120 or later. The user signs in to the relevant site and manually starts the refresh. The extension collects cookies for the configured service and sends them to the broker using a dedicated username and password for writes.

The broker stores the received cookie set in SQLite and assigns it a revision number. On the Linux server, cookie-sync polls for a newer revision. When one appears, it downloads the update through a separate read-only account and atomically replaces the local Netscape-format file with mode 0600. A network, decryption, or write failure leaves the working file in place, so the consumer continues using its last known good copy.

yt-dlp or another program reads a conventional cookies.txt and knows nothing about the extension or the broker. Media Cookie Broker only delivers updates and does not participate in the consumer’s subsequent operation.

The system’s components

The system is split into four small pieces:

In version 0.3.1, the extension was rewritten from JavaScript to TypeScript.

The default topology pairs desktop Chromium with a separate Linux server. The browser connects to the broker through an SSH tunnel bound to a loopback interface, so the HTTP API does not need to be exposed to the public network. Deployments that cannot use such a tunnel must protect the traffic with HTTPS or carry it over a private network.

Security boundaries

The broker uses separate HTTP Basic accounts for writes and reads. Each account is restricted by operation and cookie set: a client with read access cannot update that set or retrieve the others. SQLite data is encrypted with AES-256-GCM, while the key is stored separately from the database. Revision numbers keep cookie-sync from rewriting an unchanged file, and the database retains the five latest versions for recovery.

Those controls narrow access, but they do not change what cookies are: bearer credentials that let their holder act as the browser session. Database encryption cannot help if an attacker gains access to both the host and the key. The extension stores its write password in chrome.storage.local, so the system also depends on the security of the browser profile and workstation. On the Linux server, the cookies already exist in a decrypted cookies.txt available to the authorized consumer; compromising that server exposes them as well.

Installation and supported scope

Version 0.3.1 provides installers intended specifically for that release and the supported Linux-server setup. The Docker Compose path builds the broker locally from source; there is no prebuilt image in a container registry. The Chromium extension is installed manually from an unpacked directory.

The project has not yet reached version 1.0 and does not promise seamless upgrades. Moving from 0.1.0 requires a clean installation. YouTube → yt-dlp is the primary tested path; support for TikTok, Instagram, X, and VK remains experimental.

The current version does not include Firefox, non-Linux installers, a web administration interface, OAuth, high-availability replication, runtime provider loading, or automatic session verification after a cookie refresh. The broker does not bypass anti-bot measures and cannot guarantee that an external service will accept the transferred session.