서드파티 쿠키는 죽지 않았다. DNS로 옮겨갔을 뿐.

구글은 5년 동안 서드파티 쿠키를 죽이겠다고 하다가 조용히 포기했다. 별로 중요하지 않았다. 트래킹은 이미 DNS 계층으로 도망쳤고, 당신의 세션 쿠키까지 데려갔으니까.

5년 동안 광고 업계 전체가 끝내 열리지 않은 장례식을 대비했다.

구글은 2020년에 Chrome이 서드파티 쿠키를 단계적으로 없앤다고 발표했다. 그리고 날짜를 미뤘다. 또 미뤘다. 2024년 7월엔 “사용자 선택” 프롬프트로 방향을 틀었고 — 당신이 직접 정하게 하겠다는 거였다 — 2025년 4월엔 그것마저 버렸다. Chrome은 서드파티 쿠키를 기본 켜짐으로 유지한다, 프롬프트도 없고 폐기도 없다. 2025년 10월엔 Privacy Sandbox 전체를 접었다: Topics, Protected Audience, Attribution Reporting, 6년 만에 전부 은퇴 — 구글 스스로 인정하길, 살려둘 만큼 채택되지 않아서.

그래서 쿠키는 살았다. 이게 이야기의 끝이라고 생각하겠지만, 아니다.

흥미로운 일은 구글이 수건을 던지기 몇 년 전에 이미 벌어졌고, 모두가 쳐다보던 곳보다 한 계층 아래에서 일어났다. 업계가 오지도 않는 쿠키 폐기를 놓고 다투는 동안, 트래커들은 조용히 서드파티 쿠키에 의존하는 걸 아예 그만뒀다. 작전 전체를 DNS로 옮긴 것이다.

수법은 CNAME 하나

메커니즘은 이렇다. 모욕적일 만큼 단순하다.

트래킹 벤더가 당신한테 서브도메인 하나 — 이를테면 metrics.yourdomain.com — 을 만들어 c.tracker-vendor.net 같은 데를 CNAME 레코드로 가리키라고 한다. 그게 다다. 그게 익스플로잇 전부다. 당신 소유가 아닌 머신에 당신 zone의 이름 하나를 위임한 거다.

이제 브라우저가 뭘 보는지 보자. 당신 페이지의 스크립트가 metrics.yourdomain.com에서 리소스를 로드한다. 브라우저에게 그 호스트명은 당신이 실제로 방문 중인 사이트의 서브도메인이다. same-site. first-party. 브라우저의 서드파티 쿠키 장치 — 구글이 5년간 조이겠다고 위협하던 그것 — 는 애초에 발동하지 않는다. 브라우저가 보기엔 서드파티한 일이 하나도 안 일어나니까. 요청은 당신 도메인으로 간다.

그런데 안 간다. DNS가 그 CNAME을 해석하고 연결은 트래커의 인프라에서 끝난다. 트래커가 쿠키를 설정한다. 응답이 metrics.yourdomain.com에서 왔으니, 그 쿠키는 당신 도메인의 first-party 쿠키다. 차단되지도, 캡이 씌워지지도, 파티션되지도 않는다. 세탁된 것이다. 서드파티가 이제 당신 사이트에서 first-party 쿠키를 읽고 쓴다. 그걸 가능하게 한 건 당신이 직접 추가한 DNS 레코드 하나뿐이다.

이게 CNAME 클로킹(cloaking)이고, 이론상의 공격이 아니다. 측정된 현상이다. 2021년 Proceedings on Privacy Enhancing Technologies에 실린 “The CNAME of the Game”은 이 패턴을 상위 1만 개 사이트 중 대략 열에 하나에서, 트래픽 상위 사이트에 집중돼, 늘어나는 중으로 발견했다. 그때 이미 수년째 프로덕션에 있었다. 논문 저자들이 이걸 연구한 게 2020년 — 트래킹을 더 어렵게 만들 거라던 그 쿠키 폐기가 발표된 바로 그해다.

실제로 새는 것

거슬리는 건 트래킹이 아니다. 부수 피해다.

서브도메인이 브라우저에서 first-party로 해석되면, 자기 쿠키만 받는 게 아니다. 당신의 쿠키를 받는다. 브라우저는 당신 도메인에 스코프된 모든 쿠키를 그 요청에 붙인다 — 요청이, 브라우저가 아는 한, 당신 도메인으로 가니까. 쿠키를 특정 호스트에 고정하지 않고 apex(.yourdomain.com)에 설정했다면, 그 쿠키들은 metrics.yourdomain.com에 묻어가고, 그건 곧 트래커에 묻어간다는 뜻이다.

