Last week, researchers at Citizen Lab revealed a horrifying new malware campaign, dubbed “AdFection.” It used an ad network to distribute spyware to journalist’s devices to infect them without the target ever needing to click anything. This sort of attack on journalists is dangerous and incredibly concerning, especially since it’s built on the backbone of a technology we already object to: behavioral advertising. Although this type of attack has only been described targeting journalists, you can take a few steps we outline in the next section to mitigate the risk no matter who you are.

A few factors combined to make this attack a noteworthy first-of-its-kind. First, it utilized the surveillance ad-tech ecosystem to specially target the malicious code. Second, the spyware it delivered was so-called “zero-click,” meaning it required no interaction from the user to be infected: all that is required is for the ad to be delivered and code bundled along with it to be run, which happens automatically. Neither malvertising nor zero-click attacks are new on their own. What’s novel about the AdFection attack is combining them, creating a highly targeted, extremely dangerous attack which is difficult to defend against and even harder to detect.

Let’s take a deeper look from the perspective of one of the Windows devices supplied to the researchers from Al Jazeera. Here’s how the report describes the infection happening: 

• Someone browsing the web or using an app on that machine is served an ad created by Discover-Tech, a company exposed in the report as “purporting to be a legitimate advertising company, [but] appears to be a front for large-scale ad espionage abuse.” 
• The ad contains a small snippet of JavaScript code which is automatically executed when rendered in the app or website. 
• This code reaches back out to a Discover-Tech server, referred to as their “NOAS server,” with detailed information about the machine rendering it: its cookie-set advertising ID, IP address, and more.

So far, nothing particularly unusual has happened. Ads that contain JavaScript code and reach back out to their servers with lots of information on your device—and by extension you—are commonplace. It’s all part of the data-driven advertising ecosystem. What happens next is more interesting:

• The NOAS server uses this detailed information to determine it is an Al Jazeera machine requesting the ad. 
• Instead of returning an empty response (as it does most of the time), it responds with a malicious, zero-click spyware payload. That payload was created by Discover-Tech’s partner Candiru/Integrity Labs, a company previously exposed for involvement in sophisticated malware attacks. 
• The payload is then executed and infects the targeted machine.

Companies targeting zero-click malware attacks against journalists might seem like the plot of a blockbuster spy thriller. But this attack was enabled by the everyday practices of ad-tech companies, which unfortunately have extreme latitude in the collection of users’ data. By leveraging the tracking identifiers and data collected on devices for the purpose of delivering targeted ads to specific individuals, mercenary spyware companies can repurpose this data in order to fine-tune who they infect—and hide that they’re doing it from everyone else. 

Most ads are not delivered directly by the ad creators, but rather by intermediaries that facilitate Real-Time Bidding auctions. Nonetheless, winning bidders are given the ability to execute JavaScript code in the browser of the person who receives the targeted ad. This allows for interactive ads to be displayed, but also (as we’ve seen) for the compromise of a device just by delivery of malicious code.

While the different components in this attack chain are not novel on their own, the exposure of this combined attack is significant because it reveals a technique to hyper-target individuals and organizations for infection. Luckily, there are steps you can take to protect yourself from the myriad of dangers presented by the ad-tracking industry. Here’s how.

What You Can Do About It

As we work towards fundamental fixes to the ad ecosystem and banning online behavioral ads altogether, the onus is on all of us to protect ourselves. This is especially important for higher risk individuals or journalists working in states with heavy surveillance. Citizen Lab outlines several steps, depending on your threat model, to take to help protect yourself:

• Take some simple steps to lock down your devices right now.
• Establish strong security fundamentals. Sites like our own Surveillance Self-Defense and Consumer Reports’ Security Planner can help get you started.
• Use a browser extension to reduce tracking. Our Privacy Badger extension is an excellent start. Network-wide ad blocking services are also worth considering if you’re comfortable handling the set up process.
• On mobile phones, disable or reset your AD ID. Here are directions to do so for Android and iPhone.
• Consider using more privacy protective browsers.

These steps can be very helpful in protecting yourself, but there is only so much you can do as an individual. Banning behavioral ads like this would be a good place to start. Behavioral ads aren’t just a privacy nightmare as designed. They are the perfect vehicle for malvertising and similar threats, just as we see here.

An open internet where people can freely build, share, and remix each other's work is a powerful engine of grassroots innovation we’ve all benefited from. In recent decades, however, corporations have taken control of an increasing share of this work, giving them a greater ability to stifle challengers and limit our choices. When regulators address this by mandating that  tech giants play fair by requiring interoperability, the gatekeepers respond with a tired refrain: Playing fair puts users’ security at risk.

Unfortunately for these trillion-dollar companies, this gotcha isn’t the end of the conversation. Regulators can ensure that meaningful choice and security thrive.

Lawmakers have been catching up, recognizing that the best way to rein in big tech is to require these oligopolies to open up their platforms to independent developers. As we explained six years ago, mandating interoperability helps prevent the misuse of people’s data and enables more privacy-respecting alternatives. Tech giants, in contrast, have been arguing that our data is safer when they have exclusive control.

Tech Giants Claim Interoperability Means Insecurity

The European Union’s Digital Markets Act (DMA) put interoperability into law under Article 6(7): “gatekeeper shall allow providers of services and providers of hardware, free of charge, effective interoperability with” a designated Core Platform Service they operate. The language describes an unambiguous requirement to remediate vendor lockouts and anti-competitive behavior of the major service operators—it is not optional.

