Apple이 Hide My Email을 쓸모없게 만들려 하고 있음

• Sign in with Apple과 iCloud+ Hide My Email 별칭이 앞으로 @private.icloud.com 하위 도메인에서 발급될 예정임
• 이 변경으로 서비스가 iCloud의 일반 메일함에 영향을 주지 않고 릴레이 별칭만 더 쉽게 차단할 수 있게 됨
• 기존에는 Apple의 지원과 어느 정도의 그럴듯한 부인 가능성 때문에 iCloud 별칭 차단 비용이 컸음
• 많은 서비스가 무료 임시 메일함처럼 이 이메일 주소들을 받지 않을 수 있음
• iCloud+와 Hide My Email 사용자는 변경 적용 전까지 @icloud.com 별칭을 더 만들 시간이 있으며, 별칭 생성 제한은 시간당 최소 30개임

---

핵심 변경

• Apple 개발자 뉴스에 Sign in with Apple 및 iCloud+ Hide My Email의 새 도메인 공지가 올라왔음
• 앞으로 Sign in with Apple과 Hide My Email 별칭이 모두 @private.icloud.com 하위 도메인에서 발급될 예정임
• 이 구조에서는 iCloud 메일의 비릴레이 메일함에 영향을 주지 않고 모든 별칭을 차단하기 쉬워짐

개인정보 보호와 사용자 영향

• 이번 변경은 iCloud 개인정보 보호에 큰 타격이 될 수 있음
  • 기존에는 Apple의 지원과 어느 정도의 그럴듯한 부인 가능성 때문에 iCloud 별칭 차단 비용이 컸음
  • 새 하위 도메인은 별칭을 더 명확히 구분하게 만들어 서비스가 이를 거부하기 쉬워짐
• 많은 서비스가 무료 임시 메일함을 거부하듯 @private.icloud.com 이메일을 받지 않을 수 있음
• Apple이 이 결정을 재고하기를 바라는 입장이 제시됨
• iCloud+와 Hide My Email 사용자는 변경이 아직 적용되지 않았기 때문에 @icloud.com 별칭을 더 생성할 시간이 있음
  • 별칭 생성 속도 제한은 시간당 최소 30개임

[GN⁺]

Hacker News 의견들

• iCloud+와 Hide My Email을 쓴다면, 변경이 아직 적용되지 않았고 별칭 생성 제한도 시간당 최소 30개라서 지금이라도 @icloud.com 별칭을 더 만들어둘 수 있음
  Hide My Email을 쓰는 이유 중 하나가 개인정보 보호를 번거롭지 않게 해준다는 점이었는데, 값을 미리 생성하고 나중에 쓰려고 목록화하는 시스템을 만드는 건 꽤 번거로운 일임

  • 이미 수십 개가 있어서 아마 계속 재사용할 수는 있겠지만, 사이트마다 하나씩 두면 Hide My Email 주소 하나에 스팸이 오기 시작했을 때 어느 사이트가 유출했는지 알 수 있다는 점은 꽤 좋음
  • 이메일 전달을 맡길 다른 회사를 신뢰해도 괜찮다면, 비슷한 서비스를 직접 구성하는 편이 확실히 덜 번거로움
  • 그래도 혹시 몰라 몇 개 만들어뒀고, 다른 해커들도 원하면 똑같이 할 수 있음
    iCloud+는 월 1달러에 커스텀 도메인 이메일, 이메일 별칭, 100GB 종단간 암호화 클라우드 드라이브를 제공하는 최고의 서비스였음
    별 이유 없이 엔시티피케이션되는 걸 보게 된다면 당연히 아쉬울 것 같음
  • 앞으로 10년치 날짜별 별칭을 만들어서 하루에 하나씩 이메일을 쓸 수 있게 해주는 스크립트가 필요함

