3 ms·

Post mentions this Apple doc, https://developer.apple.com/documentation/kernel/1462446-mach_absolute_time https://developer.apple.com/documentation/kernel/14624

by xyst 3y ago

Post mentions this Apple doc, https://developer.apple.com/documentation/kernel/1462446-mach_absolute_time https://developer.apple.com/documentation/kernel/1462446-mac..., which states it can potentially be used to fingerprint a device? How can this API be used to fingerprint devices? It’s just getting the current time. My best guess, you can infer a users time zone? Thus get a very general/broad area of where this user lives (USA vs EU; or US-EST vs US-PST) Maybe I should just set my time to UTC on all devices

simcop2387 3y ago
The same way that you can do it from javascript I'd imagine. Timezones and such are one data point but the skews and accuracy and such are able to help you differentiate users too. https://forums.whonix.org/t/javascript-time-fingerprinting/7852 https://forums.whonix.org/t/javascript-time-fingerprinting/7...
lapcat 3y ago
mach_absolute_time is unrelated to clock time. It's basically the number of CPU cycles since last boot, so it's more of an uptime measure. I suspect the fingerprinting aspect is more indirect: mach_absolute_time is the most accurate way to measure small differences, so if you're trying to measure subtle differences in performance between different devices on some specific task, mach_absolute_time would be the way to go.
- thealistra 3y ago
  Yeah this is correct. Other comments seem misinformed. You can fingerprint a device using this because you know the wall clock difference and you know the previous cpu cycles. So you can assume any device with appropriately more cpu cycles may be the same device. We’re talking measurements taken from different apps using Google or Facebook sdk.
- MBCook 3y ago
  > It's basically the number of CPU cycles since last boot, so it's more of an uptime measure And there’s the problem. Different devices have different uptimes. If you can get not only the uptime but a very very accurate version, you’ve got a very strong fingerprint.
- VogonPoetry 3y ago
  Consider N devices behind a NAT. They all make requests to a service. If the service can learn the individual but current values of mach_absolute_time, then after a minimum of two requests you can likely compute N and distinguish between each device making a request. This is possible because devices never reboot at exactly the same time.
- hi-v-rocknroll 3y ago
  There's also a Ruby gem that uses it for better-than-Benchmark high-precision timing. https://github.com/bwbuchanan/absolute_time/blob/master/ext/absolute_time.c#L126 https://github.com/bwbuchanan/absolute_time/blob/master/ext/... https://rubygems.org/gems/absolute_time https://rubygems.org/gems/absolute_time Yes you want this in a development environment or perhaps in some sort of macOS app for developers, but probably not in most apps without a very specific and limited need.
interpol_p 3y ago
My understanding is this gets something like the system uptime? (I may be reading the docs wrong). In which case, it could be used as one of many signals in fingerprinting a device, as you could distinguish a returning user by checking their uptime against the time delta since the uptime at their last visit. It's not perfect, but when combined with other signals, might be helpful
twoodfin 3y ago
The problem is it’s getting the current time with relatively high precision, which is the same reason a developer would prefer it for non-nefarious uses. Once you have a high-precision timer, there are all sorts of aspects of the user’s system you can fingerprint by measuring how long some particular API dependent on device performance and/or state takes to execute. Platform vendors long ago figured out not to hand out the list of available fonts, but it’s a couple orders of magnitude harder to be sure switching some text from Menlo to Helvetica doesn’t leak a fractional bit of information via device-dependent timing. EDIT: Others noted it’s actually ticks since startup, which is probably good for a few bits all on its own if you are tracking users in close to real time.
- Waterluvian 3y ago
  It’s amazing just how much we lose here, elsewhere, and in browsers, because we have to worry about fingerprinting.
  - lesuorac 3y ago
    It gets even more funny when you realize that devices & browsers let you set data per device that you can just retrieve later ... Why bother fingerprinting when you can just assign them an id and retrieve it later. https://developer.apple.com/documentation/devicecheck https://developer.apple.com/documentation/devicecheck https://engineering.deptagency.com/securely-storing-data-on-ios https://engineering.deptagency.com/securely-storing-data-on-... https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage https://developer.mozilla.org/en-US/docs/Web/API/Window/loca...
    - Aloisius 3y ago
      That doesn't give you a fixed device ID like fingerprinting does. A fixed device ID survives even when an app is uninstalled and reinstalled and is the same for unaffiliated apps.
    - saagarjha 3y ago
      That gives you two bits of data, which is designed to not be easy to fingerprint with.
