TL;DR
Google's updated Chrome Web Store Developer Program Policies take effect Aug 1, 2026 (announced Jul 1). Two of the four changes are about disclosure, and they're the ones that should send you to your extensions list: collected data must be strictly necessary to the extension's disclosed single purpose, and all data collection must be prominently disclosed even when it relates to that purpose — with proactive notice if practices change after you've already installed it.
Two weeks later, Aug 31, 2026: all remaining Manifest V2 extensions get removed from the Chrome Web Store. Already-installed copies on Chrome 138 or earlier keep working, but they can't update and can't be reinstalled.
So August is a natural audit date. And here's the useful part nobody writes up: the public CWS listing page already carries the exact fields you'd want in a spreadsheet — name, developer, user count, last updated, the "Privacy practices" disclosures, permissions. That's structured, public, paginated data. ScrapeMaster pulls it into CSV in a few minutes so you can triage 40 extensions in a sheet instead of 40 tabs.
Read this first, because it's the whole spirit of the exercise: this produces questions, not verdicts. A disclosure mismatch is a reason to look closer. It is not proof of anything. An extension can be completely legitimate and still over-ask.
Why Aug 1 is a real date and not a news hook
The Jul 1 announcement carried four changes. All four take effect Aug 1, 2026:
- Collected data must be strictly necessary to the extension's disclosed single purpose.
- All data collection must be prominently disclosed — even when it does relate to that single purpose — plus proactive notice if practices change after install.
- Prediction-market extensions are banned — anything staking real money on outcomes.
- Extensions designed to circumvent AI services' safety guardrails or usage restrictions are prohibited.
Three and four are category bans; if you're not running a prediction market or a jailbreak helper, they don't touch you. One and two are the ones that matter to everyone, because they're about the gap between what an extension says it does and what it takes.
Note what change 2 actually closes. The old intuition was roughly "collection is fine if it's related to the feature." The new rule says: related isn't enough — it has to be disclosed prominently, and if the practice changes after you installed it, you have to be told proactively. That's aimed squarely at the quiet post-install pivot, which is the single most common way a good extension becomes a bad one.
And then Aug 31: MV2 extensions come off the store entirely. If something in your list is still MV2, it's not just legacy — it's an extension that after Aug 31 cannot be updated and cannot be reinstalled. Your copy keeps running on Chrome 138 or earlier. That's not a maintained dependency, that's a fossil with permissions. We covered the endgame in the Manifest V3 final cleanup.
Put those together and August is when the store's own metadata is freshest and most consequential. If you're an IT admin, on a security team, or just someone with 40 extensions installed and a vague sense of unease about it, that's a good month to look.
The honest bit about chrome://extensions
Your inventory starts at chrome://extensions. That page is an internal Chrome page, and we want to be exact about this because it's the kind of thing tool vendors fudge:
ScrapeMaster does not and cannot scrape chrome:// pages. Chrome doesn't let extensions run on its own internal pages, and that restriction is a good thing — it's part of why the extension model is survivable at all. Anyone claiming otherwise is describing something you shouldn't install.
So build the inventory the boring way:
- Individuals: open
chrome://extensions, turn on Developer mode to see IDs, and read your list off manually. For 40 extensions this is a ten-minute typing job, once. - Managed fleets: use your enterprise tooling. Chrome Enterprise policy reporting and your MDM already inventory installed extensions across the fleet, with IDs. That's the supported path and it's vastly better than any scraping trick.
What you need from this step is small: the name and the extension ID for each one. The ID is the long string in the CWS URL. That's your join key for everything that follows.
Then the public data — the store listing for each of those IDs — is where scraping legitimately helps.
Pulling the CWS listing fields into a sheet
The Chrome Web Store listing page is public, structured, and consistent across every extension. That's a good scrape target and a well-behaved one: you're reading the pages Google publishes for exactly this purpose, at human pace, for your own hygiene review.
Step 1 — Get the listing pages open
Two approaches, depending on how you built the inventory:
- From your ID list, each listing is
chromewebstore.google.com/detail/<id>. Work through them. - From category or search pages, if you're surveying a class of extension rather than your own installs — those pages are paginated and lazy-load, which ScrapeMaster handles (next-page buttons, load-more, numbered pagination, infinite scroll).
For a personal audit of your own 40, the ID list is the honest route. You're not surveying the store, you're checking your own attack surface.
Step 2 — Auto-detect and keep the comparable fields
Open ScrapeMaster in the Chrome side panel. It finds repeating structures in 2–4 seconds and names the columns. Because it reads the post-render DOM, it sees the store's client-rendered fields the way you do.
Use Follow detail to open each extension's listing from your list and pull the per-extension fields into one row each. Aim for this schema:
| Column | Where it comes from | What it's for |
|---|---|---|
name | Listing title | Human readable |
extension_id | URL | Join key to your inventory |
developer | Listing | Who actually publishes it |
users | Listing | Blast radius if it turns |
last_updated | Listing | Maintenance signal |
privacy_practices | "Privacy practices" section | The declared collection |
permissions | Listing | What it can reach |
description | Listing | The claimed purpose |
audit_date | You add it | Stamp every run |
Set an extraction delay. You're pulling a few dozen pages for a hygiene review — there is no reason to go fast, and pacing is basic manners.
Step 3 — Export and triage in a sheet
Export CSV or XLSX, or copy straight into Google Sheets. Everything saves locally. Now you can sort 40 extensions by last_updated, filter by permissions, and read privacy_practices next to description in adjacent cells — which is the entire trick. The mismatch is only visible when the claim and the disclosure are side by side. In 40 browser tabs, it isn't.
If scraping is new to you, the no-coding walkthrough covers the basics, and exporting to Google Sheets covers the plumbing.
The triage rubric
Here's the part that makes this an audit and not a data-collection exercise. Six questions, in order. Each one produces a question to investigate, never a verdict.
1. Does the stated purpose match the actual function?
Read the description, then think about what the extension actually does on your machine. A single purpose is a CWS requirement, and it's also just a good smell test. If a screenshot tool's description spends three paragraphs on "personalized recommendations," those are two products in one binary.
Red flag: the description describes a category the extension doesn't visibly occupy.
2. Is the permission set wider than the purpose needs?
This is the highest-yield question in the rubric. Map each permission to a feature you can name.
- A tool that works on the page you're on, asking for access to all sites, all the time — why?
- A tool with no network feature, requesting broad host permissions — for what?
- Something reading and changing data on every site you visit, to do one thing on one site.
Red flag: you can't name the feature a permission pays for. Note that "wide permissions" is not "malicious" — an ad blocker legitimately needs to see every page. The rubric asks whether the width is explained by the purpose.
3. Does "Privacy practices" declare collection the description never mentions?
This is the one Aug 1 sharpens, and the one the spreadsheet makes trivial. Put description and privacy_practices in adjacent columns and read across.
If the disclosure declares collection of browsing activity, personal communications, or location, and the description never mentions any feature that would need them — that's a gap. Under the new policy, collection must be strictly necessary to the disclosed single purpose and prominently disclosed. A gap between the two columns is precisely the shape the new rules are aimed at.
Red flag: disclosed collection with no corresponding disclosed feature.
4. Is it still MV2?
After Aug 31, 2026 it's off the store: no updates, no reinstall. Installed copies persist on Chrome 138 or earlier. An extension that can never be patched again, holding broad permissions, is a standing risk with a countdown on it.
Red flag: MV2 in July 2026 means unmaintained-by-force in September.
5. Last updated years ago?
Not automatically bad — a small, finished tool can be genuinely done. But combine it with question 2. Abandoned plus broad permissions is the classic setup, because an abandoned extension with reach is exactly what gets bought.
Red flag: stale and privileged.
6. Has it changed hands recently?
The hardest to see and the most important. A developer name that doesn't match the one you remember, a sudden update after two dormant years, a generic new publisher — these are worth a look. The acquisition-then-monetization path is a known pattern in this ecosystem, and it's the reason the new policy demands proactive notice when practices change post-install. We've written about what separates malicious data collection from legitimate scraping, and about the extension clusters caught earlier in 2026.
Red flag: publisher changed, or a long-dormant extension suddenly ships an update with new permissions.
Scoring it
Don't. Seriously — resist the urge to build a weighted score. Sort into three buckets:
| Bucket | Meaning | Action |
|---|---|---|
| Fine | Purpose, permissions and disclosures line up | Nothing |
| Question | One red flag, plausibly explained | Look closer, ask the developer, decide |
| Why do I have this | Multiple flags, or you can't remember installing it | Remove it |
That third bucket is where most of the value is, and it has nothing to do with malice. The most common finding in any honest extension audit is stuff you don't use anymore, still holding permissions. Uninstalling those is a bigger security win than anything you'll catch in bucket two.
Say it clearly: this is hygiene, not accusation
We're not going to name and shame anyone here, and you shouldn't either on the strength of a spreadsheet.
A disclosure mismatch is a reason to look closer, not proof of malice. Real reasons a listing looks off:
- The description is old and the feature set grew.
- The disclosure was filled out conservatively — over-declaring rather than under.
- A permission arrived via a library, and it's genuinely unused.
- Whoever wrote the listing copy was not whoever wrote the code.
And the inverse: an extension can be entirely legitimate and still over-ask. Broad permissions are frequently laziness, not intent — it's easier to request all sites than to enumerate. That's a real risk to you regardless of intent, because permissions are capabilities, not promises. But it's a different conversation than fraud, and treating it as fraud makes you worse at spotting the actual thing.
The output of this audit is a shortlist and some questions. That's a good output. It's what audits produce.
Now run it on us
Fair is fair. If we're going to hand you a rubric, we should be first through it. Privacy is the default, not the upsell is the manifesto line, and a manifesto you won't be measured against is marketing.
So here is our hand, face up:
Convert: Web to PDF converts pages locally via Chrome's DevTools Protocol. Zero network requests during conversion. It makes one anonymous post-conversion ping carrying a random install token — no URL, no page content, no IP. That is a real network request and we're not going to bury it in a privacy policy. It counts a conversion happened. It cannot tell us what you converted, because it doesn't carry it.
ScrapeMaster makes exactly one network request, during auto-detect: the page's HTML structure — not its content — goes to our analysis API to suggest selectors. Extracted data never leaves your browser. It's stored locally in IndexedDB, and exports are files on your disk.
Now the rubric, honestly applied:
| Question | Our answer |
|---|---|
| Purpose matches function? | Four extensions, one job each. That's the point of the shop. |
| Permissions wider than needed? | Judge for yourself on the listing — that's the correct answer to this question, from anyone. |
| Undisclosed collection? | The two pings above are the complete list. If you find a third, we want to hear about it. |
| Still MV2? | No. |
| Stale? | Check last_updated on our listings. Same as anyone. |
| Changed hands? | No. And if we ever shut down, we publish the source and walk — we will not be acquired into adware. |
Run it on us. Genuinely. The reason we can invite that is the same reason the rubric works: the fields are public, and the answers are checkable. An extension shop that flinches at its own rubric has told you something.
Frequently asked questions
Can ScrapeMaster read my chrome://extensions page?
No. Chrome blocks extensions from running on its own internal pages, and ScrapeMaster is no exception. Build your inventory by reading chrome://extensions manually, or through enterprise tooling if you manage a fleet. ScrapeMaster works on the public Chrome Web Store listing pages — that's the part that's worth automating anyway.
What exactly changes on Aug 1, 2026?
Four things, announced Jul 1: collected data must be strictly necessary to the disclosed single purpose; all data collection must be prominently disclosed even when related to that purpose, with proactive notice if practices change post-install; prediction-market / real-money-on-outcomes extensions are banned; and extensions designed to circumvent AI services' safety guardrails or usage restrictions are prohibited.
What happens to my MV2 extensions on Aug 31?
They're removed from the Chrome Web Store. Copies already installed on Chrome 138 or earlier keep working, but they can't update and can't be reinstalled. Treat anything still MV2 as end-of-life and plan the replacement now rather than the morning it breaks.
Is scraping the Chrome Web Store allowed?
You're reading public listing pages that Google publishes for people to read, at human pace, for your own review. That's the ordinary case. Use extraction delays, keep the list to your actual inventory, and don't turn it into a bulk harvest of the whole store. As always: ToS applies, and re-publishing someone's data wholesale is a different activity than reviewing your own installs. See is web scraping legal.
How often should I do this?
Once is worth more than never, and the disclosure fields aren't volatile. Aug 1 is the natural moment this year. After that, twice a year is plenty for most people — or whenever you notice an extension you don't remember installing. ScrapeMaster saves per-domain configs, so the re-run is quick.
Does auditing find malware?
No, and don't let it convince you it did. This finds disclosure and permission mismatches — governance smells. Real malware hides from exactly this kind of review; a listing built to deceive will look immaculate. What this reliably finds is the boring stuff that actually matters: abandoned extensions with broad permissions, tools you stopped using, and purposes that quietly drifted.
Does my scraped audit data go anywhere?
No. Extracted data stays local in IndexedDB and never leaves your browser. The only request is auto-detect sending page HTML structure, not content, to our analysis API for selector suggestions.
Bottom line
Aug 1, 2026 is when Chrome Web Store extensions have to keep their collection strictly necessary to a disclosed single purpose and prominently disclose all of it, with proactive notice if things change after you installed. Aug 31 is when the last MV2 extensions leave the store for good. Between those two dates is the best excuse you'll get this year to look at the 40 things you've granted access to your browsing.
The method is unglamorous and it works: read your inventory off chrome://extensions by hand or pull it from enterprise tooling, scrape the public CWS listing fields into a CSV, and read description next to privacy_practices next to permissions with a last_updated column beside them. Then run six questions — purpose match, permission width, undisclosed collection, MV2, staleness, changed hands — and sort into fine / question / why-do-I-have-this.
You will almost certainly not find a villain. You'll find four extensions you forgot you installed, still able to read every page you visit. Removing those is the win.
And when you've built the rubric, point it at us. ScrapeMaster is free on the Chrome Web Store — no account, no upsell, extracted data never leaves your browser, one auto-detect request carrying HTML structure and not content. That's the whole disclosure. Go check it against the listing.