Apple ist dabei, Hide My Email unbrauchbar zu machen

• Sign in with Apple und iCloud+-Aliasadressen von Hide My Email werden künftig unter der Subdomain @private.icloud.com ausgegeben
• Durch diese Änderung können Dienste Relay-Aliasse leichter blockieren, ohne den normalen iCloud-Posteingang zu beeinträchtigen
• Bisher waren die Kosten für das Blockieren von iCloud-Aliasen hoch, auch wegen Apples Unterstützung und einer gewissen plausiblen Abstreitbarkeit
• Viele Dienste könnten diese E-Mail-Adressen ablehnen, ähnlich wie kostenlose temporäre Postfächer
• Nutzer von iCloud+ und Hide My Email haben bis zur Umsetzung der Änderung noch Zeit, weitere @icloud.com-Aliasse zu erstellen; das Limit für die Alias-Erstellung liegt bei mindestens 30 pro Stunde

---

Zentrale Änderung

• In den Apple Developer News wurde die Ankündigung Neue Domains für Sign in with Apple und iCloud+ Hide My Email veröffentlicht
• Künftig werden sowohl Sign in with Apple- als auch Hide My Email-Aliasse unter der Subdomain @private.icloud.com ausgegeben
• Mit dieser Struktur wird es einfacher, alle Aliasse zu blockieren, ohne Nicht-Relay-Postfächer von iCloud Mail zu beeinträchtigen

Datenschutz und Auswirkungen auf Nutzer

• Diese Änderung könnte ein schwerer Rückschlag für den Datenschutz bei iCloud sein
  • Bisher waren die Kosten für das Blockieren von iCloud-Aliasen hoch, auch wegen Apples Unterstützung und einer gewissen plausiblen Abstreitbarkeit
  • Die neue Subdomain grenzt Aliasse klarer ab und macht es für Dienste leichter, sie abzulehnen
• Viele Dienste könnten @private.icloud.com-E-Mail-Adressen ablehnen, so wie sie kostenlose temporäre Postfächer ablehnen
• Es wird die Hoffnung geäußert, dass Apple diese Entscheidung noch einmal überdenkt
• Nutzer von iCloud+ und Hide My Email haben noch Zeit, weitere @icloud.com-Aliasse zu erstellen, da die Änderung noch nicht umgesetzt wurde
  • Das Rate-Limit für die Alias-Erstellung liegt bei mindestens 30 pro Stunde

[GN⁺]

Hacker-News-Kommentare

• Wenn man iCloud+ und Hide My Email nutzt, ist die Änderung noch nicht wirksam, und das Limit für das Erstellen von Aliasen liegt immer noch bei mindestens 30 pro Stunde, also kann man sich auch jetzt noch zusätzliche @icloud.com-Aliasse anlegen
  Einer der Gründe, Hide My Email zu nutzen, war, dass es Datenschutz ohne Aufwand ermöglicht, aber ein System zu bauen, in dem man Werte im Voraus erzeugt und für die spätere Nutzung katalogisiert, ist ziemlich mühsam

  • Ich habe schon Dutzende davon, also kann ich sie vermutlich weiterhin wiederverwenden, aber wenn man pro Website einen nutzt, ist es ziemlich praktisch, dass man sehen kann, welche Website geleakt hat, sobald auf einer Hide-My-Email-Adresse Spam eingeht
  • Wenn man damit leben kann, einem anderen Unternehmen die Weiterleitung von E-Mails anzuvertrauen, ist es definitiv weniger umständlich, sich einen ähnlichen Dienst selbst aufzusetzen
  • Ich habe trotzdem vorsichtshalber ein paar erstellt, und andere Hacker können das genauso machen, wenn sie wollen
    iCloud+ war für 1 Dollar im Monat der beste Dienst mit Custom-Domain-E-Mail, E-Mail-Aliasen und 100 GB Ende-zu-Ende-verschlüsseltem Cloud-Speicher
    Wenn man sieht, dass das ohne besonderen Grund verschlechtert wird, ist das natürlich enttäuschend
  • Wir brauchen ein Skript, das datumsbasierte Aliasse für die nächsten 10 Jahre erstellt, damit man jeden Tag eine andere E-Mail-Adresse verwenden kann

