브라우저는 주소를 통째로 건넸다. 뒤늦게 목소리를 낮췄다

Summary

• 1996년 HTTP/1.0의 Referer는 방문자가 이전에 있던 페이지의 URI를 목적지 서버에 알려 줬다. 역방향 링크와 로그에 쓸 수 있었지만, RFC는 링크의 출처가 사적인 정보일 수 있다고 이미 지적했다.
• W3C Referrer Policy는 원래 페이지가 주소를 얼마나 보낼지 고르게 했다. strict-origin-when-cross-origin에서는 보안이 유지되는 다른 사이트로 갈 때 출처의 오리진만 보내고, HTTPS에서 HTTP로 내려가면 보내지 않는다.

브라우저는 다른 사이트의 문을 두드릴 때 ‘여기서 왔습니다’라고 적힌 쪽지를 갖고 간다. 1996년 5월의 HTTP/1.0 문서 RFC 1945는 그 쪽지를 Referer라 불렀다. 철자가 틀린 이름이 오히려 인터넷에서 오래 살았다. 서버는 방문자를 보내 준 링크를 찾고, 로그를 분석하고, 캐시를 조정하거나 잘못 적힌 링크를 고칠 수 있었다. 사이트 운영자에게는 쓸모 있는 단서였다. 클릭한 사람에게는 방금 읽은 페이지의 주소가 따라간다는 사실이 낯설 수 있다.

1996년 문서도 이 어색함을 알고 있었다. 링크의 출처는 사적일 수 있으므로 사용자가 헤더 전송 여부를 선택할 수 있게 하라고 권했다. 손으로 입력한 주소에는 출처 페이지가 없고 # 뒤의 조각도 전송 대상에서 뺐다. 그래도 정확한 출발지는 매력적이었다. 유입 경로를 잘 세는 바로 그 정밀도로 누군가의 읽기 경로도 그려진다. 친절한 명함에 일기장 한 장이 끼어드는 셈이다.

W3C가 나중에 고른 예시는 구체적이다. 한 사람이 소셜 네트워크 프로필에 좋아하는 밴드의 링크를 걸고, 다른 사람이 누른다. 밴드 사이트는 그 네트워크에서 방문자가 왔다는 정도면 충분하다. 프로필 URL 전체가 넘어가면 주인의 신원까지 드러날 수 있다. 2017년 1월 W3C Referrer Policy 후보 권고안은 이 장면으로 헤더의 분량 문제를 보여 준다. 필요한 소개와 필요 없는 집 주소가 한 봉투에 담겼다.

정책에는 봉투를 접는 방법이 여러 가지다. no-referrer는 쪽지를 보내지 않는다. origin은 프로토콜과 호스트, 포트만 말하고 개별 페이지 경로를 남겨 둔다. strict-origin-when-cross-origin은 같은 출처의 요청에 정리된 전체 URL을 보내며, 보안이 유지되는 다른 출처로 갈 때는 오리진만 보낸다. HTTPS 페이지에서 HTTP 목적지로 갈 때는 전송하지 않는다. 암호화되지 않은 길에서는 사이트 이름만 알려 줘도 엿보는 사람에게 단서가 된다. 페이지 작성자는 응답 헤더 등 명시된 방법으로 이 선택을 전달할 수 있다.

누가 소개를 결정하는지가 달라졌다. 옛 HTTP 헤더는 브라우저가 목적지에 이전 페이지를 말할 수 있게 했다. 문서 정책은 출발 페이지가 말의 길이를 조절할 수 있게 했다. 소셜 사이트는 밴드에 ‘우리 쪽에서 손님이 왔다’고 알려 주면서 특정 회원의 프로필 경로는 건네지 않을 수 있다. 유입 단서는 남고 개인의 방 번호는 접힌 명함 속에 남는다.

2022년 6월 HTTP 의미론 RFC 9110에도 잘못 철자 쓴 Referer가 남아 있다. 분석과 로그, 링크 유지에는 여전히 유용하다. 동시에 URL에 계정명이나 비공개 자원 이름이 들어 있다면 바로 직전의 탐색 상황이 드러난다. 규범은 조각과 사용자 정보를 제거하고, 오리진 외의 부분을 줄일 수 있게 하며, HTTPS 페이지의 출처를 안전하지 않은 HTTP 요청에 보내지 못하게 한다. 1996년의 명함은 버려지지 않았다. 내밀기 전에 접을 수 있게 됐다.

W3C의 공개 이력은 2014년 첫 공개 초안부터 2017년 후보 권고안까지 이어진다. 한 번의 클릭으로 결과가 보인다. 프로필을 떠나 밴드 사이트로 간다. 밴드는 손님이 어느 동네에서 왔는지 알 수 있다. 매번 호수까지 물을 이유는 없다.