If you are auditing a Chrome extension's manifest, the first thing worth knowing is that not every string in the permissions array is a permission, and not every permission name you remember still exists. Manifest V3 renamed some, retired others, and left a few traps that look like typos but are not.
Here is what actually changed, checked against Chrome's current permissions reference.
Names that are case-sensitive and often written wrong
The permission is contentSettings, in camelCase. content_settings with an underscore is not a permission and will not do anything. It looks plausible because plenty of Chrome APIs use snake_case elsewhere in the manifest, so the wrong form survives in blog posts and copied snippets.
This is the failure mode worth watching for generally: a manifest entry that is silently ignored rather than rejected. You do not get an error telling you the permission does not exist. You get an extension that quietly lacks the capability you thought you granted it.
Permissions that no longer exist
browserAction and pageAction are both gone from the current permissions list. In Manifest V2 they were the two ways an extension put a button in the toolbar, differing in whether the button was always active or only on matching pages.
Manifest V3 collapsed both into a single action. If you are reading an older extension, or older documentation, and see either of the old names, you are looking at V2-era material. That is a useful dating signal when you are trying to work out how current a tutorial is.
Things in the manifest that are not permissions at all
commands is a top-level manifest key, not a permission. It declares keyboard shortcuts. It does not belong in the permissions array, and putting it there does nothing.
This distinction matters when you are reading a permissions audit written by someone else. A list that mixes manifest keys in with permissions is not describing what the extension can do, it is describing what strings appear in its manifest, and those are different questions.
What replaced the blocking web request model
declarativeNetRequest is in the current list, and it is the V3 answer to network interception. The V2 approach let an extension observe a request and decide, in its own code, what to do with it. The V3 approach has the extension declare rules up front and lets Chrome apply them.
The practical consequence for anyone reading a manifest: an extension using the declarative model has told Chrome its rules in advance, and those rules are inspectable. That is a meaningfully different posture from one that runs arbitrary code on every request, even though both end up filtering traffic.
How to read a permissions array without being misled
Three checks get you most of the way.
First, confirm each string is actually a permission rather than a manifest key that has wandered into the wrong array. Second, check the casing against the current reference rather than against memory, because a wrong case fails silently. Third, notice which era the names belong to: V2-only names in a current extension usually mean the manifest was ported without being reviewed.
None of that tells you whether an extension is trustworthy. It tells you whether its manifest was written carefully, which is a reasonable proxy for whether the rest of it was.
For a per-extension breakdown of what is requested and what each entry actually grants, Zovo on chrome extension permissions changed work through it entry by entry.