사용자를 오도하는 Chrome의 서드파티 쿠키 강화

 (brave.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Chrome의 Related Website Sets(RWS) 는 서드파티 쿠키 폐지 이후에도 관련 사이트 간 정보 공유를 예외적으로 허용해, 웹 프라이버시 보호를 약화할 수 있음
  • 이 기능은 사용자가 사이트 간 소유 관계를 알아볼 수 있다는 전제에 기대지만, 30명 대상 연구에서 전체 판단의 약 42%가 오답이었고 약 73% 는 최소 한 번 틀림
  • Chrome이 “관련 사이트”로 분류한 경우에도 사용자는 약 37% 를 관련 없다고 판단해, 사용자가 예상하지 못한 사이트 간 추적이 가능해질 수 있음
  • 관계를 확인하려면 먼저 사이트를 열어야 하므로, 공유 브랜딩이나 로고를 보는 순간 이미 정보 공유와 추적 기회가 생김
  • Brave, Firefox, Safari는 RWS 또는 이전 이름인 First-Party Sets에 반대했고, 해당 제안은 W3C Privacy Community Group에서도 제거됨

RWS가 바꾸는 웹 프라이버시 전제

  • Related Website Sets(RWS) 는 Google이 서드파티 쿠키 종료를 앞두고 Chrome에 도입한 기능임
  • Google은 RWS가 사이트 호환성 문제를 줄이고 관련 도메인 사이에서 로그인 상태를 유지하는 데 도움이 된다고 주장함
  • Brave는 RWS가 사용자 이익보다 광고주 이익을 우선하며, 서드파티 쿠키 폐지 이후에도 사이트 간 연결을 계속 허용하는 장치라고 비판함
  • 핵심 전제는 두 사이트가 같은 조직에서 운영된다면 사용자가 정보 공유를 예상할 수 있고, 브라우저가 서드파티 쿠키 수준의 차단을 적용하지 않아도 된다는 것임
    • 예시로 Meta가 운영하는 instagram.com과 facebook.com이 제시됨
  • 이 전제는 같은 조직 소유라는 이유만으로 사이트 간 추적을 허용해도 된다는 방향으로 웹 프라이버시 모델을 약화함

사용자 연구: 사이트 관계를 맞히기 어려움

  • 연구는 RWS의 핵심 가정인 “웹 사용자가 두 사이트의 관계를 정확히 판단할 수 있는가”를 검증함
  • 연구진은 소셜 미디어로 모집한 웹 사용자 30명에게 각각 웹사이트 20쌍을 제시함
    • 웹사이트 쌍은 Chrome의 RWS 목록과 인기 웹사이트 목록인 Tranco에서 무작위로 선택됨
    • 참가자는 두 사이트가 같은 조직에서 운영된다고 생각하는지 판단함
    • 일부 참가자가 모든 문항에 답하지 않아 총 430건의 고유 사이트 쌍 판단이 수집됨
  • 사용자 기대는 RWS 목록과 자주 어긋남
    • 약 73% 의 참가자가 최소 한 번은 두 사이트 관계를 잘못 판단함
    • 전체 판단 중 약 42% 가 오답임
    • RWS 기준으로 실제 관련된 사이트 쌍에서도 사용자는 약 37% 를 관련 없다고 봄
  • 이 결과는 RWS가 사용자가 예상하지 못한 상황에서도 서드파티 쿠키와 유사한 동작을 다시 가능하게 할 수 있음을 보여줌
  • 전체 논문은 arXiv 논문으로 공개되어 있으며, 2024 Internet Measurement Conference에서 발표 예정임

판단보다 먼저 발생하는 추적 기회

  • RWS의 직관은 사용자가 사이트 A와 사이트 B의 관계를 파악한 뒤, 그 관계를 받아들일 수 있을 때만 사이트 B를 방문한다는 것임
  • 실제로는 사용자가 사이트 B의 공유 브랜딩이나 로고를 확인하려면 먼저 사이트 B를 로드해야 함
  • 페이지가 로드되는 순간 정보 공유와 사이트 간 추적 기회가 이미 발생함
  • 따라서 RWS는 사용자가 두 사이트의 관계를 판단하기 전에 프라이버시 피해를 만들 수 있음

같은 조직 소유가 추적 허용의 근거는 아님

  • RWS는 두 사이트가 관련되어 있다면 브라우저가 두 사이트 사이의 프라이버시 보호를 낮춰도 무해하거나 허용 가능하다는 생각에 기반함
  • Brave는 이 전제가 틀렸다고 봄
    • 사용자가 Facebook 계정과 Instagram 계정을 서로 다른 이메일과 정보로 등록하면, 최신 브라우저는 두 계정이 같은 사람 소유임을 Meta가 알지 못하게 막을 수 있음
    • Brave, Firefox, Safari 같은 대중용 브라우저와 Tor Browser, Icefox 같은 특수 목적 브라우저도 이런 보호를 기본 동작으로 제공할 수 있음
  • 일부 회사는 링크 데코레이션이나 바운스 추적으로 브라우저의 프라이버시 보호를 우회하려고 함
  • 프라이버시 중심 브라우저가 사이트 간 추적 차단 기법을 실험하는 반면, Chrome은 사이트 간 연결을 허용하는 기능을 설계한다는 점이 핵심 차이임

브라우저와 표준화 커뮤니티의 반응

  • RWS는 일반적인 웹 제안처럼 제시됐지만, 웹 생태계의 여러 주체가 이미 검토 후 거부한 상태임
  • Brave, Firefox, Safari는 RWS 또는 이전 이름인 First-Party Sets가 사용자와 웹에 좋지 않다는 입장을 공개적으로 밝힘
  • 해당 제안은 W3C Privacy Community Group에서 제거됐고, W3C의 프라이버시 중심 그룹에서는 더 이상 검토되지 않음

소유권 변경과 언어 장벽

  • RWS 목록에 들어간 도메인이 나중에 다른 소유자에게 넘어갈 수 있음
    • 오늘 A, B, C 도메인이 같은 조직에서 운영된다고 해서 내일도 같은 조직 소유라는 보장은 없음
    • 브라우저 확장 프로그램이 신뢰받는 주체에서 악의적 주체로 판매되거나, 인기 소프트웨어 라이브러리와 의존성이 탈취된 사례와 같은 유형의 위험이 있음
    • 사이트가 목록에 포함될 당시 의미 있게 관련되어 있어도, 소유권이 조용히 바뀌었을 때 이를 제거할 메커니즘이 없다는 우려가 남음
  • 언어와 인식 문제도 있음
    • 영어 사용자가 영어 사이트를 평가하는 상황에서도 Google이 관련 있다고 판단한 사이트를 사용자가 예상하지 못함
    • 사용자가 모르는 언어의 사이트를 방문할 때는 관계 판단이 더 어려워질 수 있음

결론

  • RWS는 세 가지 방식으로 웹 프라이버시에 해로울 수 있음
    • 사용자가 어떤 사이트들이 서로 관련되어 있는지 예측할 수 있다는 전제가 실제 사용자 행동과 맞지 않음
    • 사용자가 두 사이트가 같은 조직에서 운영되는지 판단하기 전에 이미 사이트 간 추적 기회가 생김
    • 같은 조직이 소유한 사이트라면 그 조직이 사이트 간 사용자를 추적해도 된다는 가정을 웹 플랫폼에 고착시킴
  • 프라이버시를 존중하는 브라우저들은 소유 조직과 관계없이 모든 사이트의 추적을 막으려는 방향으로 움직이고 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들
  • 오랫동안 Firefox를 써 왔고 큰 문제는 없었음. 예전에 메모리가 적을 때는 Chrome이 메모리를 덜 쓰긴 했지만, Firefox에도 HTTPS 전용 모드, 대체 경로 없는 암호화 DNS, SOCKS, Encrypted Client Hello 지원이 있음
    다만 Encrypted Client Hello는 지원하는 웹사이트가 거의 없음. 메모리는 그냥 더 사는 편이 낫고, Apple 제품을 쓰는 운이 좋은 경우는 예외일 수 있음
    브라우저는 사용자 편에 서야 하고 마케팅 회사와 협력하면 안 됨. 더 나아가 사용자 추적과 지문 채취를 어렵게 만들어야 함. 사용자의 탐색 기록을 추적할 필요 없이, 경쟁 제품보다 나은 제품을 만들고 리뷰와 비교에서 1위를 차지한 뒤 인플루언서 광고를 사면 됨
    브라우저가 캔버스 데이터 읽기, GPU 이름 읽기, 오디오 카드 열거, 설치된 확장 탐지 등을 막아 지문 채취를 더 어렵게 만들면 좋겠음. 새 웹 API는 지문 데이터가 늘어나지 않음을 보장하거나 권한 뒤에 숨겨야 함
    제3자 쿠키는 RWS 같은 수상한 목록 대신, 그것에 의존하는 구식 웹사이트에서 예외로 허용하는 버튼을 브라우저가 제공하면 됨. 다만 신문, 블로그, 질의응답 사이트가 콘텐츠를 보려면 버튼을 누르라고 강요할 위험은 있음
    • 브라우저는 원래 사용자를 위해 일하는 사용자 에이전트여야 했음. 요즘은 사용자 희생으로 광고 회사를 위해 일하지 않는 브라우저를 찾기가 점점 어려워짐
      Chrome의 존재 이유는 데이터 수집이고, Firefox는 적어도 지금은 사용자 편으로 강화 설정해서 상당한 지문 채취를 막을 수 있음. 하지만 Mozilla도 이제 광고 기술 회사가 됐고, Firefox가 기본적으로 사용자를 감시하게 만들어 그 데이터를 마케터에게 팔 수 있게 한 점에서 Firefox 사용자에 대한 존중이 부족함을 드러냈음
      현재는 about:config에서 dom.private-attribution.submission.enabled를 false로 설정해 그 감시를 끌 수 있음
      https://news.ycombinator.com/item?id=41311479와 https://web.archive.org/web/20240827185708/https://make-fire... 참고. 이 선택지가 얼마나 오래 유지될지, 업데이트 뒤에 얼마나 자주 다시 false로 되돌려야 할지는 알 수 없음
      정말로 사용자의 이익을 위해 동작하는 새 브라우저가 필요함
    • 새 웹 API가 지문 데이터를 더 제공하지 않는다고 보장하는 건 사실상 불가능함. 권한 알림에서 사용자가 옵션을 골랐는지, 골랐다면 무엇을 골랐는지 자체가 이미 데이터 포인트가 되기 때문임
      그래서 이 문제의 유일한 해법은 규제라는 얘기가 자주 나오고, 그 관점에는 꽤 설득력이 있음
    • https://news.ycombinator.com/item?id=40703546 — 두 달 전 내용임
    • 선두 브라우저가 광고 회사에서 개발되는 상황에서는 사용자 편 정책을 실행하기가 꽤 어려움. 더 나쁘게는 같은 회사가 Firefox 재단에도 기여하고 웹 “표준”도 주도함
      전부 담합처럼 보이고, 브라우저가 실행되는 운영체제보다 더 복잡해진 것도 작은 팀이 판을 흔들 수 없게 하려는 의도적 구조임. 고집스러운 해법은 가능한 한 웹을 피하고 인간 규모의 컴퓨팅에 집중하는 것임
    • 브라우저 제작사의 최우선 과제는 사용자의 브라우저 지문 채취 방지여야 함
      쿠키를 둘러싼 뉴스와 정책 논의는 모두 제한적 폭로처럼 보임
  • 이런 결과는 꽤 뻔해 보임. Related Website Sets(RWS)는 회사가 사이트 간 관계를 선언해서 브라우저가 특정 목적의 제한적 제3자 쿠키 접근을 허용하게 하는 방식이라고 함
    그러면 웹사이트가 직접 제3자 쿠키 차단을 우회할 수 있는 “축복받은” 도메인을 선언하는 셈인가? 대형 웹사이트들은 사용자가 스스로를 보호하려는 시도를 우회해 악용할 방법을 계속 찾고 있음. 이런 사이트들이 이를 악용하지 않을 거라고 어떻게 믿을 수 있나
    • 웹사이트가 직접 선언하는 건 아님. 제출해야 하는 마스터 목록이 있고 승인 절차를 거쳐야 함
      하지만 기사에서 다루듯 예비 목록의 내용만 봐도 이미 불안함. “광고 관련 모든 것의 중재자로서 Google”이라는 발상은 실패임
      그렇다고 대안도 좋지는 않음. 현재의 제3자 쿠키 시스템은 훨씬 더 나쁜 일을 허용함. 더 나은 아이디어가 필요함
    • 자세히는 모르지만 최근 Safari에서 본 것과 비슷한지 궁금함. 관련된 Microsoft 웹사이트를 방문했을 때 로그인용 쿠키 공유를 허용하겠냐는 팝업이 떴고, 승인하거나 거부할 수 있었음
      그쪽 구현이 더 나아 보임
  • 이건 어려운 상황임. 도메인 간 관계를 사용자가 예상하지 못하는 방식으로 엮어 추적하는 데 악용될 수 있고 실제로 악용될 것임
    하지만 정당한 사용 사례도 있음. 예를 들어 Stack Exchange 계열 사이트들은 명확히 관련돼 있고 통합 브랜드도 있지만 서로 다른 도메인을 씀. 제3자 쿠키를 차단하는 Firefox에서는 각 도메인마다 따로 로그인해야 해서, stackoverflow.com에 로그인한 뒤 superuser.com에 가도 이미 로그인된 상태가 아님. First Party Sets가 풀려는 문제가 바로 이 부분임
    이런 사이트들이 하나의 통합 도메인의 하위 도메인이었으면 더 낫다고 할 수는 있음. 하지만 사이트가 만들어질 당시에는 제3자 쿠키가 멀쩡히 작동했기 때문에 그렇게 해야 할 강한 이유가 없었음. 앱을 다른 도메인으로 옮기면서 사용자에게 문제를 일으키지 않는 일은 정말 고통스럽고 비용도 많이 들 수 있음
    First Party Sets를 그대로 받아들여야 한다는 뜻은 아니지만, 실제 문제를 해결하려는 시도임. 사용자 개인정보를 보호하면서도 실제로 관련된 사이트의 좋은 경험을 유지하는 해법은 찾기 어렵거나 어쩌면 불가능할 수 있음
    • stackoverflow.com에 로그인한 뒤 superuser.com에서도 자동 로그인되게 하려면 “이 사이트가 stackexchange.com과 쿠키를 공유하려 합니다. 로그인하려면 허용, 영구 거부하려면 거부, 나중에 결정하려면 무시를 누르세요” 같은 권한 팝업이 기대됨
      한 번 클릭으로 양쪽 장점을 모두 누릴 수 있음. 혼란을 줄이려면 모든 웹사이트가 전체 하위 사이트에 공유되는 단일 “제1자 도메인”을 갖도록 하고, 그 제1자 도메인은 자기 자신 외의 어떤 사이트와도 쿠키를 공유하지 못하게 해야 함
    • Safari와 Firefox는 이미 수년 동안 제3자 쿠키 차단을 해 왔음. Stack Overflow는 “올바른” 조직 구조로 적응하고 이전할 시간이 충분했음
      여러 도메인에서 통합 로그인을 허용하는 걸 중요하게 여겼다면 오래전에 하위 도메인 모델로 이전했어야 함. Firefox, Safari 사용자들은 오랫동안 부정적 영향을 받아 왔기 때문임
      그다지 중요하게 여기지 않는다면 그것도 괜찮지만, 그러면 Chrome의 제3자 쿠키 차단이나 First Party Sets 논의도 그들에게 크게 관련 없어야 함
    • Stack Overflow는 2008년에 만들어졌음. Netscape는 1997년에 제3자 쿠키 차단 버튼을 추가했고, 웹은 대체로 그 기능을 켜 둔 상태에서도 잘 작동해 왔음
    • Google이 광고 차단기 같은 정당한 사용 사례가 있었는데도 Manifest V3로 편리하게 전환한 일이 떠오름. 기술적으로는 V3가 더 안전하고 사용자에게 더 나을 수도 있지만, 여기서는 그 반대 방향의 움직임처럼 느껴짐
    • 다른 사이트들은 리다이렉트와 교차 출처 헤더로 이 문제를 잘 처리하는 것 같음. 어느 순간 signin.foo.com에 도착하긴 하지만, 사용자 경험상으로는 다시 로그인하지 않고 인증된 것처럼 보임
  • Google은 다른 브라우저들이 자기네 목록을 그냥 복사하길 기대하는 건가
    아니면 개발자들이 관련 도메인을 각 브라우저에 제출하고, 브라우저마다 자체 목록을 유지해야 하는 건가
    HSTS와 비슷하게 들림
    [0]: https://github.com/GoogleChrome/related-website-sets/blob/ma...
  • Brave가 이 주제에 대해 좋은 출처이거나 객관적인 출처인 것처럼 보이진 않음
    • Brave가 Chrome에 대해 불평할 상업적 유인이 있는 건 분명하지만, 그렇다고 그 불평이 거짓이 되는 건 아님
    • Brave가 경쟁자라는 뜻인지, 아니면 다른 의미인지 궁금함
  • 이제 /.well-known/related-website-set.json을 차단하기 시작할 때인 것 같음
  • “Chrome에서 제3자 쿠키가 폐기된 이후에도”라는 문구를 보면, 이 글은 몇 주 전에 쓰인 모양임
    • 설명해 줄 수 있나
  • Firefox를 쓰니까 신경 안 씀
    • Firefox가 이것을 지원하거나, 아니면 좋아하는 웹사이트들이 동작하지 않아서 결국 동작하는 Chrome으로 옮기게 될 것임
  • Padme: 그러면 Brave는 이제 Chrome 기반이 아니게 되는 거죠?
    • Brave는 Chrome이 아니라 Chromium 파생 브라우저임. 이 상황이 왜 Chromium 파생을 그만둬야 한다는 뜻이 되는지 모르겠음
      쿠키 정책과 기본값은 원하는 대로 개발하고 배포할 수 있음
    • Brave에는 소프트웨어 엔지니어가 있으니, Chrome 엔진의 많은 부분에서 하듯 그 코드 부분만 꺼 두고 계속 갈 계획일 것임
  • 여기가 딱 맞는 장소는 아니지만, Chrome의 광고 Topics 관련 연구나 글을 아는 사람이 있으면 궁금함. 사용자 개인정보에 어떤 영향을 주는지, 제3자와 무엇이 공유되는지 지금은 거의 모름
답변달기