Configuration Drift Silently Breaks Multi-Hop Chains in sing-box Reality Fleet
A detailed post-mortem from the operators of an RCQ messenger network has exposed how configuration drift in a sing-box and Reality deployment left four out of seven nodes unreachable, while every monitoring check continued to report OK status.
Network Architecture
The fleet on 10 August comprised 14 endpoints running on seven machines hosted by four providers. Clients fetched a signed configuration (version 144) and used urltest to select routes. Since version 0.80, traffic follows a two-hop path: entry nodes know the client but not the destination, while exit nodes know the destination but not the client. This design requires every entry node to maintain an explicit allowlist of exit nodes because each machine ends its firewall rules with a reject policy.
What Went Wrong
Rules extracted from a live entry node showed only five permitted addresses: two islands and two relays. The remaining five nodes in the fleet were absent from the list. Four of those missing nodes belonged to a single provider, immediately limiting viable chains. Further inspection revealed inconsistent lists across machines; only three of the seven published nodes could reach each other. A free user whose entry landed in the first group therefore had just two possible exits, and the onion routing layer routed traffic through only three nodes instead of seven.
urltest never complained because it simply ignored dead chains and selected from the remaining live options. Canary checks verified that relays answered, external probes confirmed islands were alive, and the relay-lockdown.sh --check script only validated local services such as the masquerade host and mirrors. None of these tools compared the allowlist against the full set of relays published in the signed configuration.
Private Nodes and Additional Findings
Examination of two paid private nodes found no route section at all, meaning anyone holding the tenant key could route arbitrary traffic through the rented machine. The relay-lockdown.sh script also surfaced an outdated SNI value of www.apple.com on two machines, left over from an earlier period before operators realized the masquerade name must reside in the same ASN as the server address.
Remediation Steps
The check script was updated to compare the allowlist against relays listed in the signed configuration and to print missing addresses. A hardcoded fallback list grew from three to seven addresses. The script now runs every thirty minutes via cron on all nine machines and only expands the allowlist; narrowing remains a manual operation. Every new configuration is validated with sing-box check before deployment.
The root cause remains unknown because lists were never dated and drift leaves no log entries. The warning already present in the script header proved accurate: a snapshot locked down from one branch silently rejects every node added later.
Related articles
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.
One Request, Five Observers: What Websites, Providers, DNS and VPNs Learn When Loading a Page
The article breaks down exactly what each participant in a typical web request can observe when a user visits a page over HTTPS. It examines the roles of the browser, DNS resolver, ISP, VPN service and the destination site itself, showing that each sees different pieces of metadata or content. HTTPS protects the page body and parameters from network observers, while Encrypted Client Hello and secure DNS further limit visibility of domain names. VPNs replace the user's home IP address with the VPN exit node but introduce a new trusted party that sees all traffic metadata. Browser fingerprinting, cookies and account logins often allow sites to re-identify users even after an IP change. The piece stresses that privacy tools must be chosen according to the specific threat model rather than relying on any single mechanism.