Apple est sur le point de rendre Hide My Email inutile

• Les alias de Sign in with Apple et de Hide My Email d’iCloud+ seront désormais émis sous le sous-domaine @private.icloud.com
• Ce changement permettra aux services de bloquer plus facilement uniquement les alias relais, sans affecter la boîte mail ordinaire d’iCloud
• Jusqu’ici, le blocage des alias iCloud avait un coût élevé en raison du support d’Apple et d’une certaine négation plausible
• De nombreux services pourraient refuser ces adresses e-mail comme ils refusent les boîtes mail temporaires gratuites
• Les utilisateurs d’iCloud+ et de Hide My Email ont encore le temps de créer davantage d’alias en @icloud.com avant l’application du changement, avec une limite de création d’au moins 30 alias par heure

---

Changement clé

• Une annonce Nouveau domaine pour Sign in with Apple et Hide My Email d’iCloud+ a été publiée dans les actualités développeurs d’Apple
• À l’avenir, les alias de Sign in with Apple et de Hide My Email seront tous deux émis sous le sous-domaine @private.icloud.com
• Avec cette structure, il devient plus simple de bloquer tous les alias sans affecter les boîtes mail iCloud non relais

Protection de la vie privée et impact pour les utilisateurs

• Ce changement pourrait porter un coup important à la protection de la vie privée sur iCloud
  • Jusqu’ici, le blocage des alias iCloud avait un coût élevé en raison du support d’Apple et d’une certaine négation plausible
  • Le nouveau sous-domaine distingue plus clairement les alias, ce qui facilite leur refus par les services
• De nombreux services pourraient ne pas accepter les e-mails en @private.icloud.com, comme ils refusent les boîtes mail temporaires gratuites
• Le souhait est exprimé qu’Apple revienne sur cette décision
• Les utilisateurs d’iCloud+ et de Hide My Email ont encore le temps de créer davantage d’alias en @icloud.com, car le changement n’est pas encore appliqué
  • La limite de vitesse de création d’alias est d’au moins 30 par heure

[GN⁺]

Commentaires sur Hacker News

• Si vous utilisez iCloud+ et Hide My Email, le changement n’a pas encore été appliqué, et la limite de création d’alias est encore d’au moins 30 par heure, donc on peut encore créer quelques alias en @icloud.com pendant qu’il est temps
  L’un des intérêts de Hide My Email, c’était de rendre la protection de la vie privée sans prise de tête, mais mettre en place un système où l’on génère des adresses à l’avance puis les catalogue pour les utiliser plus tard est franchement fastidieux

  • J’en ai déjà des dizaines, donc je pourrai sans doute continuer à les réutiliser, mais le fait d’en avoir une par site est très appréciable, car dès qu’un alias Hide My Email commence à recevoir du spam, on peut savoir quel site a fait fuiter l’adresse
  • Si cela ne vous dérange pas de faire confiance à une autre entreprise pour la redirection d’e-mails, monter soi-même un service similaire est clairement moins contraignant
  • J’en ai quand même créé quelques-uns au cas où, et d’autres hackers peuvent faire pareil s’ils le souhaitent
    iCloud+ était le meilleur service à 1 dollar par mois, avec e-mail sur domaine personnalisé, alias e-mail et 100 Go de cloud drive chiffré de bout en bout
    Ce serait évidemment dommage de le voir enshittifié sans raison particulière
  • Il va nous falloir un script qui crée des alias datés pour les 10 prochaines années afin de pouvoir utiliser une adresse e-mail différente chaque jour

• Si un site me bloque parce que j’utilise une adresse e-mail respectueuse de ma vie privée, je n’ai pas envie d’avoir affaire à ce site

  • C’est vrai, mais malheureusement ce n’est pas un principe qu’on peut toujours appliquer
    Récemment en Italie, j’ai dû utiliser un parking public payant géré par une municipalité, et il n’y avait aucun autre parking, payant ou gratuit, à moins de 30 minutes à pied
    Il fallait télécharger et créer un compte sur une application tierce partenaire, pas l’application du gouvernement italien, et dans ce genre de situation, même si on ne veut pas “avoir affaire à ce site ou à cette appli”, on ne peut tout simplement pas se garer
  • Il arrive souvent qu’on n’ait pas d’alternative convenable et qu’on soit obligé de dépendre d’un fournisseur précis
  • J’achète souvent des domaines que je trouve drôles et je configure tous les e-mails pour qu’ils soient redirigés vers mon compte principal
    C’est très simple à configurer sur Cloudflare, et quand le domaine expire au bout d’un an, le spam disparaît avec
  • J’ai eu ce problème avec un opérateur mobile MVNO
    Ils n’aimaient pas les domaines e-mail personnels, par exemple plusieurs adresses en .net et .org, alors j’ai dû insister auprès du support client, qui a fini par les ajouter manuellement
    Une fois ajoutés, l’équipe marketing m’envoyait très happily des e-mails sur mon domaine personnel. Ça posera peut-être problème un jour, mais de toute façon l’objectif final est de supprimer le téléphone
  • Tout à fait d’accord. Je me demande si des gens ont vraiment déjà vécu ça
    L’astuce des alias avec signe plus de Gmail est largement connue depuis longtemps et, à ma connaissance, fonctionne toujours très bien aujourd’hui
    Pourtant, du point de vue d’un site web, il serait assez simple de bloquer le + dans les adresses Gmail ou d’en extraire l’adresse réelle

