On May 20, 2026, Texas Attorney General Ken Paxton sent Meta an open letter warning that the company's reported plan to ship facial recognition on the same glasses would "create serious risks for abuse victims, immigrants, LGBTQ+ people, protesters, [and] workers." The Texas AG's office described the central concern as the device's documented "always enabled" mode, in which the glasses continuously process video for Meta's AI products — with a recording-indicator LED that is "easily hidden" and "not active during the always-enabled mode."
This isn't a niche policy story. It's the second time in less than two years Texas has taken Meta to court over the same underlying issue: capturing biometric data from people who never consented. The , an Android app that turns the phone you already own into a security/monitoring camera. The architectural choices we made years ago map directly onto the three questions above, and they look very different from the Meta Glasses model:
No always-on mode. The user opens the app and starts the recording. The app does not auto-record, does not auto-start at boot, and does not capture anything unless the user has explicitly initiated a session.
Local-only storage. Recorded video is written to the phone's internal storage. There is no cloud upload, no off-device backup, and no vendor server holding a copy. We have no copy of your footage. We can't have one — the architecture doesn't support it.
No account, no tracking. The app does not require a Google or Meta or Super Funicular account. There's no sign-in screen. There's no analytics SDK shipping ambient telemetry. There's no advertising ID being attached to recordings.
YouTube Live streaming is user-initiated. If you want to stream to YouTube Live, you set it up yourself, using your own YouTube account and your own RTMP key. The stream goes from your phone directly to YouTube. We're not in the middle.
Screen-off recording is intentional, not covert. Recording continues when the screen is off because that's a battery and stealth-of-the-phone-itself feature (the phone looks idle to anyone glancing at it). The camera LED on the phone behaves the way Android requires.
The point isn't that we're better than Meta. The point is that the Texas filing makes "where does the video go" a question consumers can now expect to ask, and a product that can answer it crisply is in a different category from one that can't.
What developers should take from this
If you build anything that captures video, audio, or biometric-derivable data, three things are worth doing this week:
Audit your default state. Is recording opt-in or always-on? If always-on, what's the affirmative justification, and is the user indicator reliable and unconcealable?
Audit your storage boundary. Trace one frame of recorded video through your system. Where does it go, how long does it live, who has access, and what models touch it?
Audit your inference surface. What is your product deriving from camera input that the user didn't explicitly ask you to derive? Whatever that list is, decide whether it survives the question "what if the Texas AG asks."
The Meta Glasses investigation will take months to play out, and the legal outcome isn't the interesting part. The interesting part is that the architectural questions are now public. Camera products that can answer them honestly are going to find that the conversation has shifted in their favor.
If you want to see what a "no cloud, no account, no tracking" Android camera looks like in practice, .
SOCIAL SHARE CARD GENERATOR