브라우저 핑거프린팅(Browser Fingerprinting)이란?

통합적인 관점에 기반한 온프레미스 데이터 플랫폼 구조 비교분석

 

디바이스 핑거프린팅(Device Fingerprinting)이란 식별(Identification)을 위해 수집된 원격의 컴퓨팅 기기의 하드웨어 및 소프트웨어 정보를 말합니다 [1]. 브라우저 핑거프린팅은 브라우저를 통해서 이뤄지는 디바이스 핑거프린팅을 말합니다.

 

기본적으로 Persistent 쿠키를 읽을 수 없거나 클라이언트 ip가 숨겨져 있거나, 또는 한 기기에서 다른 브라우저를 사용하여 접근하는 경우 등에 사용자 식별을 위해 디바이스 핑거프린팅이 사용됩니다. 그리고 ID 위조 또는 신용카드 사용을 막는 등 좋은 목적으로도 사용되나 마케팅 개인화를 위해 사용자의 프라이버시를 넘나들며 데이터를 수집하는 것과 같이 회색지대에도 사용되기도 합니다. 또한, 웹 애플리케이션에 기반한 기업의 데이터 분야에서는 업무 진행 시에 직접 구축하거나, Google Analytics, SementIO, 또는 Amplitude 등 다양한 마케팅 도구나 이벤트 트래커를 통해 Clickstream 데이터를 수집하고 마주합니다. 

 

반대급부로 대다수의 브라우저들에서는 사용자에게 좀 더 private한 환경을 제공하기 위해 이러한 fingerprinting을 설정을 통해 정도를 조절하거나 막을 수 있는 방향으로 구현해나가고 있습니다.

 

이 글에서는 간단한 웹 브라우저의 발전사와 디바이스 핑거프린팅의 주를 이루는 웹 브라우저 핑거프린팅에 국한해, 현재 시점에서 어떠한 브라우저 핑거프린팅 기법들이 존재하고, 어떠한 방어기법들이 존재하는지 살펴보겠습니다.

 

웹 브라우저 발전사

이 장에서는 웹 브라우저의 HTML 렌더링이 어떻게 변해왔는지를 중점으로 알아봅니다 [4].

 

User-agent header를 통한 브라우저 제약 표기

웹의 초기 개발의 철학은 누구나 웹에 접근할 수 있도록 device-agnostic하여 어떠한 구조를 가진 기기에도 실행될 수 있도록 하는 것이었습니다. 90년대 초, HTTP와 HTML이 그러한 기기 간의 통신을 위해 탄생하였고 그 부분을 지원하기 위해 여러 팀에서 고안된 웹 브라우저는 곧 stadard가 되었습니다. 그러나, 온라인에서 가능한 것의 한계를 넓히며 웹의 기반은 점점 진화했기에 모든 브라우저와 플랫폼이 최신의 기능을 제공하지는 못했습니다. 

 

몇몇의 브라우저는 오직 specification의 부분만을 따랐고 각각의 고유한 기능들을 개발했습니다. 이러한 방향성이 악명 높은 "X에서 가장 잘 지원됩니다"의 시대를 열었습니다. 

 

이러한 호환성 문제를 해결하기 위해서, HTTP 프로토콜은 "User-Agent request header"를 포함하였습니다. 브라우저는 브라우저 이름과 버젼을 표기하기 시작했으며 때로는 특정 user agent 제약을 피하기 위해서 플랫폼에 대한 내용도 포함하였습니다. user agent header의 역사는 매우 길며 모던 브라우저가 맨 처음 브라우저들의 레거시를 가지고 있기에 오늘날까지도 계속 사용되고 있습니다. 이 헤더 안에 들어있는 정보는 다양한 브라우저 벤더들이 해당 브라우저의 다른 렌더링 엔진과의 호환성 표시를 위해 경쟁사의 값을 복사하기 시작하면서 더욱 복잡해졌습니다. 예로, 리눅스에서 실행되는 크롬 브라우저 68버젼의 user-agent는 다음과 같습니다.

 

