YADONGPARTY / JOURNAL
재생 버튼을 누르기 전에도 요청이 생길까?
링크만 둔 화면과 일반·지연 이미지를 각각 세 번 비교했습니다. 클릭 전 0건과 1건의 차이, 스크롤 뒤 달라진 기록, 이 실험으로 알 수 없는 범위를 함께 설명합니다.
클릭하지 않아도 페이지에 넣은 이미지 때문에 요청이 발생할 수 있습니다. 이번 실험에서 일반 이미지는 3회 모두 첫 화면을 열 때 요청되었고, 텍스트 링크만 표시한 조건은 클릭 전까지 목적지 문서 요청이 0건이었습니다. “재생 전”이라는 시점만으로 외부 접속 여부를 판단할 수 없었습니다.
왜 재생 버튼 대신 작은 그림부터 시험했나요?
영상 코덱이나 플레이어 동작을 제외하고, 링크와 이미지가 요청을 만드는 시점만 비교하기 위해서입니다. 성인 콘텐츠 페이지의 재생 버튼을 누르지 않았더라도 주변 이미지가 먼저 전달될 수 있습니다. 같은 도형을 사용하면 그림 내용은 고정하고 화면에 넣는 방식만 바꿀 수 있습니다.
원인을 나누기 위해 동영상, 광고 스크립트, 로그인 기능을 모두 제외했습니다. 직접 만든 320 × 180 크기의 단색 SVG 그림 하나와 문서 하나만 수신 서버에 두었습니다. 출발 페이지에서는 이 자원을 링크로만 가리키거나, 이미지로 표시하거나, 아래쪽에서 지연 로딩하도록 바꾸었습니다. 그림 자체의 내용은 모든 이미지 조건에서 같았습니다.
실제로 사용한 조건
- 확인 날짜: , Windows의 Chrome 156 데스크톱.
- 같은 컴퓨터에서 서로 다른 포트의 HTTP 서버 두 개를 사용했습니다. 출처는 다르지만 실제 인터넷의 서로 다른 사업자 서버는 아닙니다.
- 일반 이미지에는 지연 로딩을 지정하지 않았습니다. 지연 이미지는 위에 12,000px 빈 공간을 두고
loading="lazy"를 지정했습니다. - 응답은
Cache-Control: no-store로 전송하고, 각 시행에는 서로 다른 식별자를 붙였습니다. - 목적지 서버가 받은 요청만 셌습니다. 확장 프로그램이나 브라우저의 다른 통신을 모두 조사한 실험은 아닙니다.
같은 그림을 넣어도 요청 시점이 다른가요?
이번 표본에서는 일반 이미지 3/3회(100%)가 클릭 전에 요청됐고, 링크와 지연 이미지는 각각 0/3회(0%)였습니다. 이 비율은 각 조건을 세 번 실행한 결과만 나타냅니다. 시행별 원기록에서 조작 전후를 확인할 수 있습니다.
총 9개 시행에서 첫 화면의 상태를 확인한 뒤 수신 서버 기록을 읽었습니다. 이어서 링크 조건에서는 직접 링크를 눌렀고, 지연 이미지 조건에서는 화면을 이미지까지 내렸습니다. 세 조건을 모두 같은 방법으로 세 번 반복했으며, 결과는 각 조건 안에서 같았습니다.
| 화면의 조건 | 조작 전 | 조작 뒤 |
|---|---|---|
| 텍스트 링크만 표시 | 3회 모두 0건 | 클릭 뒤 각각 1건 |
| 일반 이미지 표시 | 3회 모두 1건 | 별도 클릭 없음 |
| 아래쪽 지연 이미지 | 3회 모두 0건 | 이미지까지 스크롤 뒤 각각 1건 |
숫자는 제어한 수신 서버에 도착한 요청 수입니다. 브라우저 전체의 네트워크 사용량이나 외부 서비스의 실제 방문 통계가 아닙니다.
일반 이미지 조건의 요청은 화면에 그림이 표시되는 과정에서 발생했습니다. 링크 조건은 링크가 보인다는 사실만으로 목적지 문서를 가져오지는 않았고, 클릭 후에 그 문서가 요청됐습니다. 지연 이미지 조건은 처음에는 요청되지 않았지만 스크롤 후 그림이 표시되면서 요청이 한 건씩 기록됐습니다.
이때 12,000px는 이미지가 첫 화면에서 충분히 멀리 있도록 우리가 정한 실험 배치입니다. 브라우저가 항상 정확히 그 거리에서 로딩을 시작한다는 뜻은 아닙니다. 지연 로딩은 화면 근처에서 미리 시작될 수도 있으며, MDN의 지연 로딩 문서도 필요한 시점에 자원을 미루어 가져오는 방식으로 설명합니다.
요청 한 건이 기록되면 추적당한 것인가요?
아닙니다. 요청이 도착했다는 사실만으로 개인 식별이나 행동 프로파일링을 입증할 수는 없습니다. 이번 수신 서버는 그림을 보내기 위해 요청을 받았습니다. 그 기록을 통해 접속 시점과 요청 종류는 확인할 수 있었지만, 다른 서비스가 로그를 보관하는 기간이나 식별자와 결합하는 방식은 조사하지 않았습니다.
그래서 “요청이 생겼다”와 “나를 알아냈다”를 구분해야 합니다. 반대로 재생 버튼을 누르지 않았다는 이유만으로 요청 자체가 없었다고 단정하는 것도 실험 결과와 맞지 않았습니다. 실제 서비스에서 개인정보 처리 범위를 확인하려면 네트워크 목록뿐 아니라 해당 서비스의 처리 방침과 사용 중인 기능을 함께 확인해야 합니다.
판단 순서는 요청의 발생과 기록의 활용이라는 두 단계입니다. 같은 요청 1건이라도 파일을 전달했다는 사실과 그 기록을 개인 식별에 사용했다는 주장은 필요한 근거가 다릅니다.
목적지에는 출발 페이지 전체 주소가 전달됐나요?
이번 기록에서는 9개 요청 모두 출발 출처만 전달되었고, 페이지 경로와 질의 문자열은 전달되지 않았습니다. 출발 문서에 strict-origin-when-cross-origin을 지정했고 서로 다른 포트의 서버로 요청했기 때문입니다. 즉, 어떤 출처에서 왔는지와 그 출처 안의 어느 문서를 읽었는지는 구분할 수 있었습니다.
| 확인한 정보 | 이번 관찰 |
|---|---|
| 출발 출처 | 9개 요청 모두 포함 |
| 출발 페이지 경로 | 9개 요청 모두 미포함 |
| 출발 페이지의 질의 문자열 | 9개 요청 모두 미포함 |
MDN의 Referrer-Policy 설명은 이 정책에서 다른 출처로 이동할 때 출처만 전달하는 동작을 설명합니다. 다만 실제 브라우저 설정, 확장 프로그램, 전송 조건 등에 따라 값이 달라질 수 있습니다. 이 결과는 방문자를 완전히 익명으로 만든다는 의미도, 모든 서비스에 항상 같은 값이 도착한다는 의미도 아닙니다.
야동파티 이용 정보에는 어떻게 적용하나요?
이번 결과를 적용할 때의 핵심은 화면에 보이는 조작과 실제 요청을 따로 생각하는 것입니다. 이미지가 들어 있는 목록은 재생 전에도 자원을 가져올 수 있고, 단순 링크만 있는 안내는 목적지 문서 방문을 클릭 뒤로 미룰 수 있습니다. 같은 “바로가기 페이지”라도 구성 요소가 다르면 요청 흐름도 달라질 수 있습니다.
- 아직 클릭하지 않았어요: 링크, 그림, 삽입 플레이어 중 무엇이 화면에 있는지 먼저 구분합니다. 클릭 여부 하나로 접속 여부를 판단하지 않습니다.
- 아래로 내리니 그림이 나타났어요: 지연 로딩일 수 있습니다. 늦게 요청된다는 뜻이지 요청이 영원히 사라진다는 뜻은 아닙니다.
- 목적지에 출발 출처가 남았어요: 출처 정보와 전체 페이지 주소를 구분합니다. 정보의 범위가 같지 않습니다.
이번에는 모바일 Safari, 시크릿 모드, 확장 프로그램, 실제 성인 서비스의 플레이어를 시험하지 않았습니다. 서버의 호스트가 같고 포트만 달랐으므로 서로 다른 사이트의 쿠키 제한을 검증한 결과로도 사용할 수 없습니다. 영상 품질이나 특정 서비스의 안전 등급을 매긴 실험이 아니라, 세 가지 단순 구성의 요청 시점을 비교한 기록입니다.