Skip to content
LEGAL & TRUST

Desktop capture privacy disclosure

How Homa is intended to receive bounded chart context, how visible consent should work, and what the desktop companion must never capture by default.

DRAFT — COUNSEL REVIEW REQUIRED

These documents reflect the intended Homa product and current marketing prototype. They are not effective terms and are not legal advice. Company identity, launch jurisdictions, provider terms, regulatory perimeter, and consumer-law treatment must be approved before production launch.

Effective date
Not yet effective — pending company details and qualified counsel approval
Last updated
16 August 2026
Version
0.5-marketing-draft

1. Product status

This disclosure describes the required design standard for the future signed desktop private beta. The public website does not capture your screen or microphone, and no production installer is currently offered.

2. Explicit source selection

Homa should begin viewing only after you start a session and choose a specific application window or region. The interface must name the selected source, keep the viewing state visible, and provide Change Window, Stop Viewing, End Session, and STOP HOMA controls. It must not default to the whole desktop or silently switch when the selected source closes.

3. Capture modes

  • Conversation: voice or text mentoring without visual capture.
  • On demand: one authorized snapshot when you choose Analyze or ask Homa to look at the chart.
  • Session awareness: an explicit opt-in for bounded, event-driven snapshots.

Continuous full-motion screen video sent to AI is not the intended design.

4. Region analysis

When you select an area, Homa may process the crop and, if clearly disclosed, limited low-resolution surrounding chart context needed to interpret it. The selection boundary and analysis state should remain visible.

5. Local preparation and transmission

Before an authorized image leaves the device, the desktop companion should resize and compress it, remove unnecessary metadata, validate the session and selected source, and send it only through an authorized backend. Screen-derived text is untrusted and cannot grant permissions or override security policy.

6. Microphone and voice

Microphone access should be requested when you choose to talk to Homa, not merely because the app is installed. Listening, speaking, mute, reconnect, and interruption states must be visible. Raw audio should normally be discarded after realtime processing or transcription.

7. Retention choices

Screenshots should be transient by default. Transcript storage, key-screenshot storage, behavior analysis, session reflection, and persistent mentor memory are separate intended controls. Stored session data and purposeful memory should be inspectable and deletable where appropriate. Exact production retention periods must be published before launch.

8. Information to keep outside the source

You should avoid selecting windows that contain passwords, banking details, private messages, email, confidential employer or client material, unrelated browser tabs, or another person's personal data. Homa should minimize unrelated notifications and overlays, but a user remains responsible for choosing a lawful source.

9. STOP HOMA

STOP HOMA is intended to immediately stop microphone access, capture, and active analysis. The production acceptance test must verify this behavior, including error, disconnect, and selected-window-close states.

10. Operating-system limits and security

Windows and macOS permission prompts, window identifiers, protected content, and capture behavior can vary. Production onboarding must explain known limitations. Permanent AI keys, service-role credentials, payment secrets, and other server-side secrets must never be shipped in the desktop client.

11. Questions and complaints

A verified privacy and complaint channel will be published here once the legal operator, launch jurisdictions, and rights-request process are confirmed.