Exciting news for Safari users: Privacy Badger is now available on Safari for macOS! You’ll need Safari version 26.5 or higher to use it.

Whether you want to protect yourself from data brokers or just don’t want Big Tech profiting off your browsing data, Privacy Badger is here to help. More than 4 million people already use EFF’s free tracker-blocking extension to take a stand against online surveillance. Safari users can now join them and EFF in the fight for a better web.  

Install Privacy Badger

Support the Fight Against Online Tracking

Safari support has been one of Privacy Badger’s most requested features for years. Thanks to recent improvements in Safari's extension support, we’ve finally made it happen for Safari version 26.5 and higher. Privacy Badger is now available on all major desktop browsers. And before you ask, yes, we will look into supporting Safari for iOS once we've ironed out any issues on macOS.

Why Install Privacy Badger on Safari? 

Most websites contain invisible tracking code that lets companies collect, share, and profit from your personal data. Some of those companies are data brokers that sell your information to anyone willing to pay. Creepy ads are just the tip of the iceberg when it comes to the harms of online tracking: Once your information enters the data broker ecosystem, it’s nearly impossible to know who buys it or what they’re doing with it. Privacy Badger blocks online trackers to prevent your browsing data from being used against you.  

Privacy Badger goes beyond Safari’s built-in privacy features to provide additional protection against online tracking. In its default browsing mode, Safari limits the information that trackers can access but still allows them to load. Privacy Badger blocks trackers from loading in the first place, preventing them from tracking you using techniques that bypass Safari’s protections. 

Privacy Badger works well by itself, and will continue to enhance your privacy when installed along side an ad blocker or with Safari’s Advanced settings to block trackers in all windows. Since Privacy Badger automatically learns to block trackers, Privacy Badger will block trackers that other tools don’t know about or choose not to block. 

For example, Privacy Badger blocks tracking from widgets like embedded tweets, comments sections, and video players. These widgets can share your data even if you never click on them. Privacy Badger prevents these trackers from loading and replaces them with click-to-activate placeholders. 

Beyond tracker blocking, Privacy Badger automatically sends the Global Privacy Control (GPC) signal to tell websites not to sell or share your personal information. The GPC signal is already legally binding in a growing number of states, including California, Colorado, New Jersey, and Connecticut.  

All these features (and more) work together to help keep your browsing activity private on Safari. 

Try It Out and Spread the Word 

If you use Safari on macOS, give Privacy Badger a try. You’ll install Privacy Badger through the App Store on your macOS device. Installing extensions is a little more complicated on Safari than other browsers, so follow Apple’s directions here if you’re having trouble.  

This is our first release of Privacy Badger for Safari, and we will keep improving it based on your feedback. If you run into any problems, let us know by emailing extension-devs@eff.org, or by opening an issue on GitHub. And if blocking harmful trackers causes issues on a website you visit, you can disable Privacy Badger for that specific site while keeping it enabled and protecting you everywhere else. You can also let us know about broken sites by using the “Report broken site” button found next to the “Disable for this site” button in Privacy Badger’s popup window. 

When you use Privacy Badger, you join EFF and millions of other users in the fight for a better web. Help spread the word by telling your friends and family who use Safari that they can use Privacy Badger too!  

Install Privacy Badger 

Support the Fight Against Online Tracking 

EFF sued the government back in March for information about the Wasteful and Inappropriate Service Reduction (WISeR) model, a new Medicare program that uses AI to evaluate prior authorization requests for certain medical services. Today, we’re releasing approximately 1,000 pages of records obtained from the Centers for Medicare & Medicaid Services (CMS) through this litigation, including contracts with tech companies, internal status reports and providers’ complaints about the program. The documents (available here) show that WISeR has resulted in widespread delays and denials of care, operational chaos, and reports of patient harm.

DONATE TO EFF 

ensure ai serves people, not power

Why We Sued for Records about WISeR