singron 3y ago
The offset from epoch time is probably unique per device per boot, and it only drifts one second per second while the device is suspended. You can get the time zone from less naughty APIs, and that has way fewer bits of entropy.

by xyst 3y ago

simcop2387 3y ago

The same way that you can do it from javascript I'd imagine. Timezones and such are one data point but the skews and accuracy and such are able to help you differentiate users too. https://forums.whonix.org/t/javascript-time-fingerprinting/7852 https://forums.whonix.org/t/javascript-time-fingerprinting/7...

lapcat 3y ago

mach_absolute_time is unrelated to clock time. It's basically the number of CPU cycles since last boot, so it's more of an uptime measure. I suspect the fingerprinting aspect is more indirect: mach_absolute_time is the most accurate way to measure small differences, so if you're trying to measure subtle differences in performance between different devices on some specific task, mach_absolute_time would be the way to go.

thealistra 3y ago
Yeah this is correct. Other comments seem misinformed. You can fingerprint a device using this because you know the wall clock difference and you know the previous cpu cycles. So you can assume any device with appropriately more cpu cycles may be the same device. We’re talking measurements taken from different apps using Google or Facebook sdk.
MBCook 3y ago
> It's basically the number of CPU cycles since last boot, so it's more of an uptime measure And there’s the problem. Different devices have different uptimes. If you can get not only the uptime but a very very accurate version, you’ve got a very strong fingerprint.
VogonPoetry 3y ago
Consider N devices behind a NAT. They all make requests to a service. If the service can learn the individual but current values of mach_absolute_time, then after a minimum of two requests you can likely compute N and distinguish between each device making a request. This is possible because devices never reboot at exactly the same time.
hi-v-rocknroll 3y ago
There's also a Ruby gem that uses it for better-than-Benchmark high-precision timing. https://github.com/bwbuchanan/absolute_time/blob/master/ext/absolute_time.c#L126 https://github.com/bwbuchanan/absolute_time/blob/master/ext/... https://rubygems.org/gems/absolute_time https://rubygems.org/gems/absolute_time Yes you want this in a development environment or perhaps in some sort of macOS app for developers, but probably not in most apps without a very specific and limited need.

interpol_p 3y ago

My understanding is this gets something like the system uptime? (I may be reading the docs wrong). In which case, it could be used as one of many signals in fingerprinting a device, as you could distinguish a returning user by checking their uptime against the time delta since the uptime at their last visit. It's not perfect, but when combined with other signals, might be helpful

twoodfin 3y ago

The problem is it’s getting the current time with relatively high precision, which is the same reason a developer would prefer it for non-nefarious uses. Once you have a high-precision timer, there are all sorts of aspects of the user’s system you can fingerprint by measuring how long some particular API dependent on device performance and/or state takes to execute. Platform vendors long ago figured out not to hand out the list of available fonts, but it’s a couple orders of magnitude harder to be sure switching some text from Menlo to Helvetica doesn’t leak a fractional bit of information via device-dependent timing. EDIT: Others noted it’s actually ticks since startup, which is probably good for a few bits all on its own if you are tracking users in close to real time.

Waterluvian 3y ago
It’s amazing just how much we lose here, elsewhere, and in browsers, because we have to worry about fingerprinting.
- lesuorac 3y ago
  It gets even more funny when you realize that devices & browsers let you set data per device that you can just retrieve later ... Why bother fingerprinting when you can just assign them an id and retrieve it later. https://developer.apple.com/documentation/devicecheck https://developer.apple.com/documentation/devicecheck https://engineering.deptagency.com/securely-storing-data-on-ios https://engineering.deptagency.com/securely-storing-data-on-... https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage https://developer.mozilla.org/en-US/docs/Web/API/Window/loca...
  - Aloisius 3y ago
    That doesn't give you a fixed device ID like fingerprinting does. A fixed device ID survives even when an app is uninstalled and reinstalled and is the same for unaffiliated apps.
  - saagarjha 3y ago
    That gives you two bits of data, which is designed to not be easy to fingerprint with.

singron 3y ago

The offset from epoch time is probably unique per device per boot, and it only drifts one second per second while the device is suspended. You can get the time zone from less naughty APIs, and that has way fewer bits of entropy.