• 내 개인정보 친화적 이메일을 썼다는 이유로 사이트가 나를 차단한다면, 그 사이트와는 엮이고 싶지 않음

  • 맞지만 안타깝게도 항상 적용 가능한 원칙은 아님
    얼마 전 이탈리아에서 지자체에 요금을 내는 공영 주차장을 써야 했는데, 도보 30분 거리 안에는 유료든 무료든 다른 주차장이 없었음
    이탈리아 정부 앱은 아니지만 제휴된 서드파티 앱을 내려받아 가입해야 했고, 그런 상황에서는 “그 사이트나 앱과 엮이고 싶지 않다”고 해도 주차를 못 하게 됨
  • 적절한 대안이 없어서 특정 제공자에게 의존할 수밖에 없는 경우가 종종 있음
  • 웃기다고 생각한 도메인을 자주 사서 모든 메일을 내 주 이메일 계정으로 전달하게 해둠
    Cloudflare에서 설정하기 아주 쉽고, 1년이 지나 도메인이 사라지면 스팸도 같이 사라짐
  • 한 MVNO 이동통신사에서 이런 일을 겪었음
    개인 이메일 도메인들, 예를 들어 여러 .net과 .org 주소를 싫어해서 고객지원에 계속 요청했고 결국 수동으로 추가해줬음
    추가되고 나니 마케팅팀은 내 개인 도메인으로 happily 메일을 보내더라. 언젠가 문제가 될 수도 있겠지만, 어차피 최종 목표는 휴대폰을 없애는 것임
  • 완전히 동의함. 실제로 이런 일을 겪어본 적이 있는지 궁금함
    Gmail의 플러스 기호 별칭 트릭은 오래전부터 널리 알려졌고, 내가 알기로는 지금도 잘 동작함
    웹사이트 입장에서는 Gmail 주소의 +를 막거나 실제 이메일을 추출하는 것도 충분히 쉬울 텐데 말임

• Apple 없이 비슷하게 하려면 저렴한 도메인을 사거나 구해서 하위 도메인을 만들고, 그 하위 도메인으로 오는 모든 메일을 받아서 전달하면 됨
  예를 들어 [e-mail] -> jono@gmail, [e-mail] -> jono@gmail처럼 쓰면 되고, 실제로 별칭을 미리 만들 필요조차 없음

  • 누군가 구조를 알아내고 {random}@domain.tld로 스팸을 보내기 시작하면 문제가 됨
    그때는 앉아서 이미 사용한 이메일 주소마다 실제 별칭을 만들고 포괄 전달(catch-all) 을 멈춰야 함
    또 자기 도메인을 쓰면 개인정보 보호가 약해지고, 그로 인해 표적 사기나 피싱 가능성이 커짐. 표적 사기는 우리가 가장 취약한 유형이기도 함
    이 방식이 나쁘다는 건 아니고 나도 직접 쓰고 있지만, 그렇게 단순한 문제는 아님
    iCloud를 쓰면 그런 문제는 해결되지만 계정이 정지되어 그 이메일들에 접근하지 못할 위험이 생김
    아마 가장 좋은 방법은 친구들과 전용 이메일 도메인을 하나 마련하고 SimpleLogin 같은 것에 연결하는 것이겠지만, 금방 복잡해짐
  • 나도 이렇게 함
    다만 직접 만나거나 전화로 고객용 이메일이 [their_business_name]@my_weird_domain.tld라고 설명해야 할 때 어색함
    보통은 그냥 고개를 끄덕이긴 함
    또 다른 단점은 수신 전달만 된다는 점임. 새 받은편지함과 보낸편지함을 통째로 만들지 않고도 답장을 프록시할 수 있으면 좋겠음
  • 전달 메일 서버가 SRS를 지원하지 않으면, Gmail은 SPF/DMARC 정렬에 실패한 메시지를 차단함
  • SPF/DMARC/DKIM 때문에 지금은 전반적으로 좀 더 복잡해졌음
    설정이 모두 맞지 않으면 메일을 보내주지 않는 메일 전송 에이전트도 꽤 많음
  • 몇 년째 이렇게 쓰고 있는데 잘 동작하고, 누가 내 이메일을 파는지 보는 재미도 있음
    하지만 기록은 꼭 잘 남겨야 함
    계정을 복구하려는데 어떤 커스텀 이메일을 썼는지 기억이 안 나면 정말 난감해짐

• 요약하자면 이제 Sign in with Apple과 Hide My Email 별칭이 모두 @private.icloud.com 하위 도메인에서 발급된다는 뜻임
  이렇게 되면 iCloud 메일의 일반 릴레이 아닌 사서함에는 영향을 주지 않고 모든 별칭을 금지하기 훨씬 쉬워짐
  그런데 Sign in with Apple과 Hide My Email이 같은 도메인에 있으면 왜 일괄 차단이 더 쉬워지는지, 오히려 더 어려워지는 게 아닌지 잘 모르겠음

  • 이전에는 이메일이 모든 Apple 사용자 기본값인 [e-mail] 형태였음
    일반 이메일과 생성된 비공개 이메일을 구분할 방법이 없었음
    이제는 [e-mail]이 되므로, 서비스 간 로그인 연결을 어렵게 만드는 생성된 비공개 이메일을 쉽게 차단할 수 있음
    Apple이 왜 스스로 이렇게 불리한 선택을 하는지는 불명확함. Ternus가 개인정보 보호에 반하는 방향으로 맞춰주는 게 아니길 바람
  • 예전에는 이 서비스를 쓰면 Apple이 (something)@icloud.com을 생성했음
    이제는 (something)@private.icloud.com을 쓰게 되니, 이 서비스로 기본적으로 “숨는” 사람들을 대상으로 하위 도메인 전체 차단이 즉시 가능해짐
    anondaddy나 simplelogin 같은 건 막고 protonmail은 막지 않는 것과 비슷함
  • 추측하자면 이전에는 별칭 계정과 비별칭 계정이 모두 @icloud.com을 썼기 때문임
    Gmail 계정 만들듯 일반 iCloud 이메일 주소를 예약할 수 있었으니, iCloud 주소 전체를 금지하면 별칭이 아닌 Apple 고객도 같이 차단됐음
    다만 별칭을 막고 싶었던 곳이 이미 못 막았을지는 확신이 안 듦. 별칭 이메일은 충분히 이상하게 생겨서, 오탐을 조금 감수하면 이미 차단할 수 있었을 것 같음

