Step-by-Step Guide to Removing Personal Data from Search Engines, Databases and Social Networks
The article opens by describing how entering a phone number in quotes, followed by formatted variants such as 8 (999) 123-45-67, and old email addresses quickly reveals scattered personal data across the internet. The guide is structured as a checklist rather than theory, supplying exact buttons to click, wording for letters, statutory deadlines, and escalation procedures when requests are refused.
Plan on seven steps and calendar
The recommended sequence begins with an audit to build a list of URLs, followed by contacting the original source, then search engines, social networks, phone directories, maps, and finally archives. The first week is allocated to auditing and sending letters, weeks two and three to waiting plus social media and directory work, week four to search engine requests, and month two to complaints with Roskomnadzor for non-responsive operators.
Step 1. 20-minute audit
Users are instructed to create a spreadsheet tracking every URL, the personal data displayed, the recipient contacted, date sent, and reply received. Search queries should include full name variations, maiden names, city combinations, four phone formats, every historical email address, and old forum nicknames. The same queries must be run in both Yandex and Google, including image search. Additional checks cover Have I Been Pwned for breach history, caller-ID apps, the Roskomnadzor register of personal-data operators, and email inboxes for forgotten registrations.
Step 2. Source site and letter template
Contact details are located in “Contacts”, “About us”, privacy policies, or WHOIS records. Letters should be sent via email, web form, and messenger simultaneously. The template cites 152-FZ, lists exact URLs and data fields, demands cessation of processing and deletion within statutory timeframes, and warns of escalation to Roskomnadzor. Screenshots of every page and message are required for later complaints.
Step 3. Search engines Yandex and Google
Yandex accepts 10.3-law requests through its feedback form and processes them within ten working days. Google offers both the Russian legal route and its global “Results about you” tool, which now covers passport and driver-license numbers. Quick removal of already-deleted pages is available via the three-dot menu. The right to be forgotten applies only to name-based queries; direct links remain accessible.
Step 4. Social networks, messengers, old accounts
Visibility settings for phone numbers, birth dates, and indexing must be disabled first. Accounts should be fully deleted rather than deactivated. When login access is lost, the same 152-FZ request applies. Photographs published without consent can be removed under Article 152.1 of the Civil Code except in cases of public interest or paid posing.
Step 5–7. Phone numbers, directories, archives
Old listings on classifieds, food-delivery profiles, and review sites are removed through account settings or support tickets. Map services such as 2GIS require identity verification. Web-archive removal requests go to info@archive.org and succeed only with copyright or proven-harm arguments. Leaked databases cannot be erased; mitigation relies on changing numbers, using separate registration emails, enabling two-factor authentication, and activating credit self-bans via Gosuslugi.
Roskomnadzor and courts
Complaints are filed when operators ignore deadlines, refuse without legal basis, or lack contact information. The regulator has 30 days to respond and may issue orders or restrict access. Court action remains a last resort with lower practical impact due to modest fines.
Maintenance and realistic expectations
A full audit should be repeated after one month and then quarterly. The realistic goal is clearing the first page of search results for phone, address, and daily routine data rather than total disappearance from the internet.
Related articles
WebRTC IP Leaks Explained: Why Disabling the Protocol Harms Anonymity in Anti-Detect Browsers
The article from Aurorium details how WebRTC technology can leak real IP addresses even when users route traffic through proxies. It explains the peer-to-peer mechanics of WebRTC, the role of STUN servers in generating ICE candidates, and why standard TCP proxies fail to handle UDP traffic. Disabling WebRTC via flags or JavaScript extensions creates detectable anomalies that anti-fraud systems flag as non-standard environments. The recommended approach involves native emulation inside the browser kernel so that STUN requests return proxy IPs while preserving full API integrity across workers. Additional leaks through local network addresses, mDNS candidates, and IPv6 are also covered with practical verification methods using tools like BrowserLeaks and CreepJS.
Docx Anonymizer: Open-Source Chrome Extension Uses Fine-Tuned rubert-tiny2 to Anonymize Personal Data Before AI Uploads
A Russian developer has released Docx Anonymizer, a browser extension that automatically detects and replaces personal data in documents using a lightweight NER model before they reach public AI services such as ChatGPT. The tool was created to help organizations comply with Russia’s 152-FZ personal data protection law while avoiding the risks of uploading contracts and other sensitive files to cloud-based LLMs. It runs entirely locally via ONNX Runtime and WebAssembly, requires no network calls, and supports any AI chat interface. The underlying model, rubert-tiny2, was further trained through knowledge distillation on WikiANN, factRuEval, and synthetic business documents, reaching strong F1 scores for person and organization entities after int8 quantization. The extension intercepts text on the fly, performs named-entity recognition in under two seconds for typical contracts, and replaces detected entities with placeholders. The project is fully open source and designed for minimal user friction, addressing the growing problem of employees inadvertently leaking corporate and personal data to public AI platforms.
Hybrid Post-Quantum Message Sealing: X25519 + ML-KEM-1024 in Umbera Messenger with Public Rust Tests
Umbera messenger has open-sourced its cryptographic core and published seven Rust tests that anyone can run to verify its hybrid post-quantum message sealing scheme. The design combines X25519 with ML-KEM-1024 so that an attacker must break both algorithms to decrypt a message. Messages are protected by Double Ratchet for forward secrecy, sealed sender packaging, and per-message ephemeral keys derived via HKDF-SHA256 into AES-256-GCM. The relay server stores only an opaque box identifier and encrypted blob with no sender or recipient fields visible. Media calls use DTLS-SRTP end-to-end while TURN servers see only encrypted datagrams. Addresses for message boxes rotate weekly and are derived solely from the shared secret between the two parties.
Free Ad Blocker for iPhone, Android, and Desktop Uses DNS Parsing Without Libraries and Skips YouTube Influencer Ads From the First Second
A new free ad-blocking solution has been released for iPhone, Android, and desktop platforms. The tool relies on a lightweight DNS parser that operates without external libraries. It includes a dedicated mode for users who already run VPN connections. An accompanying browser extension automatically skips sponsored segments in YouTube videos, even when the advertisement begins at the zero-second mark. The developer describes the technical challenges encountered after launch and the fixes applied to maintain compatibility across operating systems. The project emphasizes user privacy by avoiding unnecessary data collection and third-party dependencies.