HabrAugust 21, 2026🇷🇺Translated from Russian

Rospotrebnadzor and FAS to Extend Oversight to Websites: Automating Foreign Word Replacement Using LLM

Russian compliance specialists have created an automated system to help websites comply with Federal Law No. 168-FZ on protecting the Russian language ahead of expected enforcement actions by Rospotrebnadzor and the Federal Antimonopoly Service.

The law prohibits the use of foreign words when common Russian equivalents exist and bans both Latin script and transliterations written in Cyrillic. It requires identification of prohibited borrowings by comparing text against four official dictionaries approved by the Russian Academy of Sciences: orthographic, orthoepic, explanatory, and the dictionary of foreign words.

The developed microservice, named Normograph, implements a five-stage pipeline that significantly reduces the volume of text sent to the language model. First, HTML pages are cleaned of markup and tokenized. Second, primary filtering removes words present in normative dictionaries, user-defined white lists, and registered trademarks. Third, the system flags potential issues including words absent from dictionaries, known anglicisms, and Latin-script terms.

Only after these algorithmic filters does the LLM receive small relevant fragments. The model determines whether a word qualifies as an impermissible borrowing, considers context, and proposes accurate Russian synonyms that match in gender, number, and case. The pilot uses GigaChat API but the architecture allows easy substitution with other models such as YandexGPT.

An additional OCR module based on Yandex Cloud Vision extracts text from images collected by a crawler. The same multi-stage filter is applied to recognized text, with caching and size-based filtering to control costs. Logos and registered trademarks are automatically excluded from checks.

Testing showed that manual review of one page previously took about one hour, while the automated system reduces the process to between two and ten minutes. The solution is positioned as a corporate compliance tool for pharmaceutical, fintech, and large e-commerce platforms that must adapt hundreds of pages before regulatory inspections begin.

Related articles

HabrPolicy & Regulation

Kubernetes Audit Policy Review: Checklist Targets Common Blind Spots in Rules

An experienced Kubernetes administrator shared a detailed review process for audit policies that often remain untouched for years after initial deployment. The 580-line policy was rebuilt using the Kubernetes Threat Matrix from RedGuard as the primary reference. The author highlights recurring issues such as outdated exceptions, missing coverage for new components, and legacy comments that obscure actual security intent. The resulting checklist focuses on principles rather than cluster-specific findings to help other teams perform effective policy audits. Key recommendations address rule completeness, exception management, and periodic full-scale reviews instead of incremental patching. The approach aims to restore audit policies as active security controls rather than accumulated technical debt.

HabrPolicy & Regulation

Avoiding a Leaky Kubernetes Audit Policy: Real-World Configuration Breakdown

Kubernetes Audit Policy is typically configured once during cluster setup and then left untouched for years while accumulating exceptions for new components. Over time the policy stops functioning as a security control and instead becomes an archaeological layer of outdated comments such as "# temporary, TODO remove" that date back three years or more. The author recently reviewed their own 580-line configuration file that had been assembled from multiple sources. Primary reference was the Kubernetes Threat Matrix, which explains why many rules are designed to detect security-relevant actions rather than simply reduce log noise. Examples include targeted monitoring of RBAC modifications and deletion of events. The article emphasizes the need for periodic full reviews instead of incremental patching to maintain effective detection coverage.

AntiMalwarePolicy & Regulation

CryptoPro Develops CryptoPro-Browser with Russian Cryptography for FSB Compliance

CryptoPro is creating its own browser called CryptoPro-Browser as part of the CryptoPro CSP 6.0 cryptographic information protection system. The product will include built-in cryptographic tools, support for the company's plugin, and TLS connections using Russian cryptographic algorithms. The development follows Google's removal of the CryptoPro extension from the Chrome Web Store in February 2025, which left new users without an easy installation method. The project has been coordinated with the FSB of Russia and targets scenarios requiring compliance with Russian information security regulations. CryptoPro plans to incorporate experience from its earlier Chromium-Gost project started in 2017, while also recommending Yandex Browser as an alternative. Analysts estimate the development cost at several tens of millions of rubles, with the main focus on corporate customers needing certificate management and specialized support.

HabrPolicy & Regulation

Yandex 360 Email Archive Documentation Shows Search Snapshots and Former Employee Log Filters

The Yandex 360 administrator guide describes the email archive as a tool that stores copies of all messages sent and received by employees on the organization's domain. Two specific statements in the documentation indicate that each saved search returns a static snapshot that does not update automatically when new mail arrives, requiring manual cloning or recreation of the search to obtain current results. The same documentation states that the action log records every operation performed in the archive, yet the employee filter in the log interface only displays currently active accounts, making it impossible to select a former administrator by name. API 360 currently provides no documented endpoints for creating, executing, or retrieving archive searches, leaving all operations dependent on the web console. Additional notes clarify that messages remain available after an account is blocked but disappear once the account is deleted, and that messages removed before the archive was enabled cannot be recovered. These documented behaviors directly affect incident response and offboarding procedures that rely on historical email retrieval and audit trails.