On May 20, 2026, Texas Attorney General Ken Paxton opened a formal investigation into Meta's AI Glasses — the Ray-Ban and Oakley camera-equipped eyewear — over how the device records, processes, and stores facial geometry and ambient video. Two days earlier, the ACLU and 75 civil-liberties organizations 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 previous round ended in 2024 with a $1.4 billion settlement.

If you build, ship, or even use a camera-bearing piece of consumer technology, this is a moment to look at your own surface area and ask the question Paxton is asking Meta: where does the video go, who can see it, and did anyone agree to that?

Why this is a watershed and not a one-off

The legal text matters less than the precedent. A state AG just declared that:

1. An "always enabled" recording mode, by itself, is a regulatable consumer-protection issue when the LED indicator isn't reliably visible.
2. Cloud-side processing of ambient video — even when framed as "AI features" — falls inside biometric-privacy law if facial geometry is derivable from it.
3. The 2024 Meta settlement was not a one-time event; future biometric capture is on the table again.

That last point is the structural shift. Until this week, the operating assumption inside most consumer-hardware roadmaps was that a 2024-style consent banner and a small LED indicator were enough. Texas just signaled that they aren't, at least when the device is wearable and the camera is on by default.

A wearable camera is not a unique animal. The question is whether the same logic applies to camera apps, dash cams, smart doorbells, and any other "always on" recording product. There is no obvious reason it wouldn't.

The architecture question every recording product now has to answer

The Texas filing is really a stress-test of three architectural choices that any product with a camera can be measured against:

1. Is recording opt-in per session, or always-on by default?
Meta's vulnerability here is "always enabled." The opposite end of the spectrum is "the user explicitly starts each recording, and there is a persistent on-screen indicator that the camera is active." The latter is the model a regulator can defend.

2. Where does the footage live — locally, in a vendor cloud, or fed into a model?
Cloud storage of camera footage isn't illegal. But it inverts the burden of proof. Once the footage is in your vendor's cloud, the vendor has to demonstrate it isn't being used for anything the user didn't consent to. Locally-stored footage carries no such burden — the user holds the only copy.

3. Is biometric inference happening, and if so, where?
On-device biometric inference (Face Unlock, Apple's Vision Pro hand-tracking) is broadly tolerated. Off-device biometric inference of third parties captured in your camera frame is the actual line Texas is drawing. If your product processes video in a remote system, you need an affirmative answer for what is and isn't being inferred from each frame, and what's being retained.

These three questions — Opt-in or always-on? Local or cloud? Inference on-device or off? — now form the baseline a state AG appears willing to enforce.

What this looks like in a phone-based camera

We build Background Camera RemoteStream, 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:

1. 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?
2. 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?
3. 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, Background Camera RemoteStream is the one we ship. Source on our positioning and how we think about privacy lives at superfunicular.com.