Extenshiextenshi.io/blog
Back to articles
privacybrowser-extensionspermissionsdownloads-permissionchrome-extensionsextension-security

The `downloads` permission explained: what extensions can really do with your files

The downloads permission lets an extension read every file you've downloaded, write new ones, and hide the download UI. Here's what it allows and how to check.

Maxim Kosterin
9 min read
A thin ink arrow dropping into a shallow empty tray, and below it a long stack of hairline ledger rules with a single one painted in orange watercolor.
A thin ink arrow dropping into a shallow empty tray, and below it a long stack of hairline ledger rules with a single one painted in orange watercolor.

Chrome shows you one line when an extension asks for the downloads permission: "Manage your downloads." It sounds like filing. Like the extension is offering to tidy up your Downloads folder.

What it actually buys is a timestamped record of every file you have ever pulled down — where you got it, the page you were on when you clicked, the exact path it landed on — plus the ability to write new files, rename files as they arrive, and switch off the download UI so you never watch it happen.

Three separate manifest permissions share that same one-line warning, and the install dialog gives you no way to tell them apart. Let me walk through what's actually behind the string.

What the downloads permission actually means

Declaring "downloads" in the manifest unlocks chrome.downloads, the browser's programmatic handle on its own download manager. Per the Chrome permissions list, it surfaces to you as "Manage your downloads."

So do downloads.open and downloads.ui. Same eight words, three different capabilities. That's the first thing worth internalising: the warning you read is not the same as the capability you granted.

In our catalog snapshot from August 3, 2026, 18,856 of 338,449 live listings across Chrome, Firefox and Edge declared downloads — about 5.6%. Tenth on the permission table, well behind storage (64.1%) and activeTab (35.7%), but ahead of both cookies and webRequest. It isn't rare. It's just quiet.

What it actually allows

It reads your entire download history. One call, no arguments, no user interaction:

// With the "downloads" permission, an empty query returns everything
chrome.downloads.search({}, (items) => {
  for (const item of items) {
    console.log(item.url, item.referrer, item.filename, item.mime, item.startTime);
  }
});

Per the chrome.downloads reference, every DownloadItem carries url (before redirects), finalUrl (after them), referrer — the page you were on — and filename, documented as the absolute local path, alongside MIME type, byte size, and ISO timestamps.

Read that list again as a privacy person, not a developer. referrer is a browsing trail. filename is an absolute path, which on most machines begins with your OS username — often your actual name. And all of it arrives without the extension ever requesting the history permission.

It writes files to your disk. downloads.download() fetches a URL the extension picks, under a filename it picks, optionally with custom HTTP headers, method and POST body. The one real guardrail: the path is relative to your Downloads directory, and absolute paths or .. back-references throw an error.

So nothing lands in a startup folder. Something can absolutely land in Downloads/invoices/statement.pdf.

It renames files on the way in. The onDeterminingFilename event fires while Chrome is still deciding what to call an incoming file, and a listener can override that name. When two extensions both want to, the docs are refreshingly blunt: the last one installed wins, and users "should not install extensions that may conflict."

It can hide the download UI. With the extra downloads.ui permission, setUiOptions({ enabled: false }) switches off the download UI for the whole profile — and it stays off for as long as at least one extension keeps it off. (setShelfEnabled, the older form, is deprecated since Chrome 117.)

It can tidy up afterwards. erase() removes entries from your download history without touching the files. removeFile() deletes a file. And with the extra downloads.open permission, open() hands a downloaded file to your OS default application — that one, at least, requires a user gesture.

Why the combination is the problem, not any single call

Taken one at a time, each of those is defensible. A download manager needs search(). An exporter needs download(). A minimalist-UI extension has a plausible story for hiding the shelf.

Stack them and you get something different in kind: fetch a file, give it a boring name, suppress the notification, erase the history row. The file is on the disk. The browser's own record of it isn't.

The boundary matters for judging risk, though. This permission governs observing and managing downloads, not causing them. Any content script can build an <a download> link and trigger a save with no permission whatsoever — the mechanism behind the zero-permission dropper problem I covered earlier.

So downloads doesn't unlock file-saving. It unlocks the file-saving records, and the controls wrapped around them.

A 2025 arXiv preprint surveying malicious extensions makes the same point from the other direction: attackers rarely need exotic permissions, and minimal sets like storage, tabs and scripting cover most of what they do. So treat downloads as an amplifier and a data source of its own, not a prerequisite.

Who actually declares it

