What is this all about?
In short, this is a story about the ability of a website to include code which enables it to retrieve from a site visitor’s browser the amount of charge left in their device’s battery, and the rate at which this is discharging.
This is not a malfunction or a hack, but functionality implemented within HTML5 to enable web site operators to be more responsive to the needs of their visitors.
If, for example, the website has a variety of video streams which it can offer, with some placing greater demands on the visitor’s device than others, the site might choose to use the best quality video if the device has a lot of charge, and scale it down as the device’s battery life drops, to eke out the battery for as long as possible. Similarly, a website operator could try to reduce their site’s impact on a device’s backlight, by changing the colour of the background.
For a very basic demonstration of the HTML5 battery API, visit:
https://external.neilzone.co.uk/battery
using a browser which supports the API (ie not an iPhone). Neil promises not to track you!
So what was the problem?
Researchers have published a report (http://eprint.iacr.org/2015/616.pdf) — entitled ‘The leaking battery: A privacy analysis of the HTML5 Battery Status API’ — indicating that, because of the granularity of the information which can be retrieved through the API, it is possible to use this as a mechanism for tracking users, offering a degree of persistency of tracking even if the visitor makes use of ‘private browsing’ mode or wipes cookies from their device, if the consecutive visits are made within a short-time period.
The report identified a vulnerability in the implementation of the API in the Linux version of Mozilla’s Firefox browser, due to the higher level of precision of battery level readings obtained by the browser when running on Linux, as compared with other operating systems. The researchers provided their findings to Mozilla and a fix was deployed in June 2015.
A key part of the problem identified was that this could be done without user awareness, let alone user consent — section four of the API specification says that ‘[t]he information disclosed has minimal impact on privacy or fingerprinting, and therefore is exposed without permission grants’.
What’s the legal position?
Although there has been a lot of press coverage of this story, and it has made the mainstream media, there is nothing obviously special about it from a legal perspective: the basic principles about user tracking apply here.
Data Protection Act 1998
If a website uses the API as a form of tracking, or to supplement existing tracking mechanisms, it is highly likely that the data protection regime will apply, as tracking implies the identification of individuals. In this case, the website operator will need to comply with the eight data protection principles, including that their processing is fair and lawful.
A key aspect of fairness of processing is transparency, ensuring that users are aware of the processing which a controller is undertaking in respect of their personal data. Silent use on the API by a site operator is hard to reconcile with this duty.
A second core requirement is that a controller will need to satisfy one of the bases in sch 2 to the Data Protection Act 1998, and the most obvious of these are either consent, or reliance on the ‘legitimate interests’ basis.
Consent (in the genuine, some might argue only true, meaning of the term) would be the usual port of call, with the user having exercised a free choice over whether the user wants the processing to happen or not.
Where the battery API was used for something related to site security, or to facilitate the user’s interactions with the site, reliance on the ‘legitimate interests’ basis may be reasonable, although this does not negate the need for transparency.
Privacy and Electronic Communications Regulations 2003 (‘PECR’)
It is likely that the use of the battery API falls within the ‘cookie law’: Article 5(3) of Directive 2002/58/EC. As implemented in the UK through reg 6 of the Privacy and Electronic Communications Regulations 2003, using an electronic communications network to gain access to information stored in the terminal equipment of a subscriber or user is subject to controls.
Drafted with cookies in mind — text files stored on the user’s device — it is questionable whether, strictly, use of the battery API falls within this definition. The battery information is certainly retrieved from the device, but there might be a nuanced argument that the API queries the battery’s status in real time, rather than retrieving information which is ‘stored’ in the device.
However, such an outcome is hardly consistent with the purpose of the limitation, and arguing in this manner is unlikely to please the relevant regulator (in the UK, the ICO). Similarly, although the language of the Directive itself is one of storage, recital 24 talks in far broader terms (as does the explanatory note to the 2003 Regulations), referring simply to ‘gaining access to information’. It is hard to see why, from the perspective of privacy, there should be a difference in protection between querying information stored in a file on the device and querying information by asking for it directly from the device’s battery system.
In any case, even if the activity does fall within reg 6, notwithstanding the general requirement under this provision that a user must consent to the retrieval of information stored on a device, there is an exception for retrieval which is ‘strictly necessary’ for the provision of an information society service. It could be argued that such ‘access to [battery] information’, if indeed that is what it is, was strictly necessary for the provision of the website to the user in either a high performance or energy efficient mode under reg (6)(4)(b) of PECR, and therefore consent need not be obtained from the user in this instance. We suspect that this would be a difficult argument to sustain, given that ‘strictly necessary’ is a high threshold: a website is unlikely to be inoperable without recourse to this API, and, even if a site operator were concerned about battery, they could resort to a ‘low power’ version of the site by default, only reverting to the ‘high power’ version where the user positively agrees to this.
Misuse of private information
It is not unforeseeable that a case could be brought that acquiring a user’s device’s information in a surreptitious manner, for purposes which are not shared with the user, is a misuse of their private information. Given the nascent nature of the tort, and its ongoing common-law evolution, perhaps this is a particular area to consider for the future, potentially providing a remedy where it is difficult to bring a claim on a more formal statutory basis.
What about criminal sanctions?
As mentioned, the authors of the report noted numerous privacy concerns, including where third-party scripts — present across numerous websites — link a user’s visits (even when using VPNs or browser privacy settings on a first visit), and then reinstate cookies and client side identifiers (respawning). Computer access offences, and data interference offences, could potentially apply in this situation; a number of international instruments (for example, the Council of Europe’s Convention on Cybercrime, and Directive 2013/40/EU on Attacks against information systems) require countries to implement computer access offences, and the basic access offence in the UK is found in s 1 of the Computer Misuse Act 1990.
At the heart of these offences are concepts of authorisation (or ‘with right’), but these terms have confounded courts on both sides of the Atlantic. Whether a web server which runs code which queries a visitor’s battery level is ‘without right/authorisation’ is an interesting point, harking back to the age-old issue of whether ‘right’ refers to a legal notion of permission, or the circumvention of a code-based restriction.
In the US context, some State courts have been wary of interpreting the concept of authorisation too widely. For example, courts have overturned criminal convictions that turned on the breach of the terms of service of a social networking site (US v Lori Drew 259 F.R.D. 449 (C.D. Cal. 2009)) or a company’s computer-use policy (US v David Nosal 676 F.3d 854 (9th Cir. 2012)).
Some developments in the EU also point towards a narrowing of illegal access offences (for example, the insertion of the words ‘by infringing a security measure’ in Article 3 of Directive 2013/40/EU). Often, this debate is thought of only in relation to the risk of over-criminalisation of end-users (eg if they do not read all the T&Cs of websites), but this development highlights the other side of the coin: the risk of criminal liability if the terms of service of websites, or browsers, do not spell out the extent of their activities on the client-side.
However, the legal situation remains murky in many countries (including the UK), and depending on how the battery API is used/abused, criminal liability could apply, either in the form of charges under s 1 or s 3 of the Computer Misuse Act 1990, or offences such as the offence under s 55 of the Data Protection Act 1998.
In reality, it is unlikely that criminal sanctions would be deployed in this situation —’sledgehammer’ and ‘walnut’ spring to mind — although, if they were, it would undoubtedly offer greater incentives for compliance.
Enforcement
Where a site operator is located within Europe, a European privacy regulator is unlikely to have problems enforcing the legislative framework in the case of abuse of the API.
However, for sites located outside Europe, taking action is likely to be more difficult, even if, by virtue of tracking European users, the law does, technically, apply. Where a controller has a subsidiary in Europe, even if the subsidiary is not directly involved in the processing activity, a regulator may have a suitable target for enforcement action, as was the situation in Google Spain. For operators with no European presence, enforcement is unlikely to be straightforward under the current framework.
The impending General Data Protection Regulation (GDPR), as currently drafted, will potentially broaden the territorial scope of European regulation as it will apply to controllers who are not based in the EU but who are using processors in the EU to track — ie processing personal data of European users — as well as seeking to expand the territorial scope of EU data protection law more generally.
The GDPR is currently going through ‘trilogue’ discussions between the European Parliament, the Council of Ministers and the European Commission with the aim of reaching a common position by the end of this year; we will have to wait a little longer to find out how far this regulation will stretch.
What could be done?
Users
Mozilla has already acted to mitigate the issue reported, so there does not appear to be any particular need to take action on this issue.
Further, some browsers enable this facility to be switched off. Firefox, for example, has a function within its about:config preferences system for disabling this query, by changing the flag for dom.battery.enabled to false. Perhaps we will quickly see a more user-friendly means to achieve this, since only relatively advanced users are likely to be poking about with preferences in that way.
Looking more broadly, it is unclear whether, in reality, there is anything which a user could do to protect themselves against a future, similar, vulnerability: this is not a situation in which a piece of software from a questionable vendor posed a threat, or malware was embedded in software obtained without licence through a file-sharing network, but a bug in the implementation of a standardised API.
Site operators
Good privacy practices are key: transparency and consent where necessary. This could enable some slick functionality to be offered.
The ICO is currently consulting on its code of practice on privacy notices, recognising that the practice of sticking lengthy privacy policies on websites may not, in reality, be effective in informing users about the site’s processing of users’ personal data.
A privacy-by-design approach would combine both transparency with control: if, for example, a site’s use of the battery API means that it is able to offer slick new functionality, there is a logical opportunity to tell site users about this, and give them the choice of enabling it or not. A ‘just in time’ privacy notice or one-time pop-up as the only means of transparency or control is unlikely to be sufficient, as the user needs to be able to find more information on privacy choices easily at any point when using such sites, and alter choices accordingly. Ideally, the need for such controls would be picked up when (perhaps if?) the site operator performs a privacy impact assessment on their new functionality — another area which the GDPR may formalise.
The API itself
From a privacy-by-design perspective, it seems that the World Wide Web Consortium should re-evaluate whether the API is, in itself, appropriate to retain.
Some may argue that a web server should not have access to this kind of information from a device, and that incorporation of functionalities such as this within the standard for HTML is a step too far. Conversely, more battery-efficient websites are likely to be welcomed by those who find that their smartphone battery drains far too quickly.
If it is to be retained, the authors of ‘The leaking battery’ argue that consideration should be given as to whether it needs to be so granular in nature. Would the utility of the API remain useful if, for example, the browser converted the remaining battery life to the nearest 5% before sending it to the server?
There are also broader questions around reliance on consent: should it be up to the API authors to determine that user consent is not required, or should it be left to the individuals to determine to what, if anything, they wish to give permission?
One might also question whether the average user would even care if websites use this API to adapt the content to avoid draining dwindling battery reserves? Adaptive websites can already detect when users are using a mobile device — by querying information from the device as well as from information sent by the device to the web server — and will display a mobile version of the site accordingly. Does a site which reacts to the user’s battery state merely benefit the user even further?
Conclusion
There is growing awareness and understanding, and to some extent acceptance, by the general public that their activity online can be and will be tracked.
The issues that came out of the report are new iterations of familiar issues, namely of privacy and consent. There will always be new ways that developers can use data to identify and track users. The key issue is one of transparency and trust: users are generally willing to be tracked — to some degree, at least — if they can see a tangible benefit, which, in this instance, may be not having their battery drained by a content rich website.
Transparency can only be achieved by clearly informing a user of what information is being collected and to what ends. This very point, on which the ICO is currently consulting, can only be achieved by effective and ‘smart’ privacy notices coupled with even greater consideration of privacy issues at the design and development stage of new technologies.
Until then, running out of battery and thus being unable to browse the web may well be the safest option…
The issues of intermediary liability and responsibility for websites deploying this kind of technology will be considered at the upcoming conference on internet intermediaries at the University of Southampton on17-18 September 2015. Panels will deal with everything from intermediaries‘ security obligations, to their roles in preventing infringement, and their defences and immunities. More information is available at http://www.iclicconference.co.uk/
Neil Brown is a senior telecoms and technology lawyer at a global communications company and a director of the United Kingdom Telecommunications Academy. He is a member of the Institute of Law and the Web at the University of Southampton, and is a member of the Law Society’s Technology and Law Reference Group.
Rebecca Collard is an associate in the Technology, Media & Entertainment Group at Harbottle & Lewis LLP, who specialises in disruptive technology and advises on a broad range of commercial and intellectual property matters, including data protection and privacy.
Micheál Ó Floinn is a lecturer in Cyber Security Law at the University of Southampton, and a barrister (Inner Temple, non-practising).
