Taiwan Man Uses Robot Vacuum Camera to Prove Wife's Affair, Wins Compensation but Receives Prison Sentence for Illegal Recording
A resident of Taiwan used the built-in camera of a household robot vacuum cleaner to gather evidence of his wife's alleged infidelity, ultimately winning monetary compensation while himself facing criminal penalties for unauthorized recording.
The man grew suspicious after finding an unfamiliar toothbrush in the couple's countryside residence. Footage from a parking area camera revealed an individual who had previously driven his wife home. Three months later, while attempting to connect with his spouse via the vacuum cleaner's mobile application, he observed the same visitor through the device's live video stream.
The camera captured the wife changing clothes, lying in bed with the man, and walking naked through the house. The owner saved the recordings and submitted them to court as proof of the affair. Although infidelity itself is not a criminal offense in Taiwan, violations of spousal rights can justify financial compensation. The husband initially sought 2 million Taiwanese dollars but was awarded 500,000 — roughly $19,000.
The wife responded with a counter-suit, stating that the intimate footage had been obtained without her consent. She noted that the vacuum's sensors and indicator lights provided no clear signal that recording was underway. The husband argued that the court's acceptance of the video in the civil proceeding rendered it admissible, yet the judges rejected this reasoning.
While the recording could be used in the civil matter, the unlawful acquisition method remained a separate violation. The court determined that the right to privacy held greater weight than marital duties. Consequently, the man received a five-month prison sentence and a fine of 150,000 Taiwanese dollars — equivalent to 30 percent of the compensation he had received.
Related articles
Russian Firms Accumulate Digital Clutter: 35% of Corporate Files Unused for Years, Weak Passwords Expose Sensitive Data
A study by Russian cybersecurity firm Garda examined more than 157 terabytes of data and over 511,000 user accounts across more than 100 companies. Researchers found that approximately 35% of files in corporate repositories had not been accessed for more than five years, while duplicate data could occupy another 35% of storage volume. In several industries, up to one-third of stored content consisted of personal photographs, videos, and archives unrelated to business operations. More than 33% of accounts used critically weak passwords or credentials that had not been changed for extended periods, and numerous contractor and temporary employee accounts remained active despite being unused for over 90 days. Direct access permissions bypassing security groups were widespread, allowing broad access to folders containing passport scans, client registries, and database exports. Garda recommends automated inventory, classification, centralized access management, and lifecycle automation to reduce risks instead of manual cleanup.
Apple Updates Private Relay Domain for Sign in with Apple: Why Email Cannot Serve as Account Identity
Apple announced that new Private Relay addresses for Sign in with Apple will use the private.icloud.com domain starting later in 2026, while existing privaterelay.appleid.com addresses will continue functioning without interruption. The change highlights a deeper architectural issue: many applications incorrectly treat email addresses returned by Apple as stable identifiers rather than transient contact channels. Proper implementation requires separating the signed identity token, the verified subject claim, and the optional email relay address into distinct data models. Developers must validate the full identity token on the server, including signature, issuer, audience, nonce, and expiration, before linking any Apple identity to an internal account. Using provider and subject pairs as the unique key prevents duplicate accounts, accidental merges, and broken logins when relay domains or email claims change. The article provides concrete recommendations for data models, token verification boundaries, and test cases that remain resilient to future Apple updates.
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.