Google’s Secret Location Tracking Database

Resilient Life Public Resilient Life
, ,
1

Originally published at: https://peakprosperity.com/google-location-tracking-database/

Note: Above Phone and Peak have started an affiliate relationship. Nick spoke with Hakeem and his team extensively about their offering, and it feels right. I (Chris) now have an Above Phone and, because Hakeem will be coming to the summit, I will have the opportunity to get it set up and get acquainted with how to begin removing myself from the grid…at least a little bit. If you are coming to the summit and are interested in the Above Phone concept, be sure to attend Hakeem’s session on Saturday at 2:00, “Protecting Youth from Surveillance at School.” See you there!

Behind the maps on mobile phones exists a secret geolocation database, quietly collecting the location history of billions of people around the world.

All Android phones, and even Apple phones using Google Maps, became personalized tracking beacons, with billions of points searchable in time and space.

All of this data lives on in Sensorvault, a geolocation database and ‘geofencing’ program. Sensorvault was one of the first tools of its kind, which made it easy for law enforcement to identify the location of phones using a map-like interface.

They pick the date and time, draw an area around the map, and can then see a list of any phones in that area.

The Sensorvault database played a pivotal role in identifying thousands of participants in the January 6th events in Washington, DC, showcasing both its power and raising alarming privacy concerns.

Federal investigators submitted what may be the largest geofence warrant in history, demanding data on every device within the Capitol building during a four-and-a-half-hour window.

The precision of Sensorvault proved remarkable, recording an average of 22 distinct location points accurate enough to track the movement of each “suspect” even between floors of the building.

This is thanks to the new WiFi Positioning Systems that phones use today. Instead of using GPS satellites, phones estimate their location by looking up the location of nearby WiFi networks.

Apple and Google both have huge troves of WiFi location data. In 2022, researchers discovered Apple had more than 2 billion WiFi access points and their locations around the globe.

After the Sensorvault story was uncovered, Google announced in late 2023 that they would save Google Maps location history on the devices instead by default.

This feels like a misleading effort, as no mention of the Sensorvault program was made, and it would be trivial for Google to collect that location data from the location services that run on the phone.

And while we only have clear information about Sensorvault, it certainly isn’t the only geofencing database out there. Any location-driven app or service with a massive user base has the potential to do the exact same thing.

These providers can then aggregate and sell the data to the highest bidder, including law enforcement.

It is in this way that they circumvent the constitutional right to privacy and due process.

Geofence warrants have seen explosive growth, from fewer than 500 requests in early 2018 to over 3,000 per quarter by late 2020. Law enforcement agencies increasingly rely on this tool for investigations ranging from local burglaries to organized crime, effectively turning every phone into a dystopian corporate promise: surveillance as a service.

What can you do about it?

Unfortunately, big tech phones will always be vulnerable to this type of tracking.

Even when users choose the best privacy options, both iPhone and Android devices continue transmitting detailed location and identification data to their respective servers. This creates a permanent record of movement and behavior that proves nearly impossible to erase.

Only de-googled phones avoid using big tech location services entirely. Everyone else should avoid bringing their phones to protests.

For those genuinely concerned about privacy, completely opting out of Google’s surveillance is the way to go.

Open-source operating systems like GrapheneOS give you the ability to avoid using Google services and control the permissions your apps use.

As this surveillance infrastructure expands, phone users face a stark choice of either complying with the surveillance, contact tracing, and digital ID schemes, or opting out entirely.

Above Phone brings privacy and freedom back to your life with a range of de-googled phone solutions based off of GrapheneOS.

These phones make zero connections to big tech, work with any cell service, and make it easy to find the apps you love while maintaining your control of them.

This isn’t just an alternative; it’s better than big tech. You’ll unlock features like:

  • An Internet phone number you can run simultaneously that works worldwide.
  • Watch videos without ads and download them to your phone.
  • Navigate across the country with offline maps.
  • And much more!

Don’t let yourself be a Sensorvault datapoint. Learn about de-googled phones now and take control of your privacy.

~ Hakeem

8 Likes
2

Sounds interesting. I look forward to learning more. I used a PinePhone 64 for a while but it quit working with towers in my area, and my grasp of Linux was not great enough to overcome it if it was a software issue.

I loved that it had hardware switches for. Various components, like camera, wifi, gps.

The separate VOIP number is appealing. I had one for many years with Skype that brought privacy and security for some types of business etc, but they ended the product/ service recently.