Apple claimed that enforcing this obligation in mobile app stores would put their customers at risk and do irreparable harm to trust in their brand. It’s an argument reminiscent of Apple’s fight against the right to repair, and in both instances the company is fighting to maintain its restrictive ecosystem to stop people from finding better deals elsewhere. Apple has long cultivated a more corporate-controlled experience with the iPhone, but this argument is now also being used for the relatively-more-open Android devices from Google.

In the same year Apple argued against the DMA, Epic Games sued Google for its restrictive terms of service and extractive policies for revenue generated in apps. Google predictably alleged that opening up its platform to other app stores it couldn’t vet would allow harmful apps to be installed. The case was ultimately decided this year in the U.S. federal appeals court for the Ninth Circuit, with the court rejecting this argument, dealing a blow to  Google’s feudal security arrangement, and paving the way for third-party app stores to be delivered as apps via the Google Play Store.

Interoperating Secure Systems Can (and Should) Exist

Policymakers cannot take tech giants’ claims at face value. Companies have every incentive to resist interoperability requirements, because interoperability lowers practical barriers and reduces switching costs for consumers adopting competing services. 

Even where companies offer credible claims from internal technical and security experts, independent experts rarely have the access and information they need to test those claims. Companies have selectively made arguments that security is harmed by interoperability, often in contexts which are to their advantage. These companies are happy to let a general misconception flourish which frames security as inherently opposed to interoperability.

This narrative is wrong. We’ve seen that when interoperability and information security are both set as essential and non-negotiable criteria, secure interoperable systems result—systems that don’t sacrifice the rich features we’ve come to expect of the services we rely on. 

The cross-platform rollout of Rich Communication Services (RCS), and now Message Layer Security (MLS) on top of it is a perfect example of this, creating end-to-end secure messaging by default between Android and iOS. For RCS and MLS, Google was conveniently on the other side of the interoperability argument, campaigning Apple to adopt the standard to overcome the diminished “green bubble” experience iPhone users had when texting non-iPhone users. Once Apple finally agreed to interoperate by implementing common standards, all users benefited from improved messaging security. In cases where legitimate security concerns are raised, these can be assessed and remedied on a case-by-case basis, without sacrificing user agency.

Striking the Right Balance

Retrofitting interoperability into already secure closed systems shouldn’t be done carelessly: it requires regulators strike the right balance of pressure and leniency to allow the time and precision necessary to make these renovations. Any components developed with the assumption of privileged access by trusted parties (e.g. your browser engine) are particularly vulnerable to serious security risks when opened up to unaccountable third parties.

By adapting interoperability and information security as essential design principles, we can expect more safety, but also more freedom.

With regard to the DMA, when security concerns are legitimate, we urge the European Commission to work with companies and outside experts to offer guidance in technical implementation and provide clarity on regulatory compliance. This approach paves a path forward that balances the interest of legal oversight and the needs of the companies alike. 

Policymakers wishing to uproot these unfair platforms of control must do so with care and limit the impact this disruption can have. But security concerns must not act as a lever to indefinitely delay compliance. Closed systems should be impartially evaluated, and if concerns are valid, regulators can allow more time and guidance to be given to companies implementing these changes. One possibility is a tiered approach: offering leniency during an initial period where systems need to be retrofitted to abide by new requirements, followed by a subsequent and ongoing stricter observance of fair play.

Once interoperability and information security are adopted as essential design principles, further development with these rights-enhancing principles in mind will more easily follow. The result will be an internet the world deserves—where we can expect more safety, but also more freedom.

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 post is available as a printable one page handout in English and Spanish.

Recordings of law enforcement, whether by bystanders or by those directly encountering officers, can be powerful tools of government accountability and can support movements for social change. But recording officers can come with risks. Below are important legal and practical considerations related to recording the police and other law enforcement officers.

Can I legally record the police or immigration officers?

Yes. All Americans have a First Amendment right to record law enforcement. This includes local police and federal officers such as those from Immigration and Customs Enforcement (ICE) and Customs and Border Protection (CBP). Although the Supreme Court has not squarely ruled on the issue, nine different federal appellate courts have recognized and affirmed this right, relying on decades of Supreme Court precedent.

Courts typically frame the right to record law enforcement as the right to record officers exercising their official duties in public. This right extends to bystanders as well as people recording their own interactions with law enforcement, such as livestreaming their own traffic stops. The right also applies to private places where the recorder has a legal right to be, such as in their own home.

You may take photos, or record video and audio. Courts have held that wiretap laws, which generally protect private conversations, do not prohibit civilians from audio recording law enforcement. That’s because officers exercising their official duties, particularly in public, do not have a reasonable expectation of privacy. Neither do civilians in public places who speak to law enforcement in a manner audible to passersby.

What are some limitations on the right to record law enforcement?

Courts have been clear that behavior that obstructs or interferes with effective law enforcement or the protection of public safety is not protected. Officers can't order you to move because you are recording, but they may order you to move for public safety reasons even if you are recording.

If the law enforcement officer is off-duty or is in a private space that you don’t also have a right to be in, your right to record the officer may be limited. For example, a Los Angeles jury in 2026 found two women guilty of felony stalking after they followed an ICE agent to his home and livestreamed the pursuit.

What are some other considerations when recording officers?

Even if you believe you are appropriately exercising your First Amendment right to record law enforcement, officers may nevertheless escalate the situation and/or retaliate against you. Below are some things to keep in mind.

