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
telEgo Combines MTProxy and WEB Proxy on Single Port 443 with TLS Fronting
telEgo, a Go-based Telegram MTProxy implementation using the gnet network engine, now supports all four WEB proxy transport modes alongside traditional MTProxy connections on the same public port 443. The solution allows FakeTLS with ee secrets, Obfuscated2 with dd secrets, and WEB carriers including https, https-lanes, websocket, and websocket-lanes without requiring separate ports or secret changes. telEgo performs handshake detection, forwards ordinary TLS traffic to Nginx on a private port using PROXY protocol v2, and routes authenticated WEB streams back to the internal MTProxy backend. The setup uses Docker Compose with separate containers for telEgo, Nginx, and certificate management via Certbot, keeping ports 8080, 8443, and 8444 internal. Existing MTProxy links continue to function while new WEB proxy links become available for Telegram Desktop. The configuration supports Prometheus metrics, connection limits, and automatic certificate renewal through systemd timers.
From HAProxy to VLESS+Reality: Overcoming DPI Blocks for MTProto Telegram Proxies
A detailed case study describes the challenges of running an MTProto proxy for Telegram on Russian servers facing ISP-level DPI. Initial attempts using HAProxy TCP relays and SOCKS5 tunnels failed because modern DPI systems detect MTProto and fake-TLS signatures regardless of transparent forwarding. The author eventually succeeded by layering mtg with an Xray VLESS+Reality tunnel that performs genuine TLS 1.3 handshakes to legitimate domains. Key configuration pitfalls included the xtls-rprx-vision flow breaking non-TLS payloads, missing mux causing handshake timeouts on short-lived connections, and provider-specific network policies. Final architecture places mtg and an Xray client on the Russian entry server while the foreign exit server runs Xray in VLESS+Reality inbound mode. The guide supplies complete docker-compose examples, key generation commands, and a checklist of common misconfigurations to avoid.
TLS MITM and Throttling to 10 Mbps: Two Distinct Network Degradation Patterns Observed in Russia
Russian users have reported sudden slowdowns and instability on international connections over the past several days. Analysis of Tunnel Cat logs revealed two separate issues that produce similar user symptoms but require different diagnostic approaches. The first pattern involves successful TCP and TLS handshakes followed by sharp drops in throughput, often from 80 Mbps to 8-12 Mbps, consistent with DPI-based throttling of international traffic. The second pattern shows TLS certificate substitution on Windows systems, indicating active man-in-the-middle interception. Tunnel Cat now detects invalid certificates and terminates such sessions, yet the underlying network phenomena persist. The observations highlight the need to examine both bandwidth dynamics and certificate chains when troubleshooting connectivity problems from Russia.
Deleted Database Records Remain Recoverable in SQLite Files Despite DELETE Operations
A standard DELETE query in SQLite removes rows from the table view but leaves the actual data intact inside the database file until pages are reused. The pragma secure_delete setting controls whether freed pages are zeroed immediately or simply marked as available. With the default setting of 0, strings containing names and credit card numbers can still be extracted using grep even after deletion. The same behavior appears in PostgreSQL through dead row versions until VACUUM runs and in MySQL InnoDB through undo logs and the binary log. The issue directly affects compliance with personal data deletion requests because backups, replicas, and analytics exports often retain the original records. Proper mitigation requires enabling secure_delete, running VACUUM after bulk deletions, or encrypting sensitive fields with per-record keys that can be destroyed on request.