Stasha — Privacy Policy

Last updated 2026-09-15

Stasha ("the extension") is a browser extension that detects and saves streaming video (HLS, DASH, and progressive MP4/WebM) from pages you visit. Detection, format conversion, and saving all run inside your browser.

This policy has two parts:

• Part 1 — In force today describes the extension as currently shipped.
• Part 2 — Upon the cloud-save release describes a planned, optional feature that has not shipped. It is published in advance so you can read about the change before it exists. Until the extension's release notes announce cloud save, only Part 1 applies.

Part 1 — In force today

Summary

• The extension has no server, no backend, no account system, no analytics, and no telemetry. Nothing is ever transmitted to the developer — there is no developer infrastructure that could receive it.
• The only network requests the extension makes are to the media you are viewing or chose to download, listed exhaustively below.
• Everything the extension stores, it stores on your device, and none of it leaves your machine.

The complete list of network requests the extension can make

This list is intended to be exhaustive. If you ever observe the extension making a request that does not fit one of these categories, that is a bug — please report it.

1. Manifest and playlist fetches (detection). When a page plays a stream, or when you press "scan", the extension fetches the stream's manifest and its variant playlists — the same URLs the page's own player uses — to read out the available qualities.
2. In-page confirmation fetches (scan). The page-scan step re-fetches candidate manifest URLs that the page itself already loaded, from within the page's own context, to confirm they really are manifests.
3. Media fetches during a download you start. Segments (HLS/DASH) or the whole file (progressive), fetched from the stream's own hosts.
4. Stream-key fetch (AES-128 HLS). When an HLS stream is delivered with standard AES-128 transport encryption, the extension fetches the key at the URL the stream's manifest points to — the same key the page's own player fetches to play the video. Streams that use DRM (Widevine, PlayReady, FairPlay, SAMPLE-AES) are detected and refused, so no such request is made for them.
5. Preview fetches. When the popup shows a detected stream, the extension may fetch a small portion of that stream to render a short preview locally.

Every one of these requests goes to a URL derived from a page you visited or a stream you selected. All of them are restricted to http(s) and are blocked from reaching private, loopback, link-local, and cloud-metadata addresses by an allowlist check in the code.

What the media host learns from these requests is essentially what it learns when the page plays the video: your IP address, the request headers described in the next section, and its own cookies (attached by your browser under its normal rules). The extension gives the media host no information about you beyond that.

Requests the extension never makes: there are no analytics or telemetry endpoints, no error reporting, no version or update pings in the extension's code (your browser updates extensions through its own store mechanism, independent of anything the extension does), no uninstall page, and no remote images in the extension's UI — the extension pages' content-security policy limits images to local data, so even thumbnails are never loaded from the network.

No remote code: all executable code, including the bundled WebAssembly media library, ships inside the extension package. The content-security policy is script-src 'self' 'wasm-unsafe-eval'; nothing executable is fetched at runtime.

Request headers and cookies, precisely

To make a download succeed on sites that check where a request came from, the extension replays onto its own media fetches some of the headers the page's own media requests carried:

• Referer, Origin, and User-Agent are replayed via temporary, session-only header rules that apply only to the extension's own requests (never to normal page traffic), are installed per download job, and are removed when the job ends or the browser session ends.
• Other headers the page's media requests carried — for example a media-access token the page attached — are held in memory and re-sent on that download's media fetches so the download works the way playback did.
• Cookies are never read, copied, stored, or injected by the extension. Its media fetches are ordinary credentialed requests: your browser attaches its own cookies for each host under the browser's normal rules, exactly as it does for the page. The header-replay mechanism deliberately excludes Cookie, so one site's cookies can never be sent to a different host.

Captured headers are transient: the observation buffer drops each request's headers as soon as that request finishes, header data lives only in memory (including the browser's in-memory session storage, which is cleared when the browser closes), and headers are stripped out before anything is written to the on-disk download history.

None of this header data is ever sent to the developer.

What is stored on your device

All of the following is stored locally, and none of it ever leaves your machine:

• Settings — save-dialog preference, default quality, and the optional local download-organization options.
• Download history — a capped list (most recent 50) of your downloads: media URL, title taken from the page, quality label, timestamps, and the parameters needed to retry — with all captured headers removed. Older entries are discarded automatically; you can remove all of it at any time by clearing the extension's data in your browser or uninstalling the extension.
• The job journal — internal bookkeeping (job state and temporary-file paths) that lets interrupted downloads be cleaned up after a crash or restart. Entries are capped and expire on a 12-hour retention clock.
• Staged download data — temporary video data assembled in the browser's private extension storage (OPFS) while a download is in progress. It is deleted when the download completes; orphaned files from interrupted downloads are swept automatically, with a 12-hour backstop.
• One dormant field reserved for possible future functionality, currently always empty.

