Extenshiextenshi.io/blog
Back to articles
privacybrowser-extensionspermissionsprivacy-permissionchrome-extensionsbrowser-settings

The `privacy` permission explained: what an extension can change in your browser's own settings

The privacy permission lets an extension flip Chrome's own switches — Safe Browsing, autofill, WebRTC, cookies. Here's what it changes and how to check yours.

Maxim Kosterin
8 min read
A vertical column of four hairline toggle switches, the second one flipped and bleeding a soft orange watercolor wash sideways across the paper.
A vertical column of four hairline toggle switches, the second one flipped and bleeding a soft orange watercolor wash sideways across the paper.

Most permission warnings at least tell you what's at stake. "Read and change all your data on all websites" is terrifying, but it's honest. Here's the most under-explained string Chrome shows you: "Change your privacy-related settings."

Six words for the privacy permission. They cover the entire chrome.privacy API — including the switch that decides whether Chrome warns you before a phishing page. Of all the permission strings I've picked apart here, that's the widest gap between how a warning sounds and what it grants.

What the privacy permission actually means

Put "privacy" in a manifest and you get the chrome.privacy API. Chrome's permissions list maps that to one install warning: "Change your privacy-related settings."

Notice what it leaves out. It doesn't say which settings, or that the extension can also read their values. And "privacy-related" quietly includes your security settings, your password prompts and your autofill.

Every setting is a ChromeSetting object with get(), set(), clear() and an onChange event. That last one matters: the extension is notified whenever one of these settings changes, by anyone.

What the privacy permission actually allows

The API splits into three groups. Here's the inventory.

privacy.network — networkPredictionEnabled (DNS pre-resolving and preconnecting) and webRTCIPHandlingPolicy, which decides how much local address information WebRTC hands out. It takes values like default_public_interface_only and disable_non_proxied_udp — the classic knob against a WebRTC IP leak on a VPN.

privacy.services — the group that surprised me: safeBrowsingEnabled, safeBrowsingExtendedReportingEnabled, passwordSavingEnabled, autofillAddressEnabled, autofillCreditCardEnabled, searchSuggestEnabled, spellingServiceEnabled, translationServiceEnabled and alternateErrorPagesEnabled.

Read that list with an attacker's eyes. Safe Browsing is Chrome's phishing and malware warning layer. passwordSavingEnabled decides whether Chrome offers to save credentials.

privacy.websites — doNotTrackEnabled, referrersEnabled, hyperlinkAuditingEnabled, thirdPartyCookiesAllowed, protectedContentEnabled (Windows and ChromeOS only), plus the Privacy Sandbox toggles: topicsEnabled, fledgeEnabled, adMeasurementEnabled and relatedWebsiteSetsEnabled.

The asymmetry nobody talks about

For the Privacy Sandbox settings, Chrome's reference is explicit: extensions may only disable them. Set topicsEnabled back to true from an extension and the call throws. It's a one-way valve — an extension can make you more private, never less.

No equivalent note appears on safeBrowsingEnabled. As documented, it's an ordinary boolean an extension can set in either direction.

I don't read that as malice. Safe Browsing has legitimate reasons to be toggleable; enterprise and testing tools need it. But one six-word warning covers both "turns off ad topic tracking for you" and "can quietly switch off your phishing protection." Those aren't the same request.

levelOfControl: settings are last-writer-wins

The part most write-ups skip: a set() isn't guaranteed to stick.

Every get() returns a levelOfControl string next to the value: not_controllable if enterprise policy pinned the setting, controlled_by_other_extensions if another extension got there first. The docs are blunt about what follows — the set() call succeeds, and the setting is overridden anyway.

If two of your extensions both touch privacy settings, one is silently losing — and its UI may still show a toggle that does nothing. Chrome's own advice is that developers warn you when your settings aren't applied. An honest extension reads levelOfControl first and greys out what it can't control. Most just call set() and render a switch.

Its two much quieter siblings

privacy doesn't travel alone, and its neighbours' warnings are wildly inconsistent.

