텔레메트리는 진짜 도움이 됨. 끄는 건 당신 자유지만

텔레메트리는 진짜 도움이 됨. 끄는 건 당신 자유지만

• Firefox 보안 엔지니어가 "텔레메트리 무용론"에 반박하는 글을 씀. 결론부터 말하면: 텔레메트리 끄는 건 당신의 권리고 존중하지만, "쓸모없다"는 주장은 사실이 아님

텔레메트리가 뭐고 뭐가 아닌지

• 저자가 정의하는 텔레메트리는 "퍼블리셔에게 보내고 직접적인 대가를 받지 않는 데이터"임. 소프트웨어 업데이트 핑이나 Remote Settings(비밀번호 자동완성 오버라이드, 인증서 블록리스트 같은 것) 같은 건 사용자에게 직접 이득이 돌아가는 거라 텔레메트리로 안 봄
• Firefox 텔레메트리 수집 방식도 꽤 다양함: 일반 텔레메트리는 IP를 즉시 폐기, OHTTP는 IP 자체를 안 봄, Prio는 프라이버시 보존 연산 방식. 저장도 자동 삭제 + 분리 저장이라 "최악"은 아니라는 거임
• "제품 의사결정용 텔레메트리(버튼 클릭 수 같은 거)"는 이 글의 범위 밖. 저자가 다루는 건 기술적 텔레메트리 — 크래시, 행, 보안 변경의 안전성 검증, 최적 구현체 선택 같은 것들

텔레메트리로 실제 해결한 문제들 (저자 본인 사례만)

• 부모 프로세스에서 eval 제거 (1473549): 테스트 스위트 전부 통과, 내부 독포딩 몇 주 해도 멀쩡했는데 Nightly에 배포하자마자 폭발함. 원인은 userChromeJS 같은 커스텀 스크립트를 쓰는 사용자들이었는데, 텔레메트리가 없었으면 이 커뮤니티의 존재 자체를 몰랐을 거임. 텔레메트리 덕에 해당 커뮤니티에 직접 찾아가서 대화하고 호환성 작업을 할 수 있었음
• Background Hang Reporter (BHR): 프리릴리즈 채널에서 행(hang) 발생 시 스택을 수집하는 시스템. 저자 본인이 작성한 코드에서 행이 발생하는 걸 BHR 데이터로 발견 — 아무 이유도 안 보이고 절대 추측 못했을 문제였음. 리팩토링 후 행 그래프가 떨어짐
• Fission(사이트 격리) + 데이터 최소화: 콘텐츠 프로세스에서 프린터 이름, 디바이스 이름 같은 개인 식별 정보를 제거하는 작업. Spectre 공격으로 이런 정보가 새는 걸 막기 위해서였고, 텔레메트리로 사용자 워크플로우가 안 깨지는 걸 확인함
• jar: URI 웹 노출 제거: 보안 모델이 영 좋지 않았는데, 텔레메트리로 실제 웹 사용량이 거의 0이라는 걸 증명해서 공격 면적을 깔끔하게 제거
• XSLT 제거 추진 중: Chrome이 먼저 밀고 있고 Firefox도 동참하는 분위기. 사용량 텔레메트리가 "이 기능 웹에서 빼도 됨"을 정당화하는 유일한 근거
• 캔버스 노이즈 생성 최적 구현체 선택: 안티핑거프린팅용인데, SHA 확장이 있으면 SHA-256이 빠르고 없으면 SipHash가 빠름(입력이 ~2.5KB 미만일 때도 SipHash). 수십억 번 호출되는 거라 이 차이가 중요함
• 폰트 허용 목록: 폰트가 거대한 핑거프린팅 벡터인데, Firefox는 로컬 설치된 희귀 폰트를 웹에서 안 쓰게 해서 엔트로피를 대폭 줄임. Android용 폰트 허용 목록은 아마 Firefox만 있을 거라는 거임

"텔레메트리 없는 브라우저" 쓴다는 분들에게

• 모든 메이저 브라우저는 텔레메트리를 직접 구현하거나 업스트림 엔진에 위임해서 그 혜택을 받음. Brave도 텔레메트리를 함 — P3A라는 이름으로 버킷/히스토그램 + 셔플링/임계값 방식을 쓰고, 이건 꽤 괜찮은 접근법
• "텔레메트리 꺼놓음"을 자랑하는 Foo 브라우저들은 전부 업스트림(Firefox든 Chrome이든)의 텔레메트리 덕에 개선된 코드를 가져다 쓰면서 도덕적 우위를 점하려는 거라는 지적
• 저자의 결론: 텔레메트리는 철학적으로 나쁜 게 아님, 구현이 나쁠 수 있는 거임. 수집 범위, 프라이버시 속성, opt-in/opt-out 여부는 토론할 수 있지만, "텔레메트리 자체가 감시"라는 전제에서 시작하면 대화가 안 됨