3 Likes
3

I just got a bag that seems to block Wifi, Bluetooth, and cell network connections to my phone: “Mission Darkness Non-Window Faraday Bag”

Not a complete solution, but I use it occassionally when I am in do not disturb mode.

2 Likes
4

Location data is a drop in the bucket. This is the unresolved turd in the proverbial GrapheneOS “anonymity” bucket:

5 Likes
5

If this was actually used against criminals I think this might be good on balance.

But it seems to be mostly weaponized against law abiding citizens by the FBI. How many drive-by shootings and murders go unsolved? What about carjackings?

In Los Angeles people report having their cars or homes broken into and the police basically tell the people that they shouldn’t even bother reporting it, because nothing will happen.

This story of the huge bust of the burglary ring in Southern California - they say these guys had hit over 90 homes. How had they hit that many places when their phones and cars were tracking them, and there are cameras on many street corners taking license plates?

10 Likes
6

I like your avatar, but just thinking about carrying that axe and the sword - already makes you a criminal.

We are all potential criminals according to the government in charge (at the time and at the place). We all know Governments can change, too and abuse their powers. “Because the can”.

I don’t feel safer with surveillance cameras on the road, radar cameras, GPS tracking, digitalID.

Has any of this technology actually made us ‘safer’? I don’t think so. London UK was one of the first, if not the first, city to install surveillance cameras just about everywhere. Now, they don’t seem to care about the crime that their terrible migrant policy has brought. They just want to police and criminalize those who voice an objection to the migrants and the policy.

It seems that it would take a major terrorist incident for the police to look at the cameras. A stolen car? A mugging? Hit and run? forget about asking for the police to access their cameras to try to solve a real crime. Perhaps they may look but report back that the camera wasnt working or that there was a black smudge in the frame.

Not surprising about the burglary ring in Los Angeles hitting over 90 homes before being apprehended. I suppose this is getting to the range of a major terrorist incident and time to act. It’s not exactly about the crime, it is the degree of the crime.

I just feel far less free and less safe with all this surveillance. I see it coming to Vietnam too - at light speed. Galloping into the future.

Perhaps this phone will help? Maybe a little bit, if you want to have a full graphical interface, be connected with instant communications and being able to consume unlimited amounts of content. I am coming close to ditching any time of smart phone and going old school Nokia to use as a phone only. I can still get unregistered random SIM cards here in VIetnam.

When the time comes that I must register with DigitalID here in Vietnam, I will go in first with a simple phone and SIM card ‘registered to my name’. If I eventually succumb to the system and register, I will certainly leave this phone with this particular SIM card at my home, turned off and in perhaps a Faraday bag. I’ll only use it for the minimum mandatory things and nothing more. Of course, it will be mandatory for more and more things over time. I’m afraid of the day when they will make it mandatory to carry it with you at all time with random police checks - “Ausweis Bitte”. I suppose, then if it becomes to bothersome, I will show my personal tracking device but it will be turned off without any battery. “The battery just died.”

I am a bit suspicious and subversive, I don’t want the system to control me. My digital twin will be infinitely more paranoid than even I am. I won’t see anything good from this.

My question is can I survive free of our digital life. Maybe, perhaps I might even thrive. We don’t need to be plugged into the ethernet 100% of the time. I still think life was better three or 4 decades ago. We used to socialize more and had more time for real things.

4 Likes
7

“This ain’t the 90’s.” The level of sophistication in surveillance requires vigilance if we’re to maintain as much privacy as possible. I’ve been using a DeGoogled phone now for quite some time and am never going back!

https://x.com/MichaelAArouet/status/1964267560087527523

11 Likes
8

I’ve lived most of my life without a mobile phone. I don’t take it outside the house unless I know I’m going to need it. Why would I?
And there’s a small hack you can do to turn the phone sensors off. I don’t know if it’s perfect, but it does at least somewhat work.
And once I fix the computer, it’ll be back to a dumbphone.
I do like phones with all the bells and whistles, they’re pretty amazing, but I dislike total surveillance more. I want to put that off as long as possible.

3 Likes
9

Some sort of digital ID registration scheme is brewing in Australia, but for the time being I take simple measures like nearly always leaving my iPhone at home when I go out, and using a book map (still readily available) when travelling. I have a Faraday bag but haven’t made much use of it.