• Stay calm and courteous.
• If you are a bystander, stand at a safe distance from the scene that you are recording. But note that officers may approach and confront you, closing that distance in an effort to accuse you of interfering with and possibly also assaulting a federal officer.
• Be alert and mindful of the possibility that officers may illegally retaliate against you in a number of ways, including arrest, destruction of your device, and bodily harm. They may also try to retaliate by harming the person being arrested. 
• Consider the sensitive nature of recording in the context of an arrest. For example, the person being arrested or their loved ones may be concerned about exposing their immigration status, so think about obtaining consent or blurring out faces in any version you publish to focus on ICE/CBP conduct (while still retaining the original video). 
• Law enforcement may not search your cell phone or other device without a warrant based on probable cause from a judge, even if you are under arrest. Thus, you may refuse a request from an officer to review or delete what you recorded. You also may refuse to unlock your phone or provide your passcode.

What can I do to protect my footage?

How well protected your photos or video footage are depends on both the device and the way you’re recording. If you’re uploading video to a livestreaming service, it can save that video to the cloud if you enable that setting. But what if you want to protect your recordings  stored locally?

Modern smartphones generally protect data, including videos, using encryption. This means if your phone is locked and protected by a strong passphrase, it is more difficult for an officer to delete what you’ve stored on the device. Removing biometrics such as face and fingerprint unlock can protect your device contents further. You can check your settings by following the steps in our Surveillance Self-Defense guides (see below) to ensure device encryption is turned on.

Want more information?

• Read more about your right to record law enforcement: https://www.eff.org/issues/right-record
• Read EFF’s Surveillance Self-Defense technical guide: https://ssd.eff.org

One of the best bulwarks against monopoly is interoperability—that is making a new product or service work with an existing product or service. Interoperability allows users, and not the manufacturers of their devices or largest player in a market, to decide what application best serves them. Unsurprisingly, companies like Apple have worked hard to resist interoperability requirements. 

On July 8, the General Court of the  European Union (General Court) ruled against Apple in several cases the company brought against the European Commission (joint cases), affirming the company’s obligations under the Digital Markets Act (DMA). Apple argued in the cases that it should be exempted from the law’s requirements especially with regards to interoperability on multiple grounds. We applaud the General Court’s  decision, and congratulate the Free Software Foundation Europe (FSFE) as well as others who intervened in support of the Commission against Apple's attempt to shirk off its responsibilities, thus ensuring fair competition in European markets.

A Positive Development for Europeans

This is a clear and substantive win for developers and users in Europe. The stranglehold Apple exerts over its ‘walled garden’ is injurious for developers, users, and researchers alike. By confirming Apple’s obligations under the DMA, the General Court has ensured that developers will be given more choice on where they can publish their apps, and users will have more options to obtain apps which, for whatever reason, Apple dislikes. And researchers will have less roadblocks and hurdles to overcome in their studies of Apple’s OSes, particularly iOS, iPadOS, and watchOS.

Apple argues that the interoperability requirements will force it to lower the security standards that have led Apple products’ users to trust their devices. While this self-serving logic is not entirely without merit, it is far from the inevitable outcome. Especially with regards to the App Store, users can be given clear, informed choice when leaving the Apple ecosystem to obtain apps elsewhere. While we urge European courts to take Apple’s security concerns seriously, we’ve previously noted that this should not be used as a smokescreen to protect anticompetitive behavior.

Interoperability and security are not inherently at odds. When interoperable functionality is worked into the security model of a platform from the ground-up, a proper balance can be struck between two forces that are often falsely framed as naturally conflicting. While Apple OS platforms have not been built this way from the get-go, it is still possible, but takes more time to get it right. Here, the devil is in the implementation details.

Apple’s Case Arguments and the Court’s Rebuttal

Under the DMA, designation as a ‘gatekeeper’ is reserved for the biggest of Big Tech, companies that provide services deemed essential for businesses to reach end users. Apple is one of only seven companies that meet this designation, along with Alphabet, Amazon, Booking, ByteDance, Meta, and Microsoft. In its case, Apple argued that Article 6(7) of the DMA, specifying interoperability requirements for gatekeepers aimed at restoring fair competition, is unlawful in light of the Charter of Fundamental Rights of the European Union (specifically the right to property), and as such its designation as a gatekeeper subject to the requirements is unlawful and should be annulled as a result. In its ruling, the General Court rejected the argument as Article 6(7) does not form the legal basis of the designation.

Apple separately argues that the App Store fails to meet the requirements defining a core platform service (CPS), since the various stores (across iOS, iPadOS, watchOS, macOS) do not constitute a single platform. A company’s gatekeeper status relies on it providing a CPS that is an important gateway for business users to reach end users. Here, the implications of the argument are clear: remove service designation as CPSes, remove the gatekeeper status. The court rejected the argument on the basis that “irrespective of the device on which it was available, each of the App Stores was used for the same purpose, namely to intermediate between end users and business users in the distribution of applications and in-app digital content.”

Finally, the court rejected as inadmissible Apple’s argument that iMessage should not be classified as a number-independent interpersonal communication service (NIICS) constituting a CPS. This decision rested on the fact that the “classification does not, by itself, produce binding legal effects that bring about a change in Apple’s legal position” since iMessage was not listed as an “important gateway” in the designation decision and therefore was not subject to the DMA obligations.

In ruling against Apple in favor of the European Commission, the General Court has set an important precedent in ensuring competitive fairness and openness in the digital marketplace. The landmark effects of the DMA will serve to benefit all Europeans in the choice and freedom it affords them. Despite Big Tech’s legal challenges, these decisions build a strong foundation for a better digital future—a lesson which other regions should learn from and take note.

X Corp. should not be able to escape privacy compliance because it changed its name. 