EFF filed the FOIA lawsuit to gain badly needed transparency into an experimental AI program that could jeopardize Medicare beneficiaries' access to care. In January 2026, CMS launched the WISeR model, subjecting seniors in six states to AI-driven prior authorization decisions. Medical providers must now request permission before delivering certain medical treatments if they want assurance that Medicare will cover them. Private companies contracted by CMS evaluate the requests using AI. In the absence of rigorous safeguards, AI-driven prior authorization determinations can lead to unwarranted—and even discriminatory—delays or denials of necessary medical care. 

Little is known about the AI systems that WISeR vendors are using to process prior authorization requests. Although CMS says that a qualified human clinician must review all denials, research has shown that AI-generated recommendations often influence human decisions. And the design of the WISeR program creates a financial incentive for vendors to deny care, since they are paid for averted expenditures. Just months after the program launched, medical providers reported improper denials, administrative friction, and lengthy delays that have left patients waiting in pain.

EFF’s FOIA request sought records pertaining to the CMS contracts with WISeR software vendors; any tests for accuracy, bias, or hallucinations in vendors' technology; and any audits, monitoring, or evaluation of WISeR and participating vendors.

CMS Documents Highlight Issues with the WISeR Model

CMS records obtained by EFF echo issues that medical providers, patient advocates, and lawmakers have warned about since WISeR began. This includes long wait times, rampant technical failures, inappropriate denials, and harm to patients.

Delayed Responses to Prior Authorization Requests

CMS publicly states that WISeR vendors should respond to prior authorization requests within 72 hours, but records received by EFF show widespread delays. Internal status reports from the first few months of the program show that a significant number of prior authorization requests took far longer than 72 hours to resolve. One status report cites a prior authorization request that went unanswered for 83 days ("WISeR FOIA Response - Combined Records," page 234). These delayed responses can have serious consequences for patients. Medical providers reported that WISeR has delayed medically necessary care and left patients in pain as they waited for approvals.

Payment Methodology Provides Financial Incentive to Deny Care 

The released records confirm that WISeR’s payment methodology creates a financial incentive to deny care. Specifically, WISeR vendors are paid for requests that they deny (though not for denials reversed on appeal). This profit motive aggravates the risk that AI-assisted decision-making may unfairly deprive people of the services they need.

CMS publicly claims that it safeguards against inappropriate denials by tying vendors’ payment rates to “quality scores,” which reflect the timeliness and accuracy of vendors’ decisions. However, the recently released WISeR Data Reporting Guide shows that low quality scores reduce payments by only 5-10%.

WISeR Vendors Have Denied Thousands of Prior Authorization Requests

Documents obtained by EFF appear to support reports that WISeR vendors may be denying claims at unusually high rates. Two companies alone denied 5,944 prior authorization requests in the first 3 months of the program. One company, Virtix, the vendor that CMS required to submit a Corrective Action Plan, denied more requests than it approved during this time period.

Medical Provider Feedback Ties WISeR Delays to Patient Harm

Feedback from medical providers emphasize that WISeR delays have harmed patients. The released records include March 2026 responses to a feedback form about Innovaccer, the WISeR vendor processing requests for Ohio. Medical providers complained about a lack of communication, administrative issues, and long response times. Several responses emphasize that long response times from the WISeR vendor harmed patients ("WISeR FOIA Response - Feedback Survey Responses"):

“We have patients calling our offices crying in pain because their procedures are being delayed while awaiting approvals or guidance tied to this model. A 3–4 day delay for necessary pain procedures is already difficult for vulnerable patients, but when providers cannot obtain answers for weeks, the situation becomes unacceptable.”

“I HAVE HAD TO WATCH 3 PATIENTS CRY AT BEDSIDE FOR NOT HEARING BACK ON THEIR PRIOR AUTH FOR KYPHOPLASTY/VERTABRAL AUGMENTIATION PROCEDURE. THESE PATIENTS ARE IN DEEP PAIN.”

“I have had cases submitted and waiting over 1 1/2 months for a UTN to be generated… In the meantime patients are having to be cancelled for surgeries they need. This is not acceptable they are severely hindering patient care.”

Rushed Rollout Amidst Widespread Technical Failures 