Usually most of the advice in articles like this one is US-centric and the technologies aren’t available elsewhere. One day I suppose I’ll be motivated to seek local ways to cope with Big Brother, but until then I’ll just have to keep alert. It’s all so exhausting.

2 Likes
10

Hi, good topic. I’ve used a similar solution for a few years. I ran CalyxOS on a Google Pixel 4a and then 6a. Worked pretty well, only some apps refused. Loved the privacy it gave me. And yes, the YouTube replacement NewPipe was really nice. Just remember that it’s a cat-and-mouse game. If Big Tech considers these side uses a problem, they can squash it.

Some apps not working was not a problem until one of the apps was my new bank. The app detected it was not installed through the official store. At that point Apple had launched Lockdown Mode and allowed you to have end-to-end encrypted iCloud backups by refreshing your encryption key and storing it yourself, called ‘Advanced Data Protection’. Easy to setup and clearly explained during the process.

So, at this point I’m back on an iPhone. I like that everything ‘just works’ and that security updates arrive as soon as they are available. I don’t have any Google Apps on my device and use Next DNS to block the vast majority of outgoing telemetry and tracking data. I also run Mullvad VPN. I’m happy with this setup and it fits my threat model.

If your threat model is different, you may wish to consider a custom ROM Android. My advise is, if you can, try to get your hands on an old Android phone which is supported by your target OS (like GrapheneOS or Lineage) and play with it for a bit. See if you like it before committing.

Edit: just remembered, if the camera app is important to you, try it on a test device. The privacy-focused camera apps are less capable and slower than the stock Android or Apple ones. Manageable I think, but if you’re a parent wanting to shoot quick and great pics of your kids, this could be an issuse.

1 Like
11

People that know I’m in tech often ask me: is Apple bad for privacy?

Well, we all know Google is pretty evil when it comes to user privacy. And the post by Hakeem highlights that Apple has a lot of location data. Yes, they do. And if you turn of Wi-Fi, reportedly the Wi-Fi antenna it still used to help with location accuracy. Plus they probably send too much telemetry back to the mothership. Personally, I limit what data is available, see post above.

So, Apple has more data than the average user would like. What I’m not aware of, is them misusing or selling this data. It is a risk - but to my knowledge they have been responsible.

Have I missed something? Does Apple abuse our data? Would like to hear from the community to better inform my own decision and advise others.

1 Like
12

Before cell phones and the internet I used ham radio a couple times to notify police. You contact another ham to make a telephone call.

If you don’t want to carry a phone, a ham walkie talkie and some familiarity with procedures can give you a lifeline.

GMRS or FRS offer similiar opportunities.

5 Likes
13

Thanks for the comment! Yes we’ve also found that LinuxPhones aren’t ready for primetime yet - and the security model of Android phones is far better with built in sandboxing of applications, and verified boot - which will ensure that malware can’t persist on the device.

We’re keeping a close eye on Linux Phone developments and maybe there will be a Linux solution in the future.

The VoIP number is a game changer, it’ll provide connectivity to those cutoff from normal cell services - for instance, countries that require a Digital ID to get a SIM card or use a phone. You can use this solution and connect to WiFi and get the same (really better) functionality.

Its an important tool of resistance and productivity as we build our counter-economy.

4 Likes
14

That’s a great start! One thing we have to remember with big tech phones is that they’re patient.

They can still gather data when they’re cutoff from the internet. When they get online again its easy for them to send that out.

I would suggest shutting it off too (although this isn’t a guarantee failsafe on modern phones)

Having a degoogled phone like the above phone addresses this completely as you have control over your apps and there’s no centralized connection to big tech.

1 Like
15

Combining my replies from here on out since there’s so much interest! Thanks everyone who commented. I look forward to contributing more here.

First - thanks for bringing my attention to this.

I wouldn’t say location tracking is a drop in the bucket. Its one of the most important tracking mechanisms that can be used in a court of law - to get you in trouble for things you’ve done in real life. It has a real impact.

This also goes for the microphone permissions that centralized big tech services have over normal phones, which degoogled phones don’t have. Billions of conversations are being eavesdropped by normal phones.

Back to your concern, yes I agree fingerprinting is a real issue, however I believe that this particular issue is mitigated when using user profiles correctly.

A bit of background: Fingerprinting is a thing websites can choose to do to try and track their users. It doesn’t mean all websites are doing it, but surely the big ones are.