• Pour faire quelque chose de similaire sans Apple, il suffit d’acheter ou récupérer un domaine bon marché, de créer un sous-domaine, puis de recevoir et rediriger tous les e-mails envoyés à ce sous-domaine
  Par exemple, on peut utiliser [e-mail] -> jono@gmail, [e-mail] -> jono@gmail, et en pratique il n’est même pas nécessaire de créer les alias à l’avance

  • Le problème, c’est que si quelqu’un comprend la structure et commence à envoyer du spam à {random}@domain.tld, ça devient vite pénible
    À ce moment-là, il faut s’asseoir, créer de vrais alias pour chaque adresse e-mail déjà utilisée et arrêter la redirection catch-all
    En plus, utiliser son propre domaine réduit la protection de la vie privée, ce qui augmente le risque d’arnaques ciblées ou de phishing. Les arnaques ciblées sont d’ailleurs le type contre lequel nous sommes les plus vulnérables
    Ce n’est pas que cette méthode soit mauvaise, je l’utilise moi-même, mais ce n’est pas un problème aussi simple qu’il n’y paraît
    Avec iCloud, ce problème est résolu, mais on introduit le risque que le compte soit suspendu et qu’on perde l’accès à toutes ces adresses
    La meilleure solution serait probablement d’avoir un domaine e-mail dédié avec des amis et de le relier à quelque chose comme SimpleLogin, mais ça devient vite compliqué
  • Je fais pareil
    En revanche, c’est gênant quand il faut expliquer en personne ou au téléphone qu’une adresse client est [their_business_name]@my_weird_domain.tld
    En général, les gens hochent simplement la tête
    Un autre inconvénient, c’est que cela ne fait que de la redirection en réception. Ce serait bien de pouvoir aussi proxifier les réponses sans devoir créer une nouvelle boîte de réception et une nouvelle boîte d’envoi complètes
  • Si le serveur de redirection d’e-mails ne prend pas en charge SRS, Gmail bloque les messages qui échouent à l’alignement SPF/DMARC
  • Avec SPF/DMARC/DKIM, c’est devenu un peu plus compliqué globalement aujourd’hui
    Il y a aussi pas mal d’agents de transfert de courrier qui ne transmettent plus les e-mails si toute la configuration n’est pas correcte
  • J’utilise ça depuis des années et ça marche bien, en plus c’est amusant de voir qui vend mon adresse e-mail
    Mais il faut absolument bien tenir ses notes
    Quand on essaie de récupérer un compte et qu’on ne se souvient plus quelle adresse personnalisée on avait utilisée, c’est vraiment galère

• En résumé, cela signifie que Sign in with Apple et les alias Hide My Email sont désormais tous deux émis sous le sous-domaine @private.icloud.com
  Du coup, il devient beaucoup plus facile d’interdire tous les alias sans affecter les boîtes iCloud ordinaires qui ne sont pas des relais de messagerie
  En revanche, je ne comprends pas bien pourquoi le fait que Sign in with Apple et Hide My Email soient sur le même domaine rendrait un blocage global plus facile ; intuitivement, on pourrait penser que cela le rend plus difficile

  • Avant, les adresses e-mail avaient la forme [e-mail], qui est la valeur par défaut pour tous les utilisateurs Apple
    Il n’y avait aucun moyen de distinguer un e-mail normal d’un e-mail privé généré
    Maintenant que c’est [e-mail], il devient facile de bloquer les e-mails privés générés qui compliquent la liaison des connexions entre services
    On ne voit pas bien pourquoi Apple choisirait volontairement une option aussi défavorable. Espérons que Ternus ne cherche pas à s’aligner dans un sens contraire à la protection de la vie privée
  • Avant, quand on utilisait ce service, Apple générait une adresse (something)@icloud.com
    Désormais, on obtient une adresse en (something)@private.icloud.com, ce qui permet immédiatement de bloquer tout le sous-domaine visant les personnes qui se « cachent » par défaut via ce service
    C’est comparable au fait de bloquer anondaddy ou simplelogin, mais pas protonmail
  • J’imagine qu’avant, les comptes avec alias et ceux sans alias utilisaient tous @icloud.com
    Comme on pouvait réserver une adresse e-mail iCloud ordinaire comme on crée un compte Gmail, interdire toutes les adresses iCloud bloquait aussi des clients Apple qui n’utilisaient pas d’alias
    Cela dit, je ne suis pas certain que les sites qui voulaient bloquer les alias en étaient déjà incapables. Les e-mails alias avaient déjà un aspect suffisamment étrange pour qu’avec un peu de faux positifs, on puisse probablement déjà les filtrer