• Wenn mich eine Website blockiert, nur weil ich eine datenschutzfreundliche E-Mail verwende, möchte ich mit dieser Website nichts zu tun haben

  • Stimmt, aber leider ist das kein Prinzip, das sich immer anwenden lässt
    Ich musste vor Kurzem in Italien einen öffentlichen Parkplatz nutzen, bei dem die Gebühren an die Kommune gingen, und es gab in 30 Minuten Gehweite keinen anderen Parkplatz, weder kostenpflichtig noch kostenlos
    Es war zwar nicht die App der italienischen Regierung, aber ich musste eine verbundene Third-Party-App herunterladen und mich registrieren, und in so einer Situation hilft es einem nicht, zu sagen, man wolle mit „dieser Website oder App nichts zu tun haben“, weil man dann einfach nicht parken kann
  • Es gibt oft Fälle, in denen man mangels brauchbarer Alternativen zwangsläufig von einem bestimmten Anbieter abhängig ist
  • Ich kaufe oft Domains, deren Name ich witzig finde, und richte sie so ein, dass alle E-Mails an mein Hauptkonto weitergeleitet werden
    Das lässt sich bei Cloudflare sehr einfach einrichten, und wenn die Domain nach einem Jahr verschwindet, verschwindet auch der Spam
  • Ich hatte so etwas bei einem MVNO-Mobilfunkanbieter
    Die mochten private E-Mail-Domains nicht, etwa diverse .net- und .org-Adressen, also habe ich immer wieder den Support kontaktiert, und am Ende haben sie sie manuell hinzugefügt
    Danach hat das Marketingteam mir ganz happily E-Mails an meine private Domain geschickt. Irgendwann könnte das noch ein Problem werden, aber das Endziel ist sowieso, das Handy ganz loszuwerden
  • Stimme vollkommen zu. Ich frage mich, ob jemand das tatsächlich schon erlebt hat
    Der Gmail-Trick mit Pluszeichen-Aliasen ist seit Langem weithin bekannt, und soweit ich weiß, funktioniert er auch jetzt noch gut
    Aus Sicht einer Website wäre es doch leicht genug, + in Gmail-Adressen zu blockieren oder die eigentliche E-Mail-Adresse zu extrahieren

