When the Browser Knows More Than the App
OmniGet's browser extension solves a specific boundary problem: the browser often has the page context, authenticated session, or runtime evidence that the desktop app cannot recover from a URL alone. This chapter focuses on what crosses that boundary, how the local bridge authenticates it, and why cookie handoff is an authorized session mechanism rather than a way around DRM. The practical understanding is simple but important: the extension discovers and supplies context; the desktop app owns durable queueing and processing.
A page can look ordinary while hiding several facts. The user may be signed in, the media request may require the page's referer, and the player may construct a playlist inside an iframe or expose it only as a blob: URL. If OmniGet received only the visible address, it might know the page identity but not the request context that makes the media reachable. The extension is the component already living where those facts are available.
The browser contributes context, not a second download queue
For supported pages, the extension can send the page URL to OmniGet with metadata such as the title, thumbnail, referer, media type, user-agent information, and cookies. The app can then put the URL through the same local resolver and queue that handles pasted links. This division keeps the browser close to the source and the desktop app close to the durable result. The extension does not need to become a permanent scheduler, file manager, or media processor.
For pages the extension recognizes, this is a direct handoff. For pages it does not recognize, the extension can observe media traffic. Its sniffer watches for common media shapes such as MP4, HLS, DASH, WebM, and audio streams, then records detected media by page identity. That page identity matters because a browser tab can navigate, refresh, or contain multiple frames. A detected stream should remain associated with the page that produced it rather than becoming an unexplained global URL.
Deep search handles a harder case. Some players do not expose a playlist as a normal network response that a simple sniffer can list. The extension can run page-side discovery and record that a playlist was found, including which frame supplied the evidence. When the user sends the item to OmniGet, the background service asks that same frame for the manifest text. This is a transfer of page evidence, not merely another attempt to fetch the URL from the desktop.
That distinction explains an otherwise surprising failure. A captured playlist may be represented by a synthetic or blob-backed address that is useful only inside the tab. If the tab navigates away or the frame disappears before the text is sent, the extension cannot reconstruct the playlist. OmniGet reports that the manifest is gone rather than queueing a synthetic address that will later fail as if it were an ordinary network host. The limitation is not a missing retry; it is the disappearance of the source context that made the item meaningful.
The fallback path makes the same boundary visible. The preferred route is the local HTTP bridge, which can carry the full metadata and cookie payload. If the bridge is unavailable, the extension can open the omniget:// scheme so the desktop app can still receive the URL. That fallback queues the link but cannot carry the cookies that make private media accessible. A user may therefore see a successful handoff while losing the full session-aware experience. The two paths have different capabilities, and treating them as equivalent would hide an important failure condition.
The loopback bridge is a real interface
The extension and desktop app communicate through a service bound to 127.0.0.1, not through a remote server. The bridge exposes a public health check so the extension can determine whether OmniGet is running, but sensitive operations require an authorization bearer. Protected operations include enqueueing URLs, reading queue state or logs, exporting cookies, and using the MCP endpoint. The location limits where the service can be reached; the token decides which requests are accepted.
Pairing is intentionally user-triggered. When the user chooses to pair the extension in OmniGet, the app opens a short window in which the extension may request the token. That window is single-use and closes after a successful handoff. The token is generated for the installation and persisted so the extension can use the bridge later, while the user can regenerate it by changing the stored pairing state. This is less brittle than an operating-system native-messaging manifest tied to a hard-coded extension ID, but it still leaves a secret that must be protected.
The bridge validates more than the bearer. It checks the protocol version, rejects invalid external URLs, caps request bodies, and limits cookie batches. It can store extension metadata and captured manifest text before handing the URL to the normal external-URL handler. That ordering matters: the queue should receive the URL together with the context that will be needed when the item eventually starts, even if it does not start immediately.
Imagine a user sends a members-only lesson while another download is already active. The bridge does not need to keep the browser page open while the item waits in the queue, but the app must retain enough context to make the later request resemble the one the page authorized. Metadata identifies the item; cookies and referer supply request context; the queued URL remains the object the normal resolver will process. This is why the bridge stores context before queueing rather than asking the extension to act as a live proxy for the whole transfer.
The same ordering helps with a captured HLS playlist. The browser may have seen the playlist text inside a player, while the desktop process can perform the slower fragment transfer more reliably. The extension sends the text and the URL identity; the app parks the text locally and the HLS path retrieves it when the queued item starts. If the text is absent, the app can fall back to fetching the URL when that is possible. If the URL is synthetic and the text is gone, there is no honest network fallback. The interface preserves that distinction instead of converting a missing page fact into a misleading download error.
Frame identity is part of the same ownership problem. An iframe can hold a different player and a different captured manifest from the top-level document. Asking the whole tab for “the manifest” could return whichever frame answers first, which might be a different media item. The extension records the frame that produced the detection and asks that frame for its copy. This is a narrow implementation choice with a broad consequence: context must be carried together with the identity of the source that produced it.
The authenticated bridge also lets the app expose queue state and redacted download logs to the extension or an external harness without creating a second state store. The same bearer protects those reads. That reuse reduces disagreement between what the desktop window shows and what an integration observes, but it increases the value of the token: a client that can read queue state or enqueue a URL is participating in the same local workflow. Authentication therefore protects both credentials and operational control.
The sequence also shows why accepting browser-origin requests does not remove the need for authentication. The bridge may allow any browser origin because the bearer is intended to be the actual authorization boundary. If an unrelated local client obtains that bearer, the loopback address does not rescue the design. Localhost is a location, not a complete security policy. The repository's implementation supports constant-time bearer comparison and a paired window, but those mechanisms do not defend against every compromised browser profile, local process, or user decision.
Cookies are scoped session material
OmniGet does not need every browser cookie for every request. The extension tracks selected domains and authentication-related cookie names, groups them by the actual site, and throttles automatic capture. The grouping avoids treating a cookie for one service as generic browser material that should be attached to unrelated requests. Automatic capture is also debounced and rate-limited so that ordinary browser activity does not produce a continuous stream of credential exports.
The extension can perform an explicit manual capture as well. It normalizes the active tab's domain, reads cookies for that site, and sends source information such as the page URL and title so the desktop Cookie Manager can label the resulting account. This creates a useful human boundary: the user can deliberately say that the session on this site should be available to OmniGet, rather than silently turning the entire browser profile into a shared store.
On the desktop side, cookie sources have an order of precedence. A managed per-domain account can take priority over a manual header; an extension file or global cookie file can serve as another source; browser extraction can be a later fallback. The exact order is less important than the principle it represents: the downloader should know which session it is using and avoid combining unrelated sources by accident. Account selection is part of the job's context, not an invisible side effect of whichever browser happens to be installed.
There is also a small but meaningful file-handling detail. The extension writes a cookie file for the app, but yt-dlp may rewrite a cookie file during a run. OmniGet copies the extension file to a disposable session copy before passing it to yt-dlp, protecting the source that the browser integration will use later. This is a form of state ownership: the extension owns the original capture, while the downloader owns the temporary representation it may need to mutate.
The same context must reach the actual request. For direct media and HLS, the app can attach cookies and a referer to the HTTP client. The referer tells the host which page led to the stream; the cookies represent the user's session. Either may be required for a request that looks public from the URL alone. The bridge therefore does not merely “log in” OmniGet in a broad sense. It carries selected request context from a browser page to a particular queued job.
Convenience stops at authorization
This session-aware design is useful for a purchased course, a private story, or a members-only video that the user's browser can already open. It does not imply that every media request will succeed. Cookies may be expired, a service may require a browser fingerprint or an additional token, a profile may be logged into the wrong account, or the platform may rate-limit the request. The extension can provide context; it cannot manufacture permission that the session does not possess.
The same boundary is sharper for DRM. OmniGet's documented behavior is to use the user's existing access and stop when the content is protected in a way the tools do not support. Carrying cookies and referers is not equivalent to defeating encryption or a paywall. This distinction protects both the user and the architecture: the browser bridge remains a way to transfer authorized context, not an escalation path.
The browser also remains a sensitive part of the trust surface. A user who pairs an extension grants a local component access to selected session material. An agent connected to the same bridge may gain the ability to queue or inspect local work, depending on which interfaces are enabled. The safer interpretation is not that the bridge makes cookies safe, but that it narrows and makes visible a transfer that would otherwise be implicit. Users still need to protect the browser profile, pairing token, local machine, and any agent configuration.
Once the browser has supplied the context, OmniGet still has to choose the transfer mechanics. A direct file can be streamed, an HLS manifest can be followed and merged, and a platform URL can be sent through yt-dlp. The extension has done its job when the desktop downloader receives the right evidence and access context; it does not decide how bytes are validated, resumed, or finalized. That separation is what lets OmniGet reuse one queue across browser-assisted and ordinary jobs, while keeping the next boundary clear: discovery and authentication are complete, but acquisition has only begun.