Re: [ambient-light] Security and Privacy considerations for ALS (#13)

I hope this is the best place to post this (I was referred from [this Chromium issue](https://bugs.chromium.org/p/chromium/issues/detail?id=606766#c96)). I see there has not been much activity here recently so please let me know if there is a better place to make these comments.

I work for [iProov](https://www.iproov.com) which allows users of banks and governments services to assert and confirm their identity using secure face-based authentication. We specialise in Genuine Presence Assurance so focus on ensuring that the user is a real, live, physically present person. We do this by using the screen of the device to illuminate their face with a unique sequence of colours whilst streaming a short video back to our servers. We analysis the way the light reflects off their face in real-time to ensure we are looking at a real, 3D, skin-covered human. We also check that the unique sequence of colours are correct to ensure the user is live and we are not seeing a previous authentication attempt being replayed. And we also do face verification so ensure that the correct person is presenting themselves.

Our current live deployments use iOS and Android SDKs embedded into our customers apps which gives us great control over the device's hardware. However, we are getting increasing requests to provide a browser solution which is a much more constrained environment. So, we have have developed a WebRTC version which is working well and nearly ready for live deployment but there is once specific issue we would like to address which is why I am posting here.

Our ability to determine the Genuine Presence of user is dependent on the ability to detect the light from the screen interacting with the user's face in the video. In direct sunlight, it is too bright to detect the reflections so we do not acquire enough evidence to correctly pass real users. In our native SDKs, we have full access to the device's hardware so we can make an accurate assessment of the ambient brightness and advise the user to find somewhere less bright to prevent them from starting in conditions where they are very likely to fail.

In a browser environment, we currently have no good way to make an assessment of the ambient brightness so cannot advice the user of their current lighting conditions which increases the failure rate and frustration for the user. So, having access to the data from the Ambient Light Sensor would be a great way solve this problem for our users!

I have read this thread and understand the potential privacy concerns. The current brightness limit for our solution to work is somewhere between 1500 and 2000 lux (depending on a few things like  screen size and brightness) so only having accuracy to the closest 50 lux would not be a big issue for us.

We are very encouraged by the potential of using this new API. What are the blockers for getting the Ambient Light Sensor data made available for everyone? I hope you find our use case compelling and maybe it will help justify the release of this feature. I would be very happy to provide more details or answer any specific questions if that would be helpful. If there is anything that we could do to help with the delivery of this feature, we would be very happy to contribute.

Thank you for your consideration.

-- 
GitHub Notification of comment by Joe-Palmer
Please view or discuss this issue at https://github.com/w3c/ambient-light/issues/13#issuecomment-496935850 using your GitHub account

Received on Wednesday, 29 May 2019 13:26:33 UTC