• Wenn man etwas Ähnliches ohne Apple will, kann man eine günstige Domain kaufen oder organisieren, eine Subdomain erstellen und dann alle E-Mails empfangen und weiterleiten, die an diese Subdomain gehen
  Zum Beispiel [e-mail] -> jono@gmail, [e-mail] -> jono@gmail; man muss die Aliasse in der Praxis nicht einmal vorher anlegen

  • Problematisch wird es, wenn jemand das Muster erkennt und anfängt, Spam an {random}@domain.tld zu schicken
    Dann muss man sich hinsetzen, für jede bereits verwendete Adresse einen echten Alias anlegen und die Catch-all-Weiterleitung abschalten
    Außerdem ist der Datenschutz schwächer, wenn man die eigene Domain verwendet, was gezielten Betrug oder Phishing wahrscheinlicher macht. Gegen gezielten Betrug sind wir besonders anfällig
    Das soll nicht heißen, dass dieser Ansatz schlecht ist, ich nutze ihn selbst, aber so simpel ist die Sache nicht
    Mit iCloud ist dieses Problem gelöst, dafür besteht dann das Risiko, dass das Konto gesperrt wird und man keinen Zugriff mehr auf diese E-Mails hat
    Wahrscheinlich wäre die beste Methode, mit Freunden eine eigene E-Mail-Domain zu haben und sie an etwas wie SimpleLogin anzubinden, aber das wird schnell kompliziert
  • Ich mache das auch so
    Es ist nur unangenehm, wenn ich persönlich oder am Telefon erklären muss, dass die Kundenadresse [their_business_name]@my_weird_domain.tld ist
    Meistens nicken die Leute einfach
    Ein weiterer Nachteil ist, dass nur der Empfang weitergeleitet wird. Es wäre schön, wenn man Antworten per Proxy senden könnte, ohne gleich einen kompletten neuen Posteingang und Postausgang aufzusetzen
  • Wenn der Weiterleitungs-Mailserver SRS nicht unterstützt, blockiert Gmail Nachrichten, bei denen die SPF/DMARC-Ausrichtung fehlschlägt
  • Durch SPF/DMARC/DKIM ist das heute insgesamt etwas komplizierter geworden
    Es gibt inzwischen ziemlich viele Mail Transfer Agents, die keine E-Mails weiterleiten, wenn die Konfiguration nicht vollständig korrekt ist
  • Ich nutze das seit Jahren, es funktioniert gut, und es macht Spaß zu sehen, wer meine E-Mail-Adresse verkauft
    Man muss aber wirklich gut Buch führen
    Wenn man ein Konto wiederherstellen will und sich nicht mehr erinnert, welche Custom-E-Mail man verwendet hat, ist das wirklich unerquicklich

• Zusammengefasst heißt das, dass jetzt sowohl Sign in with Apple als auch Hide-My-Email-Aliasse unter der Subdomain @private.icloud.com ausgestellt werden.
  Dadurch wird es viel einfacher, alle Aliasse zu verbieten, ohne normale, nicht weitergeleitete Postfächer von iCloud Mail zu beeinträchtigen.
  Ich verstehe allerdings nicht ganz, warum es einfacher wird, alles pauschal zu blockieren, wenn Sign in with Apple und Hide My Email auf derselben Domain liegen — müsste das nicht eher schwieriger werden?

  • Früher hatten E-Mails das Format [e-mail], also den Standard für alle Apple-Nutzer.
    Es gab keine Möglichkeit, normale E-Mails von generierten privaten E-Mails zu unterscheiden.
    Jetzt ist es [e-mail], wodurch sich generierte private E-Mails, die das Verknüpfen von Logins über Dienste hinweg erschweren, leicht blockieren lassen.
    Warum Apple sich selbst freiwillig in diese schlechtere Position bringt, ist unklar. Hoffentlich passt Ternus hier nicht in eine datenschutzfeindliche Richtung an.
  • Früher hat Apple bei Nutzung dieses Dienstes (something)@icloud.com erzeugt.
    Jetzt wird (something)@private.icloud.com verwendet, wodurch sofort eine Blockierung der gesamten Subdomain für Menschen möglich wird, die sich mit diesem Dienst standardmäßig „verstecken“.
    Das ist ähnlich wie anondaddy oder simplelogin zu blockieren, aber protonmail nicht.
  • Meine Vermutung ist, dass früher sowohl Alias- als auch Nicht-Alias-Konten @icloud.com genutzt haben.
    Man konnte wie bei Gmail eine normale iCloud-E-Mail-Adresse reservieren, daher hätte ein Verbot von allen iCloud-Adressen auch normale Apple-Kunden ohne Alias mit blockiert.
    Ich bin allerdings nicht sicher, ob die Stellen, die Aliasse blockieren wollten, dazu nicht ohnehin schon in der Lage waren. Alias-E-Mails sehen auffällig genug aus, dass man sie wahrscheinlich schon hätte sperren können, wenn man ein paar Fehlklassifizierungen in Kauf nimmt.

