Tech Talk E10: Lasers Hack Speakers, Facebook Facial Recognition Software, Thank You FireFox

Smart speakers have been subject to issues since they were first introduced. Recently, researchers based in Tokyo and at the University of Michigan found an unexpected vulnerability in these speakers.

Reports show Facebook is working on facial recognition software that could be used to verify the identity of someone using the app. This software could be similar to the software they use when users tag another person in the app.

Unless you’ve been hiding under a rock, you’ve been hit with some irritating notification permission requests while browsing online. They usually want to serve up ads or site announcements or subscribe you to something.

Researchers in Tokyo and at the University of Michigan recently discovered an unexpected vulnerability in smart speakers. This finding highlights ongoing issues with these devices since their initial introduction. The specific details of the hack involve lasers, which could potentially exploit the speakers' functionalities.

Reports indicate Facebook is developing facial recognition software to verify user identity within its application. This new software could function similarly to their existing tagging software, which identifies people in photos. The goal is to enhance security or identification processes for app users.

Firefox is addressing irritating online notification permission requests encountered during browsing. These requests typically aim to display ads, provide site announcements, or subscribe users to services. The browser is taking steps to manage or reduce these common interruptions for users.

Users frequently encounter irritating notification permission requests while browsing online. These requests often aim to serve up ads, deliver site announcements, or subscribe users to various services. These pop-ups can interrupt the browsing experience, prompting browsers like Firefox to address them.

The consumer backlash over automatic face tagging did more than reshape one social network's settings page. It set the expectation that any device with a camera has to explain what it detects, where the inference happens and how long the data lives.

If you are building a doorbell, a retail counter, a kiosk or a robot, that expectation is now part of your requirements document, not a marketing afterthought.

The engineering consequence is concrete: on-device inference costs silicon and power, cloud inference costs bandwidth and legal exposure, and the choice has to be made before you freeze the enclosure and the thermal budget.

Biometric privacy laws in Illinois, Texas and Washington attach real damages to collecting a faceprint without written consent, and several municipalities restrict deployment outright. Teams that treat the camera as a generic sensor discover late that their product is regulated in a way their competitors avoided by detecting a body silhouette instead of a face.

Most consumer products land on the second row. A vision SoC that runs detection locally and uploads only an event flag keeps the recurring cloud bill near zero and removes the most damaging class of breach: a bucket of customer faces.

Face and voice features used to be a software decision made after launch. They are now a design input: the law in several jurisdictions attaches to the collection of a biometric identifier itself, regardless of whether the data leaves the device. If your product has a camera or a microphone and any recognition feature, the consent flow, retention policy and deletion path belong in the requirements document, not the privacy page.

The engineering consequence is concrete. On-device matching with templates that never leave the product narrows exposure dramatically compared with cloud enrollment, but it does not remove the consent requirement. Design for deletion too — a user request must actually purge templates from the device, any companion app and any backup.

Biometric data carries statutory obligations that ordinary telemetry does not. Illinois' Biometric Information Privacy Act requires written consent before collecting a face template and allows private lawsuits; Texas and Washington have their own regimes. The EU treats biometric identification as special-category data under GDPR. The practical engineering consequence is that where you store the template matters as much as whether you encrypt it.

The lowest-risk architecture keeps templates on the device in a secure element, never transmits raw images, and offers a non-biometric fallback for every function. That decision belongs in the requirements document, not in a late security review, because it drives the choice of microcontroller and the memory budget. Teams building this into connected products should read it alongside our electronic design approach to secure hardware.

Is face unlock secure enough for payments? Only with a depth or infrared channel and liveness detection. RGB-only implementations are defeated by a phone screen showing a photograph, which is why payment-grade systems all carry a depth sensor.

Does on-device inference need a special chip? Not necessarily. Modern application processors with a small neural accelerator run embedding models comfortably; microcontroller-class parts can run quantized detection but struggle with recognition at usable accuracy.

How much data do I need to train? For nearly every product, none — you use a pretrained embedding model and enroll individual users at setup. Training a face model from scratch is a research project, not a product task.

What is the biggest schedule risk? Optics. The plastic window in front of the sensor changes transmission and scatter, and that discovery usually arrives after tooling. Prototype the window with production material early; we cover this pattern in our product development process and in past programs in the portfolio.