{"slug": "my-chrome-extensions-can-read-the-page-so-i-designed-them-not-to-send-it", "title": "My Chrome Extensions Can Read the Page — So I Designed Them Not to Send It Anywhere", "summary": "A developer behind the Chrome extension suite Legacy Tools designed the extensions so that page content is analyzed locally in the browser rather than sent to a remote server, arguing that host permissions reveal what an extension can access but not where the data goes. The developer applies a \"smallest workable permission\" rule across the tools, including one that uses activeTab to gain access only when the user explicitly invokes it, and warns that local processing removes some risk classes without making an extension inherently safe.", "body_md": "Some of my Chrome extensions need access to the page you are looking at.\n\nThat sounds uncomfortable.\n\nAnd it should.\n\nIf an extension can inspect a page before you submit a form, check a link before you open it, or look for personal information before you paste text into an AI chat, it needs enough access to do that job.\n\nThe interesting question is not:\n\n“Can this extension read the page?”\n\nIt is:\n\n**“What happens to the data after it reads it?”**\n\nFor Legacy Tools, I made that distinction a design rule.\n\nThe extensions may need to inspect page content.\n\nThey should not need to send that content to my server.\n\nChrome host permissions define what an extension is allowed to interact with.\n\nFor example, a content script may need access to a page so it can inspect a form field or intercept a click.\n\nThat permission tells you something important:\n\n**the extension has the capability to access that page.**\n\nBut it does not tell you where the data goes afterward.\n\nTwo extensions can request similar page access and have completely different architectures.\n\nOne might:\n\n```\nPage\n  ↓\nExtension\n  ↓\nRemote API\n  ↓\nAnalysis\n  ↓\nResult\n```\n\nAnother can do:\n\n```\nPage\n  ↓\nExtension\n  ↓\nLocal analysis\n  ↓\nResult\n```\n\nLegacy Tools tries to use the second shape whenever the task allows it.\n\nConsider a tool that checks text before it is sent to an AI service.\n\nIt may need to see the text currently entered in the page.\n\nThe simplest server-based architecture would be:\n\nThat architecture can support powerful models.\n\nBut it creates a strange situation for a privacy tool:\n\n**to warn you about sending sensitive text somewhere, the tool first sends that text somewhere else.**\n\nSo I chose a more limited architecture.\n\n```\nText in the browser\n        ↓\nLocal detection\n        ↓\nShow possible matches\n        ↓\nUser decides what to do\n```\n\nNo cloud model is required for that path.\n\nThe trade-off is real: local rules cannot understand every form of personal information.\n\nThat is acceptable.\n\nThe goal is not to promise perfect detection.\n\nThe goal is to provide one more chance to notice something before sending it.\n\n“Everything stays local” is not a reason to request unlimited permissions.\n\nThese are separate questions:\n\nBoth should be minimized.\n\nAcross the extensions I built, I ended up using several patterns.\n\nSome tools genuinely need to work on many websites.\n\nSome only need a fixed list of sites.\n\nSome can request additional sites only when the user asks.\n\nAnd one of my extensions can use `activeTab`, meaning it gets access only after the user explicitly invokes it on the current page.\n\nI wrote about those permission patterns separately because choosing the smallest workable permission is part of the product design.\n\nLocal processing does not excuse broad access.\n\nNot having a backend removes several things I would otherwise need to think about.\n\nThere is no database of user input to protect.\n\nThere is no API endpoint receiving page contents.\n\nThere is no retention policy for text that was never collected.\n\nThere is no account containing a history of what someone checked.\n\nThat does not make an extension automatically safe.\n\nA local extension can still contain bugs.\n\nIt can request too much access.\n\nA future update could change its behavior.\n\nAnother dependency could introduce a problem.\n\nSo I avoid saying:\n\n“Local means safe.”\n\nThe more accurate statement is:\n\n**Local processing removes some classes of risk by removing unnecessary data movement.**\n\nThat is a much smaller claim, but I think it is a more useful one.\n\nI use AI coding tools heavily.\n\nThat creates another failure mode.\n\nAn agent trying to solve a problem may reasonably decide that adding an API call, analytics package, external library, or broader host permission is the easiest implementation.\n\nTechnically, it may even be a good solution.\n\nArchitecturally, it may violate the product.\n\nSo I treat some things as boundaries rather than implementation details:\n\nAI makes producing code cheaper.\n\nIt does not make architecture decisions cheaper.\n\nIf anything, those boundaries need to become more explicit.\n\nA privacy policy can say:\n\n“We respect your privacy.”\n\nThat is useful, but it is still a promise.\n\nI prefer being able to say something more concrete:\n\n“This feature does not require your text to leave the browser.”\n\nThat is an architectural property.\n\nUsers still have to trust the extension package and its updates, of course.\n\nBut every dependency or server you remove is one less thing they need to trust.\n\nFor small browser tools, that matters.\n\nI used to think broad-looking Chrome permission warnings were mostly a UX problem.\n\nNow I think the discomfort is healthy.\n\nIf an extension can read a page, users should know that.\n\nThe developer's job is not to make that capability sound harmless.\n\nThe job is to:\n\nSo yes:\n\n**some of my Chrome extensions can read the page.**\n\nThat is how they can help before you send, click, or submit something.\n\nBut being able to read the page does not mean the page needs to leave the browser.\n\nFor the kind of small safety tools I am building, that distinction has become one of the most important architectural decisions.\n\nI build **Legacy Tools**, a small collection of browser tools designed to give people one more chance to check something before they act.\n\nPrevious article: **8 Shipped Chrome Extensions, 4 Ways to Declare Host Permissions**", "url": "https://wpnews.pro/news/my-chrome-extensions-can-read-the-page-so-i-designed-them-not-to-send-it", "canonical_source": "https://dev.to/k-wada/my-chrome-extensions-can-read-the-page-so-i-designed-them-not-to-send-it-anywhere-5bp2", "published_at": "2026-09-12 12:21:19+00:00", "updated_at": "2026-09-12 12:39:29.738346+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "ai-agents", "ai-ethics"], "entities": ["Chrome", "Legacy Tools", "Google"], "alternates": {"html": "https://wpnews.pro/news/my-chrome-extensions-can-read-the-page-so-i-designed-them-not-to-send-it", "markdown": "https://wpnews.pro/news/my-chrome-extensions-can-read-the-page-so-i-designed-them-not-to-send-it.md", "text": "https://wpnews.pro/news/my-chrome-extensions-can-read-the-page-so-i-designed-them-not-to-send-it.txt", "jsonld": "https://wpnews.pro/news/my-chrome-extensions-can-read-the-page-so-i-designed-them-not-to-send-it.jsonld"}}