The Bot That Cried Wolf: Battery tracking poses no real privacy threat

If we worry about every possible privacy invasion, we will end up not paying enough attention to the ones that really need to be addressed.

IT's relationship with privacy is delicate. Corporate IT needs to take privacy fears very seriously, but if IT jumps and shouts at every tiny possible privacy invasion, we'll have the Bot That Cried Wolf. Put another way, the best way to weaken privacy protections is to embrace so many privacy problems that none have any significance.

Am I suggesting that manufactured privacy issues are obscuring real ones? Absolutely. For proof, one needs look no further than last week's battery brouhaha from a report that noted that websites can track people based on their batteries, skirting opt-in privacy rules that allow battery strength reports to be shared without site visitor permission. For those who bother to read the full report, its details do a wonderful job of establishing that if a site manager wants to invade someone's privacy, that manager could do far better than peeking at energy levels.

The researchers' argument is that battery levels -- both current power levels and battery capacity -- are being reported so precisely that it would function as a poor admin's cookie, albeit an unerasable cookie. The problem is that, in this situation, precision cuts both ways. A tracking system needs to have a static element, so that the user can be recognized the next time the user shows up, even anonymously. But given that battery levels change constantly, it will often not work. The researchers counter that this could be useful in a very short time frame. Possibly, but even so, it would sharply limit how valuable a tracking mechanism it is.

Also, this tactic does not consistently work, the researchers found, across all operating systems nor for all browsers. I tend to worry about privacy threats. On this one, I feel positively Zen-like.

How precise did those readings prove to be? In one instance, bizarrely precise. "In our exploratory survey of the Battery Status API implementations, we observed that the battery level reported by the Firefox browser on GNU/Linux was presented to Web scripts with double precision. An example battery level value observed in our study was 0:9301929625425652," the report said, adding that such ludicrous precision was not the norm: "We found that on Windows, Mac OS X and Android, the battery level reported by Firefox has just two significant digits."

To be clear, there is almost no room here for extrapolating patterns and projecting where a particular user's numbers will be, for example, an hour from now. Is the user plugged into a wall outlet or a different source of consistent power? Will the user turn off Wi-Fi and shut down the machine -- or stream an hour of video?

The report says, for example, "we can also assume that users seeing a near-drained battery generally connect their notebooks to AC power." First, having a phone or laptop battery that is nearly drained is not the same as having a user notice it. Who is to say what "nearly-drained" is? Just as different car drivers interpret an "almost-empty tank" differently -- I drive my wife crazy because I don't consider getting gas to be urgent until the empty tank light has been on for at least 10 miles, whereas she considers it mandatory at one-quarter full -- so do people react to low batteries differently.

Also, is the user perhaps in a crowded airport or in a car or somewhere else where plugging in is not practical?

But can it be used to identify site visitors in a very short time frame? The time frame suggested in the report was 30 seconds. How many site visitors do you guess your site has who visit, leave and then return 30 seconds later? How valuable is a technique that will positively identify only a small percentage of those visitors?

Shortness of time frame notwithstanding, will it work? Quite possibly. Here's the report's scenario (be forewarned: These guys love numbers): "In our test setting, the lowest indication of dischargeTime we observed was 355 (in seconds) and highest 40277 s. Assuming all the values spanning a range (355; 40277) are possible, this gives 39,922 numbers. Assuming users start to charge their devices when the battery level is 0:1, this leaves 90 available battery level states (0:11 to 1:0). The number of potential levels denoted by a tuple (level; dischargeTime) would then be a simple multiplication 355 _ 40277 and the number of possible states would be 14172310, which only accounts for the discharging state. Using the information about the battery charge (chargingTime) could effectively double the number of possible states. The probability of a (level; dischargeTime) collision (between different users, and assuming a uniform distribution) is therefore low and for a short time frame this would effectively be a unique identifier. However, we emphasize that the dischargeTime levels can be subject to frequent changes, in response to change in the users' computer use patterns. This means that, in practice, the risk of long-term tracking with this information may be negligible. But it could be used to distinguish visits of corporate users behind a NAT (Network Address Translation). In such a setting, the computers may have similar fingerprints and often identical public IP addresses. The readouts from the battery may allow distinguishing these users."

