The Data Protection Commission (DPC) has fined Google €403 million following an inquiry into its processing of Google location data under three features: Web & App Activity, Location History and Location Accuracy. The inquiry examined location data processing between May 25, 2018, when the GDPR came into application, and February 4, 2020. The DPC launched the own-volition inquiry in February 2020 after receiving complaints from several European consumer rights organisations, including BEUC. The DPC acted as the Lead Supervisory Authority for Google Ireland Limited.

Google Location Data Processing Under GDPR Review

The inquiry examined how Google processed location data through the three specified features and assessed whether the processing complied with requirements under the GDPR. The DPC's final decision found that Google infringed the GDPR in relation to the lawfulness and fairness of its processing of location data through Web & App Activity and Location History. The regulator also found that Google failed to meet its accountability obligations regarding Location Accuracy. According to the decision, Google was unable to demonstrate compliance with the GDPR principles of lawfulness, fairness and transparency in its processing of personal data through the feature. The DPC further identified transparency breaches across all three features.

Findings Cover Data Retention and Transparency

The Google GDPR fine also relates to the retention of location data. The DPC found issues with Google's retention of location data through Web & App Activity and Location History. The regulator said that location data is personal data that can allow an individual's location to be inferred, either from the data itself or in combination with other information. Deputy Commissioner Graham Doyle said location data can provide benefits by improving the utility of online services, but can also reveal significant information about individuals, including information that is inherently private. The DPC said Google's failures could have resulted in individuals being unaware that their location data was being used, including for purposes such as influencing them with advertisements or inferring their interests. It said this could result in individuals losing control over their personal data. The regulator also said that retaining users' location data for longer than necessary aggravated this loss of control.

What the Three Google Features Do

Web & App Activity is a Google Account setting available to Google Account holders. When enabled, it processes information related to activity on Google services, including websites and applications. This information can include browsing history, search history and location data. Location History tracks a user's location while they have a compatible mobile device. Users must opt in to the service. It can process data to infer information such as places visited, activities and routes between locations. The feature also uses Google's Timeline function, which displays a private map through Google Maps showing where users have travelled. The location information is saved for signed-in devices even when the user is not using a Google service. Location Accuracy is an Android OS feature designed to determine a device's location more accurately than relying only on GPS inputs. Unlike the other two features, it is available to Android users regardless of whether they have a Google Account.

Google Ordered to Change Processing

The DPC imposed administrative fines totalling €403 million and ordered Google to bring its processing into compliance within six months. The decision was made by Data Protection Commissioners Dr Des Hogan, Dale Sunderland and Niamh Sweeney. The DPC also acknowledged the cooperation and assistance of its peer supervisory authorities during the inquiry. The regulator said the full decision will be issued in due course.

Google is changing how some links in its search results work.

Instead of linking directly to the destination, Google has started routing some search result links through opaque google.com/goto?url=... redirects. The url parameter does not show a readable version of the destination but uses a custom, Google-specific encoding.

Google confirmed the rollout to Search Engine Roundtable:

“We have a long history of deploying technical measures against evolving forms of abuse, and we regularly take steps to protect our services and users.”

Google has not said precisely what abuse the change is intended to prevent. However, the most likely reason is that the redirects are designed to make bulk extraction of destination URLs from Google search results more difficult and costly. Automated tools must now ask Google to resolve each result separately.

Since the rollout has apparently not reached my neck of the woods yet, I had to grab an image from another source.

Some Reddit users find the change ironic: Google built its search business by automatically collecting information from other websites, but is now making it harder for others to collect information from Google.

Other users have complained about the collateral damage to legitimate tools. Rank tracking, SEO auditing, research, archival, accessibility, and alternate-index services may all face the same rate limits and costs as abusive scrapers.

Search results data provider Autom reports that the final destination is viewable only through the redirect response’s Location header. This means bulk collectors must make an additional request for every result.

Security

The first thing that popped into my one-track mind was the security downside. We often tell users to hover over a link before clicking it so they can check where it leads. That advice is less useful when hovering reveals an encoded Google redirect rather than the destination website.

