Habr•September 13, 2026•🇷🇺Translated from Russian

rkn-block-checker 0.6.0 Adds Local Web UI and Reduces False Positives on Anti-Bot Responses

The open-source utility rkn-block-checker has been updated to version 0.6.0, bringing both improved detection accuracy and a new local web interface.

Earlier releases contained a simple list of Russian-language markers used by ISP block pages, including phrases such as “доступ ограничен” and “решению роскомнадзора”. When a target returned HTTP 429 with the text “Доступ с вашего IP временно ограничен”, the tool treated the response as a Roskomnadzor stub and reported a high-confidence block. The issue surfaced most clearly on Avito, whose anti-bot system issues 429 responses to requests lacking proper cookies even when the User-Agent mimics Chrome.

Distinguishing censorship from rate limiting

The fix adds an explicit status-code check inside core.py. If the body matches a known stub marker but the status is 429, the verdict is set to DOWN with LOW confidence and a note explaining the likely anti-bot cause. Only responses that match both the textual marker and an expected block status (200 or 451) receive the HTTP_STUB verdict with HIGH confidence.

Lightweight local Web UI

Although the project began as a pure CLI tool, users requested an easier way to examine individual checks. The new interface is served by Python’s built-in ThreadingHTTPServer and a single static HTML file containing vanilla JavaScript and CSS. No external dependencies are required. Users start the server with the command rkn-check startweb or rkn-check startweb --port 8080; the service listens on 127.0.0.1:7777 by default.

Scan results are delivered as a newline-delimited JSON stream. The browser reads the ReadableStream chunk by chunk, parses each line, and immediately updates the corresponding table row. This approach avoids both WebSocket complexity and repeated polling while still providing live feedback.

Release highlights

  • Full local Web UI with charts, Russian/English localization, and on-the-fly addition of custom domains
  • Improved filtering of anti-bot false positives (HTTP 429)
  • One-click JSON report export directly from the browser
  • Zero additional dependencies beyond a standard Python installation

The complete source code remains available under the MIT license on GitHub, and the package can be installed or upgraded via pip install rkn-block-checker.

Related articles

Habr•Privacy & Surveillance

Following the White Rabbit: Developer Builds Custom Rust VPN PAYPHONE Using QUIC and Obfuscation to Evade Detection

A Russian developer has released PAYPHONE, an experimental IPv4 VPN written entirely in Rust that uses QUIC datagrams and optional TLS-over-TCP transport with custom obfuscation. The project aims to provide an alternative to AmneziaWG and Xray/VLESS+REALITY stacks that are commonly used to bypass Russian internet filtering. The article details the full packet path from TUN interface through a 16-byte PAYPHONE header, session management with Ed25519 tokens, and multiple post-launch bugs including MTU miscalculations, self-routing loops on macOS, and timer lifetime issues in Tokio. Key technical choices include RFC 9221 datagram support to avoid head-of-line blocking for multiplexed TCP flows and token-bucket rate limiting tied to subscription tokens. The author also describes route monitoring every 400 ms and interface-bound sockets to prevent the tunnel from swallowing its own control traffic.

AntiMalware•Privacy & Surveillance

WhatsApp Introduces Parental Controls for Teen Privacy Settings

WhatsApp, owned by Meta (recognized as an extremist organization and banned in Russia), has rolled out new parental control tools for family accounts. Parents can manage privacy settings, group participation, channel access, status visibility, and Meta AI usage for teens, but cannot read personal messages due to end-to-end encryption. All controls are voluntary and require joint setup with the teenager, protected by a single PIN code that prevents easy reversal of restrictions. Notifications alert parents when teens join or leave groups or when group sizes change significantly. Separate options cover channel usage, viewable statuses, and audience controls for teen posts. Meta AI access can be set to a standard 13+ mode or a stricter Limited Content mode with undisclosed restrictions. The company plans to expand these features gradually based on family feedback while maintaining encryption protections.

Securitylab•Privacy & Surveillance

Can Wi-Fi Owners See Your Google Search History? HTTPS, DNS, SNI and ECH Explained

A viral social media video sparked widespread concern that Wi-Fi owners could view users' search history and visited sites simply by knowing the router password. Security experts from Cybernews and Surfshark clarified that modern HTTPS encryption prevents reading of actual search queries or page content. However, metadata such as DNS requests, SNI fields in TLS handshakes, and device MAC addresses remain visible to the network administrator. The introduction of Encrypted Client Hello (ECH) under RFC 9849 aims to hide domain names, yet Russian authorities have blocked many ECH-enabled connections since November 2024. Corporate or school-managed devices with installed root certificates represent the main real-world exception where full traffic inspection is possible. VPNs hide destinations from the local router but transfer visibility to the VPN provider. The article emphasizes that password-protected Wi-Fi grants access only to connection metadata, not browser history.

Habr•Privacy & Surveillance

Yandex Deploys OPRF Protocol to Protect Phone Numbers in Mandatory Audience Measurement Data Sharing

Yandex has detailed a cryptographic scheme using Oblivious Pseudorandom Function (OPRF) to help Russian audiovisual services comply with new legislation requiring transmission of user identifiers linked to phone numbers. The approach replaces a naive shared-secret hashing method that created a single point of compromise across dozens of competing companies. Instead, two independent third parties each hold separate secret keys and process blinded elliptic-curve points derived from normalized E.164 phone numbers. Services obtain deterministic identifiers without learning the third-party keys and without exposing raw numbers to the authorized research organization. The design distributes trust, limits offline brute-force attacks to scenarios requiring both keys plus final identifiers, and adds rate limits plus key-rotation capabilities to deter abuse. Yandex positions the solution as a practical compromise between regulatory demands, competitive secrecy, and user privacy.