• Dire que c’est « inutile » est excessif
  Si un site est du genre à bloquer les e-mails de relais privés, il aurait de toute façon été le type de site à recevoir mon e-mail jetable
  Le relais privé sert à s’inscrire sur des sites dont on veut recevoir des nouvelles, tout en gardant une protection au cas où ils se feraient pirater plus tard

  • Oui. Une entreprise raisonnable n’interdira pas les e-mails de ce sous-domaine

• À l’inverse, un site qui bloque private.icloud.com se prive aussi de la possibilité d’utiliser Apple pour le SSO, et se coupe donc de l’écosystème Apple

  • Pas forcément
    Il suffit d’autoriser private.icloud.com uniquement quand l’utilisateur passe par l’Apple SSO
    Si quelqu’un essaie de créer un compte sans Apple SSO, il est possible de refuser les adresses e-mail private.icloud.com

• Tout site vraiment motivé pouvait déjà le faire facilement. Il suffisait de détecter les motifs utilisés
  Cela dit, je suis d’accord pour dire que c’est un changement inutile
  Par exemple, des formes comme [e-mail]
  Cela ne devrait pas avoir beaucoup d’effet sur Sign in with Apple, puisque les sites prennent déjà explicitement en charge cette fonctionnalité
  Les alias e-mail, c’est plus compliqué. On veut protéger sa vie privée en se fondant dans la masse des utilisateurs, mais alors on se retrouve lié à cet écosystème ; avec un domaine que l’on contrôle soi-même, on n’a plus ce verrouillage, mais on perd aussi l’anonymat de la masse

  • Tous les alias générés n’ont pas cette forme ; certains ressemblent plutôt à [e-mail] ou [e-mail]
    Quoi qu’il en soit, le fait que certains services interdisent les alias ne justifie pas de les rendre complètement inutiles au lieu d’améliorer les choses
    Apple fait partie des rares entreprises qui ont la part de marché suffisante pour imposer une solution sur ce sujet
  • Les sites qui en avaient la volonté le faisaient déjà en pratique
    Je ne sais pas comment ils les détectent aujourd’hui

• J’utilise des alias Proton presque partout
  Bien sûr, pas absolument partout ; il y a aussi pas mal de sites qui n’acceptent pas les adresses passmail.net
  Donc il est tout à fait plausible que cette fonctionnalité devienne au moins partiellement inutile sur certains sites
  À titre personnel, je n’utilise ce genre d’alias que pour des sites pour lesquels perdre l’accès au compte ne serait pas grave. Sinon, ce serait le pire des verrouillages
  J’aimerais pouvoir choisir des alias sur mon propre domaine secondaire. Au moins, cela permettrait de migrer via un wildcard ou une liste exportée

  • On peut créer des alias personnalisés sur son propre domaine
    C’est ce que je fais pour toutes mes connexions, et je suis en train de migrer mes anciens e-mails vers des alias sur domaine personnalisé

• La plupart de mes adresses de relais iCloud sont déjà en @privaterelay.appleid.com, et cela a toujours parfaitement fonctionné
  Donc je doute que cela change de sitôt

  • Ce domaine n’est utilisé que pour Sign in with Apple

• Personnellement, Hide My Email me retient encore plus dans l’écosystème Apple qu’iMessage. Après, je suis un utilisateur européen

  • Vraiment ? Moi, j’utilise surtout Hide My Email sans intégration à l’écosystème Apple
    Je crée un nouvel e-mail sur icloud.com, je le copie-colle dans le formulaire d’inscription, puis je l’enregistre dans 1Password
  • C’est une architecture fragile
    Soit on reste client iCloud à vie, soit des centaines de connexions risquent de casser