Google still displays the claimed destination above each search result, but users can no longer use the link preview as an independent check.

So, Google, where does this leave our advice? We already tell people not to click Sponsored search results. Should we now tell them to avoid goto?url links too? Or will you give users an easy way to check where a link leads before they click it?

---

---

Passkeys were supposed to make stolen passwords a thing of the past. No password to phish, no secret to reuse, and no string of characters sitting in a database waiting to be leaked.

Over time, it’s thought that passkeys will replace passwords entirely. But what happens when malware steals the master key?

Researchers have found a way for malware to hijack passkey-protected accounts through Google Password Manager, highlighting an important exception: passkeys can be very secure but the software surrounding them still has weaknesses.

What are passkeys?

Passkeys are a password replacement based on public‑key cryptography. Instead of a secret you remember and type, each account gets a key pair where the private key never leaves your devices, and the website only ever sees the public key and signed challenges. Because there’s nothing reusable to phish or reuse on another site, passkeys are marketed as “phishing‑resistant” and safer than passwords stored in a browser or password manager.

By the end of 2024 Google reportedly said that 800 million Google accounts used passkeys.

Passkeys have a major advantage over passwords: there is nothing useful for a phishing site to steal. A passkey is also tied to the website it was created for, making it much harder to trick into authenticating to the wrong domain.

The other significant difference is that if malware steals a password vault, an attacker still often needs to get past a second factor on another device, such as an authenticator app on your phone, before they fully own the account. With passkeys, many services relying on them simply trust the passkey assertion, and in some cases even trust a single “user verified” flag without confirming whether a real biometric or PIN event occurred.

Malware comes into play

The researchers, however, started with a malware infected Windows computer and came up with three possible attack scenarios to steal Google synchronized passkeys. Google Password Manager can synchronize passkeys between devices, which is convenient since you don’t want to register a new passkey every time you buy a new computer. But it also opens them up to abuse.

From bad to worse the attacks are:

• Pass‑ta‑key: malware on the victim’s computer silently asks Chrome and Google’s cloud to create a valid passkey login, no biometric or PIN prompt needed.
• Silver Pass‑ta‑key: malware abuses device re‑enrollment to register its own user‑verification key, then logs in as the victim from the attacker’s machine without touching the victim’s device.
• Golden Pass‑ta‑key: Malware extracts Google’s security domain secret (the master encryption key), decrypts all synced passkeys, and can reuse them anywhere, even after losing access to the original device.

How to stay safe

The researchers urge services to stop blindly trusting the user verification flag and to properly validate that a real User Verified event occurred before granting access. Google, in turn, is encouraged to harden device registration and recovery, and verify that new devices and keys are backed by genuine hardware rather than accepting them at face value.

For end users, passkeys still offer strong protection against classic phishing websites and credential stuffing attacks based on reused passwords. The weak point highlighted here is not so much the concept of passkeys, but the way they’re implemented, synchronized, and trusted without enough verification on the server side.

Until vendors close these gaps, basic anti‑malware hygiene remains critical. The best ways to prevent malware from using your passkeys are:

• Keep on top of updates: make sure your systems and software are patched as soon as you can.
• Use up-to-date real-time anti-malware protection.
• Treat unexpected attachments or links as suspicious until proven innocent.

---

From reporting threats to removing them.

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

Google has walked back an AI feature that allowed users to generate artificial images inside Google Earth, after a predictable flurry of deepfakes.

Google switched on the AI image generation feature inside Google Earth’s web version on July 30. It was available to everyone.

The system used Google’s Nano Banana 2 image generator to create its images. That tool can already generate images from simple text input, but the advantage of doing it in Google Earth is that it can use the real satellite images as the basis for its deepfake versions. That makes it easier to make AI pictures with real, accurate building and landscape details.

In its initial blog post on the launch, it said that students could use it to “bring history to life”, while realtors could use it to produce professional real estate plans. However, others warned that the system could be used to mislead people.

Within hours, researchers and press outlets demonstrated that the tool would happily produce photorealistic satellite imagery of things that did not happen in places where they did not happen.

