DeepSeek User Conversations Appear in Google Search Results via Publicly Shared Links
Conversations between home users and the Chinese AI service DeepSeek, including many in Russian, have been discovered in Google search results. Accessing another person’s dialogue with the model requires only a specially crafted search query.
The pages in question are Shared Conversations — dialogues that users voluntarily published via public links. Every question, answer, and the titles of any uploaded documents are visible on these pages, as verified by a TASS correspondent. Journalists were unable to download the actual files, even by inspecting the page source code.
Representatives of MWS AI stated that no new data leak has taken place. They noted that search engines had already indexed thousands of publicly shared chatbot dialogues more than a year ago. No reports of a compromise of DeepSeek or unauthorized access to private conversation histories have emerged.
Most likely, the indexed pages are either old conversations or ones that users deliberately made public. It remains impossible to obtain access to a user’s account or private chats through these links. In effect, DeepSeek did not open doors to personal accounts; users themselves left certain conversations publicly accessible, and Google simply catalogued them.
In parallel, Yandex confirmed that links to dialogues with its Alice AI assistant are blocked from search-engine indexing. Such links are created only at the user’s initiative, remain valid for 14 days, and can be revoked at any time. Attached files are never transmitted to the recipient, and continuing another user’s conversation stays private.
Related articles
Configuration Drift Silently Breaks Multi-Hop Chains in sing-box Reality Fleet
A post-mortem analysis of a censorship circumvention network using sing-box and Reality revealed that four out of seven nodes were unreachable due to outdated allowlists, even though all monitoring reported green status. The fleet consisted of 14 endpoints across seven machines and four providers, with traffic routed in two hops where entry nodes only knew client identities and exit nodes only knew destinations. White-list rules on entry nodes permitted only five addresses instead of all required relays, causing urltest to silently discard most chains without logging failures. Canary checks, external probes, and the relay-lockdown.sh script all passed because none compared the allowlist against the full signed configuration. Two private paid nodes lacked any route section entirely, exposing them to potential abuse. The issue stemmed from configuration drift over time, with no single person maintaining an overview of the entire system. Automated fixes were implemented with safeguards to prevent fleet-wide lockouts.
Why Distributed Mesh Architectures Resist IP Blocking Better Than Centralized Servers
The article explains the fundamental limitations of single-server or small-server setups when facing IP-based censorship and DPI systems. A centralized infrastructure relies on a finite, relatively static list of addresses that can be discovered, tracked, and blocked over time. In contrast, a client-side mesh turns user devices into active transport nodes that relay traffic peer-to-peer, creating a constantly changing set of endpoints. This architectural shift transforms address blocking from a one-time list-maintenance task into an ongoing discovery problem. The design still requires an auxiliary trust and coordination layer called the backbone network, while anti-DPI techniques such as ClientHello rotation and decoy traffic protect individual connections. The approach carries real costs in battery life, bandwidth, and operational complexity on client devices.
Chrome Adds On-Device Gemini Nano While Ask Gemini Sends Page Content to Google Cloud
Google has introduced an 'AI on device' toggle in Chrome settings that enables local execution of the Gemini Nano model directly on the user's computer. Several gigabytes of Gemini Nano weights are now stored in the browser profile directory and can run on CPU or GPU for tasks such as initial analysis of suspicious pages. Despite the local model being present, the user-facing 'Ask Gemini' feature does not use it and instead routes page content, URLs, and up to ten additional tabs to Google's cloud infrastructure. The company uses two distinct systems under the Gemini name: the cloud-based Ask Gemini / Gemini in Chrome service and the on-device Gemini Nano accessed only through internal APIs or by websites and extensions. When Enhanced Protection is enabled, results from the local Safe Browsing analysis may still be transmitted to Google Safe Browsing servers. The naming and interface choices have created confusion, as users cannot directly invoke the downloaded Gemini Nano model for tasks like summarizing open pages.
Yandex Details Alice Voice Assistant Audio Buffering and Data Handling in Android Apps
Yandex has issued a detailed technical response to an analysis of its Android applications that raised concerns over potential collection of audio, contacts, bank card data, and other sensitive information. The company acknowledged the existence of a cyclic audio buffer that retains approximately 1.5 seconds of sound before an activation phrase and 0.5 seconds after it, with some pre-command audio possibly transmitted to servers for speech recognition quality checks. Yandex clarified that the Alice assistant only listens locally for the wake word when the app is open and does not continuously record conversations. Access to contacts was explained as necessary for voice commands such as calling entries from the address book, with the full book sent on first sync and only changes thereafter, without hashing to support accurate speech processing. The firm rejected claims of reading messaging app conversations and stated that bank card details are routed directly to an isolated PCI DSS-compliant environment rather than standard application servers.