Mozilla /5.0 (X11; Linux x86_64 ) AppleWebKit /537.36 (KHTML , like Gecko )
Chrome /68.0.3440.75 Safari /537.36

위에서 유의미한 정보는 오직 "(X11; Linux x86_64)"와 "Chrome/68.0.3440.75"입니다. "Gecko", "KHTML" 또는 "Safari" 등은 다른 레이아웃 엔진과의 호환성 표기를 위해 존재합니다. 

 

 결국 이러한 user-agent header는 개발자가 브라우저 제약을 확인하는 데에 도움을 주기 위해 기기 간 차이를 명시한 정보로 가장 처음 확인할 수 있는 요소가 됩니다.

 

웹 브라우저와 native 애플리케이션 간 격차 해소

웹 초기에 Live 변경을 위해 페이지는 다시 로드되어야만 했습니다. 1995년 Brendan Eich가 JavaScript라는 언어를 Netscape Navigator 브라우저에 넣어 웹 페이지가 좀 더 다이내믹해지도록 하였습니다. 그 이후로, JavaScript는 주목을 받으며 다양한 브라우저에 포함되기 시작하였습니다. 1997년 6월 "ECMAScript"라는 이름으로 해당 언어에 대한 Specification이 정식공표가 되었습니다.

 

 언어가 성장하면서 브라우저는 사용자에게 점점 더 다양한 기능을 제공하였고, 개발자들은 브라우저와 해당 플랫폼을 연결하는 방향으로 개발을 진행하게 되었습니다. 그러한 방향의 최종 목적은 사용자 환경의 다양한 정보들을 결합해 브라우저가 좀 더 native 애플리케이션처럼 느껴지도록 하는 것이었습니다. 그 시초는 ECMAScript의 첫 에디션에서 사용자 운영체제의 기기 timezone에 접근해 그러한 정보를 "Date" 객체에 반영하는 것이었습니다. 

 

모던 API의 발전

모던 브라우저는 단순하게 HTML을 보여주는 도구에서 다양한 포맷과 기기와 호환가능한 멀티미디어 플랫폼으로 변모해왔습니다. 핑거프린팅 기법과 관련이 깊은 많은 API들이 사용자에게 좀 더 풍부한 경험을 제공하고 모바일 브라우징 환경을 지원하기 위해 W3C를 통해 web standard로 개발되었습니다.

 

Canvas API는 캔버스 surface에 그래픽을 그리거나 조작할 수 있도록 객체, 함수, 프로퍼티를 제공합니다. WebGL은 그래픽 API로 브라우저에서 3D 객체를 다른 플러그인 없이 JavaScript를 통해 조작할 수 있게 합니다. 또한, Web Audio API는 오디오 처리를 위한 기능을 제공합니다. 

 

이 외에도 실시간 커뮤니케이션을 위한 WebRTC, 실시간 포지셔닝을 위한 Geolocation, 브라우저 성능 개선을 위한 WebAssembly, 웹 기능 향상을 위해 (검토중인) WebPayments나 WebXR 등의 API가 존재합니다. 

 

브라우저 핑거프린팅 기법들

대부분의 브라우저 핑거프린팅 기법은 1990년대 말에 도입된 클라이언트 사이드 스크립팅 언어에 기반하지만, 본격적으로 연구되기 시작한 것은 2009년의 Mayer의 연구 이후입니다. 그리고 "브라우저 핑거프린팅"이라는 학술적인 용어를 얻을 정도의 대규모의 실험이 진행된 것은 2010년의 Panopticlick 실험이라고 할 수 있습니다.

 

브라우저 안에서 실행되는 간단한 스크립트를 통해서, 서버는 API와 HTTP Headers를 통해 다양한 정보를 수집할 수 있습니다. API는 특정 객체나 함수에 대한 접근을 제공하는 인터페이스로 마이크와 카메라 등 접근 시와 같이 Permission을 요구하는 API가 있는 반면, 대부분은 Javascript 스크립트를 통해 자유롭게 접근가능합니다 [4]. 

 