CMS WISeR launched in January 2026, just six months after it was announced. Despite warnings from both medical providers and a vendor about insufficient preparation time, CMS chose not to delay the launch. 

Approximately a month before the launch, one of the vendors, Innovaccer, alerted CMS that it intended to go live with a version of its software that lacked full functionality and had not been fully tested. It cited several barriers to going live with full functionality, including changing requirements and expectations, unclear governance processes, and lack of time for end-to-end testing with the provider community ("WISeR FOIA Response - Combined Records,", page 216-217). Innovaccer said it would auto-affirm all prior authorization requests until it could develop full functionality and explained that “Given CMS's decision not to delay the model start date, auto-affirming is the only path available” ("WISeR FOIA Response - Combined Records," page 217).

Innovaccer had not yet finished developing or testing some features several months into the program, according to an April 2026 status report. Innovaccer was not the only vendor who faced technical challenges before and after WISeR launched. Weekly status reports and provider feedback in the released records show widespread challenges associated with WISeR’s rushed rollout (for example, "WISeR FOIA Response - Combined Records," pages 238 and 383).

More Urgent Medical Services Considered for Inclusion in Future Years of WISeR Model

In its first year, the WISeR model introduced prior authorization requirements for a set of 13 medical services. The June 2025 Innovation Center Investment Plan for WISeR lists medical services that could be added to the program in future years. This planning document considers the possibility of adding services “where prior authorization would have to be done on a more urgent or emergent basis,” including air ambulance transport, cancer treatment, MRI scans, and medications without publicly available coverage criteria.

More Transparency is Needed About Medicare’s AI Experiment

CMS continues to produce records in response to EFF’s lawsuit. Records released thus far echo concerns that providers have raised since WISeR launched, including long delays, financial incentives to deny care, and technical problems. But important questions remain about the AI systems private companies are using to inform decisions about whether to provide people with Medicare benefits. As CMS continues to produce documents, we will continue to make them available to the public. The public deserves to know how AI is driving decisions that affect patients’ access to care.

Correction: An earlier version of this post misstated the number of prior authorization requests that had been denied by two WISeR vendors in the first three months of the program. This version has been corrected to reflect that the number of denials was 5,944. The post has also been updated to clarify that reported turnaround times reflect the full request pathway and are not solely controlled by WISeR vendors.

Across mobile platforms, advertising companies provide developers with software development kits (SDKs) that make it easy to monetize their apps. But those same SDKs can automatically feed users’ location data into ad systems that location data brokers use to track people. Many developers may not even be aware of this privacy violation, let alone the users who are directly affected.

When developers let advertising SDKs collect location data, they’re putting users at risk of more than just creepy ads. Location information sourced from the advertising industry has been used for ICE investigations, global spy tools, outing a gay priest, tracking union organizers, and tracking US military personnel.

Defaults matter, not just for users, but for app developers as well.

An EFF investigation has identified several advertising SDKs that publicly acknowledge collecting and sharing users’ location by default when embedded in Android apps granted location permissions. Defaults matter, not just for users, but for app developers as well. If app developers don’t pay close attention to the location-sharing settings of their advertising tools, they could inadvertently expose users’ location information.

This report explains how advertising SDKs can facilitate and encourage location data sharing through privacy-invasive defaults, financial incentives, and unclear documentation.

Contents:

• Data Brokers Harvest Location Information From Advertising Systems
• How Advertising SDKs Leak Location Data
• EFF Identified Advertising SDKs That Share Location Data by Default
• InMobi Encourages Keeping Location Sharing Enabled By Highlighting Financial Incentives
• BidMachine Updates Previously Inaccurate Developer Documentation After EFF's Technical Analysis Observed Precise Location Data Collection
• Verve Emphasizes Consent More in its Play Store Language Than its Configuration Guide
• Huawei Highlights Financial Incentives for Location Data Sharing Before Showing Developers How to Opt Out
• Location Data Sharing Can Happen Without Users’ Knowledge or Meaningful Consent
• Location Privacy Issues Extend Beyond These Four SDKs
• Fighting Back Against AdTech Companies That Enable and Encourage Location Data Sharing
• Developers
• Regulators
• Legislators

