Let there be ambient light sensing, without data theft • The Register

Six years after web security and privacy concerns surfaced over ambient light sensors in mobile phones and laptops, browser boffins have finally put some defenses in place.

The W3C, everyone’s favorite web standards body, began formulating an Ambient Light Events API specification in 2012 to define how web browsers should handle ambient light sensor (ALS) data and events. Section 4 of the draft specification, “Security and Privacy Considerations“, was empty. It was a more carefree time.

Come 2015, the specification has evolved include recognition of the possibility that ALS may enable data correlation and device fingerprinting, to the detriment of individual privacy. And he suggested that browser makers might consider event rate throttling as a potential mitigation.

In 2016, it became clear that allowing web code to interact with device light sensors posed privacy and security risks beyond fingerprints. Dr. Lukasz Olejnik, an independent privacy researcher and consultant, explored the possibilities of a 2016 blog post.

Olejnik cited a number of ways ambient light sensor readings could be abused, including data leakage, profiling, behavioral analysis and various forms of communication between devices.

He described a few proof-of-concept attacks, designed with the help of security researcher Artur Jancin an article from 2017 and explored in more detail in an article 2020 [PDF].

“The attack we designed was a conceptually very simple side-channel leak, taking advantage of the optical properties of human skin and its reflective properties,” Olejnik explained in his paper.

“The reflectance of the skin represents only the 4-7% light emitted but modern display screens emit light with significant luminance. We leveraged these facts of nature to design an attack that reasoned about website content via information encoded in the light level and transmitted through the user’s skin, returning to the browsing context by tracking sensor readings. from light.”

It was this technique that enabled proof-of-concept attacks like steal web history by inferences made from CSS changes and steal cross-origin resourcessuch as images or iframe content.

snail speed

Browser vendors have responded in a variety of ways. In May 2018, with the release of Firefox 60, Mozilla moved access to the W3C proximity and ambient light APIs behind flags, and enforced other limitations in later versions of Firefox.

Simply apple refused to implement the API in WebKit, as well as a number of other features. Apple and Mozilla currently oppose a proposed generic sensor API.

Google took what Olejnik described in his post as a “more nuanced” approach, limit the accuracy of sensor data.

But those working on the W3C specification and on browsers implementing the specification have recognized that such privacy protections must be formalizedto increase the likelihood that the API will be widely adopted and used.

So that they vote make ALS data inaccuracy normative (standard for browsers) and require camera access authorization as part of the ALS specification.

These changes finally landed in ALS spec this week. As a result, Google and perhaps other browser makers may choose to make the ALS API available by default rather than hiding it behind a flag or ignoring it altogether. ®

Comments are closed.