Dutch open source intelligence researcher Henk van Ess explained: “I tried refugees at the Mexican border, a nuclear plant in Iran, a crash in Amsterdam, a hospital with a bomb crater in Gaza. Nothing was refused”.

Demonstrating what was possible with the new capability, NPR fabricated an image of fires in Iran, along with a deepfake of Washington, D.C. underwater. The BBC ran images of a collapsed Eiffel Tower and the Great Pyramid of Giza swallowed by a sinkhole. Even though the service had some guardrails in place, the BBC’s anti-disinformation Verify service was able to circumvent them by tinkering with basic AI prompts.

Google acknowledged the failure in a statement on X:

“We’ve seen geospatial professionals using this feature for a range of useful purposes, however we’ve also seen people sharing screenshots of generated imagery that appear to violate our policies. So we’re rolling back this feature in Google Earth while we work on implementing stronger guardrails.”

It didn’t commit to never re-introducing the idea.

Users were apparently unimpressed. “There is 0 chance that no one on your development team didn’t raise exactly this concern,” commented one. “You guys are living in a complete bubble,” accused another.

Google’s fallback safeguard was a SynthID watermark and the fact that generated images didn’t appear in the main Google Earth experience for others to see. SynthID is Google DeepMind’s watermarking system, an invisible signal baked into the pixels of AI-generated images so that a compatible detector can spot them later. Google positions it as one half of its provenance stack, sitting alongside the C2PA metadata standard the wider AI industry has settled on.

On paper, the signal is meant to hold up through compression and even social media re-uploads. However, these claims collapsed on contact with reality. The watermarks are detectable by Google’s AI services like Gemini. They are not visible to users, who can screenshot the images and share them anywhere. It’s unlikely that everyone will know to check for the provenance of an image. Researchers have also reported that Gemini could not reliably identify AI-generated images with a SynthID watermark.

What this means for you

Content creators were already producing fake AI images showing events that didn’t happen. Traditionally, satellite imagery has been a key component of open source journalism. Fake it convincingly and you are attacking the reference layer reporters use to check whether something actually happened.

This also comes at a time when trust in AI is measurably eroding. According to our own research, released in June, 88% of people said it’s becoming harder to tell what content online is genuinely human or real, with 84% saying that even “convincing video evidence” no longer feels like proof. 

The practical advice is to take a breath whenever a disturbing satellite image of a disaster, a weapon strike, or a border crossing hits your timeline. Check whether a wire service with a named reporter has published it. Look for a caption identifying the imagery provider. If the source is an anonymous account posting a single dramatic frame, assume you might be looking at something assembled in a browser tab last night.

For more information on how to identify AI images, check out our guide.

The industry’s shipping model now apparently treats users as the test group. Critical media literacy is now the only reliable tool that readers and viewers have.

---

From reporting threats to removing them.

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

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.”

Here’s how to fix it.

We may all have a disdain for Chrome – OSNews users probably use Chrome a lot less than the average public – but that doesn’t mean the browser doesn’t sometimes do interesting things other browsers should copy. Chrome is in the the process of increasing its release cadence, but getting users to restart their browser more often than they already do to apply these higher number of updates is going to be a problem. As such, Google is working on something that seems quite obvious now that they’ve talking about it:

Investing in “dynamic patching” that will eliminate the need for a full browser restart in most cases. By leveraging Chrome’s multi-process architecture, dynamic patching sequentially replaces background child processes (like the Renderer and GPU) with updated binaries on the fly. Stay tuned to learn more as we research and develop this feature.

↫ Chrome Security Team

Chrome was the first browser to use multiple processes, isolating tabs from one another so that if one website or tab went haywire, your other tabs would be unaffected. It makes perfect sense to have the browser use new, updated binaries for new tabs you open as soon as they become available, in a sort of ship-of-Theseus kind of approach to updating. Of course, you can’t postpone the inevitable forever, but this should provide real-world benefits to users. Neat.

The linked blog post goes into much more detail about other things too, like various low-level mitigations to prevent bugs and security issues from causing too much harm.

