New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 642731 link

Starred by 4 users

Issue metadata

Status: Available
Owner: ----
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug

Sign in to add a comment

Round Off Ambient Light Sensor event.value

Reported by, Aug 31 2016

Issue description


Chrome is currently providing too verbose readout of Ambient Light illuminance. 

Providing too verbose, non-rounded illuminance values can potentially open unexpected issues related with fingerprinting, tracking and data leaks (possibly similarly to, but potentially more directly). It is also not necessary from a physical point of view.


Chrome Version: 54.0.2839.0 [dev]
Operating System: Nexus 5 (Android 6.0.1)


Enter a web site using AmbientLightSensor or devicelight events. Illuminance (event.value) readout is similar to the one below:

75.2131500244140625 lx  
435.8228149414062500 lx  
548.1655883789062500 lx  
13 lx 

It should be as follows:

75 lx  
435 lx  
548 lx  
13 lx 


Comment 1 by, Aug 31 2016

Labels: -Pri-3 M-54 Pri-1
Status: Assigned (was: Untriaged)
Let's not repeat the issues we had with the battery. Tim can you please take care of this?

Status: Started (was: Assigned)
Labels: OS-All

Comment 4 by, Mar 17 2017

Chris suggested today limiting light sensor to 1Hz and 2-bit read outs to generally reduce privacy risk, given the use cases.

I think that might be going a little too far, and would counter-propose 4-bit read outs and 10Hz as a compromise that would allow sites to respond to changes without appearing to lag, and to be moderately sensitive to light level changes without trying to understand the difference between 435 and 434 etc as we would even after implementing the rounding suggested here.

Also can I confirm that this issue is filed for the currently behind-a-flag light sensors to be exposed via the generic sensor spec? I wasn't aware we already expose light sensors if we do!

Comment 5 by, Mar 19 2017

uploaded a patch to address the rounding issue:
Project Member

Comment 7 by, Apr 20 2017

The following revision refers to this bug:

commit 4ce63dcc9eee16f803df5ef92d29a7c23bdb32c7
Author: timvolodine <>
Date: Thu Apr 20 02:20:21 2017

[DeviceLight] Ensure to round lux value to avoid fingerprinting risk.

Make sure to only expose rounded lux values to JavaScript in order
to decrease fingerprinting risk. This also ensures less frequent
updates in case the lux value is of high precision.


Cr-Commit-Position: refs/heads/master@{#465865}


Comment 8 by, Apr 20 2017

Labels: Security
As noted on the CL, we need to reduce the precision in a more meaningful way. See also:
FYI DeviceLight implementation has been recently removed from chrome:

no sensor - no cry )

Status: Fixed (was: Started)
Fine ;)

Just don't forget about Ambient Light Sensors. Though last time I checked - it's rounding fine?
Status: Available (was: Fixed)
Actually yes there is the Ambient Light Sensor in the context of generic sensors API. So I am going to reopen this issue.

To summarize discussion on the patch (

battre@: expressed concern that night lux value could be something like 0.01 lux in which case simple rounding may not the best option. He mentioned logarithmic scale that is divided into N steps. Or having a percentage value 0% - 100%.

palmer@: reduce to 4 bits of precision or so.

Please correct me if I gave a wrong interpretation.

Labels: -M-54 M-60
Owner: ----
Adding generic sensor people:
+Mikhail, Alexander


Comment 14 Deleted

Comment 15 Deleted

Just how frequently does one make a stable read of 0.01 lux? 
And what's the (physical) significant difference between 0 and 1? 
What would be the use case requiring to distinguish between 0.01 and 0.1?


There are some use-cases documented at As of right now, it says:

1. A Web application gradually updates document style based on light level changes.
2. A Web application provides input for a smart home system to control lighting.
3. A Web aplication checks whether light level at work space is sufficient, based on occupational health regulations.
4. A Web application monitors light level changes produced by hovering hand user gesture and interprets them to control a game character.
5. A Web application calculates settings for a camera with manual controls (apperture, shutter speed, ISO).

The mentioned use cases require plain light level data, not a pre-defined set of values.

Of these, it *seems* to me (I'm no expert here):

(1) and (2) needs 2 or 3 bits of precision (4 or 8 distinct levels)

(3) might need 3 or 4 bits?

(3), (4), and (5) might be better served by just using the actual camera

So, if I understand correctly, we can advise developers who need more than, say, 3 or 4 bits of precision (8 - 16 distinct levels) to just request use of the camera with getUserMedia. Use-case (5) will be doing that anyway, and using the camera's input to calculate exposure settings will enable features like what iOS' camera has, in which you can tell it to calibrate based on a particular region of the image. Which is a nice feature that ALS could likely not provide.

So, I'm sticking to my recommendation to provide, at most (preferably less), 4 bits of precision, and to not require a user prompt/permission for that degree of precision.

It seems to me that applications whose developers are comfortable asking for a permission might as well go all the way and get camera permission. That's likely a clearer message to the user, too.

I'm planning to test ALS using multiple devices / sensors in more or less controlled environment, so that we can understand what would be the best resolution / rounding threshold. It might help us to solve this issue. I tried to kick-off discussion here , will report back early next week with my findings.


So it seems that (5) might be a questionable use case in the spec as well. 

As for quantization, there is an ongoing discussion to provide permisson-prompt access to the powerful ALS (full spectrum) and offer a reduced-precision readout via a different API. 

Another option is to expose permissions in more creative ways than just prompting all the time.
> So it seems that (5) might be a questionable use case in the spec as well. 
lukasz.w3c@ I'm not sure how this conclusion is derived. For me, it is pretty valid use case, many native apps. I tested few devices with 'good' ALS sensors against Sekonic meter and they definitely can be used for EV measurements.

Pardon my comment. The use case is not questionable - it is valid. But perhaps as palmer@ suggested - this particular use may be addressed by simply using a camera, instead of ALS?
lukasz.w3c@ Yes, camera can be used, but it would require lots of effort. User would need to disable all camera processing, know base ISO of the sensor and take into account many other factors. In similar fashion, someone could implement motion sensors, by analyzing movements in the video stream. Doable, but not efficient.

We are researching what requirements can be derived from common use-cases and will report when we have more information.
Hi folks,

Intel's one of my clients, not my employer, so I don't have an Intel email address and just found out I was copied on this because the issue was mentioned elsewhere.

I've raised a number of issues against those use-cases but these weren't considered before the pull request was merged.

I won't repeat them here, you can have a look at them in the pull request itself:

Overall, I think liaising with the CSS WG to discuss the light-level mediaquery would be very much worthwhile, as this seems to be one of the less niche use case for ALS.

Their granularity requirement was much smaller: an enum with 3 values.
I read light-level discussion in

Unfortunately I could not find technical details about how light levels are mapped to real world values, moreover, use-cases for 3 light levels are not well thought. For example, web page should not blindly change it's contrast without knowing what display technology is used, e.g. E-Ink vs TFT LCD.

Mapping is also tricky, bright sunlight conditions could be 100000 lux, sunny day in shade 20000 lux, overcast midday 1000-2000 lux, office 300-600 lux, home 80-300 lux. In addition to that, sensors provide different measuring ranges, thus, it would be even more difficult to define dim, normal, bright levels. Anyways, that is up to CSS WG to figure out.
Status: Assigned (was: Available)
palmer@ I made few measurements, with equipment / devices that I could find around :D

Could you provide feedback when you have time. Thanks.
Owner: ----
Status: Available (was: Assigned)
Components: Blink>Sensor
Labels: Type-Bug

Sign in to add a comment