Chrome Extension Permissions Explained: What a Screen Recorder Actually Needs
Every screen recorder extension asks for a list of permissions during install. Here is what each one actually does, why ScreenKit needs it, and how to tell a reasonable request from a red flag.
Before you install any Chrome extension, you get a quiet moment of doubt: what is this thing actually allowed to do? For a screen recorder, that question matters more than most — you’re handing a piece of software the ability to see your screen. Knowing what each permission means, and why a recorder needs it, is the difference between installing blindly and installing with confidence.
Here’s a plain-English breakdown of the permissions a screen recorder like ScreenKit asks for, and what each one is doing behind the scenes.
Why permissions exist in the first place
Chrome extensions have to declare, upfront, every capability they want. This is a good thing — it means you can inspect a permission list and reason about what an extension could do, before you ever run it. The trade-off is that the list can look intimidating out of context, especially phrases like “read and change all your data on all websites.”
The fix isn’t to ignore the list. It’s to understand what each line actually unlocks.
The permissions, one by one
| Permission | What it does | Why a screen recorder needs it |
|---|---|---|
activeTab |
Grants temporary access to the tab you’re currently on, only when you invoke the extension | Lets ScreenKit see the tab you want to record without needing standing access to every tab you have open |
tabCapture |
Lets the extension capture the video/audio stream of a browser tab | This is the core recording API — it’s how a tab recording is captured at all |
offscreen |
Allows the extension to run a hidden page that can use media APIs a background service worker can’t | MediaRecorder and stream processing need a real page context, not just a background script, so this hidden page does the actual recording work |
downloads |
Lets the extension save a file to your computer | This is how a finished recording or screenshot lands as a file — it’s also what makes local export possible without a server in the loop |
storage |
Lets the extension remember small bits of state | Used for things like your current recording status and UI preferences, so the recording bar stays in sync across tabs |
scripting |
Lets the extension inject code into a page | This is what draws the in-page recording bar, countdown, and live annotation tools directly on top of the site you’re capturing |
Host permissions (http://*/*, https://*/*, file:///*) |
Lets the extension’s content script run on the pages you visit | Needed so the recording controls and annotation overlay can appear on any site you’re demoing — not just an allowlist of specific ones |
Notice what’s not on that list: there’s no special “read your files” or “access your contacts” permission, because a screen recorder doesn’t need either.
What about the camera and microphone?
Interestingly, camera and mic access isn’t requested through the extension’s permission list at all. It’s requested at record time, through the browser’s own getUserMedia prompt — the same native “Allow this site to use your camera/microphone?” dialog you’d see on a video call site. That’s a deliberate browser design: media access is scoped to the moment you actually turn on the mic or camera bubble, not baked into the extension’s standing permissions.
The file:///* line, specifically
You’ll sometimes notice file:///* in a recorder’s permissions. That doesn’t mean the extension can silently read your hard drive — Chrome requires you to manually flip on “Allow access to file URLs” for a given extension before it applies to anything, and even then it only lets the extension’s overlay run on local HTML files you open directly, the same way it runs on a normal website. It exists to support recording local prototypes and offline pages, not to grant filesystem access.
What a reasonable permission list looks like
When you’re evaluating any screen recorder — ScreenKit or otherwise — a few signals separate a sensible ask from a suspicious one:
- Every permission maps to a visible feature. If a recorder asks for something you can’t connect to a button in the UI, that’s worth questioning.
- No “read browsing history” or “manage your downloads history” style permissions. Recording your screen doesn’t require reading where you’ve been.
- Camera and mic prompts happen at record time, not silently in the background.
- The privacy policy states plainly where footage goes. ScreenKit processes everything locally, with no account and no uploads — the permission list above is the complete set of things it can do, and none of them involve a server.
Common questions
Does ScreenKit need “access to all websites” to spy on my browsing? No. That broad host permission is what lets the recording overlay and annotation tools appear on any page you choose to record — it’s a requirement of where the UI can render, not a request to monitor your activity.
Can ScreenKit record my screen without me clicking record? No. Recording only starts when you explicitly trigger it through the extension; tabCapture and getUserMedia both require an active user action to grant a stream.
Why does it need the downloads permission if everything is local anyway? Because “local” still means the finished video or screenshot has to be written to a file on your device — the downloads API is exactly how a browser extension saves a file without a backend server involved.
Is a long permission list automatically a bad sign? Not by itself. What matters is whether each permission maps to something the tool visibly does. Compare the list against the feature set and see if anything’s unexplained.
Understanding permissions is part of choosing a recorder you can trust. Add ScreenKit to Chrome — every permission above maps to a feature you can see, and nothing you record ever leaves your device.