Browsers have access to device APIs, and by rendering the web page you can get an idea of the device’s performance. There are also other IDs that can be used for phones like the AndroidID. The performance combined with device IDs creates a ‘fingerprint’ that can be used to detect recurring visits on the same time.

However, GrapheneOS has done more than any mobile OS to address the issue.

For one, there are no phone level IDs being shared with your apps or web browser - IDs like the AndroidID are randomized regularly.

This is a feature not available on most devices, except for degoogled phones.

Additionally, google and apple services have access to other IDs that uniquely identify your device - such as the IMEI. These services only run with full permission on normal phones.

To summarize that thread, someone tested the most popular fingerprinting software (that runs on web browsers) that showed the DRM Media ID stayed constant across two web browsers on the different profile.

This should not effect people who are using their user profiles the right way.

Why? The DRM Media ID stays constant per app across profiles, however it is differs across app.

This issue would only effect you if you were using the same app across different profiles.

Our guidance is to use different apps in each profile which should change the DRM Media ID.

For instance, your main profile has your personal apps. You have a separate profile for banking and travel apps. Another profile for big tech messaging apps.

Although we didn’t key in on this particular issue, we have covered user profiles on our webinar here: One Phone, Multiple Personas

I will likely add a lesson just for this, my solution would be to use different web browsers per profile.

–
And it isn’t an issue directly with GOS, but exists on all Android phones. Although I haven’t researched what happens exactly on iPhones - iOS has its own Media DRM API, called ‘Fairplay’ which likely has the same issue.

Additionally, GOS has addressed the issue and are planning a fix. No other project goes farther, and the phone provides more privacy and security guarantees than any other phone you can use today.

Thanks again!

3 Likes
16

Ok - now I’m actually combining my replies :joy:

@sonjax6

What ever happened to good old fashioned detective work? But yes - with all this surveillance, we find little justice for crimes, at least for everyday people. Its not about our safety, its about their power.

Yes - and also there are important solutions such as offline maps, cryptocurrency, and decentralized applications. I believe we will need to rely on apps like these to maintain connection with the broader world in a private and in-control way.

I am following the situation in Vietnam and how Digital IDs seemed to have popped up overnight. Its very unfortunate. I do appreciate how you’ve thought through the situation and your approach seems reasonable.

In the end though, no one can force you to carry a phone. Cheers!

That’s great, I’m happy you’ve set your boundaries with your tech usage. I don’t think everyone needs a phone.

As for me, I’d like to grow my business, community, and be connected with the world at large - to learn, and to spread the message of freedom.

All this while still being private. We do have the technology to do this, right now. And the more people using it, the more useful it is for everyone. :slight_smile:

Everything I’ve mentioned applies worldwide. Australia is actually one of our top-selling countries too, maybe because they are farther along with their surveillance state. I am connected with the privacy communities there and they are taking action. I invite you to do thes same.

Its always a game with any form of resistance, the mouse is a powerful being in its own right. The parable of the mouse and the lion comes to mind.

Re: banking apps, many banking apps still work (local smaller banks most likely) - we recommend people to use the web browser for their banking in a separate profile. We haven’t received complaints on this so it works for most people.

Apple, although I’m fond of its origins, is now cut from the same cloth as Google. Its actually more locked down than Google’s ecosystem - they must approve and have control over every aspect of your phone. They can uninstall apps remotely if they wanted.

Yes - they abuse people’s data. Good example of this is the OCSP stapling, basically everytime you opened an application on your Mac, they would send out your device identifier and App identifier - over the open internet, unencrypted. This was an easy layup for an intelligence agency, or telecom monitoring network traffic.

Agree completely and I need to educate myself better on radio.

Thanks everyone for the replies!

4 Likes
17

I don’t think you understand that the Media DRM Identifier is persistent to the devices (it is literally the Device ID str) across profiles and does not change with factory resets.

Aside from the obvious infinite session associations that can be made by third parties with the device, the implications of this includes among other things location tracking (think of the myriad of deanonymization vectors via websockets / layer 7 eith JS / client-side timings to ANYCAST’d endpoints like CDNs, DNS resolvers, CSP endpoints).

Widevine is nasty. Until GOS and uostream provide that “toggle” for the per app isolation MDTMID placeholder, it’s a fucking problem.

2 Likes
18

Its different per app.

