Privacy Policy

1. Who this applies to

This policy describes what data a Morrow instance stores and processes on behalf of [Operator], the organization or individual that deployed and controls this instance. Morrow does not have its own hosted service — every instance runs on infrastructure the operator provisions and controls.

2. What Morrow stores

A running Morrow instance persists, on the operator's own disk:

• Browser profiles — each profile is a real browser context stored on disk (by default under /data/profiles/<id>), including cookies, localStorage, IndexedDB, and any signed-in session state for sites visited in that profile.
• Profile metadata — a local SQLite database recording profile names, status, proxy and locale settings, and timestamps.
• Session and event logs — records of when profiles were started, stopped, and connected to (Playwright, viewer, MCP, or scrape sessions), used for operability and debugging.
• Artifacts — content produced on request, such as screenshots or extracted page content, returned to the caller and not persisted beyond the request unless the operator has built additional storage around the API.

3. Sensitivity of browser profile data

Because a Morrow profile is a persistent browser, it can accumulate authenticated sessions, cookies, and credentials for third-party sites the profile has logged into. This data is materially more sensitive than typical application data — anyone with access to a profile's storage or to the Morrow API can potentially act as that profile on the sites it is signed into. Treat profile data with the same care as passwords and session tokens.

4. Access control

This instance is protected by a single API key (MORROW_API_KEY). Anyone holding that key has full access to every profile, session, and stored artifact on the instance — there is currently no per-user or per-profile access separation. The operator is responsible for generating a strong key, restricting who holds it, and rotating it if it is ever exposed.

5. Where data lives

All data described above is stored on the operator's own infrastructure — the server or storage volume the operator chose to run Morrow on. Morrow's authors do not host, receive, or have access to this data. There is no separate "Morrow cloud" that this instance reports to.

6. No telemetry or analytics

The Morrow application does not send usage data, analytics, crash reports, or telemetry of any kind to Morrow's authors or any third-party analytics vendor. Nothing about how this instance is used — which profiles exist, what they browse, or how the API is called — leaves the operator's infrastructure because of Morrow itself.

7. Third-party sites

Browser profiles are used to visit third-party websites. Those sites set their own cookies, may run their own analytics or fingerprinting, and are governed by their own privacy policies and terms of service — not this one. The operator is responsible for using Morrow in a way that complies with the terms of any site its profiles interact with.

8. Security posture

• Access is gated by the API key described in Section 4; there is currently no additional user-level authentication.
• Operators should run Morrow behind TLS (a reverse proxy such as nginx or Caddy is typical) so the API key and profile data are not sent in the clear.
• Data on disk is not currently encrypted at rest by Morrow itself. If encryption at rest is required, the operator must provide it — for example via full-disk or volume-level encryption on the host.
• Keep the host, its dependencies, and the Morrow version itself up to date.

9. Data retention and deletion

Profile data is retained until the operator deletes it. Deleting a profile removes its on-disk directory and its rows (events, sessions, profile record) from the database; this action is irreversible. The operator's default retention period for profiles, logs, and events is [retention period] — adjust or remove this line to match actual practice.

10. Changes to this policy

The operator may update this policy as the instance or its usage changes. Material changes should be communicated to anyone who relies on this instance.

11. Contact

Questions about this policy or requests regarding data held by this instance can be directed to [contact email], operated by [Operator], governed by the laws of [jurisdiction].