Security and privacy considerations for Ambient Light Events

[lknik]

There is a need to address security and privacy concerns for Ambient Light Sensor. I will do so.
I will do so, starting with my report as a blueprint (http://lukaszolejnik.com/SensorsPrivacyReport.pdf, need to be slightly rewritten and adapted).

[anssiko]

Thanks, that'd be great. As you probably noticed, the spec was recently updated (and renamed to Ambient Light Sensor in the process), so you should be reviewing https://w3c.github.io/ambient-light/

You can either submit a pull request with the proposed text for the security and privacy considerations against the latest spec, or provide the text in this issue to be integrated by the spec editors.

[schwittmann]

I strongly agree that privacy is an issue in the Ambient Light Sensor API. Besides the threats discussed in the report I'd like to point out an additional example of information leakage: a malicious website can identify videos or TV channels playing in the user's proximity. This works since light emitted by a screen causes measurable changes in a room's ambient light. We recently published a paper at PerCom2016 describing and evaluating this method. You can find a preprint at https://vs.uni-due.de/schwittmann/2016_Schwittmann_Video_Recognition_using_Ambient_Light_Sensors.pdf

We also analyzed possible countermeasures. As suggested in the report, we have shown that discretizing sensor readings has a significant impact. Limiting illuminance readings to steps of 6 lx made video recognition impossible in our scenario.

[lknik]

Hi,

Thank you for your input. I will analyze the document, looking at the technical feasibility/etc. also versus mobile and web use pattern characteristics.

Definitely this is a nice addition to the (marked by myself as far-fetched) example I discuss in the report.
I will also include this work in the updated report. Is there any BibTeX entry you would suggest to use?

[schwittmann]

Hi,
indexing at ieeexplore is pending, so there is no final BibTeX entry yet. However, we compiled the information we have in this file: https://vs.uni-due.de/schwittmann/2016_Schwittmann_Video_Recognition_using_Ambient_Light_Sensors.bib

[tobie]

One of the strategies I've been thinking about to mitigate such risks was to incentive developers to use coarser sensor readings (e.g. for the case of ambient light, picked up on the CSS light level media-query, so one of "dim", "normal", or "washed") by making those available without prompting.

I'd be interested to have your thoughts on this proposal for sensors in general and the risk it might cause (notably by making fingerprinting easier).

[lknik]

Hi,

This was actually being discussed in my report already, and I suggested to minimize this. I will stress it more that there is an option to use the same terms expressing light levels, even (like in media-query).

Was there any use case that would require the (current) very verbose ambient light sensors data?

[tobie]

This was actually being discussed in my report already, and I suggested to minimize this. I will stress it more that there is an option to use the same terms expressing light levels, even (like in media-query).

Yeah. My suggestion is to split this up into LightLevel ("dim", "normal", or "washed") that matches the CSS light-level MQ and requires no permission and a low-level, AmbientLightSensor, which has more fine grained data and requires user permission.

Was there any use case that would require the (current) very verbose ambient light sensors data?

The idea of the extensible Web manifesto, is to give low-level access, security/privacy permitting and see what developers use it for. Then eventually standardize higher-level APIs and incentivize developers to use those.

[chaals]

Yeah. My suggestion is to split this up into LightLevel ("dim", "normal", or "washed") that matches the CSS light-level MQ and requires no permission

Hmm. So the issue with "lifestyle" tracking would still hold here, since what achieves that is long-term sampling that doesn't need to be very frequent.

[lknik]

Yeah. My suggestion is to split this up into LightLevel ("dim", "normal", or "washed") that matches the CSS light-level MQ and requires no permission and a low-level, AmbientLightSensor, which has more fine grained data and requires user permission.

This sounds reasonable, as MQ already provides this functionality. What will remain is the frequency of changes, which will depend on the hardware, implementation and the environment.

The idea of the extensible Web manifesto, is to give low-level access, security/privacy permitting and see what developers use it for. Then eventually standardize higher-level APIs and incentivize developers to use those.

Understood. So permissions for high-level readout (as we discussed OOB). Is it possible to disable this functionality at all, or suggest browser vendors to allow this (using settings)?
And at some point, the raw readout could be phased out?

[tobie]

@chaals:

Hmm. So the issue with "lifestyle" tracking would still hold here, since what achieves that is long-term sampling that doesn't need to be very frequent.

Well, if CSS gives it to you as an MQ, writing JS that allows you to track it is trivial.

[lknik]

Hmm. So the issue with "lifestyle" tracking would still hold here, since what achieves that is long-term sampling that doesn't need to be very frequent.

That is correct. That, and also e.g. out-of-band device communication (one flashes screen, other reads) also included.
But this is (somewhat) already provided by MQ. Just my assumption it might be slightly easier to retrieve it using the API.

In reality ambient light sensors sound very sensitive, possibly even the most sensitive API, with "rich" use cases.

[tobie]

@lknik:

This sounds reasonable, as MQ already provides this functionality.

Yes, my suggestion was based on this information already being available to the platform without permission. This assumption needs to be revisited if the MQ is rejected due to privacy concerns.

What will remain is the frequency of changes, which will depend on the hardware, implementation and the environment.

Yup. The MQ and LightLevel sensor should match precisely here. The coarser AmbientLight would do a thing of its own.

Understood. So permissions for high-level readout (as we discussed OOB). Is it possible to disable this functionality at all, or suggest browser vendors to allow this (using settings)?

Yeah, you could imagine a privacy aware browser would implement only the LightLevel API but the not AmbientLightSensor.

And at some point, the raw readout could be phased out?

Doubtful but possible.

[chaals]

Well, if CSS gives it to you as an MQ, writing JS that allows you to track it is trivial.

Sure. Which leads to a conclusion that this spec isn't the only one that should consider the privacy concerns around the information available… (among other conclusions).

FWIW I think it makes sense that the two specs should have a matching set of values :)

[fhirsch]

Right, seems to be a common set of issues across various sensor specs. Also need to ask what has been learned from WebRTC

[anssiko]

This issue is superseded by issue #13 that has a proposed fix #33.

[lknik]

@anssiko @riju

Resurrecting the issue because a new Science paper vindicates/confirms the privacy considerations that we have: https://www.science.org/doi/10.1126/sciadv.adj3608 (basically restated what we have now). Perhaps it's worth to add this to avoid an accident of forgetting of the stuff in the future?

[chaals]

@lknik do you mean to add a reference to the spec, or add an explanation, or...?

[lknik]

@chaals Yes, I meant: add a reference to the spec.

[chaals]

Sounds good to me...

[fhirsch]

I agree that adding a reference makes sense. thanks, Frederick Frederick Hirsch

…

On 19 Jan 2024, at 9:36, chaals wrote: Sounds good to me... -- Reply to this email directly or view it on GitHub: #8 (comment) You are receiving this because you commented. Message ID: ***@***.***>

[anssiko]

@lknik thanks for keeping track of the latest developments in this space. This is a well written paper on the topic. PR #90 staged for review.