On May 15, X Corp. filed a petition before the Federal Trade Commission (FTC) to set aside or modify an order issued in 2022 requiring the company to report regularly to the FTC for its violations of user data. The order or “consent decree” is a result of misleading the platforms’ 140 million users by using private information given to secure accounts, like phone numbers and email addresses, for targeted advertising. It also fined the company $150 million for the infraction. As part of an open comments period, EFF and allies including Demand Progress Education Fund (DPEF), National Consumers League (NCL) and Electronic Privacy Information Center (EPIC) call on the FTC to reject this petition.

The 2022 order was a renewal of an order stemming from a previous violation. Back in 2011, Twitter (now X) reached a settlement with the FTC after the regulator found Twitter had failed to secure users’ personal information, resulting in exposure of that data to hackers. The settlement banned the company from misrepresenting its data protection measures, required it to set up safeguards on user data, and regularly report its security posture for twenty years. The renewal updated the expiration of X’s obligations to 2042, but if the FTC accepts X's petition, it would end much sooner.

In arguing to set aside the order, X remarks that since the order in 2011 it has “built an entirely new privacy and information security program staffed by new personnel operating under new leadership with a … philosophy grounded on the importance of privacy and information security.” 

These sweeping assurances that corporate restructuring led to a fundamental change in X’s policy and practices around user data should be met with a healthy dose of skepticism, given evidence to the contrary. For example, the company’s quiet rollout integrated its AI model Grok with the platform in 2024, trained (without meaningful consent) on X user data. The company was also subject to a massive data breach in 2025. Even if a rotation of leadership led to prioritizing privacy and information security, our letter highlights that this would not be sufficient grounds to remove the order, “because the FTC orders bind the corporate entity. Those obligations do not dissolve when the employees who negotiated or administered it depart.”

X argues that its entry into the AI space should be reason not to continue the oversight, claiming that “terminating the Order is critical to advancing American leadership in artificial intelligence.” Here again, broad-stroke claims that the guardrails in place “[diverts] engineering resources from innovation to compliance paperwork” ignores the dangers that AI introduces to user data. Far from being a reason to waive the order, clever attacks on models trained on user data has the ability to supercharge the types of secondary use violations that led to the 2022 order renewal. After all, an entire art has been developed around engineering LLM prompts to reveal the data a model was originally trained on.

Our response to X’s petition debunks many claims the company uses in its arguments. For example, there’s little evidence the order placed an undue financial burden on X. In our letter, we note that the compliance cost is merely “a rounding error against the $200 billion valuation of X Corp. following the xAI merger.”

Strong safeguards on our information require eagle-eyed oversight when that data is abused and misused for profiteering ventures. X’s actions not only showed us this in the past, but continue to do so in the present day. We and our civil society partners urge the FTC to take the clear, sensible path and reject X’s petition.

Last week, we released apkeep version 1.0.0, the latest edition of our command-line Android package downloading software. Rather than indicating major changes for the project, this milestone instead signifies arriving at a relatively stable and mature place after gradual iteration on the project over the course of over four years.

What’s New in 1.0.0

We do have a few fresh features we’ve packed into this latest release, though—all focused on the Google Play Store: 

• You can now download a dex metadata file associated with an app containing a Cloud Profile, which provides information on app performance based on real usage. 
• You can now provide a token generated by the Aurora Store’s dispenser to log in anonymously for app downloads. 
• Users can specify their own device profiles when downloading apps from Google Play, which the store uses to deliver the app variant which works for your particular device specifications. 
• We’ve also fixed an authentication bug introduced by the Play Store API.

In addition to the various Linux, Windows, and Android environments we support, we’re also happy to announce that since the last release in October we’ve been included in Homebrew for macOS users!

How Researchers Use apkeep to Understand the Android App Landscape

Researchers and users contributed most of the features of this release, including downloading dex metadata containing Google’s Cloud Profiles. This feature helps them use the tool in their own research of highlighting how these Android compilation profiles can be a vital source of information for evaluating dynamic testing. Numerous other projects have cited apkeep usage in their own workflows. For example, Exodus Privacy uses it to power the εxodus tool’s downloads when they monitor the privacy properties of apps. Various research teams have noted their own use of the tool in whitepapers, including one team who used the tool to download 21,154 apps in a widespread study of Android evasive malware. We are proud to provide a reliable tool in the toolbox they use to power their work.

What’s in Store for apkeep?

Our goals with apkeep have remained constant: provide a reliable, fast, and safe way to download apps from multiple app providers, not just the Google Play Store. While we’ve focused on it as the major Android app provider of choice across much of the world, we’ve expanded support to other stores as well, such as F-Droid for downloading open source apps. We’d like to continue broadening apkeep’s list of supported providers, to make it easy to do comparative analysis of apps provided in different contexts. For this, we’d love your contributions.

How You Can Help

If you’re using apkeep as part of your own toolbox (whether using it to do malware analysis, auditing apps, or simply using it as an app archiving tool), let us know! And if you like what we do, please consider donating to EFF to support our work.

On March 23, the FCC issued an update to their Covered List, a list of equipment banned from obtaining regulatory approval necessary for U.S. sale (and thus effectively a ban on sale of new devices), to include all new routers produced in foreign countries unless they are specifically given an exception by the Department of Defense (DoD) or DHS. The Commission cited “security gaps in foreign-made routers” leading to widespread cyberattacks as justification for the ban, mentioning the high-profile attacks by Chinese advanced persistent threat actors Volt, Flax, and Salt Typhoon. Although the stated intention is to stem the very real threat of domestic residential routers being commandeered to initiate attacks and act as residential proxies, this sweeping move serves as a blunt instrument that will impact many harmless products. In addition to being far too broad, it won’t even affect many vulnerable devices that are most active in these types of attacks: IoT and connected smart home devices.