Reddit users found that by using a specific Google search query, it was possible to find Claude conversations that users had shared.

This exposed sensitive material, including crypto wallet keys, names, addresses, work notes, and even erotic or otherwise policy-violating chats. Fortune says Anthropic appears to have fixed the Google indexing issue, but the shared links themselves were still live for people who already had them.

The exposure was tied to Claude’s Share feature, which creates a public web link to a snapshot of a conversation rather than leaving it inside a user’s private account. Reddit users found a search query that surfaced many of these shared chats, plus Claude Artifacts (interactive documents, apps, and other content created by Claude) in Google results. Wired reports that this is still true for Bing.

The main risk is that people use chatbots to think through work, health, legal, or personal matters without realizing that a shared link can behave like ordinary public web content.

This isn’t unique to Claude. We’ve previously seen Grok chats show up in Google search results, and Meta AI conversations can also become public by design. We have also written about the share option in ChatGPT that was swiftly removed after users unintentionally made thousands of conversations searchable.

Anthropic says Claude chats are private by default, and only conversations users explicitly chose to share were affected. But the incident is a reminder that a “share” button on an AI chat can be more like publishing than messaging, especially if search engines can discover the resulting URL.

How to stay safe

The easy way out here is not to share your AI chatbot conversations with anyone, because you could end up reaching more people than you intended.

That’s because it’s harder to stop pages from being indexed than you might expect. And you don’t have those controls in your hands. The AI provider should take care of that.

But there are a few things you can do:

• Don’t share Personally Identifiable Information (PII) with a chatbot, so that if a conversation is ever exposed it can’t be easily linked back to you.
• To review or stop sharing conversations in Claude, go to Settings > Privacy > Shared chats.
• If you’re using an AI service from a social media company, such as Meta AI, Grok, or Gemini), remember that your conversations could be tied to your account—which might contain a lot of personal information.
• When using AI, make sure you understand how to keep your conversations private. Many services offer temporary or incognito chats that aren’t saved to your history, but they aren’t a guarantee against bugs, leaks, or data breaches. Only use the share feature when you’re comfortable with anyone potentially seeing that conversation.
• Read the privacy policy so you understand how your conversations are stored and shared. If it’s too long, you can always ask an AI to summarise the important points.

---

Let’s face it, an incognito window can only do so much. 
 
Breaches, dark web trading, credit fraud. Malwarebytes Identity Theft Protection monitors for all of it, alerts you fast, and comes with identity theft insurance. 

The Federal Bureau of Investigation (FBI) said today it worked with industry partners to seize hundreds of domains associated with NetNut, a sprawling residential proxy service operated by the publicly-traded Israeli company Alarum Technologies [NASDAQ: ALAR]. The action comes roughly two weeks after KrebsOnSecurity published findings from multiple security firms connecting NetNut to the Popa botnet, a collection of at least two million devices that have been compromised by malicious software with little or no consent from victims.

On June 19, three different security firms issued similar findings: That NetNut is a residential proxy network which populates a botnet called Popa, and distributes software for devices commonly found in homes, such as smart TVs and streaming boxes. NetNut’s software turns those systems into always-on residential proxy nodes that are rented to others, who predominantly use them to relay abusive and intrusive Internet traffic, such as mass content scraping, advertising fraud, and account takeover activity.

Earlier today, NetNut’s homepage was replaced with a seizure notice from the FBI and the Internal Revenue Service Criminal Investigation division. The seizure notice thanked Google, Lumen, Shadowserver and other industry partners for their help in dismantling hundreds of domains tied to the Popa botnet, which experts say has long been synonymous with NetNut’s residential proxy infrastructure.

In a blog post published today, the Google Threat Intelligence Group (GTIG) said NetNut’s proxy network is widely resold and white-labeled by a number of third-party proxy providers, and that its services are heavily sought out by cybercriminals seeking to obfuscate the source of their malicious traffic. The GTIG said that in a single week during June 2026, they observed 316 distinct clusters of threat actors using suspected NetNut exit nodes, including cybercriminal and espionage groups.

