Hacker News 의견
  • 만약 사용자 콘텐츠를 서브도메인에 호스팅할 계획이라면, 사이트를 Public Suffix List에 등록해야 함 https://publicsuffix.org/list/
    이렇게 하면 오염된 서브도메인이 전체 사이트에 영향을 주지 않음

    • 사용자 생성 콘텐츠를 호스팅하는 경우 PSL에 꼭 있어야 한다는 게 웹개발자들 사이에서는 일종의 묵시적인 상식임
      Immich의 이슈처럼 미리 경험해보지 않으면 이런 사실을 알기 어렵기 때문에, 실제로 겪어보기 전엔 대부분 모르는 부분임

    • 과거 브라우저는 도메인에 점이 없는 경우에만 광범위한 쿠키 설정을 막는 알고리즘을 사용했었음(예: .com, .org)
      하지만 .co.uk 같은 서브레벨 도메인에서는 모든 하위 등록 도메인에 쿠키를 흘려보내는 문제가 생겼음
      각 최상위 도메인마다 등록 정책이 달라서 개발적으로 해결할 방법이 없어, 결국 Public Suffix List처럼 리스트를 수동 관리하는 방식이 나옴
      브라우저 자체가 태생적으로 이런 한계가 있는 걸 보면 웹은 마치 덕트 테이프로 만든 자동차 같은 느낌임 https://publicsuffix.org/learn/

    • 이 글에 달린 여러 링크를 보니 실제론 두 가지 문제가 있음

  1. Immich처럼 자기 도메인에 사용자 콘텐츠를 올리면 public suffix list에 등록하는 문제
  2. 사용자가 immich, jellyfin 같은 오픈소스 프로젝트를 자기 도메인에 호스팅할 때 피싱으로 오해받는 문제
    첫 번째는 PSL에 대해 알고 있다면 비교적 쉬운 문제인데, 두 번째(특히 도메인 이름에 소프트웨어 이름이 포함된 경우)가 더 난감함
  • 문제는 사용자 콘텐츠 자체가 아니라, Immich의 release build를 내 서버에 직접 올렸는데 구글이 내 전체 도메인을 차단했다는 점임

  • Immich가 사용자 콘텐츠를 실제로 호스팅했기 때문이 아니고, PR preview용 서브도메인에서 해당 이슈가 발생한 것임
    이건 명백하게 구글의 코드 문제라고 생각함

  • Immich 팀의 ‘Cursed Knowledge’ 리스트 전체를 한 번 보는 걸 추천함 https://immich.app/cursed-knowledge

    • 리스트에 있는 내용 중 일부는 오히려 당연한 보안 설계 같음
      예를 들어 ‘일부 휴대폰은 위치 권한이 없는 앱이 이미지를 읽을 때 GPS 정보를 자동으로 삭제함’
      이건 오히려 자연스럽고 바람직한 동작 같음

    • 이런 종류의 노하우들을 CURSED.md 같은 표준 파일로 프로젝트마다 공유할 수 있으면 좋겠음
      실전에서 얻은 다양한 지식을 모두가 배우게 되는 셈임

    • ‘Postgres 쿼리 파라미터는 65,000개가 한계’
      그 정도도 모자라다는 점이 재미있음

  • 이런 경고 문구에서 항상 궁금한 점이 있음
    직접적으로 ‘사기꾼’, ‘공격자’로 딱지 붙이는데 이게 명예훼손에 안 걸리는지
    마이크로소프트의 미확인 실행파일 경고도 마찬가지임
    예전에는 ‘저희가 안전한지 모릅니다’ 식으로 말하더니, 요즘은 ‘당신이 공격자’라는 식으로 단정적으로 표시함

    • ‘사기꾼’이라는 단어는 실제 경고문에 쓰이지 않고, ‘공격자가 사이트에 있을 수 있다’, ‘~일 수 있다(might)’라는 식의 문구임
      여기엔 3자 해커가 침입한 사례까지 포함됨
      사이트 주인을 공격자로 지목하는게 아님
      법무팀에서 문구를 상당히 신중하게 검토했을 것임

    • 나는 변호사가 아니지만, 이런 경고 문구로 법정까지 간 적은 없지 않나 싶음
      명예훼손에 해당할 수도 있을 듯함

  • 이게 정말 큰 문제가 아닐 수는 있지만, Immich 같은 곳에 아무나 PR 제출해서 preview 태그만 달면 해당 내용이 무조건 https://pr-<num>.preview.internal.immich.cloud에서 호스팅되는 구조인지 궁금함
    결국 누구나 뭐든 자유롭게 올릴 수 있게 되는 것 아님?

    • github에서는 레이블을 추가할 수 있는 사람이 협업자로 제한되니까 완전히 열려 있지는 않음
      그래도 만약 협업자가 정상 PR을 먼저 제출해 놓고 라벨 획득 후에는 뭐든 올릴 수 있다면 위험요소가 있음

    • 진짜 돈 안 드는 피싱 방법 아이디어 같음

  • 한 회사가 어떤 사이트에 접속할 수 있는지까지 좌지우지한다는 게 믿기 어려움
    앱 실행을 제한하는 것도 모자라서 이젠 이 수준임

    • 미국 의회가 오랜 기간 비효율적으로 운영된 영향이 여러 문제로 이어진 것임

    • 광고를 싫어하는 사용자들까지도 어떻게 이렇게 대기업을 ‘쿨하다’고 생각하게 만들었는지 신기함
      광고는 아무도 원하지 않는데 회사 입장에서는 돈벌이 수단임
      구글이 어떻게 이런 비윤리적 기업 이미지를 오히려 ‘멋지다’고 포장하는지 이해가 안 감

  • 오픈 인터넷은 끝났다는 생각이 듦
    이제 모든 것을 독점들이 장악함
    나는 3년 동안 iOS 앱을 스토어에 두었는데 갑자기 Apple이 존재하지도 않는 새로운 라이선스를 요구하면서, 그게 없으면 앱을 내리겠다고 통보함
    3년간 아무것도 변한 게 없는데 이런 식임
    이제는 자가 호스팅조차 마음대로 못 하는 수준에 점점 질려감

    • iOS 앱과 Apple의 요구사항 문제에 대해 자세히 설명해준다면 정말 도움이 될 것 같음
  • 내 친구이자 고객이 WordPress 계열 호스팅과 간단한 리디렉션을 사용했었음
    호스트가 어느새 ‘위험한 사이트’ 블랙리스트에 올라버림
    리디렉션을 제거한 후에도 자기 도메인까지 오염된 상태였는데, 이로 인해 Google이 해당 도메인에서 이메일도 아예 받지 않음
    검토 요청을 통해 블랙리스트에서 풀리긴 했지만 이메일 차단 효과는 영구적으로 남음
    결국 새 도메인을 등록했는데, 이런 구글의 행동은 오히려 일회성 계정을 계속 만들게 하는 동기만 부여함

    • 이런 얘기 들으니 무섭게 느껴짐
      나도 25년간 잘 써 온 내 도메인이 잘못 블랙리스트에 올라가면서 이메일까지 막히게 되어 상상만 해도 끔찍함
  • 내 결론은 용도마다 도메인을 분리해서 사용하는 게 좋다는 점임
    전세계적으로 여러 TLD가 공식 서비스처럼 보이게 하는 단점도 있지만, 이번 사례에서 더 확신이 생김
    예시로
    www.contoso.com (공개용)
    www.contoso.blog (공개, 사용자 댓글 포함)
    contoso.net (내부용)
    staging.contoso.dev (개발/제로트러스트 엔드포인트)
    raging-lemur-a012afb4.contoso.build (스냅샷용) 처럼 사용 가능함

    • 하지만 이렇게 도메인을 분리하면 사용자 입장에서는 피싱으로 보일 위험이 훨씬 높음
      예전에 ‘githubnext.com’에서 메일을 받았는데, 나는 Github = github.com이라고 알고 있기 때문에 당연히 피싱이나 스팸으로 생각했음
      알고 보니 진짜 서비스였음

    • 좋은 접근임

  • 나도 현재 내 도메인으로 같은 문제를 겪고 있음
    구글이 우리 가족 Immich 인스턴스를 위험 사이트로 판단해서, 같은 도메인에서 제공하던 모든 서비스도 크롬에서 접근이 불가능해짐
    사실 워닝을 우회할 수야 있지만, 장모님께 보내드린 사진 앨범을 아예 사용 못 하게 됨

  • 똑같은 경험을 나도 올 초에 Umami Analytics 자가 호스팅할 때 겪었음
    https://news.ycombinator.com/item?id=42779544#42783321
    Google Search Console에 항의할 때 ‘법적 조치’을 언급했더니 그제서야 플래그가 풀렸음