Previously, the FCC had changed the Covered List to ban hardware by specific vendors, such as telecom equipment produced by companies Huawei and Hytera in 2021. This new blanket ban, in contrast, affects the importation and sale of almost all new consumer routers. It does not affect consumer routers produced in the United States, like Starlink in Texas. While some of the affected routers will be vulnerable to compromises that hijack the devices and use them for cybercrime and attacks, this ban does not distinguish between companies with a track-record of producing vulnerable products and those without. As a result, instead of incentivizing security-minded production, this will only limit the options consumers have to US-based manufacturers not affected by the ban—even those that lack stellar security reputations themselves.

While the sale of vulnerable routers in the U.S. will not stop, the announcement quoted an Executive Branch determination that foreign produced routers introduce “a supply chain vulnerability that could disrupt the U.S. economy, critical infrastructure, and national defense.” Yet this move does nothing to address the growing number of connected devices involved in the attacks this ban aims to address. As we have previously pointed out, supply chain attacks have resulted in no-name Android TV boxes preloaded with malware, sold by retail giants like Amazon, fuelling the massive Kimwolf and BADBOX 2 fraud and residential proxy botnets. Banning the specific models and manufacturers we know produce dangerous devices putting its purchasers at risk, rather than issuing blanket bans punishing reputable brands that do better, should be the priority.

With the FCCs top commissioner appointed by the President, this ban comes as other parts of the administration impose tariffs and issue dozens of trade-related executive orders aimed at foreign goods. A few larger companies with pockets deep enough to invest in manufacturing plants within the U.S. may see this as an opportune moment, while others not as well poised to begin U.S. operations may attempt to curry enough favor to be added to the DoD or DHS exception lists. At best, this will result in the immediate effect of an ill-targeted policy that does little to improve domestic cybersecurity posture. At worst, it entrenches existing players and deepens problematic quid-pro-quo arrangements.

American consumers deserve better. They deserve the assurance that the devices they use, whether routers or other connected smart home devices, are built to withstand attacks that put themselves and others at risk, no matter where they are manufactured. For this, a nuanced, careful consideration of products (such as was part of the FCC’s 2023-proposed U.S. Cyber Trust Mark) is necessary, rather than blanket bans.

Another year has come and gone, and with it, thousands of data breaches that affect millions of people. The question these days is less, Is my information in a data breach this year? and more How many data breaches had my information in them this year? 

Some data breaches are more noteworthy than others. Where one might affect a small number of people and include little useful information, like a name or email address, others might include data ranging from a potential medical diagnosis to specific location information. To catalog and talk about these breaches we created the Breachies, a series of tongue-in-cheek awards, to highlight the most egregious data breaches. 

In most cases, if these companies practiced a privacy first approach and focused on data minimization, only collecting and storing what they absolutely need to provide the services they promise, many data breaches would be far less harmful to the victims. But instead, companies gobble up as much as they can, store it for as long as possible, and inevitably at some point someone decides to poke in and steal that data. Once all that personal data is stolen, it can be used against the breach victims for identity theft, ransomware attacks, and to send unwanted spam. It has become such a common occurrence that it’s easy to lose track of which breaches affect you, and just assume your information is out there somewhere. Still, a few steps can help protect your information.

With that, let’s get to the awards.

The Winners

• The Say Something Without Saying Anything Award: Mixpanel
• The We Still Told You So Award: Discord
• The Tea for Two Award: Tea Dating Advice and TeaOnHer
• The Just Stop Using Tracking Tech Award: Blue Shield of California
• The Hacker's Hall Pass Award: PowerSchool
• The Worst. Customer. Service. Ever. Award: TransUnion
• The Annual Microsoft Screwed Up Again Award: Microsoft
• The I Didn’t Even Know You Had My Information Award: Gravy Analytics
• The Keeping Up With My Cybertruck Award: Teslamate
• The Disorder in the Courts Award: PACER
• The Only Stalkers Allowed Award: Catwatchful
• The Why We’re Still Stuck on Unique Passwords Award: Plex
• The Uh, Yes, Actually, I Have Been Pwned Award: Troy Hunt’s Mailing List
• (Dis)honorable Mentions

The Say Something Without Saying Anything Award: Mixpanel

We’ve long warned that apps delivering your personal information to third-parties, even if they aren’t the ad networks directly driving surveillance capitalism, presents risks and a salient target for hackers. The more widespread your data, the more places attackers can go to find it. Mixpanel, a data analytics company which collects information on users of any app which incorporates its SDK, suffered a major breach in November this year. The service has been used by a wide array of companies, including the Ring Doorbell App, which we reported on back in 2020 delivering a trove of information to Mixpanel, and PornHub, which despite not having worked with the company since 2021, had its historical record of paying subscribers breached.    

There’s a lot we still don’t know about this data breach, in large part because the announcement about it is so opaque, leaving reporters with unanswered questions about how many were affected, if the hackers demanded a ransom, and if Mixpanel employee accounts utilized standard security best practices. One thing is clear, though: the breach was enough for OpenAI to drop them as a provider, disclosing critical details on the breach in a blog post that Mixpanel’s own announcement conveniently failed to mention.

The worst part is that, as a data analytics company providing libraries which are included in a broad range of apps, we can surmise that the vast majority of people affected by this breach have no direct relationship with Mixpanel, and likely didn’t even know that their devices were delivering data to the company. These people deserve better than vague statements by companies which profit off of (and apparently insufficiently secure) their data.