Data Brokers Harvest Location Information From Advertising Systems

When an advertising SDK collects and shares location data, it becomes part of a larger ecosystem that can include advertisers, ad tech companies, and location data brokers. EFF began investigating the location-sharing practices of various advertising SDKs to better understand the pipeline from mobile apps to location data brokers.

Location data brokers sell information on the precise movements of billions of people without their knowledge or meaningful consent. This data is primarily sourced from apps on people’s phones. Some apps partner with data brokers directly, using data-broker-developed SDKs or server-to-server transfers to sell users’ location data. Other apps leak users’ location data through advertising SDKs serving behaviorally-targeted ads through “real-time bidding” (RTB). In the process of auctioning off ad space, ad tech companies can broadcast user data to thousands of potential advertisers. Location data brokers have participated in these auctions not just to bid on ad space, but to collect personal information contained in bid requests. 

Indiscriminate data sharing through RTB can lead app developers to unknowingly share their users’ location with data brokers. In 2025, a hack of location data broker Gravy Analytics revealed thousands of apps that may have been sources of its data. When journalists reached out to the app developers, many claimed they had no relationship with or knowledge of Gravy Analytics. To prevent location information from being shared with data brokers through RTB, developers must understand the location-sharing practices of their advertising SDKs.

How Advertising SDKs Leak Location Data

Developers don’t have to manually, or even intentionally, share location data for it to be broadcast through RTB auctions. Once a user grants an app permission to access their location, SDKs embedded in the app receive the same access—there are no SDK-specific location permissions. That means advertising SDKs can automatically collect users’ location data and share it in bid requests.

While apps and SDKs can estimate a users’ approximate location from their IP address without requesting any permissions, location permissions provide access to estimates that are more accurate and revealing. Precise location permissions give apps (and their embedded SDKs) access to location estimates within about 160 feet, but sometimes as accurate as 10 feet. Approximate location, a separate permissions level, gives apps access to a location estimate within about 1.2 square miles. 

Developers and advertising SDKs also have a financial incentive to share location data, since it can increase bid prices for an app’s ad space. While many advertising SDKs require developers to configure a setting before collecting and sharing users’ location data in ad requests, this is not always the case. EFF found several advertising SDKs who publicly acknowledge sharing users’ location data by default when embedded in apps granted location permissions. 

EFF Identified Advertising SDKs That Share Location Data by Default

EFF reviewed the public developer documentation of dozens of widely-used advertising SDKs to identify how they handle and communicate with developers about location data. In the following sections, we highlight four advertising SDKs who engage in a particularly egregious practice: collecting a user's location by default for ad targeting whenever a user has given an app location permissions. We reached out to each SDK company and the referenced app developers for comment. One company responded, and as detailed below, subsequently updated its documentation in response to our questions. Another company responded with clarifications to its developer documentation.

We chose to focus on SDKs with this privacy-invasive default because it increases the risk of developers leaking users’ location data without realizing it. Several studies have found that developers tend to stick to SDKs’ default settings. If an advertising SDK transmits location data by default, users' precise location can end up in advertising systems without the developer intentionally enabling location sharing. These SDKs have separate documentation pages that instruct developers to flag users covered by privacy laws like GDPR and COPPA for restricted data processing, but these modes are not the default. 

By analyzing how these four SDKs present their location sharing practices to developers, we hope to illustrate how the design and documentation of advertising SDKs can facilitate location data sharing at scale. Although the advertising SDKs we highlight are not the most prevalent SDKs used, they are embedded in thousands of apps and reach billions of users.

InMobi Encourages Keeping Location Sharing Enabled By Highlighting Financial Incentives

InMobi claims to reach “2B+ users across 150+ countries” and is the 10th most popular advertising SDK on Android (according to AppBrain and Appfigures at the time of publication). 

InMobi’s “Getting Started with Android SDK Integration” suggests that location sharing is enabled by default, stating “The InMobi SDK automatically forwards location signals when available.” InMobi provides developers with a setting to opt out, but explicitly recommends sharing location data. Developer documentation highlights the financial incentive for location sharing, stating “location-enriched impressions typically yield higher revenue.” 

