Research battery fingerprinting about fingerprintjs HOT 10 CLOSED

There is now a paper out on this, The leaking battery: A privacy analysis of the HTML5 Battery Status API. Glancing over their research it seems the changes are not “happening all the time” as @mhuisman remarks, but rather about once every 30 seconds. While still short, it is long enough to track someone going from one site to the next.

from fingerprintjs.

just for your info. I implemented this and this in my opinion can only be used server-side to distinguish devices with the same fingerprint under certain circumstances. So my suggestion would be to split the fingerprint in two parts - a more or less stable one and a highly dynamic one containing the battery fingerprint.

from fingerprintjs.

Excellent idea, thanks

from fingerprintjs.

I looked into this and it seems like the constantly-changing nature of the properties would imperil our ability to generate a consistent fingerprint.

same issue as browser plugin update up-revs, but happening all the time instead of infrequently.

from fingerprintjs.

Hey @Zegnat,

My point was grounded in an attempt to try and distinguish between fingerprint features that should be static or unlikely to change with any great frequency - screen resolution/bit depth, operating system, installed fonts, etc and those fingerprint features that seem likely to change with greater frequency - plugin list, battery life, etc.

One of the nice features of fpjs2 is that it allows the end user to select which features they choose to use. My interest - high fidelity, low mutation frequency device fingerprinting - leads me away from using the battery API.

That said, fpjs2 could well support it. I'm just not convinced of the utility of a fingerprint that changes every 30 seconds. Could you take a crack at convincing me? I am genuinely curious.

from fingerprintjs.

Oh, I fully agree with you and am not even going to try and convince you. I mostly thought to clarify its rate of change and link to the paper. Personally I don’t think battery status will turn into a viable datapoint for creating a fingerprint.

My interest - high fidelity, low mutation frequency device fingerprinting - leads me away from using the battery API.

Note that the paper agrees with you and focusses on figuring out the total capacity of the device’s battery. This is a somewhat more unique and slightly less-often-to-change data point especially for “old or used batteries with reduced capacities” and “may potentially serve as a tracking identifier”. (Quoting the paper I linked.)

The paper also mentions that it is a viable way for “reinstantiating identifiers”, which they call respawning. If a device has lost their tracking cookie, but you recognise the battery fingerprint, put it back in place. While this doesn’t work well as a fingerprint by itself it can be used to sustain super cookies.

from fingerprintjs.

Thanks for the reply, @Zegnat. I'll read the paper over lunch today. Definitely agree that total battery capacity is a potentially interesting low-mutation datapoint.

from fingerprintjs.

I would definitely recommend reading it, @mhuisman. It gives an interesting insight on how academics view security in browsers. The paper also stands in stark contrast to almost every newspaper article it has sparked. (E.g. The Guardian talked about how people are tracking you through your mobile battery, while the paper focussed on Firefox for Linux…)

from fingerprintjs.

I'd like this as an option, as I can see use cases where the battery API is stable enough to be useful.

from fingerprintjs.

I'm sorry for closing, but we'll be concentrating on stabilizing the library, not on adding new features in the foreseeable future. Closing as a non-feature.

from fingerprintjs.