contentSettings gets the most verbose string in the list: "Change your settings that control websites' access to features such as cookies, JavaScript, plugins, geolocation, microphone, camera etc." It earns it. That API writes per-site rules — allow, block or ask, matched by URL pattern — for each of those features plus notifications, popups and automatic downloads. An extension holding it can let a site reach your camera without prompting you.

browsingData is the opposite: on Chrome's permissions list it carries no install warning at all. One chrome.browsingData.remove() call can wipe cache, cookies, download history, form data, browsing history, local storage, IndexedDB, service workers — and saved passwords. Deleting cookies for one origin takes the whole registrable domain with it.

Deleting isn't reading — presumably the logic. Still: an extension that can destroy your saved passwords arrives with a quieter prompt than one that reads your bookmarks.

Who legitimately needs these

Plenty of good tools. VPN and anti-leak extensions set webRTCIPHandlingPolicy — the right API for the job. Privacy cleaners need browsingData, consent managers lean on contentSettings, and tracker blockers flip doNotTrackEnabled and the Sandbox toggles.

Note how this ages. Per the uBlock Origin project wiki, its "prevent WebRTC from leaking local IP addresses" option left desktop builds in v1.38, once browsers began obfuscating local addresses with mDNS. It survives on Android Firefox only. Some reasons to hold this permission have quietly expired.

Google publishes runnable privacy and browsingData samples if you want to see the code.

When it should give you second thoughts

Same test as always: does the extension's obvious job require it? A VPN setting the WebRTC policy — defensible. A one-click data cleaner using browsingData — that is the product.

A wallpaper switcher, coupon finder or font previewer declaring privacy? There's no honest version of that story.

Two mismatches I'd flag hardest:

  • Reading without changing. get() works fine on its own. Safe Browsing on, Do Not Track on, autofill enabled, third-party cookies allowed — those are stable configuration bits, and configuration bits are what fingerprinting is built from. I went through that machinery in the runtime tracking piece.
  • Anything touching safeBrowsingEnabled without saying so. Turning off phishing warnings is a security decision, not a side effect of installing a tool that does something unrelated.

Standing caveat: a declared permission is capability, not behavior. The numbers across 308,000 listings show the genuinely over-reaching slice is small enough to scrutinize.

Firefox implements both privacy and browsingData with its own settings and data types, so check MDN rather than assuming parity. contentSettings is Chromium-only.

How to check your own extensions

  1. Open chrome://extensions, hit Details on each one, and read the permission lines. "Change your privacy-related settings" is privacy; the long string naming cookies, JavaScript, geolocation, microphone and camera is contentSettings. browsingData won't appear at all — only the manifest shows it.
  2. Go to chrome://settings/security and check Safe Browsing is where you left it, then chrome://settings/autofill. If something is off and you didn't turn it off, something else did.
  3. Apply the mismatch test to every extension with a settings warning. VPN, privacy cleaner, cookie manager — fine. Anything else, ask why.
  4. If you run more than one privacy tool, remember last-writer-wins: their toggles may disagree with reality, and the newest install is probably in charge.

Doing this by hand, one warning at a time, is the tedious work people abandon halfway. The faster path is to cross-reference every extension's declared permissions against what it plausibly needs — which is what the Extenshi catalog is for.

Check your permissions →

The privacy permission isn't a red flag by itself. It's where the install prompt does the least work per unit of capability — the one place an extension reaches past your data into the browser's own defenses. That earns more than six words.

FAQ

What does "Change your privacy-related settings" mean on a Chrome extension?

It's the install warning for the privacy permission. The extension can read and change Chrome's own settings for Safe Browsing, password saving, autofill, WebRTC IP handling, Do Not Track, third-party cookies and the Privacy Sandbox toggles.

Can an extension turn off Safe Browsing?

safeBrowsingEnabled is documented as a normal boolean with no one-way restriction, unlike the Privacy Sandbox settings extensions may only disable. Whether a given extension does it is a separate question: the permission grants capability, not intent.

Why does browsingData have no permission warning?

Chrome's permissions list shows none. The likely reasoning: the API deletes local data rather than reading it. But that deletion covers cookies, history, form data and saved passwords, so "no warning" understates it. Its close relative, the cookies permission, is similarly quiet.

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