Apple Updates Private Relay Domain for Sign in with Apple: Why Email Cannot Serve as Account Identity
Apple announced that new Private Relay addresses issued through Sign in with Apple will use the private.icloud.com domain later in 2026. Previously issued addresses on the privaterelay.appleid.com domain will continue to forward mail without any interruption or required migration.
At the mail-delivery level the change appears minor, yet it exposes a common architectural mistake: treating the email address returned by Apple as a stable user identity instead of a contact channel. The signed identity token, the verified subject, and the optional relay email must remain separate entities throughout the authentication and account-management layers.
What exactly is changing
Private Relay lets users hide their real email address. The application receives a relay address and Apple forwards messages to the user’s actual mailbox. Apple now states that future relay addresses will be issued under private.icloud.com. Existing addresses keep working, so no database rewrites or allow-list updates are required for mail delivery.
The relay address is never a proof of permanent identity. Users may later disable forwarding, and the sending infrastructure must still be correctly registered with Apple. These facts affect only the mail subsystem, not the authentication flow.
Identity versus contact channel
Sign in with Apple returns a signed identity token containing a stable subject identifier. The email claim is optional and may be absent for managed Apple Accounts or on subsequent logins. Therefore the server must resolve the internal account exclusively from the verified provider and subject pair.
- Identity token – proves the request originated from Apple for the expected application.
- Subject (sub) – stable identifier that links the Apple identity to an internal account record.
- Email (including relay) – used only for message delivery when the user permits it.
Storing only the email or searching accounts by email address creates fragile logic that breaks when domains change or when the email claim is empty.
Recommended data model
Maintain a dedicated auth_identities table with a unique index on (provider, subject). On first successful login the server creates both the internal account and the identity record inside a single transaction. Subsequent logins locate the existing identity by provider and subject, then issue a session for the linked account. No automatic merging occurs on matching email addresses.
Verification steps that must remain on the server
The mobile client sends the identity token, authorization code, and nonce. The server alone performs signature validation, checks issuer, audience, nonce, and expiration, then extracts the subject. Only after this step does the authorization service resolve or create the internal account. Client-supplied subject strings must never be trusted.
Common anti-patterns to avoid
- Searching accounts by the email claim from the token.
- Storing only an email address as the account key.
- Hard-coding checks for the old relay domain.
- Automatically linking accounts when email values appear similar.
Each of these patterns risks duplicate accounts or unauthorized merges and will surface problems the moment Apple alters relay domains again.
Testing strategy
Tests should assert behavior around the verified subject rather than any specific domain suffix. Key scenarios include first login creating a single account, repeated logins returning the same account, parallel first-login attempts producing only one record, and tokens with invalid issuer or nonce being rejected before any account operation occurs.
When the system already uses email as a key, the migration path begins by adding the proper identity model and stopping new incorrect linkages. Existing conflicts are resolved through explicit user confirmation rather than automated scripts.
Related articles
Amnezia VPN Survives Coordinated Russian Censorship Campaign Targeting AmneziaWG Protocol Fingerprints
Amnezia VPN has published a detailed post-mortem on the multi-wave blocking campaign conducted by Russian authorities against its Amnezia Free and Amnezia Premium services during June and July. The company describes a shift from simple protocol blocking to sophisticated fingerprinting of AmneziaWG traffic combined with infrastructure DDoS attacks and automated IP-subnet blacklisting. Engineers closed multiple detection vectors including zero-length UDP packets, fixed-size keepalive messages, handshake timing patterns, and nonce zero bytes. The incident forced accelerated migration to AmneziaWG 2.0, discontinuation of legacy client support, and development of AmneziaWG 3.0 while expanding VLESS infrastructure as a backup. Self-hosted users largely avoided direct protocol blocks but still faced subnet-level restrictions. The report highlights how Roskomnadzor now applies cumulative scoring across multiple traffic features rather than single definitive markers.
Data Masking: 8 Critical Questions Businesses and Developers Ask About Protecting Sensitive Data
Garda expert Dmitry Larin addresses common challenges in data masking during a recent webinar titled 'Data Masking: Battle of Opinions'. The discussion covers why masking remains essential even when encryption is deployed, how to preserve application functionality after anonymization, and the performance trade-offs of processing large databases such as 5 TB PostgreSQL instances. Different masking types including static, dynamic, selective, and streaming are explained with specific use cases for DevOps pipelines, external contractors, and BI systems. The article also examines why machine learning alone is insufficient for discovering personal data and why custom scripts fail at scale across heterogeneous environments like PostgreSQL and Oracle. Practical recommendations include combining masking with encryption, using deterministic transformations for deduplication, and separating replication from masking tasks to avoid production impact.
MAX Desktop Client Tested for VPN Detection on Windows, No Tracking Signs Found
A Habra user named Slava_B conducted an experiment on September 8, 2026, to determine whether the MAX desktop client on Windows could detect or route traffic through a VPN configured at the router level. The setup used a Keenetic router that directed Russian resources directly while sending other connections via an OpenConnect tunnel to a European VPS, with no VPN client or virtual adapter present in Windows itself. Monitoring tools including Process Monitor, Wireshark, TCPView, and tcpdump revealed that MAX.exe and MAX-service.exe processes communicate locally and connect to MAX/ONEME infrastructure along with AppTracer services. The application repeatedly accessed MachineGuid, computer name, proxy settings, device IDs, and microphone/camera information, though these reads may support diagnostics and anti-fraud functions. No connections appeared on the VPN interface, and the client did not attempt to reach IP-checking services, Telegram, or WhatsApp. The researcher noted that TLS traffic was not decrypted, so actual transmission of identifiers could not be confirmed, and results apply only to this router-based configuration.
PII-Guard: Open-Source Detector for Personal Data in Russian Text
Andrey Ivanov, an NLP researcher at red_mad_robot, has released PII-Guard, an open-source system that detects and masks personal data in Russian text before it reaches language models. The tool combines rule-based checks with a fine-tuned ruBert-base NER model to handle names, addresses, phones, passports, INN, SNILS, bank cards and other entities. It replaces detected PII with structured XML-like tags that preserve grammatical information such as gender and entity ID, allowing models to generate coherent responses that are later restored with real values. The hybrid pipeline first applies normalization, pattern matching, Luhn and weighted checksum validation, and context windows with positive and negative keywords, then merges results with model predictions via an arbitration module. Evaluation on four public datasets, including Hivetrace, alexen2 and alrosait, shows PII-Guard outperforming other open solutions on both strict span matching and type-overlap micro-F1 metrics. The project, including datasets and code, is available on GitHub and aims to reduce leakage risks while maintaining downstream model utility.