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.

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.

So maybe Google shouldn't have guaranteed privacy of this app on a phone OS where such a promise is impossible to deliver?

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.

I consider Facebook malicious, and I've just learnt that their pre-installed app basically has root on my Android.

How is that not the story here?

No, the Facebook app most likely does not have any special permissions. These are typically granted by manufacturers based on their own signing keys.

A preinstalled fb app does not have any special permissions.

How are you even remotely surprised by that? If you are expecting any privacy or security from a combo of Facebook and Android, you've been asleep for the last 13 years.

But that's just it. I DON'T trust Google one iota.

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.

Then you shouldn’t have an Android device. This isn’t complicated.

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.

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.

As someone in a similar boat without an android, I think it adds to the discussion. It makes me feel warm and fuzzy inside to see such rants.

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.

This. My wireless networks, MAC addresses etc are collected on Google's end by my neighbors' Google devices for things like advanced location tracking.

But note that now Apple has fake mac addresses (for wifi though) for this reason.

Google's advanced location tracking logs access point ESSIDs and MAC addresses. Whatever Apple is doing won't stop that.

Actually, Google and Apple teamed up on a contact tracing concept. Even when it was first annouced, the fact that G was attached meant that I wasn't interested. Apple's involvement only lessened the distrust slightly to me, but not enough for me to want to bother with it.

The only option you have is a phone like the Nokia 3310 then. Android and iOS are equally bad, just in different quantities of bad in different areas.

In regards to privacy they are not equally bad. And for this contact tracing app they aren’t equally bad.

They are equally bad just in different ways to different people.

Just like a Nokia. Do any manufacturers even make their own OS anymore?

buy an iphone?

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.

What type of guarantees did they promise?

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?

> 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.

It's accidental exposure to someone who already had root and could record the data themselves.

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).

Link to studies?

The researcher linked to the paper (https://haystack.mobi/papers/preinstalledAndroidSW_preprint....) in their original blog post on Appcensus (https://blog.appcensus.io/2021/04/27/why-google-should-stop-...)

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.

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_-_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.

> 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?

In this case, "malicious" clearly means "interested in misusing the private data under discussion."

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.

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.

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.

Yeah it's a ridiculous assertion.

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

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

And what is the most common privacy-violating preinstalled app? Facebook.

Different kind of pre-installed.

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.

> 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.

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?

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.

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.

Ah, thanks for the clarification, that makes sense. I was jumping to the assumption that the manufacturer was malicious from day one.

On iOS, you have to trust Apple and everyone who writes code for Apple, directly or indirectly.

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.

> 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.

And people complain incessantly that they don't really own their iphones because they cannot install their own code on it. You can't win.

Sandboxing exists.

Of course it does. Sandboxing even exists on Android. The criticism here is that if you have some system that has root and can poke through sandboxes that you can access this data.

You either have full access or you don't.

That wasn't my point. It was that iPhones need not limit apps to the "App Store" in the name of protecting the system, since it can sandbox apps, wherever they come from.

If the non-app-store-installed apps are sandboxed then they cannot actually run everything that tinkerers want and the same criticism persists. The "we don't own our phones" crowd wants root.

That's a different complaint though. Just allowing sandboxed, sideloaded, apps would enable a whole host of new apps such as emulators, plus it would allow apps to provide their own monetization (e.g. Fortnite).

There’s a far larger number of iPhone users that either don’t know what root is, or don’t care. And your parent post is incorrect, Apple denies apps all the time.

How is this an instance of "you can't win"? Not "owning" your phone is a downside of iOS's approach, and avoiding the security issue as parent commenter mentions is an upside (ie a "win"). This martyr complex over phone OSes is very 2010.

He means as a phone manufacturer you can't win, either you have an open OS and get criticised for not locking it down or you have a locked down OS and get criticised for not opening it up.

This is just true in general. People complain about everything these days.

How is this prevented in ios if you have root (=jailbreak)?

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.