Mimolet Dating App Shows Strong Data Protection Practices in Photo Handling, Moderation, and Infrastructure Review
The Russian dating platform Mimolet, which combines profile feeds, private chats, and public interest-based groups, has undergone a thorough examination of how it manages user data and unwanted content. The review analyzed everyday user flows, network behavior, and publicly available infrastructure details, concluding that the service implements several sound security practices while leaving room for greater transparency in two specific areas.
Photograph processing before storage is handled rigorously. When a user uploads an image, the server validates the file by its actual content rather than relying on the JPG or PNG extension. The image is decoded, metadata such as EXIF data (camera model, timestamps, and geolocation) is removed, dimensions are limited, and multiple optimized versions are generated for the mobile feed. Files that cannot be properly recognized as images are rejected outright.
The main server infrastructure is located in Russia. The core API and primary database operate within Russian data centers, while media files are stored in an S3-compatible object storage provided by a domestic cloud vendor. This separation keeps the database lean and allows efficient delivery of images to users.
AI-powered functions, including language processing, speech recognition, vector embeddings, and image moderation, primarily run on dedicated GPU infrastructure controlled by the Mimolet team. A fallback connection to external AI providers exists for redundancy, but the primary path remains internal and isolated via a private technical channel.
Images intended for profiles or public groups are checked before publication. Two distinct models analyze the content—one for prohibited visual material and another multimodal model for contextual meaning—while an additional pass can examine suspicious regions in greater detail. If a violation is confidently detected, the image is blocked and, in severe cases, the account and linked devices may also be restricted.
Complaints and blocking are available to every authorized user without a paid subscription. The reporting form offers structured categories such as scams, cryptocurrency schemes, intimate services, prohibited substances, and false information. Once submitted, the reported profile immediately disappears from the reporter’s feed, and accumulated signals from multiple users are escalated for human review.
Moderator actions are recorded in an administrative audit log that captures the decision, timestamp, and operator involved. This internal record supports later analysis of errors or disputed cases.
Built-in voice calls rely on WebRTC and internal identifiers rather than phone numbers, so users can speak without revealing personal contact details. The feature is disabled if either party has blocked the other.
Two areas were flagged for improvement. The privacy policy uses vague phrases such as “no longer than necessary” and “within a reasonable time,” leaving users without concrete retention periods for photographs, chat history, moderation records, or AI conversation data. The review recommends publishing a clear table listing data categories, processing purposes, retention periods, and post-deletion behavior. Additionally, the appeals process for blocked accounts lacks a dedicated form with a reference number, status tracking, and expected response time, making it difficult for users to follow the progress of their request.
Overall, Mimolet demonstrates several proactive security measures—metadata stripping, pre-publication image checks, subscription-free reporting, and Russian-hosted core infrastructure—that are integrated directly into the user experience rather than added as afterthoughts. The main shortcomings lie in transparency around data retention and the appeals workflow, both of which could be addressed with relatively modest updates.
Related articles
Step-by-Step Guide to Removing Personal Data from Search Engines, Databases and Social Networks
The guide provides a practical seven-step checklist for individuals seeking to reduce their digital footprint by removing personal information from websites, search engines, and social platforms. It emphasizes starting with a 20-minute audit to compile exact URLs rather than vague requests, followed by direct contact with site owners under Russia's 152-FZ personal data law. Subsequent steps cover submissions to Yandex and Google for de-indexing, manual cleanup of old social media accounts, handling of phone numbers in caller ID services, and removal from directories and review sites. The process includes templates for formal requests, timelines for responses, and escalation paths to Roskomnadzor when operators fail to comply. Special attention is given to leaked databases, where technical removal is impossible, and to web archives such as Internet Archive that require specific legal justifications. The full cycle is estimated at two months, with quarterly maintenance recommended to sustain results.
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.