The We Still Told You So Award: Discord

Last year, AU10TIX won our first The We Told You So Award because as we predicted in 2023, age verification mandates would inevitably lead to more data breaches, potentially exposing government IDs as well as information about the sites that a user visits. Like clockwork, they did. It was our first We Told You So Breachies award, but we knew it wouldn’t be the last. 

Unfortunately, there is growing political interest in mandating identity or age verification before allowing people to access social media or adult material. EFF and others oppose these plans because they threaten both speech and privacy. 

Nonetheless, this year’s winner of The We Still Told You So Breachies Award is the messaging app, Discord — once known mainly for gaming communities, it now hosts more than 200 million monthly active users and is widely used to host fandom and community channels. 

In September of this year, much of Discord’s age verification data was breached — including users’ real names, selfies, ID documents, email and physical addresses, phone numbers, IP addresses, and other contact details or messages provided to customer support. In some cases, “limited billing information” was also accessed—including payment type, the last four digits of credit card numbers, and purchase histories. 

Technically though, it wasn’t Discord itself that was hacked but their third-party customer support provider — a company called Zendesk—that was compromised, allowing attackers to access Discord’s user data. Either way, it’s Discord users who felt the impact. 

The Tea for Two Award: Tea Dating Advice and TeaOnHer

Speaking of age verification, Tea, the dating safety app for women, had a pretty horrible year for data breaches. The app allows users to anonymously share reviews and safety information about their dates with men—helping keep others safe by noting red flags they saw during their date.

Since Tea is aimed at women’s safety and dating advice, the app asks new users to upload a selfie or photo ID to verify their identity and gender to create an account. That’s some pretty sensitive information that the app is asking you to trust it with! Back in July, it was reported that 72,000 images had been leaked from the app, including 13,000 images of photo IDs and 59,000 selfies. These photos were found via an exposed database hosted on Google’s mobile app development platform, Firebase. And if that isn’t bad enough, just a week later a second breach exposed private messages between users, including messages with phone numbers, abortion planning, and discussions about cheating partners. This breach included more than 1.1 million messages from early 2023 all the way to mid-2025, just before the breach was reported. Tea released a statement shortly after, temporarily disabling the chat feature.

But wait, there’s more. A completely different app based on the same idea, but for men, also suffered a data breach. TeaOnHer failed to protect similar sensitive data. In August, TechCrunch discovered that user information — including emails, usernames, and yes, those photo IDs and selfies — was accessible through a publicly available web address. Even worse? TechCrunch also found the email address and password the app’s creator uses to access the admin page.

Breaches like this are one of the reasons that EFF shouts from the rooftops against laws that mandate user verification with an ID or selfie. Every company that collects this information becomes a target for data breaches — and if a breach happens, you can’t just change your face. 

The Just Stop Using Tracking Tech Award: Blue Shield of California

Another year, another data breach caused by online tracking tools. 

In April, Blue Shield of California revealed that it had shared 4.7 million people’s health data with Google by misconfiguring Google Analytics on its website. The data, which may have been used for targeted advertising, included: people’s names, insurance plan details, medical service providers, and patient financial responsibility. The health insurance company shared this information with Google for nearly three years before realizing its mistake.

If this data breach sounds familiar, it’s because it is: last year’s Just Stop Using Tracking Tech award also went to a healthcare company that leaked patient data through tracking code on its website. Tracking tools remain alarmingly common on healthcare websites, even after years of incidents like this one. These tools are marketed as harmless analytics or marketing solutions, but can expose people’s sensitive data to advertisers and data brokers. 

EFF’s free Privacy Badger extension can block online trackers, but you shouldn’t need an extension to stop companies from harvesting and monetizing your medical data. We need a strong, federal privacy law and ban on online behavioral advertising to eliminate the incentives driving companies to keep surveilling us online. 

The Hacker's Hall Pass Award: PowerSchool

 In December 2024, PowerSchool, the largest provider of student information systems in the U.S., gave hackers access to sensitive student data. The breach compromised personal information of over 60 million students and teachers, including Social Security numbers, medical records, grades, and special education data. Hackers exploited PowerSchool’s weak security—namely, stolen credentials to their internal customer support portal—and gained unfettered access to sensitive data stored by school districts across the country.

PowerSchool failed to implement basic security measures like multi-factor authentication, and the breach affected districts nationwide. In Texas alone, over 880,000 individuals’ data was exposed, prompting the state's attorney general to file a lawsuit, accusing PowerSchool of misleading its customers about security practices. Memphis-Shelby County Schools also filed suit, seeking damages for the breach and the cost of recovery.

While PowerSchool paid hackers an undisclosed sum to prevent data from being published, the company’s failure to protect its users’ data raises serious concerns about the security of K-12 educational systems. Adding to the saga, a Massachusetts student, Matthew Lane, pleaded guilty in October to hacking and extorting PowerSchool for $2.85 million in Bitcoin. Lane faces up to 17 years in prison for cyber extortion and aggravated identity theft, a reminder that not all hackers are faceless shadowy figures — sometimes they’re just a college kid.

The Worst. Customer. Service. Ever. Award: TransUnion

Credit reporting giant TransUnion had to notify its customers this year that a hack nabbed the personal information of 4.4 million people. How'd the attackers get in? According to a letter filed with the Maine Attorney General's office obtained by TechCrunch, the problem was a “third-party application serving our U.S. consumer support operations.” That's probably not the kind of support they were looking for. 

