Transistors, the building blocks of modern electronics, are typically made of silicon. Because it’s a semiconductor, this material can control the flow of electricity in a circuit. But silicon has fundamental physical limits that restrict how compact and energy-efficient a transistor can be.

MIT researchers have now replaced silicon with a magnetic semiconductor, creating a magnetic transistor that could enable smaller, faster, and more energy-efficient circuits. The material’s magnetism strongly influences its electronic behavior, leading to more efficient control of the flow of electricity. 

The team used a novel magnetic material and an optimization process that reduces the material’s defects, which boosts the transistor’s performance.

The material’s unique magnetic properties also allow for transistors with built-in memory, which would simplify circuit design and unlock new applications for high-performance electronics.

“People have known about magnets for thousands of years, but there are very limited ways to incorporate magnetism into electronics. We have shown a new way to efficiently utilize magnetism that opens up a lot of possibilities for future applications and research,” says Chung-Tao Chou, an MIT graduate student in the departments of Electrical Engineering and Computer Science (EECS) and Physics, and co-lead author of a paper on this advance.

Chou is joined on the paper by co-lead author Eugene Park, a graduate student in the Department of Materials Science and Engineering (DMSE); Julian Klein, a DMSE research scientist; Josep Ingla-Aynes, a postdoc in the MIT Plasma Science and Fusion Center; Jagadeesh S. Moodera, a senior research scientist in the Department of Physics; and senior authors Frances Ross, TDK Professor in DMSE; and Luqiao Liu, an associate professor in EECS, and a member of the Research Laboratory of Electronics; as well as others at the University of Chemistry and Technology in Prague. The paper appears today in Physical Review Letters.

Overcoming the limits

In an electronic device, silicon semiconductor transistors act like tiny light switches that turn a circuit on and off, or amplify weak signals in a communication system. They do this using a small input voltage.

But a fundamental physical limit of silicon semiconductors prevents a transistor from operating below a certain voltage, which hinders its energy efficiency.

To make more efficient electronics, researchers have spent decades working toward magnetic transistors that utilize electron spin to control the flow of electricity. Electron spin is a fundamental property that enables electrons to behave like tiny magnets.

So far, scientists have mostly been limited to using certain magnetic materials. These lack the favorable electronic properties of semiconductors, constraining device performance.

“In this work, we combine magnetism and semiconductor physics to realize useful spintronic devices,” Liu says.

The researchers replace the silicon in the surface layer of a transistor with chromium sulfur bromide, a two-dimensional material that acts as a magnetic semiconductor.

Due to the material’s structure, researchers can switch between two magnetic states very cleanly. This makes it ideal for use in a transistor that smoothly switches between “on” and “off.”

“One of the biggest challenges we faced was finding the right material. We tried many other materials that didn’t work,” Chou says.

They discovered that changing these magnetic states modifies the material’s electronic properties, enabling low-energy operation. And unlike many other 2D materials, chromium sulfur bromide remains stable in air.

To make a transistor, the researchers pattern electrodes onto a silicon substrate, then carefully align and transfer the 2D material on top. They use tape to pick up a tiny piece of material, only a few tens of nanometers thick, and place it onto the substrate.

“A lot of researchers will use solvents or glue to do the transfer, but transistors require a very clean surface. We eliminate all those risks by simplifying this step,” Chou says.

Leveraging magnetism

This lack of contamination enables their device to outperform existing magnetic transistors. Most others can only create a weak magnetic effect, changing the flow of current by a few percent or less. Their new transistor can switch or amplify the electric current by a factor of 10.

They use an external magnetic field to change the magnetic state of the material, switching the transistor using significantly less energy than would usually be required.

The material also allows them to control the magnetic states with electric current. This is important because engineers cannot apply magnetic fields to individual transistors in an electronic device. They need to control each one electrically.

The material’s magnetic properties could also enable transistors with built-in memory, simplifying the design of logic or memory circuits.

A typical memory device has a magnetic cell to store information and a transistor to read it out. Their method can combine both into one magnetic transistor.

“Now, not only are transistors turning on and off, they are also remembering information. And because we can switch the transistor with greater magnitude, the signal is much stronger so we can read out the information faster, and in a much more reliable way,” Liu says.