• „Nutzlos“ ist übertrieben.
  Wenn eine Website private Relay-E-Mails blockiert, dann hätte sie meine Wegwerf-E-Mail von Anfang an ohnehin akzeptiert.
  Private Relay ist für Websites gedacht, von denen ich Nachrichten erhalten möchte, aber als Absicherung für den Fall, dass sie später gehackt werden.

  • Genau. Ein vernünftiges Unternehmen würde E-Mails aus dieser Subdomain nicht verbieten.

• Umgekehrt blockiert eine Seite, die private.icloud.com sperrt, damit auch die Möglichkeit, sich mit Apple per SSO anzumelden, und kappt sich damit selbst vom Apple-Ökosystem ab.

  • Nicht unbedingt.
    Man könnte private.icloud.com nur dann erlauben, wenn Apple SSO verwendet wird.
    Wenn jemand ohne Apple SSO ein Konto anlegen will, könnte man private.icloud.com-Adressen weiterhin ablehnen.

• Eine Website, die das wirklich will, konnte das schon immer leicht machen. Man muss nur die verwendeten Muster erkennen.
  Ich stimme aber zu, dass es eine nutzlose Änderung ist.
  Ein Beispiel wäre [e-mail].
  Auf Sign in with Apple sollte das ohnehin wenig Einfluss haben, weil Websites diese Funktion bereits explizit unterstützen.
  Bei E-Mail-Aliasen ist es schwieriger. Man möchte seine Privatsphäre schützen, indem man in der Menge untergeht, wird dann aber an dieses Ökosystem gebunden; bei einer Domain unter eigener Kontrolle gibt es keine Bindung, aber auch keine Anonymität in der Menge.

  • Nicht alle generierten Aliasse sehen so aus; manche sehen eher aus wie [e-mail] oder [e-mail].
    Dass einige Dienste Aliasse verboten haben, ist jedenfalls kein Grund, das System nicht zu verbessern und stattdessen völlig nutzlos zu machen.
    Apple ist eines der wenigen Unternehmen, das dieses Problem mit seinem Marktanteil tatsächlich durchdrücken könnte.
  • Websites, die dazu motiviert sind, machen das in der Praxis bereits.
    Ich weiß nur gerade nicht, auf welche Weise sie aktuell unterscheiden.

• Ich nutze Proton-Aliasse fast überall.
  Natürlich nicht wirklich überall; es gibt einige Seiten, die passmail.net-Adressen nicht akzeptieren.
  Deshalb kann ich mir gut vorstellen, dass diese Funktion zumindest auf manchen Websites nutzlos werden könnte.
  Ich verwende solche Aliasse übrigens nur für Websites, bei denen es mir egal ist, den Login zu verlieren. Sonst wäre das der schlimmste Lock-in überhaupt.
  Es wäre schön gewesen, wenn man Aliasse auf meiner eigenen Sekundärdomain wählen könnte. Dann könnte ich sie wenigstens per Wildcard oder exportierter Liste migrieren.

  • Man kann benutzerdefinierte Aliasse auf der eigenen Domain erstellen.
    Ich nutze das für alle meine Logins und verschiebe auch ältere E-Mails gerade auf Aliasse mit eigener Domain.

• Die meisten meiner iCloud-Relay-Adressen sind ohnehin schon @privaterelay.appleid.com und funktionieren seit langem vollkommen problemlos.
  Deshalb glaube ich nicht, dass sich das so bald ändern wird.

  • Diese Domain wird nur für Sign in with Apple verwendet.

• Für mich persönlich bindet mich Hide My Email noch stärker an das Apple-Ökosystem als iMessage. Ich bin allerdings ein Nutzer in Europa.

  • Wirklich? Ich nutze Hide My Email hauptsächlich ohne jede Apple-Ökosystem-Integration.
    Ich erstelle auf icloud.com eine neue E-Mail, kopiere sie in das Login-Formular und speichere sie dann in 1Password.
  • Das ist eine fragile Konstruktion.
    Entweder bleibt man ein Leben lang iCloud-Kunde, oder Hunderte von Logins könnten kaputtgehen.