7 ms·

This title is kind of exaggerated. In order to obtain this data you'd need to get the Bluetooth identifiers from the system log. In order to get the system log,

by arsome 5y ago

This title is kind of exaggerated. In order to obtain this data you'd need to get the Bluetooth identifiers from the system log. In order to get the system log, you need root or adb. At that point you can just log GPS directly, inject code straight into the COVID tracking app, etc. All bets are off.

mkesper 5y ago
This is the interesting thing about it: The signals that a phone’s contact tracing data generates and receives are saved into an Android device’s system logs. Studies have found that more than 400 preinstalled apps on phones built by Samsung, Motorola, Huawei, and other companies have permission to read system logs for crash reports and analytic purposes.
- arsome 5y ago
  But again, they also have system privileges on your phone and if they wanted to dump location data or bluetooth scans they could do so trivially. About the worst that could come of this is an accidental capture in a crash report.
  - ballenf 5y ago
    So maybe Google shouldn't have guaranteed privacy of this app on a phone OS where such a promise is impossible to deliver?
    - gruez 5y ago
      What type of guarantees did they promise?
    - Sebb767 5y ago
      Basically any device can be seen as compromised if anyone malicious had hardware or root access - including the manufacturer. If you don't trust your manufacturer, you have far bigger problems than bluetooth IDs in the log.
      - dylan604 5y ago
        But that's just it. I DON'T trust Google one iota.
        ryukafalz 5y ago
        Then if you have an Android phone, you have no reason to believe your location data is private from Google, with or without the contact tracing app. I'm not saying this isn't a problem, I'm in the same boat here, just that the contact tracing app doesn't really add to it.
        nthj 5y ago
        Then you shouldn’t have an Android device. This isn’t complicated.
        dylan604 5y ago
        I don't have an Android device presicely because of this. I don't use Google Chrome, search, etc. I block all GA,Tagmanager,blahblahblah as well.
        oefrha 5y ago
        Great, this “issue” is irrelevant to you and your off-topic rant adds exactly nothing to this discussion of a clearly defined risk. For other people who have made a relevant device choice, the point stands that it’s a non-issue since there’s no additional risk.
        procombo 5y ago
        Hardly. Your privacy also depends on what devices your neighbors use. Bluetooth/Wifi/etc packet broadcast, etc. Apple does _some_ things to midigate privacy risks for their users, but not enough.
        heavyset_go 5y ago
    - shawnz 5y ago
      This seems like saying they shouldn't have guaranteed privacy because someone could be looking over your shoulder while you type your password. Maybe that's true, but it also seems like a uselessly impractical way to interpret things.
  - macinjosh 5y ago
    > About the worst that could come of this is an accidental capture in a crash report. So.. this data is exposed and available even though they said would/could never leak. Seems pretty cut and dry to me. It is a black and white issue. Accidental disclosure is still a disclosure.
    - joshuamorton 5y ago
      It's accidental exposure to someone who already had root and could record the data themselves.
      - shadowgovt 5y ago
        I think there's a practical difference between what an app could do with root permissions and what is widely understood to be likely or acceptable. The "anything the app could do it is doing" model isn't really the right model to apply for vendor apps that are generally trusted by consumers (and observed by security researchers). We're not talking malware with root; we're talking the regular system health and monitoring apps that vendors install. So it's real unlikely that MotoCare is intentionally trying to de-anonymize someone's COVID-19 data by code injection or continuous GPS logging. It is extremely likely and expected that the app is periodically grabbing the syslog as a crash report, and that means Google's claim of keeping your data private now has to implicitly assume that MotoCare, without doing anything special other than its regular behavior, is also keeping your data private. That's not a claim Google should be implicitly making on behalf of MotoCare (let alone on behalf of every app that could hypothetically be installed on your system and is understood to be well-behaved in the sense that it just reads the syslog). It's really incumbent on a privacy-protecting application to not put private data in the syslog. If it's in the syslog, it's not private (even though it's more private than, say, a notification on the homescreen).
  - lofi_lory 5y ago
    I imagine for semi-criminal actors, injecting code or "accidentally" using systen data, are still two different scenarios. I mean, state actors could also just follow you around, or place agents as friends and family... so why bother about anything?