[Observed on “Getting Started with Android SDK Integration,” 7/31/26]

Apps that use InMobi may not need location information to function or may only need access to approximate location information, but InMobi highly recommends that developers request precise location permissions “to enable accurate ad targeting.” They even encourage developers to request Wi-Fi network information permissions, which (when paired with precise location permissions) provide Wi-Fi access point identifiers that can also be used for location tracking.

[Observed on “Getting Started with Android SDK Integration,” 7/31/26]

InMobi has been accused of misleading developers over location sharing practices in the past: In 2016, they settled with the FTC over charges that they bypassed users’ location permissions for apps and tracked their precise locations through WiFi network data (Android now requires apps to request location permissions to access this WiFi data too).

BidMachine Updates Previously Inaccurate Developer Documentation After EFF's Technical Analysis Observed Precise Location Data Collection

BidMachine claims to reach over 600 million “direct SDK users.” 

BidMachine reveals that it collects location data by default on the “Advanced Settings” page of its Android SDK Integration guide, stating that the “SDK can automatically track user device location to serve better ads” as long as developers request location permissions for their app. Before publication, EFF reached out to BidMachine for comment, notifying them of our plan to highlight their Android SDK location sharing practices.  

[Observed on “Advanced Settings” on 7/31/26, before EFF asked BidMachine for comment]

After EFF reached out, BidMachine changed their documentation to clarify the practice, but not their default collection of location information once app-level permissions are granted. This updated section still fails to explain how developers can opt out of BidMachine location tracking, which is critical for app developers that require location access for core features but wish to prevent user data from being shared with advertisers.

[Observed on “Advanced Settings” on 8/3/26, after EFF asked BidMachine for comment]

Before EFF reached out, BidMachine’s “App Privacy Details On Google Play” page had stated that they only collected coarse location data and precise location data was “not collected.” However, our technical analysis of two apps, which Exodus Privacy determined include the BidMachine SDK, contradicted this claim: Network requests from the apps QR Scanner and GPS Speedometer to a BidMachine domain include precise location coordinates.

[Observed on “App Privacy Details On Google Play” on 7/31/26, before EFF asked BidMachine for comment]

After EFF reached out, BidMachine also corrected its documentation to make it clear precise location is collected by the SDK whenever the app-level permission is granted:

[Observed on “App Privacy Details On Google Play” on 8/3/26, after EFF asked BidMachine for comment]

com.appswing.qr.barcodescanner.barcodereader_bidmachine.flows

com.ktwapps.speedometer_bidmachine.flows

In response to our request for comment, BidMachine stated that it wasn't possible for them to get location information “unless the user has granted the app the relevant permission through the operating system.” They also stated that“publishers are responsible for configuring their apps' permission and consent flows.”

Verve Emphasizes Consent More in its Play Store Language Than its Configuration Guide 

Verve has claimed its HyBid SDK reaches “over 1.5 billion users across more than 10,000 apps worldwide.” 

Verve’s configuration guide for its HyBid Android SDK (formerly called Pubnative HyBid) makes clear that location tracking is “enabled by default,” stating, “If the user has given location permissions, HyBid SDK will use the available user location to provide better targeted ads.” 

[Observed on “HyBid Android SDK - HyBid Configuration,” 7/31/26]  

Verve’s guidance for data disclosure to the Google Play Store tells a more careful story. Despite the fact that location tracking is enabled by default, the Google Play Data Safety Guidance states that the SDK “does not collect or attempt to collect [location] information independently.”

[Observed on “Google Play Data Safety Guidance,” 7/31/26]  

It also emphasizes user consent, claiming the SDK will only collect location data “if the publishers allows its app to collect location data from users after obtaining user’s explicit consent to such data collection” (emphasis added). The configuration guide lacks recommendations or instructions for obtaining user consent to share location data with Verve, beyond app-level access. Instead, the configuration guide highlights the financial incentives for developers to add location permissions to their app.

[Observed on “HyBid Android SDK - HyBid Configuration,” 7/31/26]  

