On 4 June 2026, a security researcher publishing under the name Buchodi released a technical analysis of Stella, the companion app for Meta’s Ray-Ban and Oakley smart glasses. Inspecting version 273.0.0.21 of the Android build, the researcher found what they described as a complete, dormant facial recognition pipeline: three on-device AI models, a biometric database schema, a vector similarity index dimensioned to those models, a write path for unrecognised faces, and a hardcoded notification channel labelled “nametags_recognition.” The research was published alongside reporting in WIRED, which confirmed that code had been added to the app across multiple updates since January 2026.
The app, which is required to use the glasses’ key features, had been downloaded more than 50 million times before any of this was disclosed.
What the researcher found in the app
The three models identified in the Stella build are SCRFD, a face detection model developed by InsightFace; KPSAligner, which crops and aligns detected faces using facial keypoints; and SFace, which converts an aligned face into a 2048-number biometric fingerprint. The SFace variant in Stella appears to be scaled larger than the public reference implementation: 96 megabytes versus approximately 40 megabytes in the open-source version, with a 2048-dimension output. These models arrive on the device via Meta’s asset delivery system.
Alongside the models, the researcher found a SQLite database stored under Meta’s cross-device sync framework, RLDrive, in a namespace called person_profiles. The database schema holds named person records, face records linked to each person, and a vector table dimensioned at exactly 2048 floats to match the SFace embedder, using cosine-distance search. Each face row links back to a person name. Recognition, when it runs, is a cosine-similarity query against the stored faceprints, followed by a join to retrieve the person’s name for the notification text.
The researcher ran the pipeline end-to-end against a test image. On a no-match result, the app wrote a cropped face image and its biometric embedding to a folder called NameTagsPending. On a match, it fired an Android notification through the nametags_recognition channel, with the title “Person recognized” and the body “Recognized [name].” The notification contained a tappable deep link intended to open a person-profile screen inside Stella; that destination screen was absent from this build.
A separate user-facing widget titled “Connections” was found in the APK, carrying the text “Remember the people you met and make new connections.” On a standard unenrolled account, the card does not appear in the app’s interface.
According to WIRED’s reporting, the same feature appears under the name “Connections” in a May 2026 version of the app.
What this does not yet show
The researcher is careful on this point and so should anyone writing about it be. On a stock account with no enrolled contacts, the user-facing interface does not appear and the recognition pipeline is not active. The researcher did not observe Meta pushing face data to the person_profiles database on a test account. The database is configured to receive server-side updates via RLDrive, which Meta uses to sync other kinds of data, but the researcher did not directly observe a transmission to the face namespace.
Meta’s response, attributed to company representative Ryan Daniels and reported by PhoneArena citing WIRED, was that the findings are “merely evidence” that Meta is developing the concept, that “nothing has shipped to consumers and no final decision has been made,” and that if Meta proceeds with the feature, it would do so openly. The company stated it was not secretly building a central biometric database of users’ faces.
The distinction between “the apparatus is built and wired together” and “the apparatus is active for users” is real and worth keeping. The researcher makes it explicitly. What the code review establishes is the existence and functional coherence of a facial recognition system, not its operation for ordinary users.
Why the context makes this harder to dismiss
This is not the first time a Meta smart glasses product has come into contact with facial recognition. In February 2021, BuzzFeed News reported that Facebook had considered building facial recognition into the first Ray-Ban smart glasses concluding that state biometric privacy laws would likely make it impossible to offer. That same month, two Harvard students, AnhPhu Nguyen and Caine Ardayfio, demonstrated a project they called I-XRAY: software they added to a standard pair of Ray-Ban Meta glasses that fed the video stream through external facial recognition tools and public data sources to identify strangers on the street. Nguyen and Ardayfio said they built the demonstration to show what was technically possible, declined to release the code, and recommended people opt out of the data sources involved. Meta’s glasses were not the cause of the demonstration, but they were the interface.
In November 2021, Meta announced it was deleting more than one billion faceprints collected through Facebook’s photo-tagging system and shutting down that system entirely, citing concerns about the use of facial recognition technology as a whole. Meta subsequently paid US$650 million to settle a class-action lawsuit brought by users in Illinois and, in 2024, agreed to a separate US$1.4 billion settlement with the state of Texas, both concerning the collection of biometric data without consent.
In February 2026, the New York Times reported that Meta had revived its plans for facial recognition on smart glasses, citing internal documents. The report described a feature internally called NameTag and quoted an internal memo recommending launch “during a dynamic political environment where many civil society groups that we would expect to attack us would have their resources focused on other concerns.” Meta’s plans, the Times noted, could change.
The Buchodi/WIRED code analysis, published in June 2026, adds a technical layer to that reporting: the machinery described in the February accounts had, by that point, already been shipped to tens of millions of devices in non-functional form.
The question the code raises
The researcher’s framing is pointed: “Capability that doesn’t ship by accident.” Building three production-scale facial recognition models, a biometric database, a vector index dimensioned to match those models, a write path, and a notification surface with hardcoded text down to the notification channel name is a substantial engineering investment. It is coherent, not stray code. Whether it represents a feature in active preparation or a feature that has been shelved in assembled form is a question the available evidence cannot settle.
What the code does show is that users of a consumer device were not informed, at the point of download or during any of the updates in which the models arrived on their phones, that their device now carried functional facial recognition infrastructure. Meta’s stated position is that the feature is not enabled. From a user’s perspective, the meaningful disclosure gap is between “not enabled” and “not present,” which are not the same thing, and which mattered differently before any of this was reported.
What to watch next
Meta has not confirmed whether NameTag will proceed to a public launch. Senator Ed Markey and other lawmakers wrote to Meta in March 2026 requesting information about its facial recognition plans; those letters appear to have prompted no public response as of this writing. Illinois and Texas biometric privacy laws were the basis of Meta’s two previous settlements; both states have specific requirements around the collection and storage of biometric identifiers, and whether the NameTagsPending write path constitutes collection under those statutes is a question regulators may eventually need to answer.
Meta’s glasses have sold approximately seven million pairs in the past year, according to reporting by the New York Times. The companion app, required for full functionality, has been downloaded more than 50 million times. At the scale of that distribution, the difference between a feature that is dormant and one that is enabled is a server-side configuration change.