Building on this demonstration, the researchers plan to further study the use of electrical current to control the device. They are also working to make their method scalable so they can fabricate arrays of transistors.

This research was supported, in part, by the Semiconductor Research Corporation, the U.S. Defense Advanced Research Projects Agency (DARPA), the U.S. National Science Foundation (NSF), the U.S. Department of Energy, the U.S. Army Research Office, and the Czech Ministry of Education, Youth, and Sports. The work was partially carried out at the MIT.nano facilities.

The Senate Commerce Committee will vote this week on several censorious and privacy invasive bills: KOSA, the SCREEN Act, Youth AI Privacy Act, and CHATBOT Act. While we appreciate that the Committee is taking the time to look at these bills separately, it’s still impossible to ignore the message Congress is sending to the world: Age-gate the internet and block young people from speaking and accessing lawful speech online. Or else. 

Take action

Tell Congress: don't age-gate the internet

Each of these bills claims to be trying to protect children and teenagers from dangerous situations on and offline—certainly a worthy goal. But the proposed solutions in these bills are unlikely to make children and teenagers safer at all. Rather, they would create sweeping new privacy and data security problems, and force platforms to adopt unconstitutional restrictions on the content they host, for both adults and teenagers. 

There is a better way. Instead of considering these bills, the Senate Commerce Committee should be focusing on a national consumer privacy bill that would protect ALL internet users, or on banning behavioral advertising that tracks us across the web—again, for users of all ages. 

But the bills being considered this week move in the other direction—more information being collected, more surveillance, and less privacy for internet users of all ages. 

Take action

help eff oppose these bills

EFF sent a letter to the Committee with our concerns about these bills. We look forward to continuing to work with them to find a way forward that protects all users. 

The Ninth Circuit Court of Appeals has endorsed a commonsense technical interpretation of the Computer Fraud and Abuse Act (CFAA), a law not usually given to such interpretation. Amazon had sued Perplexity AI to try to shut down its Comet browser, claiming the browser’s optional agentic AI “Assistant” that can browse websites like Amazon for comparison shopping purposes, violated the CFAA because Amazon did not “authorize” Perplexity to access Amazon users’ accounts. Rejecting that theory, the Ninth Circuit held that Perplexity was unlikely to be liable because users operate the tool, not Perplexity.

That’s the right conclusion, as both a legal and technical matter. As we explained to the court in our amicus brief, the CFAA requires unauthorized “access,” and Perplexity itself does not access Amazon’s servers—users of the Comet browser do. The court agreed, noting that EFF’s explanation “articulates the nature of the system most clearly.”

The court noted that agentic AI may present novel legal issues, and there is “little to no existing caselaw directly dealing with how to ascribe responsibility for AI agents like the Assistant, let alone caselaw specifically dealing with agentic AI in the CFAA context.” Ultimately, though, thorny questions of AI “intent” were irrelevant to this case, because the Assistant “is a tool, not a person for statutory purposes.” And, the court concluded, it is a tool operated by users, not Perplexity. Even where Perplexity received information from users about their Amazon accounts and used this information to instruct the Assistant, the court found that that did not constitute the sort of control needed to find access by Perplexity. As the court noted, Amazon might have other viable claims against Perplexity, but invoking the CFAA was both legally baseless and bad policy that “could expose users themselves to criminal liability. 

This is a gratifying decision because all too often, big players use the CFAA to bully upstarts and innovators who offer potentially helpful user tools. When we counsel clients as part of EFF’s Coders Rights Project, CFAA risk is a frequent topic of conversation, even for developers who merely create tools that allow others to access websites in new or different ways. We’ve stood up for these creators before, and we’ll do it again, but it’s helpful to have back up from one of the most influential appellate courts in the country.

Related Cases: Facebook v. Power Ventures

Developers Must Beware of Ad Libraries that Betray Users’ Privacy

SAN FRANCISCO – Some software development kits (SDKs) provided by advertising companies to help developers monetize their apps are automatically feeding users’ location data into systems that location data brokers use to track people, an Electronic Frontier Foundation (EFF) report found. 

