This post is built around my paper (presented to/at the International Workshop on Privacy Engineering) devoted to privacy assessment in web standards. After the previous one (Battery Status Not Included: Assessing Privacy in W3C Web Standards) this is the next insight in this domain. While I point out the security and privacy risks, the focus is put around a case study in web standardization design. In this case, it’s closer to “how Privacy by Design may work” rather than “new type of vulnerability”. This work has had a positive impact on the specification and implementations.

• web standard is fortunately amended to be better
• Firefox browser removed its obsolete implementation based on events, and apparently is not implementing the Ambient Light Sensor due to privacy,
• WebKit/Safari is not implementing the Ambient Light Sensor due to privacy (and also put the API on the no-go list)
• Chrome browser is moving forward with an implementation that applies specific strategies: the sensor readout is made less precise and with lower frequency (minimization strategy: for example rounding off the readout precision of the sensor to the nearest multiplication of 50)
• The Consultative Committee of the Council of Europe’s Convention for the protection of individuals with regard to automatic processing of personal data were happy to hear about some of the risks of modern web features
  
  

The research paper is a case study in privacy engineering and privacy impact assessment. How did it unfold?

Ambient light sensors in your devices and privacy

Smartphones and some notebooks are equipped with light sensors. They may improve some usability aspects, including energy efficiency. The W3C Ambient Light Sensor API  enable the web browser to take advantage of this device's capability to access lighting conditions in the user environment, similarly to what mobile applications can do.

Light sensors in smartphones may introduce some privacy implications. Previously I pointed to the risk of leaks and profiling (Privacy analysis of Ambient Light Sensors, Additional security and privacy risks of light sensors).
Furthermore, a case of data theft risk (i.e. list of visited sites, banking PIN across browsing contexts, etc.) from the web browsers has been shown (Stealing sensitive browser data with the W3C Ambient Light Sensor API). This particular attack was a demonstration of a rather unconsidered, unforeseen, and unexpected risk, ultimately demonstrating a bypass of the fundamental web security and privacy model.

Ambient Light Sensor Privacy Story

This privacy assessment campaign/journey is a long-term one. It started as soon as in 2016. This story contains plenty of discussions, as well as tests and demonstrations. I can summarise it with:

• Some initial plans to implement/standardize the feature.
• Security/privacy issues pointed out; more or less moving forward and documenting the issues.
• In 2017 some developers suggest the desire of removing the web browser permission prompt (asking the user to use the light sensor was the initial plan), making it available to all the websites without user interaction or knowledge. Is that okay?
• Not really. We show the demonstration of stealing data with a light sensor.
• The case moves on with interesting twists (skipped!).
• Some impact as of today: (1) the standard is updated, (2) two browser vendors apparently not shipping the feature, (3) one browser vendor sanitizing the sensor read, implementing the security/privacy recommendations in the updated standard.
  
  

Is this the end? I don’t think so but it’s the right time to summarise some of this work, which I do here. I would also like to extract some Big Picture takeaways from this journey, as I did previously.

The Lessons Learned

Viewing risk in a broad sense

We all know that web risks often emerge from the “standard business” issues (i.e. cross-site scripting, cross-origin interactions, etc.). So these well-known issues may be the lens through which new features are looked through, after all, the complexity of the web only increases. But certain cases may merit from an out-of-the-box approach. As a side note (and honestly), who would even seriously expect data leaks happening via the light sensor? But that's the way the Web works.

Role of demonstrations to show a clear-cut case to spur the discussion

In the domain of security engineering, the role of proof of concepts is well known. It certainly frames  the discussion in objective terms, and occasionally some complain that this is lacking when discussing privacy issues.

In security engineering, but nowadays even in the case of privacy technologies, the demand to “demonstrate the problem” may even to some degree contribute to questioning whether  risks exists at all - until someone actually demonstrates any (we should try to avoid this pitfall; this may also probably not be well suited to all aspects of privacy risks).

While this is a big topic, there is no question that the actual demonstration of risks is helpful and that we often lack credible and sensible demonstrations of privacy risks. Specifically, in the case of security and privacy risks of the light sensor, a working demonstration of the concept helped to frame the discussion well, and in the end helped the cause (sometimes you may show this in different ways, like when explaining that processing of web browser histories carry a privacy footprint).

However, we should in the end accept that it might not always be possible to craft such a universal, crisp, and demonstrable problem point.

Interactions between research, standardization, developers

Unsurprisingly, the researchers and folks in in the standardization and development circles tend to stick to their own fora. But sometimes a dose of interaction is very useful to exchange ideas and actually transfer them into practice (for example Blink, the Chrome browser engine, is closely linked to the W3C review process, which already helps). Standardization fora (such as the W3C) may be helpful here, including their demand to have a consensus-driven decision making, which means that sufficient time should in principle be devoted to decision making

Risk-benefit considerations for new features

Such an analysis warrants asking a few questions. Is taking risks to extend the functionality worth it? What are the risks in the first place? What do we gain/lose? If the feature does not bring benefits, why do we want to implement it? Was a proportionality assessment (risk/benefit analysis) made? If so, in what ways was the outcome transferred to the design & development phase?

Summary

The net result is that a web feature received a really solid security and privacy assessment (including a demonstration), with some concrete impact on the decisions made on the level of standardization and implementers (web browsers). For the benefit of all.
Each sensitive or potentially sensitive feature should always undergo both security and privacy review/assessment, on a standard basis. While I agree that designing, architecting or re-architecting systems is sometimes tricky (and may be time and resource consuming), this is also where the interesting challenges (and fun) is.  Indeed, architecting systems with Privacy by Design can be challenging but it is also fun. Lastly, when things are analysed and well designed, we are always in a better place.

It’s my small contribution in the buildup of insight of Privacy by Design theory & practice ;-)

Did you like the assessment and analysis? Any questions, comments, complaints or maybe even offers? Feel free to reach out: me@lukaszolejnik.com