Names make this concrete. Three from the catalog, each a different shape of "yes, it needs this":

  • Free Download Manager (Chrome, ~3M users) and Video DownloadHelper (Chrome, ~5M) are the unsurprising case. The permission is the product; take it away and there's nothing left. Both also carry nativeMessaging or webRequest, which is what a download manager looks like from the manifest side.
  • Chrome Remote Desktop (Chrome, ~38M) is the instructive one. It declares exactly two permissions — nativeMessaging and downloads — and it is not a download tool at all. A two-item manifest is about as far from over-asking as an extension gets, which is the reminder that presence alone was never the signal. Proportion is.
  • 1Password (Chrome, ~6M) sits in the middle: a password manager, with downloads among a long list. Vault export is a headline feature, so the API has an obvious job — but this is exactly the case where you'd want to know why rather than assume.

The sub-permissions are much rarer than the base one, which is worth knowing before you read too much into a sighting. In a catalog query on August 8, 2026, of the roughly 19,700 listings declaring downloads, only 464 also declared downloads.open and just 75 declared downloads.ui — fewer than one in 250. The deprecated downloads.shelf still appears on 169.

When it's fine, and when it should give you pause

Fine, and obviously so: download managers, video and image downloaders, "save every attachment" tools, backup utilities, and anything that exports data — plenty of dashboards reach for downloads.download() to ship a CSV. For all of those the mismatch test comes out clean: the headline job genuinely requires the API.

Second thoughts: a theme, a cursor pack, a coupon finder, a font previewer, a focus timer. And a hard second look at anything declaring downloads.ui that isn't a download manager — given how rare that declaration is, suppressing the profile-wide download UI has close to no honest use outside that category.

The sharpest signal is downloads sitting next to broad host permissions on a small single-purpose tool. Read-everything plus write-to-disk plus hide-the-notification is a capability set, not a feature.

The usual caveat holds: a declared permission is capability, not behaviour. Most extensions carrying downloads are precisely what they appear to be.

How to check your own extensions

  1. Open chrome://extensions, click Details on each one, and look for the line "Manage your downloads."
  2. Ask the mismatch question. Does this extension's actual job involve files landing on my disk? A downloader, yes. A wallpaper switcher, no.
  3. Cross-check the folder against the list. Put chrome://downloads next to your real Downloads folder. A file on disk with no matching entry deserves an explanation — erase() removes entries and leaves files where they are.
  4. If the download UI has been off and you don't remember turning it off, work out which extension did it. That's downloads.ui, and it applies to the whole profile.
  5. Remove whatever fails the test.

If you manage a fleet rather than one browser, Chrome admins can constrain this from above: the DownloadRestrictions policy blocks dangerous downloads outright instead of leaving each user to squint at permission strings.

Doing this by hand is tedious and easy to get wrong — the dialog collapses three permissions into one string, so it structurally cannot tell you what you need to know. Cross-referencing declared permissions against what an extension plausibly needs is what the Extenshi catalog does for you.

Check your permissions →

downloads isn't a red flag on its own. Roughly one in eighteen listings carries it, and most of them earned it. But it's the permission that turns an extension into an auditor of your file history and a writer to your disk in the same breath — and when the thing asking has no files to manage, that's the mismatch worth catching.

FAQ

What does the downloads permission let a Chrome extension do?

It unlocks the chrome.downloads API: listing every download in your history — source URL, referring page, absolute local path, MIME type, timestamps — starting new downloads, renaming incoming files, deleting them, and erasing history entries. Chrome shows it at install time as "Manage your downloads."

Does an extension need the downloads permission to make me download a file?

No, and this is the part people get backwards. A content script can create an <a download> element and trigger a save with no declared permission at all. downloads is about reading and controlling the download manager — the history, the filenames, the UI — not the raw ability to put a file on your disk.

Why do downloads, downloads.open and downloads.ui look identical in the install dialog?

Because Chrome maps all three to the same warning string. The permissions list documents them separately, the dialog doesn't, so the only way to see which variants an extension declared is to inspect its manifest — or let a scanner do it. Same structural gap I described with the management permission, where one bland string hides a lot of reach.

Is it the same on Firefox?

Firefox exposes the same core API as browser.downloads, and MDN documents it as based on Chromium's chrome.downloads. The download-UI corners are where the two diverge most, so check MDN's compatibility table before assuming a Chrome behaviour carries over.

Sources

This article is based on publicly available security research and news reporting. Extenshi does not independently verify all claims made by third-party researchers. References to specific companies or products reflect the findings of cited sources and do not constitute accusations of intentional wrongdoing. If you believe any information is inaccurate, please contact us at [email protected].

Related Articles