5 ms·

Stealing Sensitive Browser Data with the W3C Ambient Light Sensor API

105 points by epaga 9y ago

epaga 9y ago
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 9y ago
  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 9y ago
    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.
    - amluto 9y ago
      Gyro is really nice for VR. But it should not be allowed in background tabs. No clue whether it is right now.
    - untog 9y ago
      Games can use all three of those very effectively. Agree they should be behind a permission prompt, though.
- rdslw 9y ago
  Part of the problem (the big one) lies here: "(filters in SVG work on cross-origin resources)" - without it, second attack (more serious) is not possible.
Mister_Snuggles 9y ago
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
- sumitgt 9y ago
  It's almost like someone came up with a solution, then tried really hard to find a set of problems.
  - Mister_Snuggles 9y ago
    The first and last use case definitely feel that way. A smart home system would probably use a proper light sensor so that it will work if your phone is in your pocket or face down or simply not open on the page that's controlling it. Of course, all of these issues apply to an app version as well. Controlling a character via gestures sounds like a job for the front-facing camera, not the light sensor.
- nfoz 9y ago
  > 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.
  - deleted 9y ago
    [deleted]
  - tyingq 9y ago
Animats 9y ago
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
- craftyguy 9y ago
  So (for Firefox) setting this in about:config should disable usage of the light sensor API (plus other sensors that could be also working against you), right? > device.sensors.enabled = false
- immutable_ai 9y ago
  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 9y ago
    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 9y ago
      > 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.
peterburkimsher 9y ago
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.org/stories/piezo/ https://web.archive.org/web/20050301010451/http://ipodlinux....

105 points by epaga 9y ago

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 9y ago
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 9y ago
  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.
  - amluto 9y ago
    Gyro is really nice for VR. But it should not be allowed in background tabs. No clue whether it is right now.
  - untog 9y ago
    Games can use all three of those very effectively. Agree they should be behind a permission prompt, though.
rdslw 9y ago
Part of the problem (the big one) lies here: "(filters in SVG work on cross-origin resources)" - without it, second attack (more serious) is not possible.

Mister_Snuggles 9y ago

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

sumitgt 9y ago
It's almost like someone came up with a solution, then tried really hard to find a set of problems.
- Mister_Snuggles 9y ago
  The first and last use case definitely feel that way. A smart home system would probably use a proper light sensor so that it will work if your phone is in your pocket or face down or simply not open on the page that's controlling it. Of course, all of these issues apply to an app version as well. Controlling a character via gestures sounds like a job for the front-facing camera, not the light sensor.
nfoz 9y ago
> 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.
- deleted 9y ago
  [deleted]
- tyingq 9y ago

Animats 9y ago

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

craftyguy 9y ago
So (for Firefox) setting this in about:config should disable usage of the light sensor API (plus other sensors that could be also working against you), right? > device.sensors.enabled = false
immutable_ai 9y ago
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 9y ago
  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 9y ago
    > 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.

peterburkimsher 9y ago

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.org/stories/piezo/ https://web.archive.org/web/20050301010451/http://ipodlinux....