According to the GOS dev: “The current implementation is a per-app ID rather than a per-app-per-profile ID as it should have been.”

From Android’s own docs:

“If this isn’t sufficient protection, Android provides a DRM API, which can be used to limit access to content, includes a per-APK identifier, the Widevine ID.”

And according to the test in the original post it does change on factory reset.

“The Media DRM ID (MediaDRM) was the exact same across all profiles and only changed if the whole device was factory reset.”

Is there another phone / OS you know of that makes Media DRM IDs useless?

Always happy to evaluate other solutions. But if there isn’t anything else, and knowing all of the privacy improvements GOS provides and knowing they have a plan (toggle & virtualization of apps) - this really feels like splitting hairs to me when there’s a solution that deals with 80% of modern privacy threats, which mostly falls under big tech tracking.

Also, given that most of the apps are open-source on the phone and don’t use fingerprinting libraries - it may not be as big of an impact as you think. The big tech apps that are likely to use this are recommended to be used in another profile for this reason.

The protection doesn’t rely on a single OS, its a holistic approach where the OS, apps, and services work together.

That being said, we are going to change our official recommendation to suggest people use different browsers in secondary profiles.

Thanks again!

19

That’s not at all the same identifier. I suggest you get up to speed on the issue so as not to mislead people.

Static Media DRM ID on GrapheneOS: Privacy and Anonymity Analysis

Overview of the Media DRM ID Problem

The Media DRM ID (Digital Rights Management identifier) on Pixel phones running GrapheneOS presents a significant privacy vulnerability that undermines anonymity efforts. This identifier is static, globally unique, and persists across app installations, factory resets, and user profiles [1][2][3][4][5], making it one of the most problematic tracking vectors in the Android ecosystem.

Technical Nature of the Media DRM ID

Widevine Client ID Structure

The Media DRM ID is part of the Widevine Client ID system, which consists of two main components [6]:

Client Info metadata including:

  • CPU architecture (e.g., arm64-v8a)

  • Device manufacturer (e.g., Google)

  • Device model name (e.g., Pixel 7)

  • Complete build information

  • Application package name and certificate hash

  • CDM version and security patch levels

Device RSA Public Key and Certificate Chain - a unique cryptographic identifier provisioned at the factory level that creates a hardware-based root of trust [6:1].

Static and Persistent Characteristics

The identifier exhibits several concerning properties [2:1][4:1][6:2]:

  • Cross-profile persistence: The same DRM ID appears across all user profiles and Private Space

  • Factory reset resistance: The identifier survives complete device wipes on recent Pixel devices [3:1]

  • App-independent: Unlike Android ID, the Media DRM ID remains identical across different applications

  • Immediate accessibility: Available to any app without special permissions through standard MediaDRM API calls

Exposure to Apps and Browsers

App Access Mechanisms

Applications can access the Media DRM ID through straightforward Android API calls [7][8]:


UUID wideVineUuid = new UUID(-0x121074568629b532L, -0x5c37d8232ae2de13L);

MediaDrm wvDrm = new MediaDrm(wideVineUuid);

byte[] wideVineId = wvDrm.getPropertyByteArray(MediaDrm.PROPERTY_DEVICE_UNIQUE_ID);

This requires no special permissions and works even when all other permissions are denied [9]. The identifier can be obtained by:

  • Banking and financial applications [2:2]

  • Social media platforms

  • Any app using fingerprinting libraries [10]

  • Web browsers through EME (Encrypted Media Extensions) APIs [6:3]

Browser Fingerprinting Exposure

Web browsers can access DRM identifiers through the EME standard, which was designed for legitimate content protection but creates privacy vulnerabilities [6:4][11]. Research shows that:

  • Firefox on mobile transmits the Client ID in clear text without privacy mode encryption [6:5]

  • Many browsers fail to implement proper EME privacy guidelines [6:6]

  • JavaScript code can obtain DRM identifiers with minimal user consent [6:7]

  • The identifier works as a “never-lying User-Agent” that cannot be spoofed [6:8]

Privacy and Anonymity Threat Modeling

High-Impact Threat Scenarios

Cross-Platform Tracking: Adversaries can link user activity across completely separate applications, browsers, and even different user profiles on the same device [1:1][2:3][6:9]. This defeats the purpose of GrapheneOS’s profile isolation.

Long-Term Surveillance: The persistence of the identifier through factory resets means that even users who completely wipe their devices remain trackable [3:2]. This is particularly concerning for activists, journalists, or anyone requiring operational security.