“These bad actors can use NetNut to mask their origin IP address when accessing victim environments, accessing their own infrastructure, and conducting password spray attacks,” Google’s GTIG wrote. “Furthermore, when a consumer device becomes an exit node, unauthorized network traffic passes through it. This means bad actors can access other private devices on the same home network, effectively exposing them to Internet threats.”

Google said it disabled Google accounts and services used by NetNut for malware command and control, and that it shared technical intelligence on NetNut’s software development kits (SDKs) and backend infrastructure with platform providers, law enforcement and research firms. The company also disabled apps known to bundle NetNut’s various SDKs.

Omer Weiss, legal counsel for NetNut parent Alarum Technologies, said the company was aware of the FBI seizure and cooperating with investigators.

“Alarum takes this matter seriously and will fully cooperate with law enforcement to ensure any misuse of its infrastructure is thoroughly investigated and those responsible are held to account,” Weiss said in a written statement.

Benjamin Brundage is founder of the proxy tracking service Synthient, one of the companies that published evidence last month linking the Popa botnet to NetNut and Alarum Technologies. Brundage said the domain seizures appear to have disrupted both the Popa botnet and the NetNut proxy network that rides on top of it.

Brundage said NetNut’s apparent demise is likely to be a great disadvantage for the cybercrime community, which was already reeling from legal actions by Google earlier this year that seized infrastructure for NetNut’s biggest competitor — IPIDEA.

“I think this takedown is going to have a big impact, because NetNut gained significant popularity after the IPIDEA takedown,” he said. “Also NetNut has been incredibly common among resellers, and they were on par with IPIDEA in terms of their daily traffic, quality, size, price per gigabyte, all of it.”

The NetNut and Popa botnet takedown may have another added benefit, Brundage said: Lessening the impact of large distributed denial-of-service botnets that have been built on the backs of poorly configured residential proxy services. In January, Synthient revealed how cybercriminals had built the world’s largest DDoS botnet (Kimwolf) by tunneling through IPIDEA proxy connections into the local networks of TV box owners, and infecting other Android-based devices behind the victim’s firewall.

While many of the bigger proxy providers took steps to block this activity, resellers of the major proxy networks have been far slower to respond to the threat, Brundage said.

“In terms of all these TV box devices getting compromised from the proxy network, it will have an impact on the DDoS botnets out there,” he said.

For its part, Google reckons today’s actions have caused “significant degradation to NetNut’s proxy network and its business operations, reducing the available pool of devices for the proxy operator by millions.” But the company warns that proxy networks can rebuild themselves by effectively reselling other proxy services, as IPIDEA has done over the past few months.

“Google has high confidence that many popular residential proxy brands are in fact whitelabeling the NetNut botnet,” the GTIG report concludes. “While we expect this disruption to have a larger ripple effect across the residential proxy ecosystem, observations after the disruption of IPIDEA proved that individual networks can appear resilient. What we have observed is that when faced with the degradation of their own botnet, proxy operators begin buying capacity from their competitors, effectively becoming a reseller. We recognize that creating a lasting disruption in this fluid ecosystem means we must scale our efforts to target the infrastructure of several interconnected providers.”

As KrebsOnSecurity has warned repeatedly, most of the no-name TV streaming boxes for sale on the major e-commerce websites either come pre-installed with residential proxy software, or require the installation of proxy SDKs in order to use the device for its stated purpose (streaming pirated movies, sporting events and TV shows). Google’s advice here is sound: When it comes to TV boxes, stick to name brands from reputable manufacturers, and then be sparing and judicious with any apps you choose to install.

The sketchy TV boxes that are being commandeered by the Popa botnet and other threats all come with or require the user to install unofficial Android operating systems that do not operate within the confines of Google’s Official Play Protect store. Google says consumers can confirm whether or not a device is built with the official Android TV OS and Play Protect certification by following these instructions.

