The editorial frames this as an unprecedented scale of facial computer vision deployment — roughly 10-11 million new cars per year, each with a camera inferring on a human face for the vehicle's operational life. It argues the entire privacy guarantee rests on a regulatory attestation that data is processed locally and not stored, with no reference implementation, no EU-mandated conformance test suite, and paper-based type approval by national authorities.
By surfacing the AllAboutCookies explainer, this submission frames the DDAW requirement as a straightforward extension of the EU General Safety Regulation (2019/2144) — the same package that already mandated intelligent speed assistance and lane-keeping. The framing treats drowsiness detection as a natural next step in a stepwise, safety-driven regulatory arc rather than a novel surveillance push.
The editorial highlights that UN Regulation No. 159 and the Commission's delegated acts specify outcomes (detect eyes-off-road, microsleeps, prolonged gaze away) rather than prescriptive implementations. Because there is no reference implementation and no shipped-ECU conformance test suite that researchers can run, verification collapses into OEM self-attestation rubber-stamped by national type-approval authorities like KBA and UTAC.
As of July 7, 2026, every new passenger car type-approved for sale in the European Union must include a Driver Drowsiness and Attention Warning (DDAW) system. The requirement flows from the EU General Safety Regulation (2019/2144), the same package that already mandated intelligent speed assistance and lane-keeping. The 2024 deadline covered new *type approvals*; the July 2026 date closes the loop by covering every new car registration, not just new models. If it rolls off the lot with EU plates, it has eyes on the driver.
The technical spec is deliberately outcome-based rather than prescriptive. UN Regulation No. 159 (Driver Control Assistance Systems) and the Commission's delegated acts require the vehicle to detect degraded attention — eyes-off-road, microsleeps, prolonged gaze away from the forward scene — and issue an escalating warning. In practice, every OEM is converging on the same architecture: an infrared, near-IR camera in the steering column or A-pillar, feeding a small on-device neural net that tracks eyelid closure (PERCLOS), head pose, and gaze vector. The regulation says the data must be processed locally, cannot be transmitted off-vehicle, and cannot be stored beyond what's needed for the immediate warning function. That is the entire privacy guarantee.
There is no reference implementation. There is no EU-mandated conformance test suite that a security researcher can run against a shipped ECU. Type approval is handled by national authorities — KBA in Germany, UTAC in France — and the audit is largely on paper: the OEM attests, the authority stamps.
This is, quietly, the largest forced deployment of computer-vision-on-humans in consumer history. Roughly 10–11 million new cars are sold in the EU each year. Every one of them, starting now, ships with a camera pointed at a person's face, running inference every frame, for the entire operational life of the vehicle. Nothing at this scale exists in phones (opt-in), doorbells (opt-in), or workplaces (contested). Cars just crossed the line by regulatory fiat.
The interesting engineering question isn't whether the camera works — it's whether "processed locally, not stored" survives contact with the rest of the modern vehicle stack. A 2026 car is a rolling distributed system: infotainment SoC, ADAS domain controller, telematics modem, over-the-air update client, and an insurance-adjacent event data recorder, all sharing an internal bus. "Not stored" is doing a lot of work in that sentence. Does the drowsiness event get logged as a diagnostic trouble code? Does the OTA client have a debug mode that pulls a few seconds of frames for "quality improvement"? Does the insurance telematics profile ingest the attention score as a derived signal, even if the raw video never leaves the ECU? None of that is forbidden by the plain text of the regulation, and none of it is currently audited.
Compare this to how the industry treats iOS FaceID, which is functionally similar tech (IR camera, on-device model, biometric inference). Apple publishes a Secure Enclave threat model, a hardware-isolated processing pipeline, and a public security whitepaper. The EU DDAW rules require none of that. Volkswagen, Stellantis, BMW, and the Chinese entrants (BYD, MG) will each ship a different implementation, on different silicon, with different firmware update policies, and — critically — different definitions of what "processed locally" means when the ADAS DCU and the telematics modem sit on the same CAN segment. The community reaction on Hacker News (622 points, top of the front page) has been overwhelmingly skeptical, and the top comments zero in on exactly this: the regulation legislates an outcome, not a boundary.
There's also a model-drift problem nobody is talking about. A DDAW system trained in 2024 on European drivers has to keep classifying attention correctly in 2034 on the same hardware, without a cloud retraining loop, on faces it wasn't trained on (post-surgery, aging, sunglasses evolution, changing eyewear fashion). The regulation has no story for silent degradation. If your car's attention model quietly becomes 15% less accurate over five years, nobody notices until it either misses a real drowsiness event or, more likely, alarms so often the driver disables it — which the regulation permits per-trip.
If you work anywhere near automotive, in-cabin ML, or edge inference: the next two years are a hiring and integration wave. Every Tier 1 supplier — Bosch, Continental, Aptiv, Valeo, Magna — is staffing up on computer vision, model compression, and functional-safety-adjacent ML engineers. The interesting job is not the model; it's the secure enclave story around it. The OEMs that get this right will have a public threat model, a signed inference pipeline, and an attestation channel that lets a regulator (or a security researcher) verify that no frame ever left the ECU. The ones that get it wrong will have a Hacker News post in 2028 explaining how someone dumped the flash and found six months of face crops in a ring buffer.
For anyone building on-device inference — smart glasses, wearables, home robots, industrial cameras — the EU DDAW rules are now the de facto regulatory template you will be measured against. "Local processing, no storage, no transmission" is going to appear in RFPs, procurement contracts, and eventually in the AI Act's high-risk system guidance. Start writing that story now: publish your threat model, document your data lifecycle, and make sure your build reproducibility argument holds under adversarial review. If your architecture depends on "we promise the frames stay local," you're already behind.
And for the security research community: there are 27 national type approval authorities, each stamping a different OEM's implementation, with no coordinated adversarial testing regime. This is a target-rich environment. The first well-documented paper showing frame exfiltration via the telematics modem, or a firmware update quietly relaxing the on-device retention window, will define the second-generation regulation. The GSR revision cycle is already scheduled for 2028.
The camera is not the story. The camera is the excuse to have this conversation. What Europe just did — mandate a specific ML pipeline on a specific piece of hardware in every new consumer good in a category, and then decline to specify the trust boundary — is the template for the next decade of edge AI regulation. Whoever ships the first credibly auditable in-cabin ML stack, with a public threat model and reproducible build attestations, sets the standard everyone else has to match. Whoever ships the first breach defines what the AI Act's Article 26 enforcement actually looks like in practice. Both of those are engineering problems, and both of them are hiring right now.
All new cars.At this point I don't know if I'd buy anything made after 2008. Whenever I rent a new car around here (in the EU) I find them very annoying. The worst is the cruise control that tries to stick to the speed limit -- but its sensors don't always read the signs very well, so
Boeing found out the problem with "beeping" alarms.The first time they installed a warning horn, I think it was the stall warning, it was a big success. So, they started adding different horns for other situations. At one point, in an emergency, the pilot got confused about which horn mean
New cars are UX nightmares. I'm driving an electric Toyota bz4x. Lovely mechanics, but the general UX (some are because of Android Auto) is terrible. The remote's lock/unlock don't do anything when the car is on. Example: I'm by the trunk and it won't open unless I go b
Ford has had that since Blue Cruise 2.0, or thereabouts. It really shocked me how often it catches my attention being diverted. Things like talking to my passengers, adjusting the climate controls, or eating- I'm not even talking about 'advanced distractions' like my phone.It also see
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
I sometimes wonder how these systems are being tested on the road and whether there's any feedback from the test drivers, or what kind of morons are there saying "this is completely fine, exactly like intended" when they read the feedback...My car has adaptive cruise control and will