Defeating Privacy Tools: Users employing VPNs, Tor, cookie blocking, or user-agent spoofing can still be tracked through this hardware-level identifier [6:10][9:1]. The DRM ID effectively bypasses most privacy countermeasures.

Profile Correlation: Despite GrapheneOS’s strong profile separation, the shared DRM ID allows linking activities between the main profile and work profiles or Private Space [12][5:1].

Anonymity Set Reduction

The DRM ID creates a unique global fingerprint for each device, reducing the anonymity set to exactly one user [6:11][9:2]. Combined with other available metadata:

  • Device model and build information

  • Application lists and installation patterns

  • Network characteristics

  • Behavioral patterns

This creates an extremely high-entropy fingerprint that can uniquely identify users even when other identifiers are randomized or blocked.

Threat Actor Capabilities

Government Surveillance: State actors with access to DRM identifier databases can track individuals across services and time periods, even after attempts to create new identities.

Corporate Data Brokers: Companies can build persistent profiles linking purchasing behavior, app usage, and browsing activity across years of device usage.

Criminal Organizations: Fraudsters can use DRM IDs for account takeover attacks by identifying when the same device accesses multiple accounts.

GrapheneOS Response and Mitigations

Community-Developed Solutions

A GrapheneOS community member recently developed a DRM ID spoofing feature that generates unique identifiers per app per user profile [1:2]. This system:

  • Creates consistent but unique DRM IDs for each user/app combination

  • Uses SHA-256 hashing of Android ID and package name

  • Maintains stability for legitimate app functionality while preventing cross-app tracking

Current GrapheneOS Limitations

Standard GrapheneOS installations currently provide no built-in protection against DRM ID tracking [3:3][9:3]. Users can:

  • Disable network permissions for system DRM services [limited effectiveness]

  • Use developer settings to force software-based DRM [may break media playback]

  • Avoid installing apps that require DRM functionality

However, these mitigations significantly impact device usability and don’t address browser-based tracking.

Recommended Threat Model Considerations

For users requiring high anonymity:

  • The persistent DRM ID makes GrapheneOS unsuitable for scenarios requiring unlinkable identities

  • Users should consider that device-level tracking persists regardless of profile separation

  • Banking apps and media streaming services will inherently compromise anonymity

For privacy-focused users:

  • Profile isolation still provides protection against most app-level data sharing

  • The DRM ID represents one vector among many for device fingerprinting

  • Strong operational security practices remain essential

Future Outlook

The MediaDRM identifier issue highlights the fundamental tension between hardware security features and privacy. While GrapheneOS provides exceptional security through hardware attestation and verified boot, these same features create persistent identifiers that undermine anonymity.

The community-developed spoofing solution [1:3] represents a promising approach, but widespread adoption will require integration into the main GrapheneOS codebase. Until then, users must carefully evaluate whether the security benefits of GrapheneOS outweigh the anonymity costs for their specific threat model.

This situation exemplifies why security and privacy often require different design tradeoffs, and no single operating system can perfectly serve all use cases simultaneously.

