What we collect, what we don't, and why.

Browser use is a separate choice

Mercury Browser connects an approved Chrome profile to the installed Mercury desktop app. Installing the extension does not create Browser approval. When you enable Browser use, Mercury can inspect open tabs and windows, page URLs and titles, webpage text and controls, and screenshots. It can move between pages and interact with them, including entering task-provided text, for work you authorize. Signed-in pages can contain personal or sensitive information.

From Chrome to your Mercury deployment

The extension exchanges browser commands and results with the installed Mercury app through Chrome native messaging. Mercury can send relevant browser observations, screenshots, action arguments and results to your selected deployment and its configured models to carry out the task. Browser-derived material can become part of conversation and tool history, agent memory, working files and other records produced by enabled tasks. This browser connection is separate from Gmail and Calendar OAuth; its transport does not use the shared Google connection gateway described below.

Use, transfer and human access

We limit browser-data use to the disclosed browser features and their maintenance and security. We do not sell browser-derived data, use it for advertising, pool it into cross-client memory, or use it to train or improve general-purpose models. Transfers are limited to providing those features and the legal, security or explicitly consented business-transfer exceptions permitted by the Chrome Web Store User Data Policy. Human access to private browser-derived content requires the user's documented explicit consent to view the specific data, except for the policy's permitted security, legal, or aggregated and anonymized internal-operation uses. A general engagement agreement does not replace that consent or waive these commitments.

Stored records and deployment controls

The extension and desktop app keep local profile and approval identifiers, revocation records, and bounded recovery and diagnostic metadata to maintain the connection and avoid repeating uncertain input. Your deployment information identifies its hosting operator, configured models and other recipients, and the applicable storage, retention, caching, recovery-copy and human-access arrangements. It must be available before the corresponding processing is authorized. Useful task records follow the enabled service purposes and user or client instructions; separately retained provider copies and backups have their own disclosed controls. Changing a model or operator does not override these data-use restrictions.

Stop access and request removal

Turning off Browser use or cancelling the debugger connection in Chrome blocks new browser commands under that approval; an action already dispatched may still finish. Disabling or uninstalling the extension also stops its future browser access. These actions do not delete website originals or automatically erase records already retained by Mercury, model services, task destinations, exports or backups. Contact your deployment operator or Shane at shane@mcintoshsystems.com for access, correction, export or deletion requests, identifying the deployment and records concerned. We verify authority and scope and explain supported actions and any separately retained copies.

Chrome Web Store Limited Use

Mercury Browser's use and transfer of information received through the Chrome extension adheres to the Chrome Web Store User Data Policy, including its Limited Use requirements.

Mercury is software delivered by McIntosh Systems for individual client organizations. It has no public self-service signup. Each deployment has its own operator, hosting and model configuration. This notice explains the shared Google connection service and the product's Google-data uses. Your organization's deployment information explains its actual processing arrangements and data controls. Applicable client agreements govern the engagement alongside these Google-data commitments.

Access and purposes

When you connect Gmail or Google Calendar, Mercury requests the permissions shown in the connection flow and Google's consent screen. The core email features use message content and headers, attachments, drafts, labels and mailbox state to display/search email, organize messages, prepare drafts and send reviewed messages. The core calendar features use subscribed-calendar information, events and related attendee details to select calendars, find meetings and perform event work you authorize. Google account permissions and separate Mercury Bot/tool grants continue to apply.

The shared connection gateway

McIntosh Systems operates the default connection gateway on Cloudflare. It handles Google authorization, holds Google access and refresh credentials encrypted, and proxies authorized Google API results to the enrolled Mercury deployment. The deployment holds an opaque connection reference and its own signing identity rather than the gateway's Google credentials. A client-owned direct OAuth setup has a separately identified credential arrangement. The common gateway does not mean all clients share one Mercury database, hosting location or model account.

Deployment storage and model processing

Hosting, administrative access, supported model providers and recovery arrangements are chosen for each client deployment. For enabled tasks and features, relevant Google content and retained context may be processed by that deployment's configured models. The applicable deployment information identifies actual destinations, purposes and relevant data-handling arrangements, including applicable retention, caching and human-access conditions. It must be available to affected users before the corresponding processing is authorized. Before using Google data for a materially new purpose or an undisclosed transfer, we update the applicable disclosure and obtain the user consent required for that change. Choosing another model or operator does not override these restrictions.

Useful service records

Enabled features can retain email and conversation/work history, a mailbox search index, agent memory, working files and related execution records to provide authorized searches, requested work, continuity and review. Useful records remain while needed for those purposes, until user/client-directed deletion or an explicitly agreed policy calls for removal. A selected mail history window determines what is indexed; it is not a blanket expiry for all Mercury records. Disposable operational material, provider copies and backups have their own applicable handling described for the deployment. Retention and removal follow the enabled service purposes, user/client instructions and the deployment’s disclosed arrangements; separately retained copies may have different controls.