다시 읽어라. 당신의 세션 쿠키. 쿠키에 저장한 CSRF 토큰. 인증 상태. 전부 자동으로, 데이터 수집이 본업인 회사의 서버로 실려간다. DNS가 그들 서버를 당신 것처럼 보이게 만들었기 때문에. 측정 연구가 정확히 이걸 찾아냈다: analytics와 아무 상관 없는 쿠키 — 세션 식별자, 민감한 토큰 — 가 same-site 착시의 부작용만으로 CNAME 트래커에 유출되는 실제 배포들. 아무도 그 유출을 일부러 설계하지 않았다. 아키텍처에서 공짜로 떨어져 나온 거다.

쿠키만이 아니다. 클로킹된 서브도메인으로 가는 모든 요청은 same-site Referer, 전체 Cookie 헤더, 브라우저가 first-party에 빚졌다고 여기는 걸 전부 실어 나른다. 당신은 자기 방어선에 구멍을 뚫어 광고 네트워크를 향해 겨눴고, 그건 페이지에 당신이 운영하는 뭔가처럼 보이는 친근한 metrics. 서브도메인으로 렌더링된다.

막으려 한 브라우저들

다 놓친 건 아니다. Safari가 가장 직접적인 걸 했다.

WebKit은 2020년 11월 Safari 14에서 방어를 내놨다: Intelligent Tracking Prevention이 first-party 서브리소스가 사이트 자신과 다른 호스트로 CNAME을 통해 해석된다는 걸 감지하면, 그 응답에서 설정된 쿠키의 수명을 7일로 캡을 씌운다. 논리는 무뚝뚝하다 — DNS로 서드파티를 first-party로 위장할 거면, ITP는 그 쿠키를 서드파티에 마땅한 의심으로 다룬다. 7일, 그다음 소멸. 이 한 방의 변화가 사실은 서브도메인을 뒤집어쓴 서드파티였던 수많은 “영구” first-party analytics를 조용히 깨뜨렸다.

Firefox는 다른 길을 갔다: 기법 자체를 금지하진 않지만, uBlock Origin 같은 확장이 리소스 호스트명에 실제 DNS 조회를 걸어 CNAME 체인을 벗기고, 목적지가 알려진 트래커면 요청을 차단하게 해주는 유일한 브라우저다. 그게 결정적 능력이다 — 호스트명만으로는 클로킹을 탐지할 수 없다. 호스트명은 설계상 당신 것이니까. 어디로 실제로 가는지 보려면 DNS를 해석해야 한다. Chrome 확장은 그 조회를 못 한다. Firefox 확장은 한다.

그러면 Chrome — 방금 서드파티 쿠키를 아예 안 건드리기로 정한 그 브라우저 — 이, 애초에 서드파티 쿠키를 선택사항으로 만든 그 기법에 가장 약한 답을 가진 셈이다. 곱씹을 만한 아이러니다. 모두가 두려워한 폐기는, 트래커들이 이미 우회해버린 메커니즘을 겨눈 것이었다.

이건 쿠키 문제가 아니라 DNS 문제다

10년 동안의 반사신경은 트래킹을 쿠키 문제로 생각하는 거였다. 쿠키를 막으면 트래킹이 멈춘다. 이 프레이밍 때문에 구글의 쿠키 폐기는 5년치 헤드라인을 얻었고 CNAME 클로킹은 논문 몇 편을 얻었다.

하지만 쿠키는 어려운 부분이 아니었다. 쿠키는 그냥 저장소다. 어려운 부분은 신원(identity) — 트래커와 대화하는 브라우저가 다른 천 개 사이트를 방문한 그 브라우저와 동일하다고 확립하는 것. 서드파티 쿠키는 그 신원을 경계 너머로 나르는 한 가지 방법이었다. CNAME 클로킹은 또 다른 방법이고, 완전히 다른 가정을 공격해서 작동한다: 당신 사이트의 서브도메인이 당신 사이트에 속한다는 가정. DNS에서 그 가정은 선택이고, 당신은 레코드 하나로 그 선택을 조용히 남에게 넘길 수 있다.

불편한 결론은, 이걸 쿠키나 스크립트를 봐서는 바깥에서 감사할 수 없다는 거다. 클로킹된 트래커는 보통 사람이 들여다보는 모든 표면에서 first-party 인프라처럼 보인다. 진실이 보이는 유일한 곳은 DNS다 — CNAME 체인, 위임, 그 이름이 실제로 가리키는 호스트. 당신 도메인의 서브도메인이 정말 당신 것인지 알고 싶으면, 레코드를 끝까지 따라가 어디에 착지하는지 봐야 한다. 그 계층 위의 모든 것은 당신을 속이도록 설계돼 있다.

구글은 서드파티 쿠키 죽이기를 포기했다. 별로 중요하지 않은 걸로 드러났다. 중요한 것은 이미 쿠키 아래로, 아무도 보지 않던 그 한 계층으로 기어 내려갔으니까. 도메인을 운영한다면, 당신 자신의 CNAME 레코드를 읽어봐라. 그동안 누구를 보증해왔는지 보고 놀랄지도 모른다.

토론 참여

← 블로그로 돌아가기