[13][14][15][16][17][18][19][20][21][22][23][24][25][26][27][28][29][30][31][32][33][34][35][36][37][38][39][40][41][42][43][44][45][46][47][48][49][50][51][52][53][54][55][56][57][58][59][60][61][62][63][64][65]

  1. I made a new feature that spoofs media DRM id - GrapheneOS Discussion Forum ↩︎ ↩︎ ↩︎ ↩︎

  2. Device Fingerprinting Test Results, Concerns, and Questions - GrapheneOS Discussion Forum ↩︎ ↩︎ ↩︎ ↩︎

  3. MediaDRM identifier - GrapheneOS Discussion Forum ↩︎ ↩︎ ↩︎ ↩︎

  4. Identifiable device parameters - GrapheneOS Discussion Forum ↩︎ ↩︎

  5. Unique DRM ID - GrapheneOS Discussion Forum ↩︎ ↩︎

  6. https://arxiv.org/pdf/2308.05416.pdf ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  7. https://stackoverflow.com/questions/67396257/android-mediadrm-unique-id ↩︎

  8. https://stackoverflow.com/questions/64509905/how-to-get-unique-id-in-android-q-that-must-be-same-while-uninstalling-and-inst ↩︎

  9. FINGERPRINTING - So much data exposed to apps by default! - GrapheneOS Discussion Forum ↩︎ ↩︎ ↩︎ ↩︎

  10. GitHub - fingerprintjs/fingerprintjs-android: Swiss army knife for identifying and fingerprinting Android devices. MIT license, no restrictions on usage in production. See link below to get the Pro version with 500K free monthly API calls. ↩︎

  11. [2308.05416] Your DRM Can Watch You Too: Exploring the Privacy Implications of Browsers (mis)Implementations of Widevine EME ↩︎

  12. Identifiers across private space and profiles - GrapheneOS Discussion Forum ↩︎

  13. Google’s Identity Check for Android keeps phone thieves out of your digital accounts | The Verge ↩︎

  14. Usage guide | GrapheneOS ↩︎

  15. Google's New Feature Ensures Your Pixel Phone Hasn't Been Hacked. Here’s How It Works | WIRED ↩︎

  16. https://www.reddit.com/r/GrapheneOS/comments/bg03np/browsers/ ↩︎

  17. https://www.reddit.com/r/GrapheneOS/comments/ej2vz8/does_grapheneos_leak_any_unique_identifiers_to/ ↩︎

  18. Are the new Google Pixel phones spying on you? | TechRadar ↩︎

  19. Features overview | GrapheneOS ↩︎

  20. https://blogs.ischool.berkeley.edu/w231/2022/03/09/google-pixel-privacy-issues/ ↩︎

  21. Best browser/ user setup? - GrapheneOS Discussion Forum ↩︎

  22. https://www.reddit.com/r/GooglePixel/comments/p33y82/pixel_phones_drm/ ↩︎

  23. https://www.youtube.com/watch?v=dPXu-XKxBT4 ↩︎

  24. Manage security & privacy settings on your Pixel phone - Pixel Phone Help ↩︎

  25. https://www.youtube.com/watch?v=FEN_NvKsVBc ↩︎

  26. Google’s Advanced Protection Arrives on Android: Should You Use It? | Electronic Frontier Foundation ↩︎

  27. https://www.reddit.com/r/degoogle/comments/1kubi9x/grapheneos_really_can_save_my_privacy_i_mean/ ↩︎

  28. https://stackoverflow.com/questions/2785485/is-there-a-unique-android-device-id/64032032 ↩︎

  29. Websites Are Tracking You Via Browser Fingerprinting | Texas A&M Engineering Experiment Station ↩︎

  30. The good, the bad, and the ugly about browser fingerprinting - Hoxhunt ↩︎

  31. Help with appropriate Threat Model and Profiles - GrapheneOS Discussion Forum ↩︎

  32. https://arxiv.org/pdf/2506.22639.pdf ↩︎

  33. How Device Fingerprinting Works: A Comprehensive Guide - Doverunner ↩︎

  34. MediaDrm | Android Developers ↩︎

  35. Understanding Hardware Fingerprint, Browser Fingerprint, and Device Fingerprint in DRM Protection. Lock PDF to a specific device – VeryPDF DRM Protector ↩︎

  36. MediaDrm - Android SDK | Android Developers ↩︎

  37. What Is Browser Fingerprinting and How Does It Work? ↩︎

  38. Frequently Asked Questions | GrapheneOS ↩︎

  39. Build  |  API reference  |  Android Developers ↩︎

  40. What is Google Widevine DRM? How Does Widevine Work? - OTTVerse ↩︎

  41. Practical GrapheneOS for the Paranoid • Ventral Digital ↩︎

  42. https://www.reddit.com/r/privacy/comments/10vcdpq/does_widevine_allow_good_to_track_all_sites/ ↩︎

  43. Android vs GrapheneOS: Privacy, Security & Features Compared ↩︎

  44. Privacy implications of browsers’ (mis)implementations of Widevine EME (2023) | Hacker News ↩︎

  45. Google Widevine DRM: Guide to Security & Integration ↩︎

  46. https://www.reddit.com/r/privacy/comments/sk05wx/is_grapheneos_really_secure/ ↩︎

  47. https://petsymposium.org/popets/2023/popets-2023-0112.pdf ↩︎

  48. https://www.youtube.com/watch?v=zT3EOSjCvsA ↩︎

  49. Releases | GrapheneOS ↩︎

  50. https://www.reddit.com/r/androiddev/comments/19895zn/using_drm_to_provide_a_unique_id/ ↩︎

  51. https://docs.verimatrix.com/docs/how-are-devices-counted-by-the-system ↩︎

  52. https://www.radware.com/cyberpedia/bot-management/device-fingerprinting/ ↩︎

  53. https://lemmy.world/post/32187260 ↩︎

  54. https://iut-fbleau.fr/docs/android/training/articles/user-data-ids.html ↩︎

  55. https://workos.com/blog/beyond-the-basics-why-device-fingerprinting-is-mission-critical-in-2025 ↩︎

  56. https://www.celersms.com/device-id-android.htm ↩︎

  57. https://www.w3.org/2014/strint/papers/41.pdf ↩︎

  58. https://lemmy.toot.pt/comment/586218 ↩︎

  59. https://proandroiddev.com/how-to-generate-android-unique-id-38362794e1a8 ↩︎

  60. https://www.iddataweb.com/beyond-device-fingerprinting-orchestrating-device-risk-signals-into-every-access-decision/ ↩︎

  61. https://www.reddit.com/r/GrapheneOS/comments/1iok64k/allow_users_to_spoof_device_model_for_enhanced/ ↩︎

  62. https://docs.talsec.app/appsec-articles/articles/fraud-proofing-an-android-app-choosing-the-best-device-id-for-promo-abuse-prevention ↩︎

  63. https://chargebacks911.com/device-fingerprinting/ ↩︎

  64. https://w3c.github.io/fingerprinting-guidance/ ↩︎

  65. https://developer.android.com/identity/user-data-ids ↩︎