Permitted use and human access

We do not sell Google-derived data, use it for advertising, pool it into cross-client memory, or use it to train or improve general-purpose models. Model assistance is for the disclosed user-facing tasks and authorized client work. Human access to private Google-derived content requires the user's documented explicit consent or affirmative agreement to view the specific messages, files or other data, except where Google permits access for security, applicable law or aggregated and anonymized internal operations. A general engagement agreement does not replace that consent. Client and provider handling must remain consistent with the Google Limited Use requirements.

Disconnecting and deleting records

Disconnecting a service stops future use of that selected connection. With the company gateway it removes the current gateway credential for that connection; it does not delete Google originals or automatically erase content already retained in Mercury, model systems, exports or backups. Removing the entire company app from your Google Account can affect other connections under that app. Search indexes, conversations, memory and files have separate controls and request scopes. The product help explains these distinctions and the supported actions.

Requests and recovery copies

Contact your deployment operator or Shane at shane@mcintoshsystems.com for access, correction, export or deletion requests. Identify the deployment, connected service and the records or processing concerned. We verify the request's authority and scope, coordinate the supported actions, and explain completion and any separately retained copies or applicable exceptions. Do not send passwords, tokens or an entire private mailbox in ordinary support email. Backup expiry and restoration restrictions follow the actual deployment arrangement; active-record removal is not a claim of immediate physical erasure from every recovery copy.

Google Limited Use

Mercury's use and transfer of information received through Google Workspace APIs adheres to the Google API Services User Data Policy, including its Limited Use requirements.

About Mercury’s Google features · Manage your connection and records

Gmail and Google Calendar in Mercury

McIntosh Systems delivers Mercury for individual client organizations. In your organization's deployment, connect a Google account to read and organize email, prepare drafts and reviewed sends, select calendars, and work with events you are allowed to manage.

McIntosh Systems provisions client Google connections. We are preparing the company Google app for verification. Google may display an unverified-app notice until the app is approved.

The default Google connection uses McIntosh Systems' gateway on Cloudflare. The gateway keeps Google connection credentials encrypted and forwards authorized results to your Mercury deployment. Clients can instead choose their own Google OAuth arrangement.

Hosting and model providers are configured for each deployment. Enabled mail search, work history and agent memory can help you find older information and continue your work. Read the Mercury Google privacy information and the information for your deployment before connecting. For product support or privacy questions, contact Shane at shane@mcintoshsystems.com.

Manage your Google connection and Mercury records

Disconnect an account

Open Mercury's connected-account settings for Gmail or Google Calendar and choose Disconnect for the service concerned. This stops that connection's future use. It does not delete Google email/events or every retained Mercury record. Removing the company app in Google Account connections is broader and can affect other connections under the same project. Legacy direct/BYO disconnect can also have a broader Google-revocation effect.

Manage mail search

In Email Space's search/index controls, Pause stops indexing and preserves the existing search data. Remove index removes the selected account's search corpus. It does not erase content already included in conversations, memories, files or recovery copies. History to index controls the selected mail date range.

Manage history, memory and files

Use the available control for the record you intend to change. Conversation Delete and a separately available permanent-delete action have different scopes. Eligible private-conversation permanent deletion does not cover every shared/work-associated record, memory, file, provider copy or backup. Manage those records separately or request help from the deployment operator.

Request help

Contact your deployment operator or Shane at shane@mcintoshsystems.com for a scoped access, correction, export or deletion request. Identify the deployment and relevant account/service and explain what you want to stop or remove. We verify authority, explain supported actions and report any separately retained copies or limits. Do not send passwords, OAuth credentials or whole mailbox contents.

Mercury Google privacy information

We handle website logs, contact messages, client engagement data, Mercury Google connections and approved Chrome access separately. The sections below explain what we collect and how we use it.

The site itself (mcintoshsystems.com). The site is served by Cloudflare. Standard edge and access logs record the usual request metadata: IP address, requested path, user agent, response code, timestamp. These exist for delivery and abuse prevention. We run no third-party analytics or advertising pixels. We measure a small set of first-party visit, contact-button, form and email-link events to understand whether the site helps people reach us. These events contain no form text, email address or IP address. We do not treat a click as an inquiry or a sent email.

The contact form. The form on /contact accepts your note. What you type is what we get, which can include your name, email, company, and a description of the workflow or question you want to talk through. Section 03 covers where it goes and how long we keep it.