EFF began investigating the location-sharing practices of various advertising SDKs to better understand the pipeline from mobile apps to location data brokers. The probe revealed how such SDKs can facilitate and encourage location data sharing – without users’ knowledge or meaningful consent – through privacy-invasive defaults, financial incentives, and unclear documentation.    

“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,” EFF Staff Technologist Lena Cohen said. “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.” 

Cohen and EFF Senior Staff Technologist Bill Budington 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 their analysis, they highlighted four advertising SDKs that collect and share a user's location by default for ad targeting whenever the user has given the app location permissions: InMobi, BidMachine, Verve’s HyBid, and Huawei’s Petal Ads. But EFF’s focus on these four 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. In fact, advertising SDKs not discussed in this investigation have been criticized and sued for collecting location data without valid user consent.  

“When developers let advertising SDKs collect location data, they’re putting users at risk of more than just creepy ads,” Budington said. “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. Developers have a responsibility to protect their users’ from these harms, regardless of advertising SDKs’ default settings.” 

For the EFF report: https://www.eff.org/deeplinks/2026/07/developers-beware-ad-libraries-betray-your-users-location-privacy

For more on location data brokers: https://www.eff.org/issues/location-data-brokers 

For more on SDKs: https://www.eff.org/deeplinks/2022/06/how-federal-government-buys-our-cell-phone-location-data   

Contact:  WilliamBudingtonSenior Staff Technologistbill@eff.org LenaCohenStaff Technologistlcohen@eff.org

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.

Attribution is preliminary, and so far it seems no real damage.

And it seems like this is a campaign that has targeted at least seven states. And, because this is where the US is right now, Trump doesn’t believe it’s Iran and that Minnesota…I guess…hacked itself.

“I think I blame it on Minnesota because they’re grossly incompetent,” Trump said. “I would blame it on Minnesota and the governor, the corrupt governor of Minnesota. They like to say, ‘Oh, it’s Iran.’ Iran should be so lucky. Iran’s got bigger problems than worrying about Minnesota.”...

In the scorching heat of every Las Vegas summer, EFF joins thousands of hackers, makers, policy analysts, and activists for the world's largest computer security gathering. If you're there during this summer security week, be sure to say hello to us at BSides Las Vegas, Black Hat Briefings, and DEF CON 34. While tech companies align with governments to target the people, our community is harnessing technology to fight back. Will you lend your support this year?

JOIN EFF

EFF’s relentless work in the legal system makes a meaningful difference for privacy and free expression everywhere. But we also know that your rights won't wait while the wheels of justice turn.

Sometimes hacking the system means creating tools and resources to protect your rights today. That includes EFF’s Privacy Badger, Certbot, Surveillance Self-Defense guide, and the countless security trainings that our team conducts for vulnerable populations—all thanks to EFF member support.

Technology is inseparable from our workplaces, schools, healthcare, the justice system, and our democratic process. If you think tech should benefit everyone and not just accumulate wealth and control for the powerful, then congratulations: We'd like to welcome you to the team.

Hayley and Joe take a break from EFF’s Activism Team to show off EFF’s DEF CON member t-shirt.

For a limited time only: Get EFF’s “Many Hands Make Light Work” t-shirt designed for the DEF CON 34 hacker conference by EFF artist Hannah Diaz. Don’t miss the link to the online puzzle incorporated into the design! With the strength of community and the spirit of curiosity, we can hack anything.

Many thanks to our puzzlemasters Aaron Steimle (AKA Elegin) and Kevin Hulin (AKA CryptoK). Elegin is our longtime collaborator on the EFF shirt puzzle, and previously a multiyear winner of this very contest. CryptoK is a crypto puzzle enthusiast and also develops challenges for the DEF CON Crypto and Privacy Village's Gold Bug Contest.

Members can also choose from EFF’s puffy stickers, the internet tracker-obsessed Privacy Badger embroidered sweatshirt, and our ALPR-focused “Claw Back” t-shirt.

EFF member t-shirt designs: Claw Back and Many Hands Make Light Work

EFF fights to protect fundamental rights for everyone, and your privacy and free expression have never been more important. Support the cause today! Together we can make sure that technology supports freedom, justice, and innovation for all people.