- not_knuth 5y ago
  Link to studies?
  - derpus 5y ago
    The researcher linked to the paper (https://haystack.mobi/papers/preinstalledAndroidSW_preprint.pdf https://haystack.mobi/papers/preinstalledAndroidSW_preprint....) in their original blog post on Appcensus (https://blog.appcensus.io/2021/04/27/why-google-should-stop-logging-contact-tracing-data/ https://blog.appcensus.io/2021/04/27/why-google-should-stop-...)
nl 5y ago
Yeah it's a ridiculous assertion. It's basically arguing that because the phone knows it's own identity it's not private.
jrm4 5y ago
I get that this might not be useful from a technical point of view for this crowd, but it's not exaggerated at all even if the point of failure isn't Google and the app; if we want to be serious about fixing privacy issues, we can't just wave away vulnerabilities that we've accepted for a long time out of pure convenience and apparent difficulty to solve.
joeblau 5y ago
On iOS, none of that is even possible with physical access. Nothing that you’re saying sounds hard for a malicious actor to pull off. The interesting thing is that you’re getting is a historical log without the need to install anything.
- arsome 5y ago
  > Nothing that you’re saying sounds hard for a malicious actor to pull off. A malicious actor would need to be your phone manufacturer, Google or someone with a root exploit (jailbreak in iOS terms) or this "vulnerability" would be completely useless. All of those parties could just as easily push code to your device any number of other ways that could do far worse than reading your logcat for BT IDs. I understand the concern, but if you're at the point where you can't trust the parties who push automatic updates with high privilege levels but you do need to be concerned about reading logcat your threat model here is pretty strange.
  - Aerroon 5y ago
    Isn't the difference based on time though? The device manufacturer can push a patch, but they would get access to the information after the patch, whereas access to the log gives you information from before the patch. Or have I misunderstood?
    - hundchenkatze 5y ago
      The device manufacturer has access to the device (at the hardware level even) the moment they start building it. They don't need to push a patch to gain access, they could access your logs at any point throughout the lifespan of the device.
      - Aerroon 5y ago
        I think we're talking about different things. If a manufacturer wants to eavesdrop on my device then they need to push a patch to my device. They can only get information about what happens after they push this patch. They can do it at the start of the life of the device, but they'd have to do it then. However, if important data is retained in logs, then the manufacturer could grab the data from the logs. They can get information from a time before they decided to look into you. It's like a wiretap vs access to a diary. A wiretap only gives you information after the tap has been installed, whereas getting your hands on someone's diary would give you access to previous information too.
6gvONxR4sf7o 5y ago
Isn’t it saying that a bunch of preinstalled apps also have access to this info?
- privacyking 5y ago
  And what is the most common privacy-violating preinstalled app? Facebook.
  - iudqnolq 5y ago
    Different kind of pre-installed.
deleted 5y ago
[deleted]
JAlexoid 5y ago
It's the fact that it logs other people's data, not just it's own, that makes it less than perfect anonymity. But then again... You'd need to have a list from the "other side", to actually deanonimize this data. At that point, you can just get WiFi and Bluetooth physical addresses.
compiler-guy 5y ago
Google did claim that the identifiers are ephemeral. They may be hard to access but they aren't ephemeral. This sets up the possibility of post-hoc attacks. Sure, if you get root, all bets are off generally, but now if you get root, you can figure out identifiers used before you got root, which isn't what Google said was possible.
- deleted 5y ago
  [deleted]
- PossiblyDog 5y ago
  The identifiers are ephemeral. About 10 minutes for a given RPI (what gets broadcast over Bluetooth), 1 day for a TEK, and 14 days of local TEK history. The generated RPIs aren't retained, and the TEKs - which can be used to re-derive the RPIs - never leave the device unless you choose to report a diagnosis. All of this is destroyed after 14 days. This report doesn't change any of this. I recommend reading the GAEN cryptography spec: https://blog.google/documents/69/Exposure_Notification_-_Cryptography_Specification_v1.2.1.pdf https://blog.google/documents/69/Exposure_Notification_-_Cry... The issue here is that privileged apps that are bundled with the OS could snoop on the system log to capture new RPIs when they're generated in real-time. Which isn't great... but privileged apps can already do much worse. If one of these apps is malicious, they could just log your GPS position directly (for example). Heck, an application with root could just read the 14-day TEK history directly off disk. Once we're talking privileged apps and processes running as root, all bets are off. You need to be able to trust the device's firmware.
  - deleted 5y ago
    [deleted]
  - lurkerasdfh8 5y ago
    > but privileged apps can already do much worse. If one of these apps is malicious One of these apps (google play service) downloads Ads non stop, mine wifi and gps data and send to a central server, etc. All against user wishes ...or even knowledge! At which point do you draw the line for an app to be malicious?
two_handfuls 5y ago
I've seen this described as "the security vulnerability is on the other side of the airtight door", which I found was both poetic and apt. It's apparently pretty common in bug bounty submissions.
- UncleMeat 5y ago
  Replace "apparently" with "definitely". The number of bounty submissions that I've seen which come in the form of "I can read a program's private data using root" is too high to count.

by arsome 5y ago

mkesper 5y ago

This is the interesting thing about it: The signals that a phone’s contact tracing data generates and receives are saved into an Android device’s system logs. Studies have found that more than 400 preinstalled apps on phones built by Samsung, Motorola, Huawei, and other companies have permission to read system logs for crash reports and analytic purposes.

arsome 5y ago
But again, they also have system privileges on your phone and if they wanted to dump location data or bluetooth scans they could do so trivially. About the worst that could come of this is an accidental capture in a crash report.
- ballenf 5y ago
  So maybe Google shouldn't have guaranteed privacy of this app on a phone OS where such a promise is impossible to deliver?
  - gruez 5y ago
    What type of guarantees did they promise?
  - Sebb767 5y ago
    Basically any device can be seen as compromised if anyone malicious had hardware or root access - including the manufacturer. If you don't trust your manufacturer, you have far bigger problems than bluetooth IDs in the log.
    - dylan604 5y ago
      But that's just it. I DON'T trust Google one iota.
      - ryukafalz 5y ago
        Then if you have an Android phone, you have no reason to believe your location data is private from Google, with or without the contact tracing app. I'm not saying this isn't a problem, I'm in the same boat here, just that the contact tracing app doesn't really add to it.
      - nthj 5y ago
        Then you shouldn’t have an Android device. This isn’t complicated.
        dylan604 5y ago
        I don't have an Android device presicely because of this. I don't use Google Chrome, search, etc. I block all GA,Tagmanager,blahblahblah as well.
        oefrha 5y ago
        Great, this “issue” is irrelevant to you and your off-topic rant adds exactly nothing to this discussion of a clearly defined risk. For other people who have made a relevant device choice, the point stands that it’s a non-issue since there’s no additional risk.
        procombo 5y ago
        Hardly. Your privacy also depends on what devices your neighbors use. Bluetooth/Wifi/etc packet broadcast, etc. Apple does _some_ things to midigate privacy risks for their users, but not enough.
        heavyset_go 5y ago
  - shawnz 5y ago
    This seems like saying they shouldn't have guaranteed privacy because someone could be looking over your shoulder while you type your password. Maybe that's true, but it also seems like a uselessly impractical way to interpret things.
- macinjosh 5y ago
  > About the worst that could come of this is an accidental capture in a crash report. So.. this data is exposed and available even though they said would/could never leak. Seems pretty cut and dry to me. It is a black and white issue. Accidental disclosure is still a disclosure.
  - joshuamorton 5y ago
    It's accidental exposure to someone who already had root and could record the data themselves.
    - shadowgovt 5y ago
      I think there's a practical difference between what an app could do with root permissions and what is widely understood to be likely or acceptable. The "anything the app could do it is doing" model isn't really the right model to apply for vendor apps that are generally trusted by consumers (and observed by security researchers). We're not talking malware with root; we're talking the regular system health and monitoring apps that vendors install. So it's real unlikely that MotoCare is intentionally trying to de-anonymize someone's COVID-19 data by code injection or continuous GPS logging. It is extremely likely and expected that the app is periodically grabbing the syslog as a crash report, and that means Google's claim of keeping your data private now has to implicitly assume that MotoCare, without doing anything special other than its regular behavior, is also keeping your data private. That's not a claim Google should be implicitly making on behalf of MotoCare (let alone on behalf of every app that could hypothetically be installed on your system and is understood to be well-behaved in the sense that it just reads the syslog). It's really incumbent on a privacy-protecting application to not put private data in the syslog. If it's in the syslog, it's not private (even though it's more private than, say, a notification on the homescreen).
