A federal appeals court just made it harder for online services, big and small, to get lawsuits over user speech dismissed early. In California v. Meta, a Ninth Circuit three-judge panel held that the lower court’s denial of Section 230 immunity to Meta is not immediately appealable. The misguided ruling has the potential to have widespread impact and to threaten the free speech of all internet users.

The ruling is bigger than a loss for Meta, which has the resources to defend itself against these lawsuits. The court’s ruling signals that all online services (and internet users) that host others’ speech—including those without Meta’s deep pockets—must bear the burden and expense of fighting lawsuits that Section 230 ultimately precludes. This will have real consequences, incentivizing online services to take down users’ speech in response to spurious legal threats, filter speech preemptively, or simply stop offering a place for people to speak online. So even though some may think that Meta is not a sympathetic company, the ruling should raise concerns for anyone who cares about an open and free internet.

Immunities from Suit Advance Important Public Interests

A little procedural background is necessary to understand the implications of the Ninth Circuit’s ruling.

Meta had moved to dismiss a group of social media addiction cases brought by state attorneys general, school districts, and local governments. Meta argued that Section 230(c)(1) immunity applies because the plaintiffs’ claims, framed as seeking to hold Meta liable for allegedly harmful platform features, really seek to hold the company liable for publishing decisions related to third-party content. Section 230 is one of the most important laws supporting online free speech, because its protections for online services enable them to distribute users’ speech at an unprecedented scale.

The district court ruled that Section 230 does not apply to certain features (and does apply to others) and so denied the motion to dismiss on the claims related to those features. Meta immediately appealed invoking appellate jurisdiction under 28 U.S.C. § 1291, but the question before the Ninth Circuit was whether the appeal was legally appropriate.

Under Section 1291, U.S. circuit courts generally only have jurisdiction to hear appeals of “final decisions” from the district courts. Final decisions are trial court orders ending a case, or come after a trial on the merits. Section 230 appellate cases often arise from a district court’s grant of a defendant platform’s motion to dismiss the plaintiff’s case based on Section 230. Typically, a district court’s denial of a defendant’s motion to dismiss is not a final order—it simply means that the case may continue to discovery and summary judgment or trial, after which time an appeal would be appropriate.

However, federal law allows for “interlocutory appeals,” which are appeals of orders that do not end a case but nonetheless are allowed because they involve important legal issues. For example, there is an exception to Section 1291 called the “collateral order doctrine”—at issue in this case—allowing for immediate appeal if, as the Ninth Circuit explained here, “holding a trial would imperil a substantial public interest.”

Inherent in the collateral order doctrine is the consideration of whether an immunity like Section 230 provides mere “immunity from liability” or a more robust “immunity from suit.”

An immunity from liability does not require an immediate appeal and so demands that Section 1291’s final order rule be followed. That’s because waiting until the end of a case before an appellate court can consider the trial court’s denial of immunity does not prejudice the defendant. The appellate court may overturn the trial court and grant the immunity, and thus the defendant’s right to be immune from liability would be vindicated on appeal.

Immunity from suit is different. It means that the public interest demands that a defendant be able to get out of a case as early as possible and avoid having to litigate the case to the end. The U.S. Supreme Court has held, for example, that qualified immunity is such an immunity, and that a district court’s denial of qualified immunity for a government official is immediately appealable under Section 1291, notwithstanding the lack of a final order. The idea is that the public interest is served when government officials are free to act without fear of consequences when established rights are not implicated, and so determining as soon as possible whether their acts are immune serves that public interest.

Here, the Ninth Circuit held that the district court’s denial of Section 230 immunity for Meta was not immediately appealable under Section 1291’s collateral order doctrine because the immunity is not from suit, but rather from ultimate liability. The panel’s absurd result contravenes the text of Section 230, the statute’s policy goals, and the court’s own prior rulings.

Treating Section 230 as an Immunity from Suit Protects Online Free Speech

Meta rightly argued that Section 230(e)(3) plainly states, “No cause of action may be brought and no liability may be imposed under any State or local law that is inconsistent with this section.” The panel dismissed this argument, stating that this language likely amounts to “redundancy” reflecting only immunity from liability. The court failed to side with the more reasonable position that statutory language should generally not be interpreted as superfluous.

Meta also reminded the panel that the Ninth Circuit has many times over the past two decades framed Section 230 as both an immunity from liability and an immunity from suit. The panel also dismissed this argument, stating, “It is true that we have used the phrase ‘immunity’ somewhat loosely in our section 230 jurisprudence.”

But “loosely” is a gross mischaracterization—the panel did not discuss a seminal prior ruling, Fair Housing Council of San Fernando Valley v. Roommates.com (2008), in which the entire Ninth Circuit, not just a three-judge panel, explicitly ruled that Section 230 is also an immunity from suit. That court rightly explained that Section 230 “must be interpreted to protect websites not merely from ultimate liability, but from having to fight costly and protracted legal battles.”

Why is it important that social media platforms and other internet intermediaries (and their users) have immunity from suit for engaging in publishing activities related to third-party content—and thus a right to immediately appeal when Section 230 immunity is denied?

The Ninth Circuit panel here, using their own words, failed to “evaluate the interests that would be lost through rigorous application of a final judgment requirement” and failed to consider the “substantial public interest” served by treating Section 230 as an immunity from suit.

Section 230 immunity, contrary to what some argue, is not a gift to Big Tech—it applies to all internet intermediaries, big and small, from the large social media companies to smaller entities like community message boards and local ISPs. It even protects internet users who forward others’ emails or host comments on their blogs. In turn, the law supports the free speech of all internet users.

While it is helpful when an internet intermediary can ultimately benefit from Section 230 immunity, if a trial court’s early denial is not immediately appealable, that means the intermediary must bear the extended logistical and financial burdens of defending itself. Under the Ninth Circuit’s logic, anyone hosting others’ speech online would have to endure the pain and expense of discovery, summary judgment, or trial, before they ultimately can be protected by Section 230.

Congress crafted Section 230 to give internet intermediaries legal breathing room, so that they will be incentivized to facilitate online communication and commerce, allowing the rest of us to go online with minimal barriers to entry, without needing to have loads of money or to know how to code. Congress acknowledged in Section 230 itself, “Increasingly Americans are relying on interactive media for a variety of political, educational, cultural, and entertainment services.”

Yet if platforms, especially smaller platforms, know that they will have to defend themselves for years in court before they can ultimately benefit from Section 230 immunity, this alone will create a perverse incentive, as we have explained, to censor user speech, in order to reduce the platforms’ legal exposure. And this incentive is only exacerbated at scale, where the sheer volume of user-generated content hosted by modern platforms makes legal risk astronomical.

Unfortunately, this opinion seems to be part of larger trend reflecting the Ninth Circuit’s increasing disdain for Section 230, and apparently for free speech rights more broadly. The court similarly held last year in Gopher Media v. Melone (2025)—overruling itself—that a trial court’s denial of a defendant’s anti-SLAPP motion also is not immediately appealable under the collateral order doctrine. This is despite the fact that, similar to Section 230, California’s anti-SLAPP law is intended to allow defendants to get harassing lawsuits meant to silence them dismissed early, lest they be chilled from engaging in lawful speech on public issues due to the risk of being mired in litigation, even if they ultimately win a delayed appeal.

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.