Apples Terugtrekking Dekt Slechts de Helft van de Wijziging

Twee Domeinwijzigingen, Eén Terugtrekking

Apple kondigde medio juni 2026 aan twee afzonderlijke e-mailrelayfuncties naar één nieuw domein te verplaatsen, private.icloud.com: Hide My Email, de iCloud+-functie die wegwerp-doorstuuradressen genereert, en Sign in with Apple, het inlogsysteem dat het echte e-mailadres van de gebruiker verbergt achter een eigen relayadres. Op 24 augustus 2026 maakte Apple de helft van dat plan ongedaan. In een ontwikkelaarsnotitie liet Apple weten dat het, na verdere overweging en het bekijken van feedback uit de community, de wijziging voor Hide My Email niet zou doorvoeren, en dat iCloud+ Hide My Email-adressen op icloud.com blijven.

De berichtgeving over de terugtrekking behandelde die grotendeels alsof Apple de hele domeinmigratie had geschrapt. Die lezing is onvolledig. Sign in with Apple maakte geen deel uit van de terugtrekking, en de verhuizing naar private.icloud.com loopt later in 2026 gewoon door.

Waarom Domeingebaseerd Blokkeren Hoe Dan Ook Mislukt

De terugtrekking bestaat omdat identificatie op domeinniveau een bot instrument is. Hide My Email-adressen delen momenteel het domein icloud.com met elk gewoon iCloud Mail-account, waardoor een website het ene niet kan blokkeren zonder het andere te riskeren. Hide My Email naar een eigen domein verplaatsen had die ambiguïteit voor Apples techniek opgelost, maar had elke website ook een eenvoudige, betrouwbare manier gegeven om Hide My Email-adressen op het eerste gezicht te herkennen en te weigeren - herkenbaar aan het domein, niet aan gedrag, wat het doel van de functie tenietdoet voor iedereen die zich aanmeldt bij een site die ervoor kiest te discrimineren.

Sign in with Apple loopt niet hetzelfde botsingsrisico, omdat relayadressen van die functie in de meeste integratiestromen al zichtbaar verschillen van een persoonlijke iCloud-inbox - vermoedelijk de reden waarom Apple die helft van het plan liet doorgaan.

Het Deel dat de Meeste Berichtgeving Miste

Sign in with Apple-adressen die vanaf nu worden aangemaakt, krijgen het nieuwe domein private.icloud.com, terwijl elk adres dat vóór de omschakeling is aangemaakt zonder onderbreking blijft werken op privaterelay.appleid.com, volgens Apples eigen verklaring. Dat is een lopende migratie, geen stopgezette, en de hele aankondiging behandelen als teruggedraaid is precies de fout die maanden later de e-maillevering voor een gebruiker breekt.

Elk systeem, waar dan ook, dat is gebouwd om Apples privacy-relayverkeer te herkennen door een domeinstring te vergelijken met een vaste lijst, zal een onbekend domein tegenkomen zodra een gebruiker zich aanmeldt met een nieuw aangemaakt Sign in with Apple-adres. Niets aan de Hide My Email-terugtrekking verandert dat.

Wat Sitebeheerders Nu Moeten Doen

Voeg private.icloud.com toe aan elke toegestane lijst, spamfilter, frauderegel of e-mailvalidatiesysteem dat momenteel controleert op privaterelay.appleid.com, en doe dat voordat het nieuwe domein bij echte registraties opduikt, niet pas na de eerste supportmeldingen. Laat icloud.com-regels precies zoals ze zijn; Hide My Email-adressen zijn onder deze aankondiging niet verhuisd en zullen dat ook niet doen.

Breid dezelfde update niet uit naar Hide My Email. Omdat die migratie is teruggedraaid, zal een regel geschreven om Hide My Email-adressen op private.icloud.com te verwachten simpelweg nooit iets matchen, wat onschadelijk is, maar een regel die nog alleen het oude Sign in with Apple-domein herkent, zal bij nieuwe accounts stilletjes gaan falen.

De Bredere Les voor Antimisbruikontwerp

Deze bijna-misser is een heldere casestudy over waarom domeingebaseerd blokkeren van privacy-relayadressen niet werkt als controlemiddel. Maak het relaydomein onderscheidend en herkenbaar, en elke beheerder krijgt een triviale manier om privacybewuste gebruikers ronduit te weigeren - precies het resultaat waar Apples eigen community zich hard genoeg tegen verzette om een publiek plan terug te draaien. Houd het relaydomein gedeeld met gewone accounts, en geen enkele beheerder kan er een betrouwbare regel tegen bouwen - precies waarom Sign in with Apple, van meet af aan opgezet als een gescheiden naamruimte, deze afweging nooit hoefde te maken.

Elk team dat zijn eigen wegwerpadres- of privacy-relayfunctie bouwt, kijkt nu naar een praktijkvoorbeeld van die afweging op de schaal van Apple, in het openbaar beslist, in minder dan drie maanden.

Lees hierna: ChatGPT kan nu berichten versturen vanaf je werk-Mac  |  9,8 CVSS: macOS-VNC-lek mint nu Monero