Engagement data. Anything we touch during a paid engagement is governed by that engagement's contract. Mercury Google connections also follow the Google-data commitments above. Section 04 covers the engagement defaults we work to.

For website visitors, we do not use the following:

• No Google Analytics, Plausible, Fathom, Mixpanel, PostHog, or third-party behavioral analytics.
• No advertising or remarketing pixels. The site sets no advertising cookies and joins no audiences.
• No selling, renting, or sharing of contact data with third parties for their marketing.
• No newsletter list. If we start one it will be opt-in only, and documented here before it ships.
• We do not install session replay, heatmaps, or advertising fingerprinting tools.
• No third-party font CDN. Geist font files are served with the site, without a request to an external font service.

When you submit the contact form, the fields are stored in our lead database on Cloudflare D1, along with an opaque inquiry reference, timestamp, and browser user-agent string. When available, we retain the first-session public landing path, a registered referrer origin and registered campaign label. We discard query strings, fragments, referrer paths and unrecognized campaign values. A copy may also be emailed to the firm's inbox so we see it promptly. We use what you send to reply, to understand the problem, and to scope a possible engagement.

The form uses a hidden field and Cloudflare Turnstile to check for automated submissions. Turnstile processes request and browser information for this security check. The submission endpoint may pass the request IP address to Cloudflare when verifying the check.

Email you send directly to hello@mcintoshsystems.com is delivered to a single mailbox the firm operates. We read it, reply, and keep the thread for context. We do not add you to a marketing list, enrich the message with third-party data brokers, or run inbound mail through external sales tooling.

Tab-scoped browser session storage holds random visit and inquiry references and safe first-session context, without your form text. The visit context expires after 24 hours or when that browser session ends. We honor Do Not Track and Global Privacy Control by disabling measurement and leaving inquiry attribution unknown. The form still works if measurement or browser storage is unavailable.

Anonymous intent events are removed after 90 days by daily cleanup. Confirmed inquiry records and any reviewed CRM inquiry link follow the separate conversation retention policy below. A CRM link does not automatically qualify a lead, create an opportunity or change a business outcome.

Under an engagement, the data we encounter (invoice records, vendor masters, spreadsheets, CRM exports, source code, anything in scope) is governed by the data-processing terms in that engagement's contract. The contract identifies the engagement’s operating terms. For Mercury Google connections, the Google-data commitments above also apply and are not waived by the engagement agreement.

Our default engagement posture is bring-your-own-cloud. In that arrangement, we deploy and operate the application inside the client’s tenant, typically Azure. Application data sits in the client’s storage, application credentials live in the client’s secret manager, and access is granted through the client’s identity controls. When the engagement ends, the client revokes our access. Mercury’s shared Google gateway has the separate credential arrangement described in the Mercury notice above.

Each engagement contract specifies how long data is kept, where it is stored, audit requirements, and which service providers may process it. Mercury’s default shared Google gateway is operated by McIntosh Systems on Cloudflare; the deployment’s application hosting and model arrangements are described separately in its deployment information.

For the site and the firm's day-to-day operations, the third parties that may receive data on our behalf are:

• Cloudflare serves the site, hosts the lead database (D1) and the Turnstile bot check, routes form notifications, and provides the domain's DNS. Processing locations depend on the Cloudflare services and their configuration; this website does not promise that all processing stays in one country.
• Email to hello@mcintoshsystems.com is delivered to a mailbox operated by the firm.

Sub-processors used inside a paid engagement (LLM providers, cloud regions, third-party APIs, partner specialists) are listed in that engagement's contract and disclosed before work starts. Mercury’s Google-data notice and deployment information describe its shared gateway and actual configured processing arrangements.

A submission or email is kept while there is an active or realistic conversation about working together, and for a reasonable period after so we have context if you come back. If nothing comes of it, the record is not mined for anything else in the meantime. You can have it deleted at any point (section 07). Cloudflare's edge logs age out on the host's own retention cycle and are not addressable per-visitor by us.

To have a form submission or an email thread deleted, write to hello@mcintoshsystems.com with the subject line Delete my data. We will remove the record from the lead database and the message from the mailbox, and confirm back in writing.

For data held inside an active engagement, the same rights run through that engagement's data-processing agreement, which names the controller and processor explicitly. The client controls the data.

Visitors in jurisdictions with statutory data rights (UK and EU GDPR, California's CCPA, and similar) can exercise those rights through the same address, and we will respond inside the statutory window.

For Mercury product support, privacy questions or data requests, contact your deployment operator or Shane at shane@mcintoshsystems.com. Website privacy questions and procurement reviews can use the address below.

McIntosh Systems LLC is a limited liability company organized in and operating from Minnesota, United States.

hello@mcintoshsystems.com