• “쓸모없다”는 건 너무 나간 말임
  비공개 릴레이 이메일을 차단할 만한 사이트라면 애초에 내 임시 이메일을 받았을 곳임
  비공개 릴레이는 소식을 받고 싶은 사이트에 쓰되, 나중에 해킹당했을 때를 대비한 안전장치로 쓰는 용도임

  • 맞음. 합리적인 기업이라면 이 하위 도메인의 이메일을 금지하지 않을 것임

• 반대로 private.icloud.com을 차단하는 곳은 Apple로 SSO하는 능력도 막게 되므로, 스스로 Apple 생태계와 단절하게 됨

  • 꼭 그렇지는 않음
    Apple SSO를 쓸 때만 private.icloud.com을 허용하면 됨
    Apple SSO 없이 계정을 만들려고 하면 private.icloud.com 이메일 주소를 허용하지 않는 방식이 가능함

• 의지가 있는 사이트라면 이미 쉽게 할 수 있었음. 쓰이는 패턴을 감지하면 됨
  그래도 쓸모없는 변경이라는 데는 동의함
  예를 들면 [e-mail] 같은 형태임
  Sign in with Apple에는 별 영향이 없어야 하는데, 사이트들이 이미 명시적으로 그 기능을 지원하고 있기 때문임
  이메일 별칭은 어렵다. 사용자 무리 속에 섞여 개인정보를 보호하고 싶지만 그러면 그 생태계에 묶이고, 직접 통제하는 도메인은 묶임은 없지만 무리 속 익명성도 없음

  • 생성된 별칭이 모두 저런 형태는 아니고, 일부는 [e-mail]이나 [e-mail]처럼 생겼음
    어쨌든 일부 서비스가 별칭을 금지했다는 사실이, 더 좋게 만들기는커녕 완전히 쓸모없게 만들 이유는 아님
    Apple은 시장 점유율로 이 문제를 밀어붙일 수 있는 몇 안 되는 회사 중 하나임
  • 의지가 있는 사이트는 이미 실제로 그렇게 하고 있음
    지금은 어떤 방식으로 판별하는지는 모르겠음

• Proton 별칭을 거의 모든 곳에서 씀
  물론 모든 곳은 아니고, passmail.net 주소를 받지 않는 곳도 꽤 있음
  그래서 이 기능이 적어도 일부 사이트에서는 쓸모없어질 수 있다는 건 충분히 상상됨
  참고로 로그인 잃어도 괜찮은 사이트에만 이런 별칭을 씀. 아니면 최악의 락인이 될 테니까
  내 자체 보조 도메인에서 별칭을 선택할 수 있었다면 좋았을 것임. 그러면 와일드카드나 내보낸 목록으로 옮길 수라도 있음

  • 자기 도메인에서 커스텀 별칭을 만들 수 있음
    나는 모든 로그인에 이렇게 쓰고 있고, 예전 이메일들도 커스텀 도메인 별칭으로 옮기는 중임

• 내 iCloud 릴레이 주소 대부분은 이미 @privaterelay.appleid.com이고 완벽하게 잘 동작해왔음
  그래서 당분간 이게 바뀔 것 같지는 않음

  • 그 도메인은 Sign in with Apple에만 쓰임

• 개인적으로 Hide My Email은 iMessage보다도 나를 Apple 생태계에 더 묶어두고 있음. 다만 나는 유럽 사용자임

  • 정말 그런가? 나는 Apple 생태계 통합 없이 Hide My Email을 주로 씀
    icloud.com에서 새 이메일을 만들고 로그인 폼에 복사해 붙인 다음 1Password에 저장함
  • 불안한 구조임
    평생 iCloud 고객으로 남거나, 수백 개 로그인이 깨질 수 있음