Browser access, explained plainly.

Last updated: 2026-09-30

Canonical public URL: https://sylin.org/ghostlight/privacy/

This policy covers the Ghostlight in Browser Manifest V3 extension published by Sylin. It explains what the extension can access, why it needs that access, and where data does and does not go.

The credential-input and passive-page-feedback changes described for version 1.3.12 apply when the matching native application and browser adapter are installed. Earlier public versions refuse credential-class fill and typing requests.

What the extension is

Ghostlight has a native application installed on the same machine and a thin browser extension. The native orchestrator owns browser jobs, policy, runtime controls, completion truth, and payload-free audit. The extension owns physical Chromium operations, page-local DOM access, local observation, and content-free visual feedback.

The extension receives typed instructions through Chrome native messaging. It does not make policy decisions, expose model-facing tools, maintain an allow-list, send telemetry, or operate without the separately installed native application.

Data used for requested browser work

For controlled Ghostlight tabs, the extension may handle:

• Page content and structure. Text, DOM structure, accessibility-relevant controls, open shadow DOM, element state, and bounds support requested reading, discovery, and interaction.
• Browser state. Current tab URL, title, loading state, window, opener, and tab-group facts keep controlled work visible and correctly associated with its local Ghostlight session.
• Screenshots. Ghostlight captures the current viewport, page, or target only when requested.
• Recordings. During an explicitly requested recording, compressed frames remain in bounded volatile extension memory. The extension uses a bundled encoder in a local offscreen document to create the animated GIF; individual frames never cross native messaging. Recording stops after at most two minutes. Finished or interrupted bytes remain for at most five additional minutes unless explicitly discarded; extension worker loss erases the volatile state. Saving to a page target or through Chrome's download mechanism remains inside the browser. Only a save requested by the MCP client returns the finished GIF through the local native-messaging chain. A browser download creates a file only after that destination is explicitly requested.
• Console and network diagnostics. When explicitly enabled for a controlled tab, Ghostlight may retain bounded, volatile console entries and sanitized network metadata. It does not retain headers, bodies, cookies, authorization values, post data, query strings, or fragments, and it does not use diagnostics to build browsing history.
• Synthetic input and navigation. Pointer, keyboard, scroll, drag, zoom, navigation, dialog, and tab-management actions perform the browser work requested by the connected MCP client.
• Form values. Values supplied by the connected MCP client may be placed into form fields. Ghostlight processes the supplied text to perform the requested edit. From version 1.3.12, credential-class fields accept input when the client acknowledges the user's explicit instruction for that request, subject to configured policy and human controls. Earlier public versions accept only non-credential fields for fill and typing.
• User-requested page JavaScript. When the MCP client explicitly requests browser_execute, bounded script text is evaluated through the Chrome Debugger API in the attached page. Its bounded serializable result may return through the local chain. The text is not installed, retained, or executed in the extension's own origin.
• Host-supplied files. The native application may supply bounded file bytes for an explicitly named page file input.

The extension does not browse the filesystem. File paths are validated and bytes are read by the native application only for the requested upload.

In version 1.3.12, fill and typing default to refusing credential-class input with guidance to the client. They accept the per-request user_authorized_credentials acknowledgement when the user explicitly instructed credential entry; an existing instruction is sufficient. The acknowledgement is supplied by the client, not independently verified by Ghostlight, and cannot override configured policy or human Pause/Stop. Without it, the current request returns guidance without pausing the session. Ghostlight does not add submitted form values to audit, diagnostic logs, or visual feedback.

Where data goes

Browser results travel through Chrome native messaging to the local Ghostlight application and then to the MCP client the user chose. Browser-local recording saves to a page target or Chrome download do not use that path; a client-requested recording save sends only the finished GIF, never its individual frames. This local process channel does not send data to Sylin. The MCP client's own handling of tool results is governed by that client's configuration and privacy terms.

Ghostlight's local audit and desktop history are payload-free. They contain opaque ids, tool, capability, decision, reason, terminal status, effect class, and bounded operational measurements. They may contain a normalized governed host and, when the configured privacy setting permits it, a bounded accessible name for the control Ghostlight acted on. They never contain URL paths, query strings, fragments, page text, selectors, form values, file paths, scripts, screenshots, recording frames or GIFs, dialog text, console text, or network payloads.

What Sylin does not do

• No developer-operated runtime service receives browser data.
• No analytics, telemetry, advertising, profiling, creditworthiness, or lending use.
• No sale or developer transfer of browser data.
• No remotely hosted extension logic or runtime update code.
• No Chrome sync storage; adapter identity and user settings remain local to the browser profile.
• No browsing-history database or background collection unrelated to a requested operation.

The use of information received from Google APIs will adhere to the Chrome Web Store User Data Policy, including the Limited Use requirements.

User control

The user controls whether the native application and extension are installed, which MCP harness is registered, whether a session is active or paused, whether controlled tabs may be closed by the model, and whether Ghostlight remains running. The extension popup and tray workbench expose controls without reading page content. In version 1.3.12, page receipts are passive messages and animations: they contain no buttons or focusable controls and never intercept pointer or keyboard input. Repeated policy refusals and credential-input guidance no longer automatically pause a session in that version.

Removing the extension or stopping the native application ends its browser access. Closing only the workbench window destroys that local surface and does not imply the orchestrator stopped.

Policy changes

If the extension's data access, use, or destination changes, this policy will be updated before the changed version is submitted.

Contact

Questions or concerns can be raised at https://github.com/sylin-org/ghostlight or by email at [email protected].