# Permission Justifications — Adom for Chrome & Edge

For the Chrome Web Store "Privacy practices" tab and the Edge Add-ons submission. Paste each
justification into the matching field. Lead context (use in the single-purpose / overview):

> **Single purpose.** Adom for Chrome & Edge lets a developer's own Adom AI assistant operate
> their real, signed-in browser on their behalf — navigate, screenshot, inspect, fill, click,
> and debug — so the developer and the AI can build and test web software together. Adom
> Industries is an AI electronics-prototyping company whose users continuously build web-based
> oscilloscopes, web-based EDA/CAD tools, and circuit-board-control apps in the browser; this
> Extension is the AI's "hands" in that browser, the same category of tool as the Claude
> browser extension. Every permission below exists to deliver that user-directed automation,
> not to collect data.

## Worked example — why a developer needs full DevTools-grade access

A concrete, representative task (use this verbatim if a reviewer asks "why so much power?"):

> An Adom developer is building a web app that pulls live pricing and availability from the
> **Mouser** and **DigiKey** APIs — calls that only succeed from their **signed-in** browser
> session. A request comes back empty, so they ask their Adom AI assistant to debug it. The
> assistant does exactly what the developer would do in DevTools, in the developer's own
> logged-in tab:
>
> 1. **`eval`** `await fetch('/api/digikey/search?mpn=ADS1262IPWR').then(r => r.json())` directly
>    in the app's page context, and reads back the **real authenticated** response.
> 2. Inspects the **console and network** for the failing call — the `401`, the malformed auth
>    header, the rate-limit body.
> 3. Patches the code, re-runs the call, and confirms the parts now resolve — all without the
>    developer leaving their seat.
>
> This is the single purpose: an AI pair-developer operating the user's own DevTools on the
> user's own session. `debugger` (run / inspect / console / network), and `cookies` + `<all_urls>`
> (act in the real signed-in session, on whatever app is being built) are not optional extras —
> remove them and the only thing left is a worse screenshot tool. The Extension never harvests
> these APIs or sessions; it performs the developer's debugging task, on the developer's command.

| Permission | Justification (paste into store) |
|---|---|
| **nativeMessaging** | Connects the Extension to the user's local Bridge application over Chrome's native-messaging channel, so the user's AI session can send commands and receive results. This is the core transport; without it the Extension cannot function. |
| **debugger** | Uses the Chrome DevTools Protocol on the active tab to dispatch trusted (isTrusted) input, capture full-page screenshots, evaluate and debug JavaScript, and read console/network logs — the exact capabilities a developer or AI coding assistant needs to build, drive, and test web applications. Attached only while an action runs and detached when idle. |
| **scripting** | Injects helper scripts to read the DOM, locate and fill form fields, and report page state when carrying out a user-requested action. |
| **tabs** | Opens, closes, switches, reloads, and lists tabs the user asks the AI to operate, and maps the user's session to the correct tab. |
| **webNavigation** | Detects when pages finish loading and when navigations occur, so commands (e.g. "navigate then screenshot") run at the right moment and sessions self-heal. |
| **cookies** | Lets authenticated workflows use the developer's existing signed-in sessions (their own dashboards, tools, and vendor sites) without forcing re-login, and supports a clean sign-out where requested. Cookies are used to perform the user's task, never collected as a dataset. |
| **downloads** | Saves files the user asks to download (datasheets, exports, CAD/3D assets) into their own browser profile. |
| **storage** | Persists minimal local state — the user's session-to-window mapping — so commands stay consistent across the service worker's lifecycle. |
| **alarms** | Keeps the service worker responsive and schedules lightweight keepalive/health checks for the native-messaging connection. |
| **tabCapture** | Records a tab to video when the user explicitly asks for a walkthrough/recording of their own page. |
| **desktopCapture** | Provides an optional screen/window capture path for recordings the user explicitly initiates. |
| **offscreen** | Hosts short-lived offscreen processing (e.g. encoding a capture) that MV3 service workers cannot do directly. |
| **identity / identity.email** | Lets the developer optionally link the Extension to their own Adom account so their AI session is associated with them; used only with the user's consent to identify their own session. |
| **host_permissions: `<all_urls>`** | A development environment must work on **any** site the developer is building, testing, or signing into — there is no fixed allow-list for "the whole web." Like an AI coding assistant that can drive any page the user points it at, the Extension needs to act on whatever URL the user is currently working with. Access is exercised only per user-issued command, never to crawl or harvest. |

**Remote code:** The Extension executes **no** remotely-hosted code. All logic ships in the
package; it evaluates JavaScript only as part of user-directed automation of the current page
(via the debugger/scripting APIs), not by loading external scripts.

**Data use certification:** We do not sell or transfer user data to third parties for purposes
unrelated to the single purpose; we do not use or transfer it for advertising or
creditworthiness. See the Privacy Policy at https://adom.inc (and the page on wiki.adom.inc).
