How to Judge a Video Downloader Extension's Privacy and Permissions

A browser extension’s permissions tell you what it is able to do. Its privacy policy tells you what its developer says it does. Neither proves what the code actually does. To judge a video downloader, compare those three things: ask whether the permissions fit the job, whether the disclosures match the permissions, and whether the publisher is accountable if they don’t. Broad access alone doesn’t show that anything is being collected, and the absence of a warning doesn’t show that nothing is.

This guide gives a checklist you can run in a few minutes using only public information, without opening your own cookies or inspecting request headers.

Capability, disclosure and behavior are different evidence

	What it tells you	What it can’t tell you
Permissions (the manifest and install prompt)	The most the extension is allowed to access	Whether it uses that access, or what it does with the data
Store listing and privacy policy	What the developer says it collects and why	Whether the code does only that. It is a statement, not an audit
Behavior (what the code really does)	The truth	Not visible from a prompt; takes code review or traffic analysis

Keeping these apart avoids two mistakes: treating a scary-looking permission as proof of misuse, and treating a reassuring policy as proof of safety.

How Chrome describes permissions

Chrome’s permission documentation separates several categories: API permissions such as storage or downloads, host permissions that give access to sites matching a pattern, content-script match patterns, and optional versions granted at runtime. Many powerful capabilities need a permission and host access together. The documentation lists, among the things host permissions enable, monitoring network requests with webRequest, accessing cookies through the cookies API, injecting scripts and making requests from the extension.

Two points follow from this, and both correct common advice:

• Judge combinations, not single permissions. The dedicated cookies API requires the "cookies" permission together with host permissions for the sites involved. But that API isn’t the only place cookie data can appear: the webRequest API can expose the Cookie request header and the Set-Cookie response header to an extension that has the right host access and asks for extraHeaders. So “no cookies permission” doesn’t mean an extension can never see cookie values, and “all sites” access doesn’t by itself mean it does see them. Ask what the extension’s whole set of permissions, host access and declared features allows, and whether that fits its job. Network-observation permissions plus wide host access is a stronger capability than either alone, and a downloader that detects streams on arbitrary pages needs exactly that combination, so what matters is whether the extension explains it and you trust the publisher.
• You cannot verify theft by inspecting your own cookies. Checking cookie values or request headers on sites you are logged into is unreliable as a consumer test, and it puts session tokens in front of you and your screen. Don’t paste them anywhere, and don’t test an extension on sensitive accounts.

A checklist you can run safely

1. Read the permissions and their scope

Open the extension’s store page and look at the permissions, and read the host access. Note which are API permissions, which are host patterns, and whether any are optional. A narrow permission list is easier to reason about; a wide one needs an explanation.

2. Ask whether the access fits the job

Match each broad permission to a feature the extension advertises. A downloader that detects media on whatever page you open has to be able to see that page’s network activity, so it may reasonably ask for wide host access. A tool that only saves videos from one named site shouldn’t need it. If a permission doesn’t correspond to anything the extension does, that is a question for the developer, not proof of malice. If you can’t get an answer, don’t install it.

3. Read the privacy policy against the permissions

Look for specifics: what data is collected, whether it leaves your device, what is sent when you contact support, retention, and any analytics. Chrome’s Web Store privacy policy requirements say that a product that handles user data must post an accurate privacy policy that discloses how data is collected, used and shared. Vague language, no mention of the permissions it requests, or a policy that contradicts the listing are all reasons to hold off. Remember that store review is not a guarantee that a particular extension behaves safely.

4. Check accountability and change

Is there a named publisher, a working support address and a website? Look at the update history: when permissions grow, Chrome may show a new warning, and a new permission should have a plausible reason in a feature change. Reviews and install counts are weak signals; they say what other people noticed, not what the code does.

5. Respond in proportion

If a permission or disclosure stays unclear, don’t grant it. If you no longer use an extension, remove it. Prefer extensions that ask for access when needed or that explain every permission plainly. You can also keep a separate browser profile for tools you don’t fully trust, so they never see your main accounts.

Reading a real example: MAX

MAX is our product, so treat this as a publisher’s disclosure and not an independent audit. MAX’s privacy policy says that media detection, preferences, settings and download history are handled locally in your browser and are not sent to the website during normal extension use, and that the extension doesn’t use browsing activity for advertising, resale or third-party profiling. It also says what does leave your device: if you submit a report, feedback or a support request, diagnostic details you send are transmitted, which may include the page URL, browser information, settings, detected media information, download details or error logs.

The policy’s permission table is the kind of mapping to look for. It lists tabs, webRequest, declarativeNetRequest, webNavigation, downloads, nativeMessaging, storage, notifications and the host permission <all_urls>, with a stated purpose for each: for instance, observing network requests to detect HLS and DASH streams, and using the host permission to detect media across sites. That list is a good example of a broad permission with a matching explanation. It does not prove the code never does anything else, and the same test applies to any extension: the explanation must fit the feature, and you decide whether you trust the publisher.

If you want to try it, MAX Video Downloader is free and doesn’t need an account.