Local-First YouTube Transcript Extension: What It Can See

A Chrome extension with host permission for youtube.com can read the video page you have open, call YouTube's caption endpoint with your own cookies, and read that tab's URL and title. Host permission for youtube.com alone gives it nothing on any other site. The install dialog says this in one line, and the manifest says it exactly.

What host permission on youtube.com lets an extension do

Chrome's Declare permissions page, last updated 5 February 2024, lists what host permissions grant: fetch() requests from the extension service worker and extension pages, reading the url, title and favIconUrl properties of a tab, programmatic content script injection, network monitoring through chrome.webRequest, cookie access through chrome.cookies, and request rewriting through chrome.declarativeNetRequest. The same page records that patterns in content_scripts.matches produce the same warning as host_permissions.

The list is a ceiling rather than a description. An extension that declares https://www.youtube.com/* and nothing else has no access to any other origin, and one that never calls chrome.cookies cannot read cookies.

Host permission also excludes two things. Chrome blocks extension access to chrome:// pages, and access to file:// URLs and incognito windows stays off until the user enables it from the details page.

For a transcript extension, the sentence that matters is the warning Chrome generates from the host pattern: "Read and change your data on www.youtube.com". It comes from the manifest, not from the code, and it is not a report of what the code does with the access.

What each permission in a transcript extension grants

The permissions below recur in this category. The warning text is quoted from Chrome's Permissions reference, last updated 9 September 2026.

Three rows deserve more than a glance.

tabs overlaps with activeTab, and Chrome suppresses the tabs warning when the extension also requests <all_urls>, as the permission warnings page states. A broad extension can read every tab and show a dialog that never mentions browsing history.

clipboardWrite and clipboardRead carry separate warnings, and a reader scanning for "clipboard" can conflate them. Only the read side takes something from you.

web_accessible_resources is the row nobody reads, because it is not a permission and it never appears in a dialog. It decides whether a web page can reach into the extension's own files.

How to audit any extension in five minutes

The audit below ran on a real extension directory on 19 September 2026, and every output shown is what came back. The directory was the Prepublish extension source, which ships without a build step, so the files on disk are the files that run.

Step one, the store page. Open the listing and read the privacy panel, which is not the manifest. It lists the data categories the developer disclosed and three certification bullets about sale, unrelated transfer, and creditworthiness. A live listing checked on 19 September 2026 showed personally identifiable information, authentication information, and user activity. No permission string appears there.

Step two, find the extension on disk. Get the extension id from the store URL, or from chrome://extensions with Developer mode on. Then look under the user data directory, whose location chrome://version prints as Profile Path. The paths are:

On the machine used for this audit, that macOS path held four extension directories, and one had both 3.0.10_0 and 3.0.11_0 side by side. Chrome keeps the previous version folder after an update, so two releases of the same extension can be diffed in place.

Step three, read the manifest.

jq '{manifest_version, permissions, host_permissions, optional_permissions, web_accessible_resources}' manifest.json

On the Prepublish extension it printed manifest_version 3, three entries under permissions, four host patterns, and null for both optional permissions and web accessible resources. The values are in the worked example below.

Steps four to seven, four greps. These cover network calls, hosts referenced, dynamic code, script tags, and API namespaces.

grep -rn --include=*.js -E "fetch\(|XMLHttpRequest|sendBeacon|new WebSocket|EventSource" src
grep -rho --include=*.js -E "https?://[a-zA-Z0-9.-]+" src | sort | uniq -c | sort -rn
grep -rn --include=*.js -E "\beval\(|new Function\(|document\.write\(" src
grep -rn --include=*.html "<script" src
grep -rhoE "chrome\.[a-zA-Z]+(\.[a-zA-Z]+)?" src | sort | uniq -c | sort -rn

Two rows need a note. The single w3.org hit is the SVG namespace string, not a network destination, which is the first sign that this check produces noise alongside signal. The remote-code row covers half the rule: Manifest V3 also forbids remotely hosted code entirely, per Chrome's Improve extension security page, so a <script src="https://..."> inside an extension page would violate it with no eval in sight.

Step seven is the one worth keeping. An extension that declares cookies and never calls chrome.cookies carries a permission it does not need, and one that calls chrome.webRequest while declaring nothing that grants it will not work.

Step eight, watch it run. Right-click the extension icon, choose Inspect popup, open the Network tab, and use the extension. Then go to chrome://extensions, keep Developer mode on, and open the inspect link on the service worker row to watch the background context separately.

