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.
About the worst that could come of this is an accidental capture in a crash report.
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.
How is that not the story here?
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.
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).
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.
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_-_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.
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?
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.
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.
It's basically arguing that because the phone knows it's own identity it's not private.
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.
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.
You either have full access or you don't.
If any Apple code that runs as root is evil, then your location data can be stolen in exactly the same way.
In the case of Android, the equivalent is code written by Google, the OEM, the chipset maker, and anyone those people gave root access to (which is often a long list of 'sponsorware' apps).
Overall, the class of vulnerability is the same, but Apple just does a far better job of vetting and controlling the list of people/code.
This as well as the extreme lack of trust for anything Google. Apple has an incentive to keep the privacy kick going, Google is already figuring out a way around Apple nuking ad identifiers. Trust is important.