Even people without TV streaming boxes can find their smart TVs enrolled in residential proxy networks, just by installing one of thousands of apps available for download on Samsung and LG smart TVs. In a report released last month, the proxy tracking company Spur found 42 percent of apps available for download via the webOS operating system on LG smart TVs include SDKs that turn one’s television into an always-on residential proxy node. More than a quarter of the apps made for Samsung’s Tizen operating system had similar residential proxy components, Spur found.

Update, 4:24 p.m. ET: Included a statement shared post-publication from an attorney representing NetNut parent Alarum Technologies.

Update, July 8, 2:34 p.m. ET: The website for Alarum Technologies — alarum[.]io — now also features a seizure notice from the FBI. The company’s stock has taken a beating since the FBI action, and is currently trading at $2.62 a share, a roughly 67 percent decline over the past week.

Artificial intelligence platforms may be just as susceptible to social engineering as human beings, but they are proving remarkably good at finding security vulnerabilities in human-made computer code. That reality is on full display this month with some of the more widely-used software makers — including Apple, Google, Microsoft, Mozilla and Oracle — fixing near record volumes of security bugs, and/or quickening the tempo of their patch releases.

As it does on the second Tuesday of every month, Microsoft today released software updates to address at least 118 security vulnerabilities in its various Windows operating systems and other products. Remarkably, this is the first Patch Tuesday in nearly two years that Microsoft is not shipping any fixes to deal with emergency zero-day flaws that are already being exploited. Nor have any of the flaws fixed today been previously disclosed (potentially giving attackers a heads up in how to exploit the weakness).

Sixteen of the vulnerabilities earned Microsoft’s most-dire “critical” label, meaning malware or miscreants could abuse these bugs to seize remote control over a vulnerable Windows device with little or no help from the user. Rapid7 has done much of the heavy lifting in identifying some of the more concerning critical weaknesses this month, including:

• CVE-2026-41089: A critical stack-based buffer overflow in Windows Netlogon that offers an attacker SYSTEM privileges on the domain controller. No privileges or user interaction are required, and attack complexity is low. Patches are available for all versions of Windows Server from 2012 onwards.
• CVE-2026-41096: A critical RCE in the Windows DNS client implementation worthy of attention despite Microsoft assessing exploitation as less likely.
• CVE-2026-41103: A critical elevation of privilege vulnerability that allows an unauthorized attacker to impersonate an existing user by presenting forged credentials, thus bypassing Entra ID. Microsoft expects that exploitation is more likely.

May’s Patch Tuesday is a welcome respite from April, which saw Microsoft fix a near-record 167 security flaws. Microsoft was among a few dozen tech giants given access to a “Project Glasswing,” a much-hyped AI capability developed by Anthropic that appears quite effective at unearthing security vulnerabilities in code.

Apple, another early participant in Project Glasswing, typically fixes an average of 20 vulnerabilities each time it ships a security update for iOS devices, said Chris Goettl, vice president of product management at Ivanti. On May 11, Apple shipped updates to address at least 52 vulnerabilities and backported the changes all the way to iPhone 6s and iOS 15.

Last month, Mozilla released Firefox 150, which resolved a whopping 271 vulnerabilities that were reportedly discovered during the Glasswing evaluation.

“Since Firefox 150.0.0 released, they have been on a more aggressive weekly cadence for security updates including the release of Firefox 150.0.3 on May Patch Tuesday resolving between three to five CVEs in each release,” Goettl said.

The software giant Oracle likewise recently increased its patch pace in response to their work with Glasswing. In its most recent quarterly patch update, Oracle addressed at least 450 flaws, including more than 300 fixes for remotely exploitable, unauthenticated flaws. But at the end of April, Oracle announced it was switching to a monthly update cycle for critical security issues.

On May 8, Google started rolling out updates to its Chrome browser that fixed an astonishing 127 security flaws (up from just 30 the previous month). Chrome automagically downloads available security updates, but installing them requires fully restarting the browser.

If you encounter any weirdness applying the updates from Microsoft or any other vendor mentioned here, feel free to sound off in the comments below. Meantime, if you haven’t backed up your data and/or drive lately, doing that before updating is generally sound advice. For a more granular look at the Microsoft updates released today, checkout this inventory by the SANS Internet Storm Center.