Chrome 141 reached the stable channel on Saturday with a change to the cookies API that restricts extensions to reading cookies for the origin of the active tab and origins the user has explicitly granted. Extensions with broad host permissions previously could enumerate cookies across every site the browser had visited, which meant an installed extension could reconstruct a user's browsing history and, in many cases, hijack authenticated sessions. Google estimates roughly 14,000 extensions in the Web Store use the API in ways this change affects, and that about 900 of them will lose core functionality. The company gave developers six months of warning through origin trials and console deprecation notices.
What extensions could do before
An extension declaring host permissions for all URLs and the cookies permission could call the cookie API and receive every cookie the browser held. That includes session tokens for banking sites, email, and internal corporate applications. Nothing prevented an extension installed to change the color of a webpage from reading the authentication cookie for a payroll system, and several extensions caught in security research over the years did exactly that.
The permission prompt shown at install time said the extension could read and change your data on all websites, which is technically accurate and conveys nothing about session token access to a typical user. Security researchers have argued for a decade that cookie access should be a separate, narrower permission. Google's position was that host permissions implied it and that separating them would produce prompt fatigue. That position has now changed.
What breaks
Price comparison and coupon extensions are the largest affected category. Many work by observing which retailer sites a user visits and reading affiliate cookies to attribute commissions, which is both the business model and the reason these extensions have been repeatedly caught doing more than they disclose. Several will need to move to a model where the user explicitly grants access per retailer, which will reduce their coverage substantially.
The legitimate casualties are session management tools, testing extensions used by developers, and enterprise tools that audit cookie usage. Google added a policy-controlled exemption for enterprise-installed extensions, so an organization can grant broader access to tools it deploys through management. That covers the corporate cases and leaves individual developers to use a flag or a development build, which several have complained is a downgrade in daily workflow.
The story is rarely the launch. It is what breaks, what ships, and who owns the mess at 2 a.m.
The security case
Extension compromise is a persistent and under-covered attack vector. Extensions get sold, and the new owner ships an update with different behavior to an installed base that never re-reads permissions. Extensions get compromised through their developer accounts. In late 2024 a phishing campaign against extension developers pushed malicious updates to more than thirty extensions with a combined install base in the millions, and the payload harvested exactly the cookies this change now protects.
Google's own telemetry, cited in the announcement, says extensions accessing cookies for origins unrelated to their stated function correlate strongly with later removal for policy violations. That is a useful signal and it also means Google had a detection capability it was choosing not to enforce structurally. Restricting the API removes the need to detect the behavior at all, which is generally the better design.
How other browsers handle it
Firefox's extension model has the same broad access and Mozilla has not announced equivalent restrictions, though its review process for extensions requesting cookie access is stricter than Google's. Safari's extension model has been narrower since it moved to the App Extension architecture, requiring per-site permission grants that expire, which users have found irritating and which is meaningfully safer.
The direction across all three is toward permissions that are narrow, revocable, and re-confirmed. That produces friction and the friction is the point. Chrome's implementation splits the difference by keeping the active tab accessible without prompting, which covers most legitimate use and means users see prompts only when an extension reaches beyond what it visibly needs.
What users and administrators should do
Individuals should take the release as a prompt to audit installed extensions. The Chrome extensions page shows permissions per extension, and anything with all-sites access that does not obviously need it should be removed or restricted to specific sites, which Chrome has supported for years and almost nobody uses. Extensions you have not deliberately used in months are pure risk.
Administrators should enumerate extensions across their fleet, which Chrome Enterprise reporting makes straightforward, and move to an allow list if they have not already. The most common finding in that exercise is a long tail of extensions installed by one or two people each, several of which have changed ownership since installation. That inventory is worth doing regardless of this particular change.
One more configuration deserves attention while you are in there. Chrome supports restricting an extension's site access to specific domains or to click-to-run, where the extension activates only when the user clicks its icon. That setting has existed since 2019 and remains buried in a per-extension detail page that almost nobody opens. For a screenshot tool or a note clipper, click-to-run is strictly better than persistent access and costs one extra click per use. Administrators can apply the same restriction by policy across a fleet, which is a stronger control than the cookie change and available today without waiting for a browser release.
Skarvonix will keep following this beat with reporting grounded in how systems behave outside the launch keynote.
- Privacy