ID에 의존하는 쿠키와는 다르게 브라우저 핑거프린팅은 stateless를 특징으로 합니다. 

Example of a browser fingerprint - Image from [4]

 

각 속성별로 Entropy는 다음과 같습니다:

 

Browser attributes and their entropy - Image from [4]

Canvas(and WebGL) Fingerprinting

캔버스 핑거프린팅은 브라우저 핑거프린팅 기법의 하나로 2012년 Mowery and Shacham의 paper에서 처음 알려졌습니다 [3]. 저자는 브라우저의 캔버스 API를 통해 동일한 텍스트나 WebGL Scene을 렌더링하여 일정한 핑거프린트를 얻어낼 수 있고 그것은 사용자가 인식하지 못하는 순간이내에 실행될 수 있음을 발견하였습니다. 

 

동일한 텍스트는 운영체제, 폰트 라이브러리, 그래픽카드, 그래픽 드라이버, 그리고 브라우저에 의해 다른 컴퓨터에서는 다르게 렌더링될 수 있습니다. 렌더링의 차이는 anti-aliasing과 같은 폰트 rasterization 차이, hinting 또는 sub-pixel smoothing, 시스템 폰트의 차이, API 구현 차이, 심지어 물리적 디스플레이로 인하여 발생할 수 있습니다. 식별하려고 하는 자는 최대한 다양한 글자를 적어서 결과를 다양하게 만들어 더욱 잘 식별할 수 있습니다. 

13 ways to render 20px Arial - Image from [3]

 

캔버스 핑거프린팅의 엔트로피는 광범위하게 조사된 적은 없으나 [3]에 의하면 5.73 bits of entropy고, 실험이 제한되었다는 점을 고려해 10 bits of entropy로 가정해도 1000명 중 1명이 같은 핑거프린트를 공유한다는 점을 발견하였습니다.

 

아래 이미지는 캔버스 핑거프린팅의 기본적인 흐름을 보여줍니다. 사용자가 페이지를 방문하면, 핑거프린팅 스크립트는 설정된 폰트와 사이즈의 텍스트를 그리고 배경색을 더합니다 (1). 그리고 스크립트는 Canvas API의 ToDataURL 함수를 실행하여 dataURL의 캔버스 픽셀 데이터(바이너리 픽셀 데이터의 Base64 인코딩 값)를 얻습니다. 마지막으로, 스크립트는 인코딩된 텍스트 픽셀 데이터에 hash를 취하여 추후 사용을 위해 송신하여 저장합니다. 

Canvas Fingerprinting basic flow of operations - Image from [2]

이러한 hash 값은 high-entropy 브라우저 특징인 플러그인 리스트, 폰트 리스트, 또는 유저에이전트 값과 합쳐져 유용한 식별자로 사용될 수 있습니다.

 

사용되는 대부분의 스크립트는 유사한 형태를 가지며 그러한 핑거프린팅 라이브러리를 오픈소스화(fingerprintjs)하기도 하였습니다 [2].

 

WebGL은 Canvas과 유사한 형태로 3D surface를 통해 핑거프린트가 가능합니다. 

 

AudioContext

Web Audio API는 오디오 처리 파이프라인을 생성하는 인터페이스를 제공합니다. 오디오 모듈을 연결해서 누구나 오디오 시그널을 발생시키고 특정 출력을 얻기 위해 압축이나 필터링과 같은 특징적인 operation을 적용할 수 있습니다. 오디오 시그널을 처리하는 스크립트는 캔버스 핑거프린팅과 유사하게 환경의 소프트웨어나 하드웨어로 인해 기기마다 특징적인 차이를 보이기에 핑거프린팅에 사용될 수 있습니다. 비교적 사용하는 웹사이트 수가 매우 적은 기법입니다.

 

Browser Extensions

