Skip to content
Vision & productOpen Situation ↗
Docs/Start here
PRODUCT EXPERIENCE

Privacy boundaries

What gets shared, who may receive it, how browser permissions work and what withdrawing access or deleting copies can change.

Privacy information7 min read

Privacy depends on the feature you use, the information you supply and who receives it. This guide covers the original Situation app and the current limited shopping view. The broader ghost browser experience is still being built. Provider practices and service settings need separate confirmation; these controls do not establish a universal privacy guarantee.

The original Situation app can send the full supplied description to OpenAI before optional Jev filtering. The ghost's selected shopping view does not protect that separate request. Understand where information goes before supplying details about yourself or someone else.

Permission to act and permission to share

Permission to do a task and permission to disclose someone's information are separate. An organizer's authority to plan a trip does not automatically supply each participant's permission to send private circumstances to a model company. Checking who may act does not establish that separate consent.

Situation's existing sign-in, membership and action checks control defined application access and work. They do not establish that every person has agreed to every model disclosure. A model's interpretation must not become permission to share or act.

What the ghost shopping view contains

The current limited shopping view is built from selected product identifiers, names, quantities, prices, descriptions, basket contents, totals, task limits and checkout status. Dedicated retailer address and payment fields are excluded. The view also excludes retailer login cookies, raw page structures, screenshots, navigation, forms, source styling and images, browser errors and network traces.

Included text can still contain private facts or hostile instructions. A product title or description could contain an address even though the separate address field is excluded. Some sharing choices depend on information being removed before it reaches the hosted view; that view does not independently enforce every choice to withhold a description. Selecting fields is not a general detector of private information.

The hosted service receives the selected view along with task and action information. Situation also processes account sign-ins, delegated task access credentials and authorization connecting the local browser worker. Keeping retailer credentials out of the ghost view does not mean the hosted service receives no credentials or identifying information.

Shopping requests are limited to adding, removing or changing quantities and requesting checkout. The software checks the permitted task and shopping limits before acting. A checkout request can reach private owner review. Final live payment is disabled; reaching review does not complete a purchase.

Accounts, invitations and ending task access

Owner access uses the signed-in Situation account and the selected workspace's permissions. Knowing a task identifier does not give ownership or payment authority. Access remains specific to the owner, workspace, website, task and permitted duration.

Sharing a shopping invitation delegates access to that task and its basket. It does not create an independent basket for every recipient. Delegated access can continue without checking the owner's login on every request, so signing out alone does not revoke every existing shopping delegation.

Supported task revocation applies to the selected workspace and its owner. Replacing an invitation clears that task's delegated access and pending request. These changes do not delete the saved task information or establish revocation across every website and connection. Ending access and deleting retained copies are separate steps.

Your browser connection has its own permissions

When a local browser worker is used, it operates a paired retailer tab and connects to the hosted task service. The installed Chrome extension has permissions across its configured websites and local connection. Shopping actions are restricted to the paired tab, but installed browser permissions have a separate lifetime: revoking a shopping task does not remove the extension's permissions.

Replacing a shopping task can reset its shopping permissions and basket while keeping the separately approved browser pairing. Cloud revocation or expiry stops that cloud task's work without universally unpairing the browser, removing its connection credentials or clearing local information. Ending browser access requires separate attention to the pairing and installed permissions.

Checks on the selected tab and website do not establish complete protection for every page, private overlay or information channel. Separate private browser profiles and cookies for different owners have not been verified. Application accounts and task records alone do not prove that separation or its cleanup.

When information goes to a model provider

The original Situation app makes model requests separate from the ghost. Supplying a description can send its full text to OpenAI before an optional Jev filter attempts to remove common email addresses, phone numbers and URLs. Later filtering cannot undo that earlier disclosure. Names and private circumstances can remain in the filtered text.

Jev filtering depends on which information the feature selects and which identifying text it is told to replace. Selecting a whole group of information includes its contents. Replacing specified text does not find every private fact, determine what is necessary or supply each person's disclosure consent.

Live style generation can also send the supplied prompt and generated content used for review. That request has no Jev filter. The reviewed OpenAI connections request store: false; this request setting does not establish the provider's complete retention, training or deletion practices. Those practices and the actual service settings need their own confirmation.

Documents, records and analytics

Uploaded documents are processed on the server, and original files are retained separately. Extracted text shared for review can still contain private facts from the document. Restricting access to the original file does not remove those facts from the shared text.

Records of work can retain identifiers, timing information, inputs or model answers, depending on the feature. Filters remove some credentials and common contact details, but identifiers, private circumstances and unexpected error messages can remain. Changing a saved record does not undo information already sent elsewhere. There is no complete assurance that every record, log and error message is free of private facts.

Analytics requires a separate opt-in in the existing Situation app. Automatic capture, session recording and automatic exception capture are disabled in that path, and collected fields are limited and filtered. Account, device, session and browser identifiers remain, so this is not anonymous analytics. Withdrawing consent stops later capture through those paths; it does not delete events already sent to a recipient. These controls do not establish every recipient's actual retention settings.

Withdrawing access and deleting copies

Hosted task information can remain stored after a task expires or is revoked. Existing membership revocation blocks later defined application access and work. Application deletion clears the contents of saved application state, but does not establish erasure of every other record. Different records can have different retention periods, and an export does not establish that it contains all of a person's information.

Removal from provider or recipient copies, logs, recovery records and backups has not been established. If you use a retailer's fulfillment or a payment provider's services, they receive the information those services need. Other browser extensions and separately authorized agent connections have their own permissions and information flows. Revoking a Situation task cannot recall information already received or end every separately granted connection.

Choosing what to share

Personal Programming Interfaces are intended to make people's purpose, decisions, information boundaries and permission explicit. People choose those boundaries, and software must encode and enforce them. This direction does not itself establish contributor consent, isolated agent work or complete removal of shared information.

Before supplying information, consider its destination, the fields and free text involved, who may receive it and how long copies can remain. Permission to act, permission to disclose, withdrawing access and deleting copies are distinct choices.

Read the ghost browser experience and our vision for the product we are building. Personal Programming Interfaces describes the longer-term approach to people's choices and permissions.

AI does the work. People set the limits.