Can You Own It?

Privacy, data rights, and content ownership when building a health app on Meta smart glasses

A sourced review synthesized by Claude Code (development assistant) for SomaSoft / AURIV, from 23 primary and secondary sources, 100 extracted claims, 25 adversarially verified (22 confirmed / 3 refuted). Reality-Engine note: each claim below carries its source and its 3-vote verdict; refuted claims are reported as refuted.

The honest answer

No — you cannot fully guarantee user privacy, and you cannot own "all" content and data, when you build a health app on Meta's smart-glasses platform.

Meta's own developer terms are structurally hostile to exactly the app you'd want to build. The strongest defensible position available is data-minimizing, local-first processing that never invokes Meta AI — which is a real, if narrow, opening. But it is not an absolute privacy guarantee, and a zero-egress guarantee could not be verified. For a project whose whole point is privacy, ownership, and beside-not-above values, this matters: you would be building your privacy castle on rented, extractive land.

What Meta's terms actually say

• A health app is contractually obstructed. Meta's Wearables Developer Terms state you "may not use the Technology to create, receive, maintain, transmit, or otherwise Process any Protected Health Information unless you have signed a Healthcare Addendum" (a BAA is required first); the technology "is not intended to be a medical device"; and you "may not use the Technology for mission critical, life-saving, or hazardous activities." Meta disclaims HIPAA obligations and puts all compliance on you. (3-0, high — wearables.developer.meta.com/terms)
• You own your IP but not exclusive control. Terms §2.3 (updated Oct 6, 2025) grants Meta a "worldwide, non-exclusive, sublicensable (through multiple tiers) license to your Integration (including all Intellectual Property Rights therein) and data" — for review, marketing/advertising, and platform improvement. You keep ownership; you cannot exclude Meta or its sublicensees from those uses. (3-0, high)