And it’s personal information (alternate link):

The exposed data includes an AI-powered therapy app that someone appears to have vibe-coded, notes on meetings, and a dashboard someone made apparently to analyze medical billing data. Exposed chats reportedly include private cryptocurrency wallet keys and personal information like peoples’ addresses.

What seems to be the issue is a user setting about data sharing. Anthropic’s position is that it’s not their problem:

“We give people control over sharing their Claude conversations publicly, and in keeping with our privacy principles, we do not share chat directories or sitemaps with search engines like Google,” the company said in a statement. “These shareable links are not guessable or discoverable unless people choose to share them themselves. When someone shares a conversation, they are making that content publicly accessible, and like other public web content, it may be archived by third-party services.”...

A summer surge in power consumption is straining regional grids that are also seeing a boom in data center energy demand.

Requiring companies to disclose their climate risks provides valuable information that otherwise isn't always available, they said.

Former Republican EPA leaders and a conservative scholar join Democrats supporting local efforts to sue for climate-related damages.

House and Senate Democrats are looking for more data on how home insurers calculate their pricing.

The world hit a milestone of 3 terawatts of solar deployed this year.

Member countries are worried that low-carbon quotas in the Industrial Accelerator Act could push up prices and hurt Europe’s competitiveness.

Firefighters continued to battle wildfires in southern Greece and France on Monday, and much of the U.K. is officially in drought.

Illegal land grabbing, cattle ranching and expanding infrastructure continue to put heavy pressure on the Amazon.

A one-size-fits-all approach likely isn’t the best strategy when designing artificial intelligence systems that assist users in disease diagnosis.

A new study by researchers at MIT and elsewhere found that, while AI assistance generally improved the accuracy of non-experts and clinicians in diagnosing skin diseases, AI explainability methods had different impacts depending on the users’ knowledge level. 

Explainable AI methods help users know when to trust a model’s predictions by describing or validating the model’s decision-making. For instance, a model might use a heat map to highlight image regions that were most important in its diagnosis or a large language model (LLM) to explain the prediction in plain language.

In this study, researchers tested non-experts and primary care providers in skin disease diagnosis, with and without the help of different explainable AI systems. 

They found that non-experts’ diagnostic accuracy improved, but it was largely due to deference to the AI system. Non-experts trusted LLM-based explanations whether they were right or wrong, and found explanations more convincing when they were vague or generic.

By contrast, clinicians were not tripped up by incorrect AI assistance and performed best when given only a model’s prediction, with no accompanying explanation. 

“Good AI systems can improve performance in some health settings, but this has to be balanced carefully with algorithmic deference that can lead to more error. We know that both AI and explainability methods can engage automation bias in humans, and this anchoring effect is something that must be accounted for when we design AI systems,” says Marzyeh Ghassemi, an associate professor in MIT’s Department of Electrical Engineering and Computer Science (EECS), a member of the Institute for Medical Engineering and Science, and a principal investigator at the Laboratory for Information and Decision Systems and the Abdul Latif Jameel Clinic for Machine Learning in Health.

“These findings are important as patients increasingly turn to AI to help with their health care. Our findings show that those with the least medical knowledge are most likely to be led astray when explainable AI models give an erroneous output,” says Roxana Daneshjou, a co-author and assistant professor of biomedical data science and dermatology at Stanford University.

These results underscore the importance of building AI systems with users in mind and of developing explainability methods that encourage critical thinking rather than overreliance on the model, the researchers say.

“It’s getting obvious that we cannot just assume a good AI will solve all problems. We need to pay careful attention to the users who will be using the AI system, because the same explanation can help an expert and mislead a beginner. Often the people who could benefit most from AI are the ones most likely to be led astray by it, so how we present a recommendation matters as much as whether it’s correct,” says lead author Orson Xu, an assistant professor in the Department of Biomedical Informatics at Columbia University.

Ghassemi, Xu, and Daneshjou are joined on the paper by many authors, including MIT graduate student Haoran Zhang, undergraduate Reina Wang, and Luis Soenksen PhD ’20, a research affiliate at the Jameel Clinic, along with clinicians and researchers. A description of the work appears today in Nature Medicine.