- lofi_lory 5y ago
  I imagine for semi-criminal actors, injecting code or "accidentally" using systen data, are still two different scenarios. I mean, state actors could also just follow you around, or place agents as friends and family... so why bother about anything?
not_knuth 5y ago
Link to studies?
- derpus 5y ago
  The researcher linked to the paper (https://haystack.mobi/papers/preinstalledAndroidSW_preprint.pdf https://haystack.mobi/papers/preinstalledAndroidSW_preprint....) in their original blog post on Appcensus (https://blog.appcensus.io/2021/04/27/why-google-should-stop-logging-contact-tracing-data/ https://blog.appcensus.io/2021/04/27/why-google-should-stop-...)

nl 5y ago

Yeah it's a ridiculous assertion. It's basically arguing that because the phone knows it's own identity it's not private.

jrm4 5y ago

I get that this might not be useful from a technical point of view for this crowd, but it's not exaggerated at all even if the point of failure isn't Google and the app; if we want to be serious about fixing privacy issues, we can't just wave away vulnerabilities that we've accepted for a long time out of pure convenience and apparent difficulty to solve.

joeblau 5y ago

On iOS, none of that is even possible with physical access. Nothing that you’re saying sounds hard for a malicious actor to pull off. The interesting thing is that you’re getting is a historical log without the need to install anything.

arsome 5y ago
> Nothing that you’re saying sounds hard for a malicious actor to pull off. A malicious actor would need to be your phone manufacturer, Google or someone with a root exploit (jailbreak in iOS terms) or this "vulnerability" would be completely useless. All of those parties could just as easily push code to your device any number of other ways that could do far worse than reading your logcat for BT IDs. I understand the concern, but if you're at the point where you can't trust the parties who push automatic updates with high privilege levels but you do need to be concerned about reading logcat your threat model here is pretty strange.
- Aerroon 5y ago
  Isn't the difference based on time though? The device manufacturer can push a patch, but they would get access to the information after the patch, whereas access to the log gives you information from before the patch. Or have I misunderstood?
  - hundchenkatze 5y ago
    The device manufacturer has access to the device (at the hardware level even) the moment they start building it. They don't need to push a patch to gain access, they could access your logs at any point throughout the lifespan of the device.
    - Aerroon 5y ago
      I think we're talking about different things. If a manufacturer wants to eavesdrop on my device then they need to push a patch to my device. They can only get information about what happens after they push this patch. They can do it at the start of the life of the device, but they'd have to do it then. However, if important data is retained in logs, then the manufacturer could grab the data from the logs. They can get information from a time before they decided to look into you. It's like a wiretap vs access to a diary. A wiretap only gives you information after the tap has been installed, whereas getting your hands on someone's diary would give you access to previous information too.

6gvONxR4sf7o 5y ago

Isn’t it saying that a bunch of preinstalled apps also have access to this info?

privacyking 5y ago
And what is the most common privacy-violating preinstalled app? Facebook.
- iudqnolq 5y ago
  Different kind of pre-installed.

deleted 5y ago

[deleted]

JAlexoid 5y ago

It's the fact that it logs other people's data, not just it's own, that makes it less than perfect anonymity. But then again... You'd need to have a list from the "other side", to actually deanonimize this data. At that point, you can just get WiFi and Bluetooth physical addresses.

compiler-guy 5y ago

Google did claim that the identifiers are ephemeral. They may be hard to access but they aren't ephemeral. This sets up the possibility of post-hoc attacks. Sure, if you get root, all bets are off generally, but now if you get root, you can figure out identifiers used before you got root, which isn't what Google said was possible.

deleted 5y ago
[deleted]
PossiblyDog 5y ago
The identifiers are ephemeral. About 10 minutes for a given RPI (what gets broadcast over Bluetooth), 1 day for a TEK, and 14 days of local TEK history. The generated RPIs aren't retained, and the TEKs - which can be used to re-derive the RPIs - never leave the device unless you choose to report a diagnosis. All of this is destroyed after 14 days. This report doesn't change any of this. I recommend reading the GAEN cryptography spec: https://blog.google/documents/69/Exposure_Notification_-_Cryptography_Specification_v1.2.1.pdf https://blog.google/documents/69/Exposure_Notification_-_Cry... The issue here is that privileged apps that are bundled with the OS could snoop on the system log to capture new RPIs when they're generated in real-time. Which isn't great... but privileged apps can already do much worse. If one of these apps is malicious, they could just log your GPS position directly (for example). Heck, an application with root could just read the 14-day TEK history directly off disk. Once we're talking privileged apps and processes running as root, all bets are off. You need to be able to trust the device's firmware.
- deleted 5y ago
  [deleted]
- lurkerasdfh8 5y ago
  > but privileged apps can already do much worse. If one of these apps is malicious One of these apps (google play service) downloads Ads non stop, mine wifi and gps data and send to a central server, etc. All against user wishes ...or even knowledge! At which point do you draw the line for an app to be malicious?

two_handfuls 5y ago

I've seen this described as "the security vulnerability is on the other side of the airtight door", which I found was both poetic and apt. It's apparently pretty common in bug bounty submissions.

UncleMeat 5y ago
Replace "apparently" with "definitely". The number of bounty submissions that I've seen which come in the form of "I can read a program's private data using root" is too high to count.