When reached for comment, Verve clarified that “in its current Android implementation, the SDK reads the cached network-provider location and does not use the GPS data of the end user's device. Furthermore, any geolocation data is coarsened prior to processing, ensuring that location is limited to an accuracy radius of no less than 1,850 feet.” It also said that it contractually requires apps to comply with data protection laws. 

To Verve’s credit, the HyBid SDK is open source, so careful developers can check the code instead of relying on documentation alone. HyBid’s open-source code shows that latitude and longitude coordinates are rounded to two decimal places, and that it does only collect and share network-derived location data, confirming the statement the company sent to us. If an app has precise location permissions, networked-derived location data rounded to two decimal places could be accurate within approximately 0.5 square miles, which is still more precise than the 1.2 square miles typically revealed with Android’s approximate location permission. But even coarse location data, especially when collected repeatedly over time, can reveal movements that should remain private by default.

Verve’s response also conveyed a willingness to revise their documentation: “As part of our ongoing commitment to providing clear and comprehensive developer resources, we continually review and enhance our documentation, and we will take your observations into account as part of that process.”

Huawei Highlights Financial Incentives for Location Data Sharing Before Showing Developers How to Opt Out

Huawei has claimed its Petal Ads SDK is embedded in more than 85,000 apps worldwide.

Huawei’s “Integrating the Petal Ads SDK into an Android App” guide begins with a recommendation that developers obtain location permissions to increase app revenue and an acknowledgement that location sharing will happen by default in apps with location permissions.

[Observed on “Integrating the Petal Ads SDK into an Android App,” 7/31/26]

A separate “Use of Location Data for Ads” page repeats that the Petal Ads SDK will include users’ location information in ad requests if an app has access to location information. Neither of those pages mention that developers can use the setRequestLocation method to disable the default collection of location information (this setting is referenced in the last section of the Ads SDK Compliance Guide). Huawei’s Ads SDK Privacy Statement states that “The SDK and its services will not store precise location information, and will only use it to determine the approximate device location.” However, the guide does not specify how Huawei defines approximate versus precise location data. 

[Observed on “Use of Location Data for Ads,” 7/31/26]

Location Data Sharing Can Happen Without Users’ Knowledge or Meaningful Consent 

In some cases, after an app itself obtains location permission, advertising SDKs can separately obtain and share users’ location information without their knowledge or meaningful consent. Neither app that EFF observed sharing precise location data with BidMachine (QR Scanner and GPS Speedometer) showed a notice or requested consent before doing so. Additionally, neither apps’ Google Play Store “Data safety” section includes location data under “This app may share these data types with third parties.” The lack of transparency and control that users have over their location on mobile apps is dangerous. QR Scanner and GPS Speedometer are just two examples of apps that quietly share users’ location data through advertising SDKs, but they have been downloaded more than 50 million and 10 million times, respectively. 

App-level location permissions alone cannot signal meaningful consent to location collection and sharing by third-party advertising SDKs.

Even if users’ were to grant these apps permission to obtain their location data, they would likely not expect their location data to be shared with third parties. Many users don’t know that granting location permissions to an app grants the same permissions to third-party SDKs embedded in the app, or that an app they're using contains code from outside companies. And many apps that request location permissions, like GPS Speedometer, require it for core functionality. App-level location permissions alone cannot signal meaningful consent to location collection and sharing by third-party advertising SDKs.

Location Privacy Issues Extend Beyond These Four SDKs

Our initial focus on four advertising SDKs does not mean that other SDKs adequately protect location data or that developers never choose to share location data when it’s not the default. Advertising SDKs not discussed in this report have been criticized and sued for allegations that they collect location data without valid user consent. 

The issues we’ve highlighted around privacy-invasive defaults, financial incentives, and unclear documentation extend beyond the specific SDKs we analyzed. Multiple studies have found that advertising SDKs often steer developers toward increased data collection through their design and documentation. A 2021 study found that popular advertising SDKs used dark patterns to nudge developers towards sharing more sensitive data. A 2024 study identified discrepancies between several SDKs’ documentation and their actual data collection practices. And a 2025 study concluded that developers have minimal influence over SDKs’ data transmission, often leaving them with the choice of accepting SDKs' invasive data collection or avoiding them entirely. 

