Apple snur om «Skjul e-postadressen» etter brukerreaksjoner

Apple deler den planlagte endringen i to. Etter at selskapet i juni varslet at både iCloud+ «Skjul e-postadressen» og «Logg på med Apple» skulle ta i bruk @private.icloud.com, opplyste Apple 24. august at aliaser fra «Skjul e-postadressen» likevel blir værende på @icloud.com. Nye adresser fra «Logg på med Apple» skal fortsatt flyttes fra @privaterelay.appleid.com til @private.icloud.com senere i 2026. Eksisterende videresendingsadresser skal fortsette å fungere uten avbrudd. 10

Dette er det Apple endrer

Den opprinnelige planen var å samle nye adresser fra begge personvernfunksjonene under @private.icloud.com. Eksisterende aliaser fra «Skjul e-postadressen» med endelsen @icloud.com og eksisterende «Logg på med Apple»-adresser med endelsen @privaterelay.appleid.com skulle fortsatt videresende e-post. 15

Den reviderte planen er smalere:

• iCloud+ «Skjul e-postadressen»: Nye aliaser bruker fortsatt @icloud.com.
• «Logg på med Apple»: Nye videresendingsadresser får @private.icloud.com senere i 2026.
• Eksisterende «Logg på med Apple»-adresser: Adresser på @privaterelay.appleid.com forblir gyldige og fortsetter å videresende e-post.

Apple begrunnet snuoperasjonen med «ytterligere vurderinger» og tilbakemeldinger fra fellesskapet. Selskapet har ikke sagt at en bestemt sikkerhetsavsløring førte til beslutningen. 10

Derfor reagerte brukerne på det nye domenet

Problemet var ikke at en endring av domenet automatisk ville avsløre hvilken innboks som lå bak et alias. Bekymringen var at @private.icloud.com tydelig ville vise at adressen var en del av Apples videresendingstjeneste.

Et nettsted eller en app kunne oppdage domenet med en enkel kontroll og deretter avvise adressen, kreve en annen e-postadresse eller bruke den som et signal i svindel- og risikovurderinger. Dermed ville det bli enklere å blokkere adressene ved registrering. 44

@icloud.com brukes derimot også av vanlige iCloud-e-postadresser. Et «Skjul e-postadressen»-alias med denne endelsen er derfor vanskeligere å skille fra en ordinær postkasse for tjenester som prøver å identifisere maskerte adresser.

Det var kjernen i reaksjonene: Brukerne fryktet at det foreslåtte domenet ville svekke funksjonens praktiske personvern og muligheten til å holde identiteten mindre synlig, selv om Apples videresendingsinfrastruktur ellers forble uendret. 35

Dette må utviklere gjøre

Utviklere som bruker «Logg på med Apple», bør behandle endringen som en overgang mellom to videresendingsdomener – ikke som en utskifting der det gamle domenet forsvinner.

Godta begge domenene

Oppdater kontosystemer, regler for e-postvalidering, regulære uttrykk, tillatte lister og annen domenespesifikk logikk slik at de godtar både nye adresser som slutter på @private.icloud.com og eksisterende adresser som slutter på @privaterelay.appleid.com. Apples tidligere veiledning viste også til @icloud.com i håndteringen av videresendingsdomener. Systemene bør derfor ikke anta at det bare finnes én gyldig Apple-endelse. 810

Det viktigste er å ikke flytte eller deaktivere eksisterende brukerkontoer bare fordi e-postadressen bruker det eldre domenet. Apple sier at eksisterende @privaterelay.appleid.com-adresser fortsatt vil fungere og videresende e-post uten avbrudd. 10

Kontroller utgående e-post

Hvis en app eller et nettsted sender meldinger via Apples private e-postvideresending, må utvikleren registrere domenene og underdomenene som brukes til utgående e-post, i Apples utviklerkonto. Apples veiledning krever også at de registrerte e-postkildene består en SPF-kontroll. 6

Teamene bør derfor gå gjennom:

• registrerte avsenderdomener og underdomener
• SPF-poster i DNS
• e-postvalidering og rutiner for kontogjenoppretting
• tillatte og blokkerte lister
• databasefelt eller skjemaer som forutsetter et fast e-postdomene
• kundestøtte- og kontoverktøy som finner brukere basert på e-postendelsen

Apple beskriver videresendingstjenesten som en løsning som sender meldinger videre til én av e-postadressene som er bekreftet på brukerens Apple-konto. 3

Sikkerhetsavsløringene gir viktig bakgrunn

Domenedebatten kom samtidig med separate rapporter om svakheter i Apples personvernsystemer. Disse hendelsene viser ikke at @private.icloud.com i seg selv ville lekke en e-postadresse eller IP-adresse. De bidrar likevel til å forklare hvorfor brukerne gransket en endring som kunne gjøre personvernaliaser enklere å klassifisere.

Sårbarhet i «Skjul e-postadressen»

En rapportert feil i «Skjul e-postadressen» kunne avsløre den virkelige adressen bak et alias når en melding til aliaset ble avvist som spam. Den underliggende adressen kunne da dukke opp i e-postlogger hos avsenderen, noe som svekket selve personvernløftet. Apple sa at selskapet hadde rullet ut en løsning 3. juli 2026, og senere testing viste at feilen ikke lenger kunne gjenskapes. 474954

En oppdatering fjerner imidlertid ikke nødvendigvis historiske lekkasjer. E-postsystemer hos tredjeparter kan ha beholdt eldre leveringslogger. Adresser som ble eksponert før feilrettingen, kan derfor fortsatt finnes i registre utenfor Apples kontroll. 4860

Rapporterte IP-lekkasjer i Private Relay

Sikkerhetsforskere rapporterte også at enkelte WebKit-relaterte forespørsler kunne omgå iCloud Private Relay og avsløre brukerens faktiske IP-adresse. De rapporterte veiene inkluderte passordnøkkelrelaterte WebAuthn-forespørsler, WebTransport og forhåndshenting av DNS. 192023

En senere rapport beskrev en tilsynelatende løsning i iOS 26.6.1. Det tilgjengelige materialet gjelder imidlertid en rapportert feilretting, ikke en bred forklaring fra Apple om arkitekturen eller konsekvensene. 18

Dette er andre mekanismer enn synligheten til et e-postdomene. Feilen i «Skjul e-postadressen» handlet om at en avvist melding kunne avsløre adressen, mens Private Relay-rapportene gjaldt nettverkstrafikk som kunne slippe utenom videresendingsbanen. Ingen av delene viser at det foreslåtte @private.icloud.com-domenet direkte ville avsløre identiteten til brukeren.

Den mest nærliggende forklaringen på snuoperasjonen

Den direkte forklaringen er motstanden mot at aliaser skulle bli enklere å blokkere. Brukerne argumenterte for at et eget personverndomene ville gi nettsteder en enkel måte å identifisere og avvise adresser fra «Skjul e-postadressen» på. Apple bekrefter selv at beslutningen ble tatt etter tilbakemeldinger fra fellesskapet. 10

De samtidige sikkerhetsavsløringene bør først og fremst forstås som en omdømmemessig bakgrunn, ikke som en dokumentert årsak. De gjorde tilliten til Apples personvernløsninger mer sårbar, men Apple har ikke knyttet rapportene til domenebeslutningen.

Det praktiske resultatet er et kompromiss: «Skjul e-postadressen» beholder den mindre påfallende @icloud.com-endelsen, mens utviklere som bruker «Logg på med Apple» må forberede seg på @private.icloud.com og samtidig støtte det eldre videresendingsdomenet.