TransUnion said in a Texas filing that attackers swept up “customers’ names, dates of birth, and Social Security numbers” in the breach, though it was quick to point out in public statements that the hackers did not access credit reports or “core credit data.” While it certainly could have been worse, this breach highlights the many ways that hackers can get their hands on information. Coming in through third-parties, companies that provide software or other services to businesses, is like using an unguarded side door, rather than checking in at the front desk. Companies, particularly those who keep sensitive personal information, should be sure to lock down customer information at all the entry points. After all, their decisions about who they do business with ultimately carry consequences for all of their customers — who have no say in the matter.

The Annual Microsoft Screwed Up Again Award: Microsoft

Microsoft is a company nobody feels neutral about. Especially in the infosec world. The myriad software vulnerabilities in Windows, Office, and other Microsoft products over the decades has been a source of frustration and also great financial rewards for both attackers and defenders. Yet still, as the saying goes: “nobody ever got fired for buying from Microsoft.” But perhaps, the times, they are a-changing. 

In July 2025, it was revealed that a zero-day security vulnerability in Microsoft’s flagship file sharing and collaboration software, SharePoint, had led to the compromise of over 400 organizations, including major corporations and sensitive government agencies such as the National Nuclear Security Administration (NNSA), the federal agency responsible for maintaining and developing the U.S. stockpile of nuclear weapons. The attack was attributed to three different Chinese government linked hacking groups. Amazingly, days after the vulnerability was first reported, there were still thousands of vulnerable self-hosted Sharepoint servers online. 

Zero-days happen to tech companies, large and small. It’s nearly impossible to write even moderately complex software that is bug and exploit free, and Microsoft can’t exactly be blamed for having a zero-day in their code. But when one company is the source of so many zero-days consistently for so many years, one must start wondering whether they should put all their eggs (or data) into a basket that company made. Perhaps if Microsoft’s monopolistic practices had been reined in back in the 1990s we wouldn’t be in a position today where Sharepoint is the defacto file sharing software for so many major organizations. And maybe, just maybe, this is further evidence that tech monopolies and centralization of data aren’t just bad for consumer rights, civil liberties, and the economy—but also for cybersecurity. 

The Silver Globe Award: Flat Earth Sun, Moon & Zodiac

Look, we’ll keep this one short: in October of last year, researchers found security issues in the flat earther app, Flat Earth, Sun, Moon, & Clock. In March of 2025, that breach was confirmed. What’s most notable about this, aside from including a surprising amount of information about gender, name, email addresses and date of birth, is that it also included users’ location info, including latitude and longitude. Huh, interesting.

The I Didn’t Even Know You Had My Information Award: Gravy Analytics

In January, hackers claimed they stole millions of people’s location history from a company that never should’ve had it in the first place: location data broker Gravy Analytics. The data included timestamped location coordinates tied to advertising IDs, which can reveal exceptionally sensitive information. In fact, researchers who reviewed the leaked data found it could be used to identify military personnel and gay people in countries where homosexuality is illegal. 

The breach of this sensitive data is bad, but Gravy Analytics’s business model of regularly harvesting and selling it is even worse. Despite the fact that most people have never heard of them, Gravy Analytics has managed to collect location information from a billion phones a day. The company has sold this data to other data brokers, makers of police surveillance tools, and the U.S. government. 

How did Gravy Analytics get this location information from people’s phones? The data broker industry is notoriously opaque, but this breach may have revealed some of Gravy Analytics’ sources. The leaked data referenced thousands of apps, including Microsoft apps, Candy Crush, Tinder, Grindr, MyFitnessPal, pregnancy trackers and religious-focused apps. Many of these app developers said they had no relationship with Gravy Analytics. Instead, expert analysis of the data suggests it was harvested through the advertising ecosystem already connected to most apps. This breach provides further evidence that online behavioral advertising fuels the surveillance industry. 

Whether or not they get hacked, location data brokers like Gravy Analytics threaten our privacy and security. Follow EFF’s guide to protecting your location data and help us fight for legislation to dismantle the data broker industry. 

The Keeping Up With My Cybertruck Award: Teslamate

TeslaMate, a tool meant to track Tesla vehicle data (but which is not owned or operated by Tesla itself), has become a cautionary tale about data security. In August, a security researcher found more than 1,300 self-hosted TeslaMate dashboards were exposed online, leaking sensitive information such as vehicle location, speed, charging habits, and even trip details. In essence, your Cybertruck became the star of its own Keeping Up With My Cybertruck reality show, except the audience wasn’t made up of fans interested in your lifestyle, just random people with access to the internet.

TeslaMate describes itself as “that loyal friend who never forgets anything!” — but its lack of proper security measures makes you wish it would. This breach highlights how easily location data can become a tool for harassment or worse, and the growing need for legislation that specifically protects consumer location data. Without stronger regulations around data privacy, sensitive location details like where you live, work, and travel can easily be accessed by malicious actors, leaving consumers with no recourse.

The Disorder in the Courts Award: PACER

Confidentiality is a core principle in the practice of law. But this year a breach of confidentiality came from an unexpected source: a breach of the federal court filing system. In August, Politico reported that hackers infiltrated the Case Management/Electronic Case Files (CM/ECF) system, which uses the same database as PACER, a searchable public database for court records. Of particular concern? The possibility that the attack exposed the names of confidential informants involved in federal cases from multiple court districts. Courts across the country acted quickly to set up new processes to avoid the possibility of further compromises.

The leak followed a similar incident in 2021 and came on the heels of a warning to Congress that the file system is more than a little creaky. In fact, an IT official from the federal court system told the House Judiciary Committee that both systems are “unsustainable due to cyber risks, and require replacement.”