Fighting Back Against AdTech Companies That Enable and Encourage Location Data Sharing 

EFF’s analysis shows that advertising SDKs don’t just allow developers to share location data–they often encourage it. Default settings, financial incentives, and unclear documentation can make sharing users’ location the easiest option for developers.

Users can take extra steps to defend their location privacy, but they shouldn’t have to. Developers, regulators, and legislators must act to stop apps from leaking users’ location to advertising companies and data brokers.

Developers

Developers should carefully evaluate all third-party SDKs they include in their apps and disable unnecessary data collection whenever possible. Regardless of advertising SDKs’ default settings, developers have a responsibility to protect their users’ location data. But protecting users’ privacy shouldn’t depend on developers reading the right piece of SDK documentation. Advertising SDKs should not make sharing personal data the default, especially for data as sensitive as a person’s location. 

Regulators

Regulators should continue to hold app developers accountable when they unlawfully share personal data and include libraries which subject users to privacy harms, as they have in the past. But they should also scrutinize the companies whose SDKs encourage these practices at scale. Otherwise, companies can continue to design SDKs that make invasive data sharing the default while shifting the responsibility and consequences to developers who include their tools. 

Legislators

The US is in dire need of a federal law to protect all Americans’ location privacy, one which doesn’t preempt stronger state privacy laws, and has a private right of action empowering individuals to sue those who violate their privacy. Countries across the globe should likewise enact legislation that protects their users’ location privacy. Everyone deserves privacy as a universal human right.

Legislators can address the root of the problem by banning online behavioral advertising. This would remove the primary incentive for companies to track and share your personal data. It would also prevent users' precise locations from being broadcast to data brokers through RTB auctions. 

Until then, developers should be wary of ad libraries that betray their users’ location privacy.

Notes on Methodology We were interested in looking at network traffic for various Android ads SDKs that send precise location by default when granted location permissions. We chose Android for this investigation because of the relative openness of and our familiarity with analysis on the platform. We’ve used publicly available resources like Exodus Privacy and AppBrain to identify popular ads SDKs and the apps which include them. In a lab setting, we set up a machine to view our own http(s) traffic using mitmproxy from our test device, and connect the test device to that machine in order to view our real-time traffic.  Where needed, we use the dynamic instrumentation toolkit Frida to ensure the traffic we generate can be analyzed. We’ve included flows files in this post, which can be opened in mitmproxy to show the requests we’ve observed with location coordinates.

This Pride month, we’re calling on the dating app Grindr to prioritize LGBTQ+ user safety by making privacy the default across its platform. That means no more sharing personal data with advertisers or training AI on private information without users’ opt-in consent.