What Meta collects by default (and you can't turn off)

• Voice storage is now mandatory. Effective April 29, 2025, Meta removed the option to disable voice-recording storage. Voice transcripts and audio are stored by default and kept up to one year to train Meta's products (misactivations deleted within 90 days). (3-0, high — PetaPixel, eMarketer, EFF)
• Camera AI is on by default. "Meta AI with camera" is "always enabled unless you turn off Hey Meta," and visual content you submit to Meta AI may be used for training. (3-0)
• Meta AI cannot run locally. Per EFF (Mar 2026): "You can't use any AI features locally on the glasses… anytime you use AI features… the footage is fed to Meta." Meta's AI/voice layer is not exposed to third-party developers in the initial toolkit preview. (3-0)
• Good-news nuance (refuted the scary version): the claim that photos/videos you capture are automatically uploaded to Meta was REFUTED (0-3) — locally captured media is not used for training or auto-sent unless you submit it to Meta AI. Your own captures, kept out of Meta AI, stay yours.

The one real architectural opening

• The Wearables Device Access Toolkit exposes camera, microphone, speaker, the Ray-Ban Display, motion/orientation, and phone GPS to developer apps, and Meta's FAQ says developers "can process data locally or via cloud/edge platforms" — so Meta cloud is not mandatory for your own pipeline. A local-first app that never calls Meta AI is architecturally permitted. (2-1, medium)
• But the limits are real: the Meta AI app is required to pair the glasses, and the toolkit is a phone-mediated SDK — raw streams still transit Meta's app/SDK layer. The stronger claim that developers get "raw camera and audio streams" was REFUTED (1-2). And a zero-egress guarantee was REFUTED (0-3): you can process locally by policy, but you cannot architecturally prove nothing leaves.
• On-device inference is feasible but unguaranteed here. Billion-parameter LLMs run on modern phone NPUs (Gemma 2B, Phi-3.5-mini, Qwen2-1.5B in ~5.7 GB, ~20–50 tok/s — though ~3× slower time-to-first-response than cloud). Hardware trusted-execution (ARM CCA) can isolate agent inference at <5.15% overhead — but Meta's glasses do not expose ARM CCA to third-party developers, so the hardware-guarantee architecture is a valid general technique, not a Meta-glasses solution. (mixed 2-1/3-0)

The law applies even without HIPAA

• HIPAA likely won't cover you as a solo, non-covered-entity consumer app — but that is not a free pass. (3-0)
• The FTC Health Breach Notification Rule (effective July 29, 2024) covers consumer health apps: breach notice within 60 days, civil penalties. (3-0)
• Washington's My Health My Data Act (effective Mar 31, 2024) is the sharpest obligation: it covers derived/inferred data and wearable metrics, applies beyond HIPAA, requires opt-in consent, bans geofencing near health facilities, and carries a private right of action (individuals can sue). (3-0) GDPR special-category rules and biometric laws (Illinois BIPA) apply to face/voice/health data as well.
• A proposed federal Health Information Privacy Reform Act (S.3097, Nov 4, 2025) would extend HIPAA-like protection to wearables — pending, not law. (3-0)

Bystander privacy

Recording others via always-available glasses raises two-party-consent-state audio-recording exposure and genuine ethical concerns; a health app that captures the wearer inevitably captures bystanders. This is a design constraint, not an afterthought.

A privacy-preserving reference architecture (the strongest defensible version)

If you build on Meta anyway, this is the most private, most ownership-protective shape available — offered honestly as harm-reduction, not a guarantee:

1. Never invoke Meta AI. Use only the Device Access Toolkit streams; do all inference yourself. The moment you call Meta AI, data goes to Meta's cloud and may train its models.
2. Process on-device or on your own infrastructure (the local-first NAS/edge you already run). No third-party cloud.
3. Minimize by design. Derive the health signal, discard the raw frame. Store inferences, not footage.
4. Encrypt at rest and in transit; self-host storage; keep the wearer's data on the wearer's hardware.
5. Consent, explicitly and opt-in (MHMDA-grade), with a plain-language notice — and treat bystander capture as a first-class concern.
6. Accept the residual: raw streams still pass through Meta's SDK; you cannot prove zero-egress. Disclose that honestly to any user.

What cannot be guaranteed (SYM-008, applied)

• That data never reaches Meta (unverifiable — the SDK is in the path).
• Exclusive control of integration data (Meta's license precludes it).
• Hardware-enforced isolation (ARM CCA not exposed to you).
• HIPAA-grade protection from the platform itself (it disclaims it).

Recommendation

For experimenting with the pair you have: fine — build local-first, never touch Meta AI, minimize data, and know you cannot promise privacy. For a serious, values-driven health product where privacy and ownership are the point, Meta glasses are the wrong platform. Its model is extractive and above-not-beside by construction; your project's model is sovereign, local, and honest. The consistent path is the one you're already on with AURIX — open, self-owned hardware where you control the whole stack (the OAK-D camera you already have, open AR platforms) — where "I own all content and it stays private" can be true, not merely hoped.

The honest one-liner: on Meta's glasses you can reduce harm, but you cannot make the promise. On hardware you own, you can.

Sources (primary)

• Meta Wearables Developer Terms — https://wearables.developer.meta.com/terms/
• Meta Wearables Device Access Toolkit (dev blog + FAQ) — https://developers.meta.com/blog/introducing-meta-wearables-device-access-toolkit/ · https://developers.meta.com/wearables/faq/
• EFF, "Think twice before buying or using Meta's Ray-Bans" (Mar 2026) — https://www.eff.org/deeplinks/2026/03/think-twice-buying-or-using-metas-ray-bans
• PetaPixel / eMarketer on the Apr 29, 2025 voice-storage policy change
• FTC Health Breach Notification Rule (eff. Jul 29, 2024) — federalregister.gov 2024-10855
• Washington My Health My Data Act (eff. Mar 31, 2024)
• On-device LLM / TEE feasibility — arXiv 2604.18302, arXiv 2604.18231
• Proposed HIPRA — Congress.gov S.3097 (Nov 4, 2025)

Reality-Engine note: this review reports adversarial verdicts, including the three refuted claims, rather than only the convenient ones. Legal points are informational, not legal advice — confirm with counsel before building.