Which parts of transcript work need a server, and which do not

The split is not local good, server bad. It is about which operations have a reason to leave the machine.

Summarising or judging a transcript with a hosted model requires a server. The weights run on hardware you do not have, and no Manifest V3 extension can ship them or fetch them at runtime, so anything that returns prose about the meaning of a transcript sends the transcript somewhere. Prepublish's own site works this way, and the privacy page names the processors it uses for uploads and analysis.

Producing a public transcript page also requires a server, for a different reason. Prepublish pulls captions server-side with yt-dlp, and the public transcript API answers a cold request in 37.1 s and a cached one in 3.9 ms, measured on 19 September 2026. A shared 30-day cache is the point of that design, and a browser extension cannot share a cache between users.

None of that work is what a word count, a words-to-minutes conversion, a speaking-pace measurement, or a subtitle export needs. Those are arithmetic on text you already hold, and the extension performs them in the browser. The in-browser caption pull measures 1.4 s when the player's caption request is already captured, 14 s cold, and 26 to 38 s in a hidden background tab, measured on 18 and 19 September 2026.

The fair way to read a claim in this category is to ask which bucket the feature falls into. A summariser with no server is not a thing that exists. A word counter with a server is a choice.

The Prepublish extension, checked line by line

The Prepublish extension is a Manifest V3 package written in plain JavaScript and CSS with no build step and no dependencies. Its complete declared surface, read from its manifest.json on 19 September 2026, is three API permissions and four host patterns:

It declares no tabs, scripting, clipboardRead, webRequest, cookies, downloads or unlimitedStorage permission.

What it computes locally is counts, pace, and length. The header comment in src/lib/calc.js states the boundary: nothing in that file judges a script, and anything that would be an opinion is a hand-off to the website. The file touches no DOM, calls no chrome API, and imports nothing.

The caption pull is local in the sense that matters. A content script runs in the page's own JavaScript world at document_start and patches window.fetch and XMLHttpRequest.prototype.open to record any URL containing /api/timedtext. The extension then refetches the player's own URL with &fmt=json3 and credentials: 'include', so the request carries your YouTube session and goes to youtube.com rather than to Prepublish. It strips tlang, which the player appends for auto-translated captions, so the pull returns the track in the language the video is spoken in.

The one moment information about the video reaches Prepublish is when you open the public transcript page. The button opens prepublish.ai/youtube-transcript/<video id>, and the only thing about the video that crosses is the id in the address, along with attribution parameters naming the extension as referrer. No caption text, no draft, and nothing you typed is uploaded. Prepublish's servers pull the transcript on that page independently, so it is a second pull of the same public video rather than a copy of the one in your browser.

Two things it deliberately does not do matter as much.

The extension does not send the transcript anywhere, including to Prepublish. When you hand text to one of the free checks, the page loads with attribution parameters and the text is written into that page's own form field. The extension never submits the form. Every check on the site is free and needs no account, and the privacy page covers what happens after you press submit yourself.

The package also declares no web_accessible_resources and no host permission for YouTube's image host. Thumbnails load as ordinary image requests from the extension's own pages, which is why i.ytimg.com never appears in the permission list. With web_accessible_resources absent, no web page and no other extension can reach into the extension's files, which is the default Chrome ships and the one that keeps sites from fingerprinting extensions.

Where the audit stops

A privacy policy is a promise, and nothing in the browser enforces it. Chrome re-prompts for a new permission only when it triggers a warning, so a change that starts using access the extension already has arrives silently in an update, and the permission list describes a version you have not read.

The greps describe the files they ran against, and on a minified bundle the picture inverts. The same host-listing command against a bundled extension directory in the same Chrome profile returned hundreds of URL strings, mostly license headers, documentation links and specification references, and the most frequent hit was http://www.w3.org. On a minified bundle a grep tells you a string is present, not that it is reachable.

The Network tab shows what your actions caused. A request that fires on a code path you did not exercise, such as a first run, an error handler, or a specific video state, will not appear. It is the strongest available check and it is still a sample.

The permission dialog describes patterns, not behaviour. It names origins and capability classes and says nothing about what the code does with them. The gap between "can read youtube.com" and "reads only the caption track of the video the user asked about" is the entire privacy question, and only the code or the network tab closes it.

None of this argues against reading the permission list. Read it as the cheap first filter and treat the code as the answer. An extension that declares three permissions and makes five matched network calls in unminified source is auditable in five minutes.