My Chrome Extensions Can Read the Page — So I Designed Them Not to Send It Anywhere

Some of my Chrome extensions need to inspect the page you are viewing. At first glance, this may seem intrusive. However, the real concern should be what happens to the data after it is inspected. The true question is not "Can this extension read the page?" but rather "What happens to the data after it is read?"

For Legacy Tools, I implemented a design rule that prioritizes this distinction. While these extensions may require access to page content, they should not transmit that content to my server. In essence, permission is a capability, not a data flow.

Chrome host permissions define what an extension is allowed to interact with. For instance, a content script might require access to a page to analyze a form field or intercept a click. This permission indicates the extension's ability to access the page, but it doesn't reveal where the data goes afterward. Two extensions can request similar page access yet have entirely different internal architectures.

One might follow this path: Page → Extension → Remote API → Analysis → Result. Conversely, another can implement this flow: Page → Extension → Local analysis → Result. Legacy Tools typically aims for the latter whenever feasible.

To illustrate, consider an extension that checks text before sending it to an AI service. Such an extension may need to view the text currently entered on a page. The simplest server-based architecture would involve: Reading the text → Sending it to an API → Analyzing it on a server → Returning detected personal information → Displaying the result.

However, this design creates a privacy conundrum: to warn users about sending sensitive text elsewhere, the tool must first send that text to a remote server. Therefore, I opted for a more restricted architecture: Page → Local detection → Display possible matches → User decides what to do. This design does not require a cloud model.

The trade-off is clear: local rules cannot comprehensively identify all forms of personal information. That is acceptable. The primary goal is to provide an additional opportunity to notice something before transmitting the data.

While I strive to minimize the permissions requested, it's crucial to differentiate between two questions: "What pages can the extension access?" and "What does it do with the data it can access?" Both concerns should be minimized. Throughout the extensions I developed, I employed various permission patterns. Some tools genuinely need to operate across multiple websites.

Others only require a predefined list of sites. Certain extensions can request additional sites only upon explicit user action. One of my extensions utilizes the activeTab permission, meaning it gains access only when explicitly invoked on the current page.

I have previously discussed these permission patterns separately, emphasizing that limiting the scope of access is an integral part of product design. However, simply stating "no server" is insufficient. Not having a backend simplifies several aspects I would otherwise need to consider. There is no database of user input to secure, no API endpoint receiving page contents, no retention policy for text that was never collected, and no account containing a history of what someone checked.

Despite these advantages, a local extension can still harbor bugs, request excessive access, or undergo future updates that alter its behavior. Therefore, I refrain from asserting that "local means safe." A more accurate statement is: "Local processing eliminates certain classes of risk by minimizing unnecessary data movement." This is a smaller claim but a more practical one.

AI-assisted development has exacerbated this issue. An AI agent, attempting to solve a problem, might reasonably conclude that adding an API call, analytics package, external library, or broader host permission is the simplest implementation. Technically, this could be a beneficial solution. However, architecturally, it may contradict the product.

To maintain focus on the product's intent, I treat certain aspects as boundaries rather than implementation details: avoid broadening host permissions without a specific reason, refrain from adding external transmissions solely for easier detection, refrain from enabling telemetry by default, and avoid replacing local implementations with hosted services without thoroughly reviewing the privacy implications.

AI streamlines coding, but it does not simplify architecture decisions. Conversely, these boundaries must become more explicit. Trust should stem from constraints, not promises. A privacy policy stating "We respect your privacy" is useful but remains a promise. Instead, I prefer to communicate: "This feature does not require your text to leave the browser."

This is a tangible architectural property. Users must still trust the extension package and its updates, but eliminating unnecessary dependencies or servers reduces the aspects they must trust. For small browser tools, this distinction is significant. The uncomfortable permission warning is still valuable. It warns users that some extensions can read the page.

The developer's responsibility is not to make this capability appear harmless. It is to request only the access needed by the feature, explain why it requires that access, minimize actions taken after access is granted, and avoid moving user data unless that movement provides enough value to justify the additional risk. Thus, even though some of my Chrome extensions can read the page, this does not imply the page must leave the browser.

For the small safety tools I develop, this distinction forms one of the most critical architectural decisions.