The Only Stalkers Allowed Award: Catwatchful

Just like last year, a stalkerware company was subject to a data breach that really should prove once and for all that these companies must be stopped. In this case, Catwatchful is an Android spyware company that sells itself as a “child monitoring app.” Like other products in this category, it’s designed to operate covertly while uploading the contents of a victim’s phone, including photos, messages, and location information.

This data breach was particularly harmful, as it included not just the email addresses and passwords on the customers who purchased the app to install on a victim’s phone, but also the data from the phones of 26,000 victims’ devices, which could include the victims’ photos, messages, and real-time location data.

This was a tough award to decide on because Catwatchful wasn’t the only stalkerware company that was hit this year. Similar breaches to SpyX, Cocospy, and Spyic were all strong contenders. EFF has worked tirelessly to raise the alarm on this sort of software, and this year worked with AV Comparatives to test the stalkerware detection rate on Android of various major antivirus apps.

The Why We’re Still Stuck on Unique Passwords Award: Plex

Every year, we all get a reminder about why using unique passwords for all our accounts is crucial for protecting our online identities. This time around, the award goes to Plex, who experienced a data breach that included customer emails, usernames, and hashed passwords (which is a fancy way of saying passwords are scrambled through an algorithm, but it is possible they could still be deciphered).

If this all sounds vaguely familiar to you for some reason, that’s because a similar issue also happened to Plex in 2022, affecting 15 million users. Whoops.

This is why it is important to use unique passwords everywhere. A password manager, including one that might be free on your phone or browser, makes this much easier to do. Likewise, credential stuffing illustrates why it’s important to use two-factor authentication. Here’s how to turn that on for your Plex account.

The Uh, Yes, Actually, I Have Been Pwned Award: Troy Hunt’s Mailing List

Troy Hunt, the person behind Have I Been Pwned? and who has more experience with data breaches than just about anyone, also proved that anyone can be pwned. In a blog post, he details what happened to his mailing list:

You know when you're really jet lagged and really tired and the cogs in your head are just moving that little bit too slow? That's me right now, and the penny has just dropped that a Mailchimp phish has grabbed my credentials, logged into my account and exported the mailing list for this blog.

And he continues later:

I'm enormously frustrated with myself for having fallen for this, and I apologise to anyone on that list. Obviously, watch out for spam or further phishes and check back here or via the social channels in the nav bar above for more.

The whole blog is worth a read as a reminder that phishing can get anyone, and we thank Troy Hunt for his feedback on this and other breaches to include this year.

Tips to Protect Yourself

Data breaches are such a common occurrence that it’s easy to feel like there’s nothing you can do, nor any point in trying. But privacy isn’t dead. While some information about you is almost certainly out there, that’s no reason for despair. In fact, it’s a good reason to take action.

There are steps you can take right now with all your online accounts to best protect yourself from the the next data breach (and the next, and the next):

• Use unique passwords on all your online accounts. This is made much easier by using a password manager, which can generate and store those passwords for you. When you have a unique password for every website, a data breach of one site won’t cascade to others.
• Use two-factor authentication when a service offers it. Two-factor authentication makes your online accounts more secure by requiring additional proof (“factors”) alongside your password when you log in. While two-factor authentication adds another step to the login process, it’s a great way to help keep out anyone not authorized, even if your password is breached.
• Delete old accounts: Sometimes, you’ll get a data breach notification for an account you haven’t used in years. This can be a nice reminder to delete that account, but it’s better to do so before a data breach happens, when possible. Try to make it a habit to go through and delete old accounts once a year or so. 
• Freeze your credit. Many experts recommend freezing your credit with the major credit bureaus as a way to protect against the sort of identity theft that’s made possible by some data breaches. Freezing your credit prevents someone from opening up a new line of credit in your name without additional information, like a PIN or password, to “unfreeze” the account. This might sound absurd considering they can’t even open bank accounts, but if you have kids, you can freeze their credit too.
• Keep a close eye out for strange medical bills. With the number of health companies breached this year, it’s also a good idea to watch for healthcare fraud. The Federal Trade Commission recommends watching for strange bills, letters from your health insurance company for services you didn’t receive, and letters from debt collectors claiming you owe money. 

(Dis)Honorable Mentions

According to one report, 2025 had already seen 2,563 data breaches by October, which puts the year on track to be one of the worst by the sheer number of breaches.

We did not investigate every one of these 2,500-plus data breaches, but we looked at a lot of them, including the news coverage and the data breach notification letters that many state Attorney General offices host on their websites. We can’t award the coveted Breachies Award to every company that was breached this year. Still, here are some (dis)honorable mentions we wanted to highlight:

Salesforce, F5, Oracle, WorkComposer, Raw, Stiizy, Ohio Medical Alliance LLC, Hello Cake, Lovense, Kettering Health, LexisNexis, WhatsApp, Nexar, McDonalds, Congressional Budget Office, Doordash, Louis Vuitton, Adidas, Columbia University, Hertz, HCRG Care Group, Lexipol, Color Dating, Workday, Aflac, and Coinbase. And a special nod to last minute entrants Home Depot, 700Credit, and Petco.

What now? Companies need to do a better job of only collecting the information they need to operate, and properly securing what they store. Also, the U.S. needs to pass comprehensive privacy protections. At the very least, we need to be able to sue companies when these sorts of breaches happen (and while we’re at it, it’d be nice if we got more than $5.21 checks in the mail). EFF has long advocated for a strong federal privacy law that includes a private right of action.