A 2022 Trinity College Dublin study (PDF; news release) found Google’s Messages and Phone apps sent a log to Google of every text made/received (including the timestamp and a truncated content hash) and every call made (time and duration).
Affected workflows
This assumes both parties are using the Google Dialer and Messages apps.
Phone call
- Alice calls Bob on the cellular network
- Alice’s phone logs the call setup events (dialpad opened, each digit typed, call connecting)
- Bob’s phone logs the incoming call event
- Alice and Bob end the call
- Alice’s phone sends the call’s duration to Google over the data network
- Bob’s phone sends the call’s duration to Google over the data network
- Both phones send a notification to Google Analytics over the data network that a call happened, each with the phone’s advertising ID
Google could use the nearly identical call-duration values to infer that the two numbers were in the same phone call. This was even worse with default settings; if the receiving phone has “Caller ID & Spam Protection” on, it straight-up reported the caller’s number to Google.
The app didn’t disclose this in its privacy policy or provide a way to opt out.
SMS message
- Alice texts Bob using her Android Messages app
- Alice’s Messages app sends a fingerprint of the message (a hash of the message text and the hour it was sent) to Google’s Clearcut logging service, tagged with her Android ID
- Bob receives Alice’s text message over the cellular network
- Bob’s Messages app computes the same hash and sends it to Google over the data network
- Bob’s Messages app reports Alice’s phone number to Google over the data network
- Both phones report to Google Analytics over the data network that a message was sent/received at a specific time, each with the phone’s advertising ID
Assuming Bob was using Google Messages, Google’s server saw two matching hash values from two different device IDs, which could confirm their devices were in communication with each other.
Evidence
Google Messages
| Field / string | Where it appears | Example value seen in the study | What it proves |
|---|---|---|---|
sha256HashMsg | Clearcut logger: the ANDROID_MESSAGING log on the sending phone has a BUGLE_MESSAGE event with SENT status | "247836537599431109" | Nothing by itself |
sha256HashMsg | Clearcut logger: the ANDROID_MESSAGING log on the receiving phone has a BUGLE_MESSAGE event with RECEIVED status | "247836537599431109" (same as above) | Two devices were involved in the exchange of a message with the exact same contents during the same clock hour |
sha256HashPrevMsg | Both of the rows above | "200428458475182371" (matches on both ends too) | The fingerprint of the previous message in the conversation, also matching on both phones — reinforces that this is designed to chain and link an entire conversation, not just one message. |
incomingPhoneNumber | Clearcut logger, CARRIER_SERVICES log source, receiving phone only | "+353872...351" | The receiving phone directly reports the sender’s real phone number to Google. This is a separate, more blunt disclosure than the fingerprint — an actual phone number, not a scrambled code. |
google_ad_id | Google/Firebase Analytics, both phones, event ACTIVE_EVENT | "916c714a-e838-479d-a7a6-3325d838da5f" | This is the phone’s Google advertising ID — the same identifier Google uses to target ads. Attaching it to a “you just texted someone” event is what lets this data plug into the rest of your ad profile. |
firebase_instance_id | Same Analytics event | "eVpvvohEDCqhfIGC7pXLnv" | A per-app-install ID that the paper shows is linked back to the phone’s permanent Android ID — i.e., not anonymous or resettable in practice. |
| (tagged at the message-batch level, not a field inside each event) | All Clearcut (not Analytics) events | handset Android ID | The paper shows this ID is separately linkable to the SIM card serial number, the phone’s hardware serial number, and the Google account signed into the phone — so “just a device ID” still traces back to a real person. |
"E2EChatIntegrityMetricsHelperImpl" | Decompiled app code (not a network event — found inside the app itself) | — | The internal programmer-facing label Google gave to the code that builds the fingerprint. “E2E” commonly means “end-to-end” — the researchers read this as confirming the fingerprint’s real purpose is linking both ends of a conversation, not just debugging. |
Why a rainbow table of sorts could actually be built
The hash uses the hour a message was sent as an input, which means that the exact same message sent at 11:59 and at 12:00 would have different hash values. This means that, while it’s not simple and straightforward to build a durable rainbow table,
What Google said and did
- Google’s stated reason for the fingerprint: detecting bugs where messages arrive out of order (“message sequencing bugs”).
- Google committed to stop collecting the message fingerprint starting with Messages app version 10.9.160 (an unspecified later version was promised to also drop the sender’s phone number and the SIM card ID collection — no version number given for those two).
- Google told journalists the data was “not — and were never — used for targeting ads” and was covered by “strict internal access controls.” The paper only shows what leaves the phone and how it’s tagged; it has no visibility into Google’s servers, so it can’t confirm or refute that claim either way.
Google Dialer
The evidence: exact strings, and what each one proves
| Field / string | Where it appears | Example value seen in the study | What it actually proves |
|---|---|---|---|
callDuration | Clearcut logger - ANDROID_DIALER log source- calling phone - event USER_PARTICIPATED_IN_A_CALL | 12344 (milliseconds → 12.344s) | The length of the call the caller’s phone reports to Google. |
callDuration | Clearcut logger - ANDROID_DIALER log source- receiving phone - event USER_PARTICIPATED_IN_A_CALL | 12865 (12.865s) | The receiving phone’s own independently-logged duration for the same call — close but not identical to the caller’s value. The ~0.5s gap is attributed to normal network delay between one phone hanging up and the other being told. This near-match (not an exact cryptographic match, unlike texts) is what lets Google probabilistically pair the two phones. |
searchQuery- queryLength: 1 through queryLength: 10 | Clearcut logger - ANDROID_DIALER log source- calling phone | — | Each individual keypress while dialing is logged with its own timestamp — i.e. Google receives a keystroke-by-keystroke timing trace of you typing the phone number, not just the final number. |
incomingPhoneNumber | Clearcut logger - SCOOBY_EVENTS log source (Caller ID & Spam Protection, on by default)- receiving phone | "+353872...351" | The direct phone number of the person calling you, sent to Google. The paper states this fires “every time a call is received and even if the phone number is in the handset contacts database.” |
google_ad_id- firebase_instance_id | Google/Firebase Analytics - calling phone, event OUTGOING_CALL_PLACED- receiving phone, event INCOMING_CALL_RECEIVED | "916c714a-e838-479d-a7a6-3325d838da5f" | Same mechanism as texts: ties the fact that a call happened to the phone’s advertising identity. |
| Android ID | All Clearcut (not Analytics) events, per Table IV in the paper - tagged at the message-batch level | — | Same identity-linkage point as Messages — the interaction log (dialpad opens, call history views, contact searches) is tied to a durable, traceable device ID, not an anonymous session. |
A genuine discrepancy worth flagging
The paper’s own measurement says the caller-ID number report fires on every incoming call, even for contacts already saved on your phone. But per the paper’s “Response From Google” section, Google told the researchers the spam-protection data collection “only occurs for phone numbers not in the handset contacts list.” Those two statements directly conflict — either Google’s explanation to the researchers was inaccurate, or the behavior differs from what the researchers measured. The paper doesn’t resolve this; it just reports both, side by side. Worth naming directly if you cite this, rather than picking whichever side is more convenient.
What Google said and did (Dialer-specific)
- Google’s stated purpose for the Caller ID/Spam Protection number collection: user protection from spam calls.
- Google committed to fuzz the SCOOBY_EVENTS timestamp to the nearest hour, server-side immediately and client-side from Dialer app version v75 onwards — this is a real, version-numbered commitment, unlike the Messages phone-number/ICCID fixes. Note this only coarsens the timestamp; it doesn’t stop the phone number itself from being sent.
- Google committed to remove call-related event logging from Firebase Analytics for both Dialer and Messages, again with no version number given.
- Google planned a “product tour” and a visual in-app indicator to tell users Caller ID/Spam Protection is on and how to disable it — an acknowledgment that most users likely don’t know it’s active, since it’s on by default.
The paper says Google’s stated justification for the hashing was to detect message sequencing bugs. However, there are some problems with this as an explanation:
- Google never allowed users to consent to or opt out of this behaviour; a legitimate, value-added service would do so
- There’s no user-supporting reason why data that can be linked to your hardware ID, SIM ICCID, and Google Account, need to be sent out to a logging service
Conclusions
Per the paper, Google committed to stop collecting the hash in Messages v10.9.160, and the phone number and SIM ICCID in later, unspecified releases. If it were a clean value-add to users, it would make more sense to just keep and disclose the functionality; this comes across more like Google sullenly withdrawing their hand from the cookie jar once called out.
Tech learnings
Inspecting traffic
The researchers used mitmproxy 6.0.2 on their Raspberry Pi Wi-Fi access point to capture traffic. They used an iptables rule to redirect HTTP/S traffic to port 8080 (the mitmproxy listener).
They specifically blocked UDP on 443 to force traffic using the proprietary QUIC protocol (TL;DR) to fail over to TCP.
Related questions
Did Google ever remove the phone and SIM ICCID logging?
Unverified from the web searching I’ve done so far.
Does Google normally announce updates to issues like this anywhere?
TL;DR: not in detail or proactively.
The Play Store has generic release notes, but they’re too vague to pin a specific bugfix to a specific version, and official blogs (Android Developers Blog, Google Security Blog, Google’s “Safety Center”) usually concern security patches (CVEs), major feature launches, or policy changes Google wants credit for; a privacy-violating “oopsie” doesn’t fit that brand.
In this case, Google privately responded to Leith during co-ordinated vulnerability disclosure, which he chose to publish in his own paper. Google also provided damage-control statements to journalists (The Register, Android Police, MobileSyrup) once the story broke in March 2022. These were not proactive public statements.
How would I verify the status of this vulnerability myself?
Follow Leith’s methodology in the paper: decompile sequential Messages APKs from spring 2022 onward and note which version’s code no longer has CARRIER_SERVICES logging phone numbers and collecting SIM ICCIDs.