Exploring explanations

Several FDA-approved AI interfaces are being used to help clinicians identify skin conditions in medical images, as a way to streamline early diagnosis. In addition to providing a prediction of whether disease is present in the image, these tools often use one of several methods that explain the model’s decision-making.

At the same time, non-experts can perform digital diagnosis on their own using AI-powered search engines that predict skin diseases based on user prompts. These systems often use LLMs to explain the model’s prediction in simpler terms.

The researchers explored the effects and potential benefits of these explainable AI tools on primary care physicians and non-experts in dermatological disease detection. They tested users by showing them medical images plus an AI prediction of skin disease, employing different explainable AI approaches. 

These approaches included: an AI prediction and confidence level with no explanation, a method that provides similar images to reinforce its prediction, a heat map-based approach that highlights important image regions, and an LLM that explains the model’s reasoning in plain language.

Non-experts were tasked with deciding whether an image of a skin mole was cancerous, with and without the help of explainable AI. Clinicians were given the more challenging task of providing a differential diagnosis of dermatological disease.

The researchers found that all explainable AI approaches improved the accuracy of non-experts, mostly because the tools helped users diagnose non-cancerous moles. 

In addition, when they employed a fairness-constrained model designed to combat bias against darker skin tones, the system significantly improved accuracy and reduced diagnostic disparities based on skin tone.

“But the reason non-expert users are better is because they are more reliant on the models. When the model is wrong, it hurts performance more than it helps performance when the model is right. We were just able to train very good AI models for this setting,” Ghassemi says.

This deference effect is largest with LLM explanations, and users were more confident about their wrong answers when aided by an LLM.

On the other hand, clinicians were resilient to incorrect AI explanations and, of all the explainability methods, LLMs boost their accuracy the least.

“It really comes down to how each group uses the explanation. A clinician already has a diagnosis in mind and checks the AI against their own training, so a bad explanation gets caught. Meanwhile, a non-expert can use that exact same explanation to form an opinion in the first place, so a plausible, confident-sounding rationale can pull them toward the wrong answer. The same tool ends up being an asset for one user and a liability for another,” Xu says.

Overcoming the deference effect

When the researchers dug deeper, they found that users who were most deferential to AI assistance were the worst performers on the task without the help of AI. 

They also found that the time at which users were presented with AI explanations influenced their behavior. If an explanation is given first, before the user can perform the diagnosis on their own, they tend to become more deferential to the model.

In addition, AI systems outperformed humans when the presentation of disease was subtle, but humans performed much better if there are atypical symptoms or unrelated features in an image.

Taken together, these results indicate that explainable AI can cause overreliance on models and lead users to blindly follow AI recommendations even when they are wrong. 

Rather than using LLMs to generate more detailed explanations, it might be more effective to force users to give a diagnostic hypothesis first, then provide an AI-based suggestion to highlight other possible conditions for consideration. 

“We really want AI to improve creativity and either upskill or fill in gaps where users are missing subtle presentations. Otherwise, we risk engaging automation bias and then, when the model is wrong, users can’t recover,” Ghassemi says. 

This research was funded, in part, by the National Science Foundation, Schmidt Sciences, the National Bureau of Economic Research, and Columbia University.

Nature Climate Change, Published online: 04 August 2026; doi:10.1038/s41558-026-02729-3

Climate change communication shapes how societies perceive risks and respond to them. In this issue of Nature Climate Change we examine the evolving content and methods of climate communication, the challenges of urgency and injustice, and the strategies for building effective and inclusive communication channels.

Nature Climate Change, Published online: 04 August 2026; doi:10.1038/s41558-026-02714-w

Communication is essential for keeping communities safe when climate disasters occur. Here, we explore how disaster communication informs protective actions and examine five challenges: false information, exhaustion from repeated disasters, unequal access to information, polarized climate attitudes and mental health.

Nature Climate Change, Published online: 04 August 2026; doi:10.1038/s41558-026-02680-3

Social media have become an important arena for climate change communication. This Review synthesizes climate-related content on social media, its effects on climate attitudes, knowledge and behaviour, and its role in reshaping the broader communication landscape.