7 Likes
20

Hi Hakeem,

I want to make clear I’m a fan of privacy and appreciate you’re trying to make De-Googling easy. I myself had registered a bunch of domains in my country to try and do something similar. Just didn’t happen b/c my consulting work took all my time. Just to say: I support the mission!

Wanted to reply to your OCSP Stapling comment.

Hakeem: Yes - they (edit: Apple) abuse people’s data. Good example of this is the OCSP stapling, basically everytime you opened an application on your Mac, they would send out your device identifier and App identifier - over the open internet, unencrypted. This was an easy layup for an intelligence agency, or telecom monitoring network traffic.

I did some research because stapling wouldn’t be used for apps. It’s used when communicating with remote servers. Below is my fair assessment of the situation, which I composed with the help of ChatGPT, which you can find below.

In short: Yes, Apple had some undesirable privacy exposure and should have moved to a secure protocol earlier, but the exposure was limited and to me does not look malicious, rather inertia (things tend to stay the same until they need to change). Also of note, since this only applies to the desktop operating system.

My summary of Apple’s OCSP story
On macOS, Gatekeeper verifies all apps signed with a Developer ID certificate and distributed outside the Mac App Store by querying Apple’s OCSP servers at first launch and periodically afterward. These checks confirm the app’s integrity by validating its digital signature against a Developer ID certificate and ensuring that certificate hasn’t been revoked. Checking an app’s integrity is important for security (so you know it hasn’t been tampered with). Apps from the Mac App Store or signed by Apple skip these checks, while unsigned apps are blocked outright. This system means any third-party app—downloaded from a developer’s site, Homebrew, etc.—triggers an OCSP request whenever its signature needs validation.

From 2012 (OS X Mountain Lion) until mid-2021, these OCSP requests were sent over plain HTTP, exposing not just the developer identity but also a timeline of app launches tied to users’ IP addresses, allowing Apple or any network observer to infer app usage patterns and approximate location. However, this did not expose the app’s internal communication or network traffic—only the certificate check metadata was leaked. By 2019, industry best practice had shifted to OCSP over HTTPS (with browsers and CAs leading the way) due to privacy concerns. Apple didn’t adopt HTTPS until mid-2021, after a November 2020 OCSP outage caused app launches to hang and triggered a wave of public criticism over privacy and reliability. Their response was a quick HTTPS migration, but no major protocol redesign or promised opt-out feature.

OCSP stapling isn’t viable here because there’s no persistent server to fetch and attach fresh revocation proofs to a local app binary—developers distribute static files, so live checks are Apple’s way to revoke compromised Developer IDs instantly.

Currently, the OCSP requests on macOS expose: the Developer ID certificate serial number, issuer metadata, timestamp of the request, and the source IP address. Together, these allow Apple to have a correlation of app launch times, approximate location (unless using a VPN), and developer identity.