Grindr is a dating app for the LGBTQ+ community; and for queer people, privacy violations can have life-altering consequences. Information that reveals someone’s sexual orientation, gender identity, or HIV status can be used by employers, governments, family members, scammers, or bad actors to inflict harassment, discrimination, arrest, or violence. For example, data from Grindr and other gay dating apps was sold by data brokers and used to 'out' (the act of disclosing someone's sexual orientation without permission) a gay priest in 2021. 

Despite being the world's most popular gay dating app, Grindr has repeatedly mishandled users' sensitive data. Grindr has been caught sharing users' HIV status and precise location with advertisers without obtaining valid consent, resulting in reprimands and fines in several countries. Its former Chief Privacy Officer even sued, alleging the company fired him for raising concerns about Grindr prioritizing “profit over privacy."

Grindr ended several of its most egregious data sharing practices after they were exposed. But more changes are needed if Grindr wants to earn back trust and prove its commitment to users’ privacy and safety. This Pride month, we’re calling on Grindr to make privacy the default and ensure the immediate implementation of two changes to better protect its users:

Opt Users Out of Behavioral Advertising by Default

Grindr currently allows users to opt out of behavioral advertising, but that protection is not enabled automatically (except in some unspecified regions). As we’ve long warned, behavioral advertising relies on the collection and sharing of personal data across a vast network of advertisers, intermediaries, and data brokers. Once information enters this ecosystem, users have little control over where it goes or how it is used: people’s most private and intimate information can be aggregated, sold, and combined with information from other sources to create detailed personal profiles.

By default, Grindr appears to share data with numerous advertising and tracking companies. Using TrackerControl, an app developed by privacy researcher Konrad Kollnig, we recorded Grindr contacting 20 third-party tracking domains during 15 minutes of app activity (see Grindr_TrackerControl_06-23-2026.csv for exported results). TrackerControl observed Grindr contacting Big Tech companies and ad-tech intermediaries, many of which have faced significant legal scrutiny for privacy violations. Several of these companies auction off ad space through a process called “real-time bidding,” which can expose user data to hundreds of additional companies and be exploited by data brokers. 

The dangers of Grindr’s default settings exposing users’ personal data to this ecosystem are not hypothetical. Between approximately 2017 to 2020, a location data broker collected the precise movements of millions of Grindr users from digital advertising networks and made them available for sale. The commercially available data was allegedly so detailed that, in some cases, it could be used to infer romantic encounters between specific Grindr users. 

Although Grindr has stated that it no longer shares precise location data or profile information with advertisers, it acknowledges sharing other personal data, including mobile advertising identifiers (MAIDs)—unique, persistent device IDs that allow advertising companies and data brokers to connect data about the same individual across different sources. MAIDs are not anonymous, and an entire industry exists to link them to more directly identifying information, like emails and phone numbers. According to Grindr’s privacy policy, companies receiving users’ MAIDs “are aware that such data is being transmitted from Grindr,” which could expose a users’ sexuality to the advertising and data broker ecosystem.

Opt Users Out of AI Training on Personal Data by Default

Grindr should stop training its AI models on users’ personal data without opt-in consent. 

Grindr has been investing heavily in AI features as its CEO strives to make Grindr an “AI-first business.” New AI features include a wingman chatbot, profile recommendations based on users’ inferred “type”, summaries of previous interactions with other users, and AI-generated insights about other profiles (like responsiveness, typical online hours, and engagement patterns). By default, Grindr uses its users’ personal data to train the AI models behind these features.

Grindr claims to never use sensitive health information for AI training and requires users to opt-in to AI training on “special-category” data, which includes chat content and precise location. But Grindr automatically enrolls users in AI training on other private information, including profile photos, age, taps, and display names. Users must navigate several levels of Grindr settings to prevent these personal details from being used to train Grindr’s AI.

AI systems trained on personal data create new privacy risks, including the possibility that personal information may be retained, reproduced, or exposed in unexpected ways. For example, researchers have been able to extract training data from AI systems like ChatGPT.

Beyond AI training, Grindr enables AI-powered features by default and allows both “special-category” data and other personal information to be processed by those features. Even users without access to premium-subscription AI features could have their data automatically used to power those features for other users. “Behavior-based profile insights” (pictured below) could expose information that users would never choose to share publicly, like the types of people they interact with on Grindr, their typical online hours, and how often they initiate conversation with other users.

Regardless of whether new AI features leak private information, users deserve meaningful control over how their personal data is used and by whom. Grindr notifies users that their personal information may be used to train AI and that they can opt out on a separate settings page, but this notice does not specify the type of data used (i.e. profile photos, taps) and it is unlikely that people carefully read or understand it. Closing the notice or clicking its only button (which is “Proceed”) maintains Grindr’s default of using personal information for AI training. To respect users’ autonomy, Grindr should require opt-in consent before training AI models on personal data.

Celebrate Pride by Demanding Better Privacy

Grindr must immediately stop prioritizing profits over users’ safety. The ability to opt-out is not an acceptable substitute for opt-in consent, especially given the added risks of data sharing for LGBTQ+ users. Defaults matter—studies show that most people cannot or do not change the default settings of technologies they use.

If Grindr wants to back up its claim that it “takes user privacy very seriously,” it should make privacy the default across its platform, rather than something users need to go through complicated processes to opt in to.