모던 브라우저는 초기부터 사용자 커스텀화를 제공하였는데 그중 한 가지 방식이 브라우저 익스텐션입니다. 적은 사이즈의 직접 만든 add-ons을 추가하거나, 많이 사용되는 ad blockers 등이 그 예입니다. API가 지원되지 않아 모든 브라우저 익스텐션의 리스트를 추출하는 것은 어렵지만 add-ons이 브라우저에 결합한 방식에 따라 몇몇은 쉽게 접근할 수 있습니다.

 

Sjösten에 따르면, 특정 URL에 접근하여서 익스텐션이 설치되어있는지 아닌지 파악이 가능하다고 합니다. 예로, 익스텐션의 로고를 display하기 위해서 브라우저는 로고에 기기 어디에 저장되어 있는지 알아야 하고 그것은 "extension://<extensionID>/<pathToFile>"과 같은 형태로 접근에 fetch 합니다. 그러나 이러한 리소스는 아무 웹 페이지 컨택스트 상에서 접근가능하기 때문에 이러한 메커니즘은 특정 익스텐션 설치여부를 파악하기 위한 스크립트에 악용될 수 있습니다. 

 

익스텐션 관련 두 번째 연구로는 설치된 특정 익스텐션이 실행을 위해 DOM을 특정 방식으로 변경하는데, 스크립트가 그러한 DOM 변경 방식을 통해 어떤 익스텐션이 설치됬는지 알 수 있다는 부분에 관한 연구입니다. 

 

세 번째 연구는 timing side channel attack을 사용한 연구로, 가짜와 존재하는 익스텐션에 대해 쿼리를 실행하여 요청 간의 시간차를 측정하는 방식입니다. 이러한 방식을 사용해, 어떤 브라우저 익스텐션이든지 detect할 수 있다고 합니다.

 

