
Stealing Sensitive Browser Data with the W3C Ambient Light Sensor API - epaga
https://blog.lukaszolejnik.com/stealing-sensitive-browser-data-with-the-w3c-ambient-light-sensor-api/
======
Mister_Snuggles
What was the purpose of exposing the Ambient Light Sensor to web pages in the
first place?

The W3C document[0] has a few suggestions:

> A Web application provides input for a smart home system to control
> lighting.

> A Web aplication checks whether light level at work space is sufficient.

> A Web application calculates settings for a camera with manual controls
> (apperture, shutter speed, ISO).

> A Web application monitors light level changes produced by hovering hand
> user gesture and interprets them to control a game character.

While these applications are all potentially valid, it seems like each use
case would be better served by a native app.

[0] [https://www.w3.org/TR/ambient-light/#usecases-
requirements](https://www.w3.org/TR/ambient-light/#usecases-requirements)

~~~
nfoz
> While these applications are all potentially valid, it seems like each use
> case would be better served by a native app.

That is the threat. They're pushing hard to keep the "open web" competitive
with native apps, so that the web is not abandoned as an app platform.

~~~
tyingq
Well said. I'm surprised this is the only comment focused on this. WASM fits
in that spot as well.

Eventually there's a point where the web platform is good enough that some
companies choose to sunset native apps.

Delivering the same functionality across 3 disparate platforms is a waste of
time and energy. Especially when the form factor in the end users hands is the
same.

I get why it's that way now, but the question will come up over time.
Especially for any app that needs live remote API calls to function.

~~~
pavement
The goal of keeping the open web “competitive” seems a little dubious,
however, considering who’s favor shall ultimately be competed for, no?

Offering up every last conduit one could possibly expose on a general purpose
platform, so that competing interests on the other side of the wire are all
fighting on a level playing field to harvest all the imaginable minutia of
every quiver of flesh (whether voluntary or reflexive) against a piece of
smartphone glass, in an effort to line pockets, starts to feel a little
obscene after a while.

And if any quarter should be given, the big bad companies will pack up their
wares and refuse to conduct business in the commons, leaving the web to
disintegrate and decompose back unto what geocities, myspace and aol used to
look like? Not sure that’d be so terrible, tbh.

~~~
nl
_The goal of keeping the open web “competitive” seems a little dubious,
however, considering who’s favor shall ultimately be competed for, no?_

No.

I like my ebook reader app to automatically adjust to the light. I'd like to
be able to build similar apps on the web platform.

I agree getting the security balance right is important though.

------
epaga
Such evil genius - and what is the solution? Yet another popup so sites can
ask for permission to access the ambient light sensor?

We're already past the point where the average consumer is confused by what
they are actually allowing when they click "Allow" for the various
permissions.

~~~
nobodyorother
The obvious solution is not having an ambient light sensor API, or a much more
granular one, like the battery API should've been.

~~~
0x00000000
Exactly. Same with vibration, accelerometer, and gyro. For me personally there
is zero reason why my browser should ever need these yet they can use them
without any permission on Android Chrome and they cannot be disabled without
rooting your phone.

~~~
untog
Games can use all three of those very effectively. Agree they should be behind
a permission prompt, though.

------
Animats
Mozilla response: ignore problem.[1]

    
    
        Component:▸ Security
        Importance: P3 normal
        Status: NEW
        Reported: 6 months ago
    

This wouldn't be hard to fix. Filter the signal down to about 0.5Hz, which is
comparable to how fast most displays auto-adjust for brightness.

[1]
[https://bugzilla.mozilla.org/show_bug.cgi?id=1357733](https://bugzilla.mozilla.org/show_bug.cgi?id=1357733)

~~~
immutable_ai
This "vulnerability" is extremely hypothetical and they have not given proof
that it can be exploited in the field. Just conjecture and a demo in a totally
unrealistic environment.

~~~
nathanaldensr
It's not hypothetical at all. Watch the demos; they clearly demonstrate data
being exfiltrated. Additionally, the article mentions several times that yes,
the bits/sec is quite low due to several factors. I don't think the author is
exaggerating the situation at all.

Would you rather wait for the API to go live and then be abused to steal real
data? I would much rather researchers discover and report on possible attack
vectors long before they are enabled by default. "Trust by default" long ago
proved foolish.

~~~
immutable_ai
> Although in our proof of concept demonstrations we rely on the assumption
> that the light conditions do not change during the exfiltration phase,
> extending the demos to handle these situations shouldn’t be a problem

They say themselves that their demo is not real world and wont work in the
real work and then say it "shouldn't be a problem" to make it work.

Not to mention that it takes 20 seconds of flashing the users screen to do the
thing (how is that supposed to work without setting off alarm bells).

As I said, they have no proof of a real world vulnerability, only proof it a
staged environment, and they readily admit it.

~~~
pdkl95
> they have no proof of a real world vulnerability

So what. This "default allow" attitude is easily more damaging than any other
source of security problems. You (or anyone else) cannot know all of the ways
exposing new data could be exploited, or might already be exploited in ways
that we are not _lucky_ enough to know about.

Caring about security - which includes the future unknown unknowns you don't
yet know to even look for - means minimizing what is exposed to the public
attack surface to what is both _needed_ (which does _not_ include anything
merely "wanted") and demonstrated/proven to have trivial risk with known
limits.

------
peterburkimsher
Actually extracting data this way sounds like the kind of hack that would gain
someone an impressive reputation as a hacker, instead of triggering serious
privacy risks.

Compare it to the iPodLinux project, when nilss extracted a bootloader using a
piezo buzzer. Yes, this type of hack can be done, but something tells me it's
not going to be a frequent worry.

[https://web.archive.org/web/20050301010451/http://ipodlinux....](https://web.archive.org/web/20050301010451/http://ipodlinux.org/stories/piezo/)