A key part of the uniqueness is that batteries with the same capacity when they are manufactured degrade at different rates, based on tasks and other variables.

The privacy nightmare scenario that the authors paint is based on this half-minute-later return visit. Within those limited situations, it could be used to find those who want to be found the least, the authors argue: "Users who try to re-visit a website with a new identity may use browsers' private mode or clear cookies and other client side identifiers. When consecutive visits are made within a short interval, the website can link users' new and old identities by exploiting battery level and charge/discharge times. The website can then reinstate users' cookies and other client side identifiers, a method known as respawning. Note that, although this method of exploiting battery data as a linking identifier would only work for short time intervals, it may be used against power users who can not only clear their cookies but can go to great lengths to clear their evercookies."

The report also concedes why this works on so few OS/browser combinations: "We emphasize that our method only works for UPower and Firefox on Linux, and during our study we encountered some computers for which we cannot recover the capacity with our method. This can be due to the differences in how processors handle floating point calculations or measurement errors in UPower."

This is the quintessential theoretical hole that simply isn't significant. To have a true privacy threat, it has to be effective enough that people will bother implementing it. Please forgive me, but this tactic isn't nearly powerful enough to worry about.

Join the CSO newsletter!

Error: Please check your email address.

Tags securitydata privacyprivacy

More about Linux

Show Comments

Featured Whitepapers

Editor's Recommendations

Solution Centres

Stories by Evan Schuman

Latest Videos

  • 150x50

    CSO Webinar: Will your data protection strategy be enough when disaster strikes?

    Speakers: - Paul O’Connor, Engagement leader - Performance Audit Group, Victorian Auditor-General’s Office (VAGO) - Nigel Phair, Managing Director, Centre for Internet Safety - Joshua Stenhouse, Technical Evangelist, Zerto - Anthony Caruana, CSO MC & Moderator

    Play Video

  • 150x50

    CSO Webinar: The Human Factor - Your people are your biggest security weakness

    ​Speakers: David Lacey, Researcher and former CISO Royal Mail David Turner - Global Risk Management Expert Mark Guntrip - Group Manager, Email Protection, Proofpoint

    Play Video

  • 150x50

    CSO Webinar: Current ransomware defences are failing – but machine learning can drive a more proactive solution

    Speakers • Ty Miller, Director, Threat Intelligence • Mark Gregory, Leader, Network Engineering Research Group, RMIT • Jeff Lanza, Retired FBI Agent (USA) • Andy Solterbeck, VP Asia Pacific, Cylance • David Braue, CSO MC/Moderator What to expect: ​Hear from industry experts on the local and global ransomware threat landscape. Explore a new approach to dealing with ransomware using machine-learning techniques and by thinking about the problem in a fundamentally different way. Apply techniques for gathering insight into ransomware behaviour and find out what elements must go into a truly effective ransomware defence. Get a first-hand look at how ransomware actually works in practice, and how machine-learning techniques can pick up on its activities long before your employees do.

    Play Video

  • 150x50

    CSO Webinar: Get real about metadata to avoid a false sense of security

    Speakers: • Anthony Caruana – CSO MC and moderator • Ian Farquhar, Worldwide Virtual Security Team Lead, Gigamon • John Lindsay, Former CTO, iiNet • Skeeve Stevens, Futurist, Future Sumo • David Vaile - Vice chair of APF, Co-Convenor of the Cyberspace Law And Policy Community, UNSW Law Faculty This webinar covers: - A 101 on metadata - what it is and how to use it - Insight into a typical attack, what happens and what we would find when looking into the metadata - How to collect metadata, use this to detect attacks and get greater insight into how you can use this to protect your organisation - Learn how much raw data and metadata to retain and how long for - Get a reality check on how you're using your metadata and if this is enough to secure your organisation

    Play Video

  • 150x50

    CSO Webinar: How banking trojans work and how you can stop them

    CSO Webinar: How banking trojans work and how you can stop them Featuring: • John Baird, Director of Global Technology Production, Deutsche Bank • Samantha Macleod, GM Cyber Security, ME Bank • Sherrod DeGrippo, Director of Emerging Threats, Proofpoint (USA)

    Play Video

More videos

Blog Posts

Market Place