What the extension refuses by design

• YouTube is blocked by design. The extension will not surface YouTube as a downloadable source.
• DRM-protected streams are detected and refused (Widevine, PlayReady, FairPlay, SAMPLE-AES) — at manifest parsing, in the UI, and again in the download code. The extension never attempts to break DRM and contains no DRM components.

Data retention and deletion

Everything is local. Clear the download history from the extension's UI; remove everything by uninstalling the extension or clearing its site data in your browser. Uninstalling removes all of its stored data. There is nothing to delete anywhere else, because nothing exists anywhere else.

Permissions, in plain terms

• tabs, webRequest, scripting, host access on all sites — detect streams on whatever page you happen to be on, and read basic page metadata (title) to label them.
• declarativeNetRequest — the session-scoped header replay described above.
• downloads — save the finished file through the browser's normal download mechanism.
• offscreen, storage, unlimitedStorage — assemble large videos locally.
• sidePanel — the optional side-panel UI.

The extension requests no permission it does not use.

Changes to this policy

If what the extension does with data ever changes, the change will be announced in the extension itself before it takes effect, this document will be updated with a new "last updated" date, and any feature that sends data anywhere new will require your explicit opt-in first (see Part 2 for the one such feature currently planned).

Contact

Questions about this policy: stasha@developeroffice.de.

Part 2 — Upon the cloud-save release

This part is not yet in effect. It describes an optional cloud-save feature that is planned but has not shipped. It becomes effective only when a released version of the extension includes the feature, which will be announced in that version's release notes and in the extension itself. It is published now so the change can be reviewed in advance.

What the feature is

Cloud save will let you connect your own storage — for example your own Dropbox, a WebDAV server you control (such as a NAS), an S3-compatible bucket you own, or your own Google Drive — and have finished downloads uploaded into it, organized into folders.

Consent comes first

• Cloud save is off by default and does nothing until you connect a storage provider.
• Before the first upload ever happens, the extension will show a consent screen describing exactly what will be sent where, and will proceed only if you agree. Existing users will see this disclosure in the extension before the feature can activate for them.

What changes on the network

When (and only when) you connect a provider and uploads run, these request categories are added to Part 1's list:

1. Upload requests from your browser directly to your chosen provider — the finished video file's bytes and the folder/file names it is saved under. Note that the folder template can include the name of the site a download came from; if you use it, that site name becomes a folder name inside your storage.
2. Sign-in and token requests to your chosen provider's authorization service (for providers that use OAuth, e.g. Google or Dropbox): the standard requests that connect your account and periodically renew the access credential.
3. For self-configured destinations (WebDAV, S3-compatible): requests to the server address you yourself entered, authorized with the credential you entered.

Everything travels directly from your browser to your provider. There is no intermediary.

What we can and cannot see — unchanged

• We operate no servers. Your files, your file names, your provider credentials, and your OAuth tokens are never sent to the developer and never pass through any developer-controlled system. We cannot see, scan, copy, or delete anything you upload.
• Credentials are stored locally only, in the extension's storage on your device, and are sent only to the provider they belong to. Disconnecting a provider in the extension, or uninstalling the extension, removes them from your device; you can also revoke the extension's access at any time in your provider's own security settings.
• Where a provider supports scoped access, the extension will request the narrowest scope that works (for example, Dropbox "app folder" access, or a Google Drive scope that can only see files and folders the extension itself created — it cannot read the rest of your Drive).

Google API Services — Limited Use disclosure

The following statement applies from the release that includes Google Drive support, and will also appear on the hosted privacy page at that time (placement required by Google):

Stasha's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

For clarity: the only "information received from Google APIs" the extension will handle is what is needed to place your files into your own Drive (the OAuth credential and the metadata of files/folders the extension itself creates). It is used solely to provide the upload feature you configured, stored only on your device, and never transferred to anyone.

What does not change

• Still no telemetry, no analytics, no developer server, no account with us.
• Downloads themselves work exactly as in Part 1 whether or not you connect any storage.
• The store data-use declarations and this policy will be updated in the same release the feature ships in, and the feature will remain inert until you opt in.