블루투스 헤드폰의 멀티포인트 기능은 PC와 스마트폰에 동시에 연결한 뒤, 보통 PC 소리를 우선하되 PC에서 아무것도 재생되지 않을 때 폰의 소리가 흘러나오도록 해 준다. 그런데 한 사용자가 겪은 문제는 특이했다. 파이어폭스나 크롬에서 알리익스프레스 홈페이지를 열어 두면, 잠시 뒤 폰에서 재생하던 음악이 끊겼다. 탭을 닫으면 즉시 정상으로 돌아왔지만, 탭이나 브라우저, 윈도우 자체를 음소거해도 소용이 없었고 페이지에는 눈에 보이는 동영상이나 음악도 없었다. 흔한 자동재생 광고를 의심해 오디오·비디오 요소를 뒤졌지만 아무것도 나오지 않았고, navigator.mediaSession의 상태도 계속 'none'이었다.
단서는 문제가 페이지 로드 직후가 아니라 몇 초 뒤에야 나타난다는 점이었다. 그래서 필자는 일반적인 미디어 요소 대신 Web Audio API를 감시하도록 페이지를 계측했다. AudioContext 생성자와 AudioNode의 connect() 호출을 가로채 오디오 처리 컨텍스트가 언제 만들어지고 무엇이 오디오 목적지에 연결되는지 기록한 것이다. 그 결과 유휴 상태의 홈페이지가 두 개의 숨은 AudioContext를 만들어 모두 running 상태로 진입시키고, 각각 AudioContext.destination에 노드를 연결한다는 사실이 드러났다.
지문을 채취하는 무음 오디오 그래프
생성자의 스택 추적은 두 스크립트를 가리켰다. assets.aliexpress-media.com 아래 AWSC 디렉터리에 있는 collina.js와 fireyejs.js로, 알리바바의 브라우저 보안·부정행위 방지 도구의 일부로 보인다. 두 스크립트는 심하게 난독화되어 있지만, 남아 있는 이름과 연산만으로도 오디오 코드가 하는 일을 파악할 수 있었다. 오실레이터가 알려진 파형을 만들고, 이 신호가 브라우저의 오디오 구현을 통과한 뒤 애널라이저가 주파수 데이터를 읽어 들이는 구조다. 게인은 0으로 설정돼 있어 사용자에게는 아무 소리도 들리지 않지만, 그래프는 여전히 시스템 오디오 목적지에 연결돼 있다.
바로 이 지점이 자동재생 동영상과 결정적으로 다르다. 볼륨이 0이라도 목적지에 연결되어 있으면 브라우저는 그래프를 실제로 처리하며, 게다가 멈출 수 있는 미디어 요소가 없으니 탭의 음소거 버튼이 아무 힘을 쓰지 못한다. 페이지 입장에서 이것은 엄연히 '실시간 오디오 처리'이고, 필자의 환경에서는 그 처리가 PC 쪽 블루투스 오디오 경로를 계속 살려 두어 멀티포인트 헤드폰이 폰으로 깔끔하게 전환되는 것을 막은 것으로 보인다. 오디오 지문 채취는 브라우저 버전, 운영체제, 오디오 라이브러리, 하드웨어의 미세한 차이가 같은 신호에서 조금씩 다른 결과를 내놓는다는 성질을 이용한다. 그 자체만으로 기기를 유일하게 식별하지는 못해도, 캔버스·WebGL·하드웨어·타이밍·상호작용 데이터와 결합하면 훨씬 강력해진다.
안티프래드라는 명분과 실제 부작용
실제로 두 번들에는 오디오 외에도 여러 값을 조회·측정하는 코드, 그리고 결과를 직렬화·암호화해 fetch()나 sendBeacon()으로 알리바바 텔레메트리 서버에 전송하는 코드가 들어 있었다. 상당히 포괄적인 기기 지문인 셈이다. 알리익스프레스가 이런 데이터를 수집할 동기는 분명하다. 계정 탈취, 가짜 계정, 스크래핑, 자동 구매, 결제 사기, 리뷰 조작, 신규 고객 쿠폰 남용 같은 위협을 정상 쇼핑객과 구분해야 하기 때문이다. 쿠키는 지우거나 복제·교체할 수 있어 신뢰도가 낮지만, 여러 독립적인 브라우저 측정값으로 만든 지문은 일관되게 조작하기가 훨씬 어렵다. 상호작용 데이터로 사람인지 자동화인지 판별하면 신뢰 고객에게는 캡차를 덜 띄우는 이점도 있다.
다만 이 구현에는 현실적인 문제가 있다. 로그인이나 결제 같은 민감한 행동을 하기도 전에 일반 쇼핑 홈페이지에서 그래픽·오디오·WebRTC·하드웨어·모션 API를 광범위하게 건드리고, 그 과정이 의도적으로 들여다보기 어렵게 난독화되어 있으며, 실시간 오디오 그래프가 시작됐다는 어떤 시각적 표시도 없다. 게다가 무음 지문 테스트가 외부 하드웨어의 동작 방식까지 바꿔 버리는 실제 부작용을 냈다는 점이 뼈아프다. 필자는 서버가 이 지문을 얼마나 오래 저장하는지, 다른 알리바바 서비스와 신원을 연결하는지까지는 브라우저에서 증명할 수 없다고 선을 긋는다. 클라이언트 코드가 보여 주는 것은 방대한 지문성 측정값이 수집·전송된다는 사실까지다.
실무자를 위한 차단법과 유의점
대응은 의외로 단순하다. 필자는 uBlock Origin의 'My filters'에 collina.js와 fireyejs.js를 아래처럼 알리익스프레스 도메인에서만 차단하는 규칙 두 개를 추가했다. ||assets.aliexpress-media.com/g/AWSC/uab//collina.js$script,domain=aliexpress.com 와 ||assets.aliexpress-media.com/g/AWSC/fireyejs//fireyejs.js$script,domain=aliexpress.com 형태다. 두 요청을 막자 홈페이지는 정상 렌더링되면서 대조 캡처에서 AudioContext나 목적지 연결이 전혀 나타나지 않았다. 단, 스크립트를 막아도 이미 생성된 오디오 컨텍스트는 종료되지 않으므로 기존 알리익스프레스 탭을 모두 닫고 다시 열어야 한다.
이 규칙들은 관찰된 두 스크립트 계열만, 그것도 알리익스프레스가 요청할 때만 막도록 일부러 좁게 짰다는 점을 이해할 필요가 있다. 향후 스크립트 경로나 이름이 바뀌면 무력화될 수 있고, 이들이 안티프래드 시스템과 얽혀 있는 만큼 차단이 로그인·결제 과정에서 추가 캡차나 오류를 유발할 가능성도 있다. 필자 역시 홈페이지와 일반 상품 탐색은 문제없었지만 정당한 로그인이나 결제가 거부되면 규칙을 임시로 꺼 두겠다고 했다. 결국 이 사례가 남기는 교훈은 명확하다. 숨은 분석·보안 기능이 오디오 경로를 사용자보다 강하게 점유해 외부 하드웨어의 동작까지 바꿀 정도라면, 편의성과 투명성 사이의 균형이 어디서 무너졌는지 다시 물어야 한다는 것이다. 안티프래드의 필요성은 이해하더라도, 사용자가 인지하지도 통제하지도 못하는 무음 오디오 처리가 그 대가여서는 곤란하다.