Prompt and suitable context
The extension processes the current page only after an explicit toolbar click, then sends filtered fields to a controlled backend. It does not need background scanning of every tab or access to arbitrary site cookies. Propose the Manifest V3 permission split, runtime flow, graceful degradation, and release verification plan.
This question tests browser-extension permission boundaries and product security. The backend still owns authentication, data minimization, and audit controls; extension permissions do not replace them.
What the interviewer evaluates
The interviewer wants to see API capability, reachable hosts, and user consent treated as separate decisions. Chrome documents API permissions, host permissions, optional permissions, and activeTab separately; they affect available APIs, URL access, install warnings, and update behavior.
A strong answer starts with the smallest capability, explains why a one-shot current-page action should not request <all_urls>, and covers denial, revocation, upgrades, and telemetry. Merely saying “add permissions” does not demonstrate a secure lifecycle.
Clarifications to ask first
- Does “current page” include special pages, cross-origin frames, file URLs, or incognito windows?
- Does the API need the full document or only user-selected fields?
- Must the extension observe page changes when the user has not clicked it?
- Which WebExtensions implementations must be supported?
- Can enterprise policy preconfigure permissions, and how long may audit fields be retained?
A 30-second answer framework
“I would split the capability into current-page reading, backend communication, and storage. For a one-shot action I would use activeTab instead of broad host access. Only a genuine cross-page background feature would justify precise optionalhostpermissions, requested when the user triggers that feature. I would declare only required API permissions, stop on denial or revocation, and provide a manual-copy fallback. Before upgrades I would diff permissions and monitor new access and data flows; rollback would remove the new capability.”
Step-by-step deep answer
Step 1: Map behavior to permissions
API permissions such as storage and scripting provide extension API capabilities; host permissions define the URL range that can be interacted with. The manifest should be derived from each data flow, not from features that might be needed later.
A starting point for processing only the tab where the user clicked is:
{
"manifest_version": 3,
"permissions": ["activeTab", "scripting", "storage"],
"optional_host_permissions": ["https://app.example.com/*"]
}When a script is injected only into the current page, activeTab grants temporary access after a user action; closing or navigating the tab ends it. If the product truly needs background processing for app.example.com, evaluate a precise optional host permission instead of defaulting to :///*.
Step 2: Design progressive consent
Request only core, lower-risk capabilities at install time. When the user clicks “Analyze this page,” check the URL against the allowed set. If an extra host is needed, call chrome.permissions.request() and explain purpose, scope, and how to leave the feature.
const granted = await chrome.permissions.request({
origins: ["https://app.example.com/*"]
});
if (!granted) {
showManualCopyFallback();
return;
}Success means browser capability is available; it does not bypass backend authentication. If the request fails, the user later revokes it, or policy disables it, return to the no-permission state without repeated prompts.
Step 3: Distinguish active, granted, and revocable state
Chromium distinguishes currently active permissions from historically granted permissions. chrome.permissions.remove() reduces current capability, while the historical grant set may still record the permission; a later request may not show the same prompt again. Runtime decisions should use what is currently available, and settings should expose a clear revoke action.
Before every task, call chrome.permissions.contains() for the actual permission. During the task, listen for permissions.onRemoved; stop reading and uploading, clear the outbound queue, and record an auditable permission-change event.
Step 4: Handle denial, upgrades, and rollback
On denial, present a non-technical next step such as manual selection, copy and paste, or exit. Do not classify denial as a network error or retry permission requests in the background.
Before a release, produce a permission diff covering new APIs, host patterns, content-script matches, and data fields. Chrome may disable an extension when an update increases privilege and wait for renewed consent. Removing a permission also does not necessarily erase historical grants, so rollback tests must cover users who previously granted it and users who never did.
Step 5: Make permissions a testable security boundary
Content scripts process page-controlled input, so message handlers should validate sender, message type, and size. The backend must reauthorize the extension identity, user identity, target resource, and field allowlist. Host permissions limit browser capability; they do not make a page trustworthy or stop an extension from sending read data to the wrong backend.
Before launch, build a matrix for install, allow, deny, revoke, activeTab expiry after navigation, optional-host request, permission-increasing update, rollback, enterprise policy disablement, unsupported browsers, and offline mode. Telemetry should record permission key, host pattern, outcome, and version, never page text.
High-quality sample answer
“I would start with the capability and data-flow map. Because the toolbar action processes only the current page, the core design uses activeTab, scripting, and required storage, without all-site access. Only a background feature for app.example.com would use a precise optional host permission, requested when the user triggers it. I would explain purpose and scope before the request, offer manual selection after denial, and avoid prompt loops.
Before each task I would check current permissions and listen for revocation. If access disappears, stop reading, clear the outbound queue, and make the backend reauthorize identity and resource. Before an update, diff API, host, and content-script changes, then test disablement, renewed consent, and rollback. Finally, use a permission matrix and anonymized telemetry to verify no background scan, no cross-host injection, no page text in logs, and safe degradation for denial and revocation.”
Common mistakes
- Request
<all_urls>by default → expands read and injection exposure and increases warnings → start withactiveTab, then assess precise hosts for continuous features. - Treat
optionalhostpermissionsas automatic consent → declaration is not user approval → request at feature time and handle denial. - Check permissions only at install → users can revoke them later → check before work and listen for removal.
- Review only code changes on upgrade → new permissions can disable the extension → diff permission sets and test prior grants.
- Treat browser permission as backend authorization → data can still reach the wrong account → reauthorize identity, resource, and fields server-side.
- Fill consent copy with API names → users cannot form a useful risk model → explain purpose, scope, and exit.
Follow-up questions and responses
Follow-up 1: Why not request <all_urls> directly?
A one-shot current-page action does not need background access to every site. activeTab grants temporary capability after a user action and reduces long-lived exposure; only a clear continuous cross-page requirement warrants precise host access.
Follow-up 2: What about data already uploaded when the user revokes access?
Revocation prevents later browser access but cannot recall data that already left the device. Use minimal fields, short retention, and deletion controls on the backend; clear the local outbound queue and tell the user what processing already occurred.
Follow-up 3: Why reauthorize on the backend after optional permission succeeds?
Browser permission says the extension may read a page, not that the user may access a business resource. The backend must validate the session, extension version, target resource, and field allowlist and reject stale or anomalous requests.
Follow-up 4: Can Chrome and Firefox permission behavior be assumed identical?
No. They share WebExtensions concepts, but prompts, match patterns, and runtime boundaries can differ. Test install, request, revoke, navigation, and upgrade on each target browser and keep the differences in a compatibility matrix.