마지막 연구는 오류가 존재하는 애플리케이션 로직으로 인해 익스텐션의 존재를 들키는(?) 부분을 통한 연구(extension's bloat)입니다. 이러한 것들은 빈 placeholder injection, script나 style tags injection 또는 페이지에 message 송신 등을 사용합니다. 구글 크롬스토어의 58,034개의 익스텐션 중 5.7%가 이러한 bloat이 있었고, 그 중 61%가 uniquely identified라고 합니다.

 

 

JavaScript Standards Conformance

Muzanni는 브라우저가 기반한 JavaScript 엔진을 통해 안정적으로 identify할 수 있는 방법을 보였습니다. JavaScript standard로 컴파일 될 수 있는지 그리고 어떠한 기능이 지원되는지를 분석하고 테스트하였습니다. 그러한 테스트를 통해 각 조합을 unique하게 identify할 수 있는 최소한의 케이스를 찾아내었고, 그러한 케이스를 통해 브라우저의 JavaScript 엔진이 한 단계의 버젼 차이만 있어도 구분할 수 있었습니다. 

 

 추가적으로 유사한 방향성의 연구가 navigator와 screen 객체의 mutability 분석이나 OS나 architecture 레벨의 정보를 통해 이루어졌습니다.

 

CSS Querying, Font metrics

Unger은 특정 브라우저에서 unique한 CSS properties를 테스트하였고, 특정 브라우저에서 발견되는 CSS properties prefix를 통해 쉽게 브라우저 계통을 알아낼 수 있었습니다. 

 

또한, character의 모양새도 브라우저나 기기에 따라서 다른 bouding boxes로 렌더링된다는 사실에 착안해 핑거프린팅에 이용될 수 있습니다. 

 

Benchmarking

기기의 정보에 접근하는 다른 방법 중 하나는 기기의 CPU와 GPU capabilities를 벤치마크하는 것입니다. JavaScript을 통해서, 스크립트는 연속된 어떤 task를 실행하고 완료되는 시간을 측정합니다. 그러나, 벤치마킹을 사용할 때 가장 어려운 부분은 차이와 변동성을 정확하게 해석하는 부분입니다. 순간적인 리소스 사용량에 따라서도 똑같은 기기에서 벤치마킹에 큰 차이가 발생하는 결과가 나올 수 있기 때문입니다. 

 

Battery Status

"Battery Status" Specification은 "hosting 기기의 배터리 상태에 대한 정보를 제공하는 API"입니다. 해당 API는 기기에 충전 중인지 아닌지 report하는 BatteryManager 인터페이스로 구성되어 있습니다. 또한, 그것은 충전량과 충전시간과 같은 정보도 포함합니다. 이러한 API를 제공하는 배경에는 웹 개발자가 power-efficient한 앱을 만드는데에 도움이 되기 위한 의도였습니다.

 

그러나 그러한 의도와는 달리 Battery API는 매우 오남용될 수 있었습니다. 충전량은 단기 identifier로 사용될 수 있으며 반복된 접근을 통해 배터리 용량도 파악을 가능하게 하였습니다. 이러한 이슈를 처리하기 위해, 많은 브라우저 벤더들은 이 API를 제거하거나 정보를 은닉하는 방법을 취하고 있습니다.

 

 

핑거프린팅 방어 기법들

핑거프린팅 방어의 목적은 원하지 않는 트래킹을 막으면서 사용자의 privacy를 높이는 것입니다. 그러나 완벽한 접근 방법이 존재한다기보다는 대부분은 모던 웹 브라우저의 기능을 제한하는 것과 privacy를 높이는 것 사이의 균형을 맞추는 것에 가깝습니다. 

 

Summary of existing defense solutions - Image from [4].&nbsp;M = Modifying the fingerprint content. M* = Modifying the fingerprint content by switching browsers. U = Universal fingerprint. BS = Blocking Scripts. BA = Blocking APIs or Access.

 

Increasing device diversity

핑거프린트 컨텐츠 변경

브라우저 핑거프린트를 막기 위한 첫 번째 방법은 기기의 다양성을 높여서 실제 핑거프린트 결과를 노이즈를 통해 숨기는 것입니다. 이 방법의 기반에는 써드파티가 핑거프린트를 하나의 기기로 매핑하기 위해 '핑거프린트 안정성(stability)'에 기반한다는 사실에 있습니다. 실제값말고, 랜덤화되거나 사전에 설정한 값으로 보내어 수집된 핑거프린트가 다르고 일정하지 않아 웹 상에서 식별이 불가능하게 만듭니다.

 

The inconsistency problem

이 방법은 연구 환경에서는 비교적 강력한 방법이나 실제 환경에서는 조금 그 결과가 다릅니다(Paradox of Fingerprintable Privacy Enhancing Technologies). 사용자의 privacy를 강화하는 방법 대신 특정 도구들은 핑거프린트를 좀 더 분별력있게 렌더링하여 핑거프린팅을 쉽게 만듭니다. 크롬과 파이어폭스에 존재하는 확장판인 실제 스크립트에 수집되는 값을 변경하는 spoofer와 switcher들이 그러한 것들입니다. 가장 유명한 것으로는 파이어폭스의 Random Agent Spoofer로 "complete browser profiles (from real browsers / devices) at a user defined time interval" 기능을 제공합니다. 

 

특정 값을 다른 값으로 변경하는 아이디어는 일견 적절해 보이나, 브라우저가 다양한 속성이 강하게 연결되 끊임없이 진화하기에 이러한 방법이 권장되지는 않습니다(OS 정보는 Linux인데 navigator.platform 특성은 Windows를 가르키는 등 속성 간의 작위적인 미스매치가 발생할 수 있음). 

 

Replacing the values of attributes

tracker가 사용하는 속성에 대하여 다양한 profile을 정의하고 보여주거나, 핑거프린팅 의도를 점수화하여 특정 점수를 넘으면 핑거프린팅 방어 코드가 실행되는 방식, 특정 속성값 변경에 대한 policy를 가지고 trigger되었을 때 그러한 정책을 적용하여 변경하는 방식, 각 소프트웨어 컴포넌트별로 서로 상응하는 속성값을 저장해두고 사용 시 랜덤으로 조합된 컴포넌트(OS, browser, plugins 등) 값을 제공하는 방식(위에서 언급된 문제점이 없어서 좀 더 안정적) 등이 존재합니다.

 

Attributes used in fingerprinting - Image from [5]

 

노이즈 주입

대부분은 string 형태의 값들이지만 Canvas 또는 AudioContext API와 같은 경우 좀 더 복잡한 데이터구조를 가집니다. 단순하게 특정 값을 사전 설정된 값으로 변경하는 것 대신에 이러한 API 처리 과정에 노이즈를 주입할 수도 있습니다. 노이즈가 주입되면 캔버스나 AudioContext 테스트 값이 실행 시마다 조금씩 달라집니다. 

 

스크립트가 속성값을 읽으려고 할 때 다른 값을 읽도록 하는 방식, Chromium이나 파이어폭스 소스 코드를 변경하여 관련 API를 변경하는 방식 등이 존재합니다.

 

핑거프린트 컨텐츠를 변경하는 방법의 도전과제

핑거프린트 값을 변경하여 diversity를 높일 수 있으나 특정 트래커에는 뚫리는 사례가 대부분입니다. 속성값은 브라우저를 오작동하게 할 정도로 변경이 불가능해서, 속성간의 미스매치는 사용자를 식별가능하게 만들 수도 있습니다. 이러한 핑거프린팅 방어를 위한 속성값 변경이 반드시 사용자를 더 식별가능하게 만드는 것은 아니지만, 모던 웹 브라우저는 지속적으로 진화하고 복잡하여 실제로는 언제나 그러한 방어기법들을 무력화할 수 있는 작은 부분들이 존재합니다. 

 

브라우저 변경

기기 핑거프린팅의 대부분이 특정 브라우저 정보로 구성되어 있기 때문에, 다른 2가지 브라우저를 사용해서 2가지 기기의 정보를 노출할 수 있습니다. 이 방법을 통해서 써드파티가 2가지 브라우저 프로파일을 받게 되어 트래킹을 어렵게 만들 수 있습니다. 

 

방법은 비교적 간단하나 여러 연구 결과를 보면 그 결과가 실제로 효력이 있는지 판단하기 어렵고, OS 또는 하드웨어 레이어의 정보를 통해 식별할 수 있는 써드파티도 존재합니다.

 

 

Homogeneous한 핑거프린트를 제출하기

다른 방어 기법의 한 가지는 웹 상의 모든 기기가 동일한 핑거프린트를 보이도록 하는 것입니다. 이것은 TBB(the Tor Browser Bundle)로 알려진 Tor Browser에서 선택한 방식으로 Tor network를 사용합니다. 

 

Tor Browser

이론

Tor network가 공격자가 클라이언트의 실제 ip를 찾아내는 것을 막는다고 해도, http request의 컨텐츠를 변경하지 않기에 만약 cookie ID나 브라우저 핑거프린트가 payload에 있다면 식별될 수 있습니다. 이것을 막기 위해서 Tor 브라우저는 특정 요구사항을 만족하고 있고 그 중 하나는 브라우저 핑거프린팅을 타겟으로 한 Cross-Origin Fingerprinting Unlinkability를 포함하는 것입니다. 랜덤화가 핑거프린팅을 막는 것에는 더 효과적이나 모든 Tor users가 하나의 핑거프린트를 사용하는 전략을 선택하였습니다. 

 

디자인 문서에는 Tor 브라우저에 24개의 다른 변형방법이 소개되고, 그 중 주요한 것은 Canvas와 WebGL API는 막는 것, plugins 제거, font enumeration을 막기 위한 디폴트 폰트 번들 포함하는 것 등이 존재합니다. 사용자가 Windows, Mac 또는 Linux를 사용하는 것과 관계없이 Tor 브라우저는 기기가 Windows라고 표시합니다.

 

실제

Tor 브라우저는 브라우저 핑거프린팅을 방어하기 위한 가장 강력한 방법 중 한 가지로 여겨지지만, 여러 결점을 가지고 있습니다. Tor 브라우저가 사용하는 핑거프린트는 매우 잘 알려져 있습니다. User-agent, screen resolution 그리고 알려진 Tor exit의 IP 주소는 다른 브라우저와 Tor 브라우저를 식별하는데 충분한 정보입니다. 개인식별과는 관련이 없지만 브라우징 경험에는 많은 영향을 줍니다. 실제로 한 연구에 따르면 Alexa의 top  1,000 사이트 중 3.67%는 아예 Tor 사용자를 막거나 제한된 서비스를 제공합니다.

 

Tor 브라우저의 두 번째 문제점은 screen resolution과 같은 경우 브라우저 간에 차이가 있을 수 있는 부분입니다. 초장기 Tor 브라우저에서 사용자가 window 크기를 바꾸려고 하면, 식별이 가능해질 수 있다는 경고문구가 발생하였습니다. 이와 같이, 사용자가 일반적이지 않은 screen resolution을 가지면 식별이 가능하게 될 수 있습니다.

 

세 번째 문제는 OS 레벨의 정보를 통해 식별이 가능해질 수 있는 부분인데, 이 부분은 문서 상에서도 "최대한 제거하려 노력했으나, OS 레벨 방어는 우선사항은 아니다"라고 표시되고 있습니다. 

 

마지막으로는, 디폴트 상에서 Tor 브라우저는 다양한 사용자와 동일한 핑거프린트를 가지기에 안전하나 일부 custom으로 인해 조금이라도 식별가능한 속성이 들어나면 눈에 띄게 식별가능해진다는 부분입니다.

 

 

UniGL

WebGL API가 복잡한 3D scenes을 생성 시, 기기 마다 차이를 보이는 이유는, 연구결과 시스템의 graphics 레이어에서 floating-point 연산의 차이로 인한 것이었습니다. 이 연구자들은 3D 렌더링이 일정하도록, UniGL이라는 소프트웨어를 만들었는데, 이것이 GLSL 프로그램으로 작성된 floating operations을 명시적 또는 암시적으로 재정의하는 기능을 하도록 했습니다. 그렇게 특정 렌더링 task에 같은 WebGL 핑거프린트를 보여주도록 하였습니다. 

 

 

Decreasing the surface of browser APIs

마지막 방법은 브라우저 API 접촉면을 낮추어 트래킹 스크립트가 수집할 수 있는 정보의 양을 줄이는 방법입니다. 한 가지 방법은 플러그인을 disable해서 Flash 또는 Silverlight와 같은 추가적인 핑거프린트 벡터가 존재하지 않도록 하는 것입니다. 

 

다른 방법으로는 Javascript 실행 자체를 막는 법, ad blocker(Adblock Plus, Ghostery, uBlock Origin, Disconnect)를 사용하는 법, 특정 API 사용을 못하도록 브라우저 기능을 disable하는 법 등이 존재합니다. 그러나, 역시 이런 방법은 브라우저의 기능을 제한할 수 있습니다. 

 

 

Reference

[1] https://en.wikipedia.org/wiki/Device_fingerprint

[2] www.ftc.gov/system/files/documents/public_comments/2015/10/00064-98109.pdf

[3] Pixel Perfect: Fingerprinting Canvas in HTML5

[4] Browser Fingerprinting: A survey

[5] FP-Block : usable web privacy by controlling browser fingerprinting

[6] www.w3.org/TR/fingerprinting-guidance/

[7] www.scss.tcd.ie/Doug.Leith/pubs/browser_privacy.pdf

 

 

(FASTCAMPUS) 패스트캠퍼스 온라인 'THE RED: 데이터사이언티스트 하용호' 후기 - 강의내용요약 #1