핑거프린트 브라우저 파라미터를 무작위로 바꿔야 할까? '무작위로 갈수록' 문제가 커지는 이유

"모든 환경의 파라미터를 무작위로 설정해 두면 가장 안전할 거라고 생각했는데, 계정이 며칠을 버티지 못했습니다." 다계정을 운영하는 사람이라면 이런 이야기를 한 번쯤 들어봤을 것입니다. 직관적으로는 파라미터가 매번 바뀌면 플랫폼이 알아보지 못할 것 같습니다. 하지만 실제 결과는 반대인 경우가 많습니다. 무작위로 갈수록 계정은 더 빨리 상합니다.

방향은 처음부터 반대였습니다. 플랫폼이 보는 것은 "바뀌었는가"가 아닙니다. "실제 기기처럼 보이는가"입니다. 실제 기기의 가장 큰 특징은 오히려 안정적이라는 점입니다.

결론을 먼저 말하면 파라미터를 일부러 무작위로 만들 필요는 없습니다. 하나의 환경이 믿을 만한지는 세 가지로 결정됩니다. 각 파라미터가 실제 값인가, 수십 개 파라미터가 서로를 설명할 수 있는가, 같은 계정의 파라미터가 시간 대조를 견디는가입니다. 무작위화가 건드리는 것은 첫 번째이고, 부수는 것은 나머지 둘입니다. 아래에서는 먼저 "독립"과 "무작위"가 각각 무엇을 맡는지 나누고, 다음으로 핑거프린트 파라미터를 하나씩 펼쳐 본 뒤, 무작위화가 어디를 부수는지 살펴봅니다.

독립된 환경과 무작위 파라미터는 같은 것인가?

가장 흔한 오해부터 풀어 둡니다. 갓 시작한 사람은 모든 환경이 독립적이니 파라미터도 무작위여야 한다, 그러지 않으면 환경끼리 같아진다고 생각하기 쉽습니다.

환경의 독립이 맡는 것은 경계입니다. 두 환경은 로그인 상태도 사이트 데이터도 공유하지 않으며, A 환경의 작업이 B 환경으로 넘어가지도 않습니다. 이것은 격리 기술이 하는 일이고, 파라미터가 어떤 값을 갖는지와는 관계가 없습니다. 파라미터의 무작위화가 맡는 것은 값의 결정입니다. 각 환경이 어떤 기기로 읽힐지를 정합니다.

두 요소의 역할 분담은 한마디로 갈립니다. 계정 사이에는 경계가 필요하고, 한 계정 안에는 연속성이 필요합니다. 경계는 격리가 받치고 연속성은 안정이 받칩니다. 무작위화는 바로 경계의 요구를 연속성에 잘못 적용한 것이고, 계정 안에서 원래 안정적이어야 할 것을 매번 뒤집습니다.

핑거프린트 파라미터에는 무엇이 있고 사이트는 어떻게 읽는가?

브라우저가 외부에 드러내는 핑거프린트 파라미터는 흔히 거론되는 것만 스무 개를 넘습니다. 전부 외울 필요는 없습니다. "사이트가 어떻게 가져가는가"로 두 종류로 나누면 그림이 잡힙니다. 첫째는 브라우저가 스스로 보고하는 항목이고, 사이트가 요청을 보내면 읽을 수 있습니다.

둘째 종류의 파라미터는 사이트가 묻지 않고 현장에서 직접 측정합니다. Canvas와 WebGL이 가장 전형적입니다. 브라우저에 그림을 한 장 그리게 하고 3차원 장면을 렌더링시키면, 그래픽카드와 드라이버에 따라 결과에 미세한 차이가 납니다. 사이트는 그 결과로 브라우저가 자기 보고한 신원을 거꾸로 대조합니다.

그래서 자기 보고 파라미터는 사이트가 그대로 받아들일 수밖에 없습니다. 실측 결과는 현장에서 만들어지는 값이라 바꿀 수 없고 위조할 수밖에 없습니다. 여기가 무작위화의 균열이 시작되는 지점입니다.

무작위 파라미터는 왜 문제를 일으키기 쉬운가?

무작위화 플러그인은 이 두 종류에 각각 다른 구멍을 냅니다.

먼저 자기 보고형을 봅니다. User-Agent, 해상도, 폰트를 각각 무작위로 뽑으면 나온 값은 실재하는 한 대의 기계로 조립되지 않는 경우가 대부분입니다. Windows의 폰트 목록에 macOS의 자기소개가 붙고, 화면 해상도는 스마트폰 크기를 뽑았는데 자기 보고 신원은 데스크톱 그대로입니다. 플랫폼의 리스크 판정 모델은 방대한 실기기 기록을 봐 왔고, 이렇게 어긋난 조합은 한눈에 걸러냅니다.

더 눈에 띄지 않는 수법도 있습니다. 무작위화 플러그인이 수고를 덜려고 모든 사용자의 특정 항목을 같은 다수파 값으로 바꾸는 것입니다. 쓰는 사람이 늘수록 전혀 관계없는 계정 무리가 같은 특징값을 걸고 네트워크를 돌아다닙니다. 플랫폼은 하나씩 식별할 필요 없이 그 값 하나만 인정하면 됩니다.

다음으로 실측형을 봅니다. 잡음을 더하는 유형의 플러그인은 Canvas 같은 읽기에서 매번 조금씩 다른 결과를 돌려줍니다. 같은 그림인데 오늘은 이 값, 내일은 다른 값입니다. 실제 기기는 그렇지 않습니다. 같은 한 대의 읽기는 정상적인 사용에서 꿈쩍하지 않고, 두 번의 읽기가 어긋나는 것 자체가 이상 신호입니다.

플랫폼은 실제 기기가 변하는 리듬도 봐 왔습니다. 브라우저 메이저 업데이트나 운영체제 재설치는 1년에 몇 번뿐이고, 게다가 네트워크 전체가 동시에 겪습니다. 무작위한 변화에는 그런 리듬이 없습니다. 접속할 때마다 일어날 수 있습니다. 변하는 것은 당신뿐입니다.

무작위화가 바꾸는 것은 파라미터의 값이고, "실제 기기처럼 보이는가"라는 판단은 바꾸지 못합니다.

핑거프린트를 볼 때 왜 점수만 봐서는 안 되는가?

많은 사람이 무작위에 갖는 확신은 점수 도구에서 옵니다. 파라미터를 바꾸고 측정해 90점, 100점이 나오면 안심하고 실전에 올립니다. 여기에 걸리기 쉬운 빈틈이 있습니다. 점수 도구가 재는 것은 단일 항목이고, 플랫폼이 보는 것은 관계입니다.

단일 항목 점수가 높다는 것은 그 항목 자체의 품질이 좋다는 뜻일 뿐입니다. IP가 깨끗하고 파라미터도 흔하며 뚜렷한 누출도 없습니다. 그러나 플랫폼이 연관성을 판단할 때는 수십 개 항목이 서로를 설명할 수 있는지를 봅니다. 운영체제의 말과 그래픽카드의 말이 어긋나고, 언어의 말과 IP의 말이 어긋납니다. 어느 한 곳만 어긋나도 플랫폼이 한 번 더 들여다볼 이유가 됩니다.

이 "파라미터 상호 증명"은 관계를 읽는 판단이라 점수 도구로는 잴 수 없습니다. 만점 환경의 위험은 바로 여기에 있습니다. 항목마다 깨끗한데 조립하면 존재하지 않는 기기가 되기도 합니다.

점수는 상호 증명을 보장하지 않습니다. 잘못된 안심만 줄 뿐입니다.

그래서 환경을 점검할 때는 점수보다 순서가 중요합니다. 세 층으로 진행합니다. 먼저 수십 개 파라미터를 늘어놓고 서로를 설명하는지 살핍니다. 다음으로 읽힌 값이 설정과 일치하는지 하나씩 대조합니다. 마지막으로 며칠 간격을 두고 다시 측정해 두 번의 값이 같은지 봅니다. 도구로 옮기면 다음 세 단계면 충분합니다.

1. 먼저 일관성 전용 검사를 돌립니다. CreepJS 같은 도구는 파라미터끼리 충돌하는 지점을 집어냅니다. UA의 말, 그래픽카드의 말, 폰트의 말을 나란히 놓고 대조합니다.
2. 다음으로 단일 항목 누출을 확인합니다. BrowserLeaks는 항목별 보고값을 분류해 나열하므로 기기 설정과의 일치를 하나씩 확인합니다.
3. 마지막으로 이력의 안정성을 봅니다. 같은 환경을 며칠 간격으로 다시 측정합니다. 두 번의 읽기는 같아야 합니다. 어긋난다면 읽히는 값에 잡음이 섞여 있습니다.

MostMate는 "실제"와 "무작위"의 선택을 어떻게 다루는가?

원리를 설명했으니 처음 질문으로 돌아갑니다. 파라미터는 결국 어떻게 잡아야 할까요. **MostMate는 실제·일관·안정을 기본값에 넣은 핑거프린트 브라우저**입니다. 파라미터 모드는 실제, 무작위, 사용자 지정 세 가지로 나뉘고 기본값은 "실제"입니다. 화면 해상도, CPU 코어 수, 기기 메모리는 현재 기기의 실제 특징을 그대로 쓰고, Canvas와 WebGL도 실제 출력을 따르며 군더더기로 이어 붙이지도 잡음을 더하지도 않습니다. 공식 사이트의 설정 미리보기는 이 동작을 "합리적이고 실제이며 논리적으로 일관된 브라우저 환경을 시스템이 자동으로 구축합니다"라고 설명합니다. "논리적으로 일관"이라는 네 글자가 앞서 말한 파라미터 상호 증명에 대응합니다.

시간대와 언어처럼 지역과 관련된 항목은 기본적으로 "IP 기반 설정"에 묶입니다. 출구가 어디로 정해지면 그것들도 그에 맞춰 정렬되고, 회선은 한 지역에 있는데 시각은 다른 지역을 가리키는 어긋남은 생기지 않습니다. 실제와 일관이라는 두 원칙을 왜 이렇게 정했는지는 MostMate의 네 가지 설계 원칙에서 자세히 다뤘습니다.

환경을 만들면 경계도 그걸로 그어집니다. 공식 사이트에서는 환경을 Profile이라고 부르고, Profile마다 파라미터를 한 세트씩 따로 저장합니다. 두 Profile을 같은 컴퓨터에서 만들어도 읽히는 지문은 각각 한 세트로 묶이고 섞이지 않습니다. 양식을 위에서 아래로 어떻게 채우는지는 설정 미리보기에서 첫 환경까지의 네 단계에서 순서대로 설명했습니다. 설정한 뒤에는 공식 사이트의 수동 핑거프린트 설정과 권장 구성 대조표를 한 번 훑고 각 항목의 모드를 확인합니다.

이 도구가 다계정 관리에서 무엇을 맡는지는 제품 설명 페이지에 전체가 정리되어 있습니다.

핑거프린트 파라미터는 언제 바꿔도 되는가?

진짜 안정은 파라미터가 영원히 변하지 않는 것과 같지 않습니다. 변화에는 현실적인 이유가 있어야 합니다.

브라우저 메이저 업데이트는 정상적인 변화라 신경 쓰지 않아도 됩니다. 모든 사용자가 같은 한두 주 안에 순차적으로 따라가고, 플랫폼은 이 리듬에 익숙합니다. 환경이 실제 기기를 따라가면 틀어지지 않습니다.

기기를 바꾸거나 회선을 바꿀 때는 한 세트로 움직입니다. 새 파라미터는 스스로 맞아떨어지는 하나의 묶음이라 지역 관련 항목도 새 회선에 함께 맞춥니다. 계정 상태가 잠잠할 때 고르고 한 번에 끝냅니다. 위험한 것은 단일 지점을 갑자기 바꾸는 일입니다. 한 세트를 교체하는 것은 위험하지 않습니다.

계정에 이상이 나온 직후이거나 수치가 흔들릴 때는 먼저 손을 멈춥니다. 어떤 파라미터 조정도 리스크를 키웁니다. 판단이 서지 않으면 먼저 다시 측정합니다. 변경 전후로 각각 재고, 모순 항목이 0이고 두 번의 값이 일치한 다음에 진행합니다.

자주 묻는 질문

파라미터 무작위화는 아예 쓸 수 없는가?

금지가 아닙니다. 계정의 기본 전략으로 삼을 수 없다는 뜻입니다. MostMate의 파라미터 모드에는 "무작위"도 남아 있고, 테스트나 디버깅처럼 장기적인 신원이 필요 없는 상황에 맞습니다. 길게 키울 계정이라면 기본값인 "실제"가 더 안정적입니다.

User-Agent 하나만 바꾸면 되는가?

안 됩니다. User-Agent는 스무 개가 넘는 항목 중 하나일 뿐이고, 다른 파라미터가 그대로면 기기의 모습은 변하지 않았습니다. 게다가 그래픽카드나 폰트 같은 실측 항목과 대응 관계에 있습니다. 한 곳만 바꾸면 파라미터끼리 오히려 어긋납니다. 움직이려면 한 세트를 일관되게 움직여야 합니다. 단일 지점 변경이 가장 나쁜 선택입니다.

실제 지문을 쓰면 플랫폼 리스크 판정을 반드시 피할 수 있는가?

그렇게 이해할 수 없습니다. 실제 지문이 해결하는 것은 "기기가 실제처럼 읽히는가"라는 층입니다. 플랫폼의 리스크 판정은 행동, IP 품질, 조작 리듬처럼 지문 밖의 것도 봅니다. 실제 지문은 기기 층을 단단하게 만드는 것이고, 계정에 보험을 드는 것이 아닙니다. 기기 층이 안정해도 계정은 조작 습관과 함께 받쳐야 합니다.

MostMate의 일관성 검사가 플랫폼 리스크 판정을 대신할 수 있는가?

아닙니다. 이것은 별개의 문제입니다. MostMate의 일관성 검사는 생성 시점에 파라미터가 모순 없이 IP와 정렬된 환경을 짜도록 돕는 것이고, 어떤 플랫폼의 검출 규칙에도 관여하지 않습니다. 플랫폼이 어떻게 판단하는지는 플랫폼 쪽의 일입니다. 여기서 할 수 있는 일은 자기 환경을 실제 기기처럼 정돈해 두는 것입니다.

이전에 무작위화 플러그인으로 키운 계정도 살릴 수 있는가?

살릴 수 있습니다. 다만 서두르지 마십시오. 먼저 무작위화를 멈추고 실제 파라미터를 한 세트로 고정합니다. 지역 관련 항목을 새 회선에 맞추고, 그 상태로 한동안 건드리지 않고 둡니다. 자주 조정하는 쪽이 현상을 유지하는 것보다 위험합니다.

맺음말

무작위화는 매번 새로워지는 것을 좇습니다. 플랫폼이 인정하는 것은 계속 안정적인 상태입니다. 파라미터 관리의 정답은 경계를 환경 격리로, 연속성을 파라미터 안정으로 돌려놓는 것입니다. 두 가지 일이 각자의 자리로 돌아갑니다.

아직 두 방안 사이에서 흔들린다면 MostMate 다운로드로 환경을 두 개 만들어 이 글대로 각각 설정해 보십시오. 하나는 기본값인 실제로 두고, 다른 하나는 무작위로 바꿉니다. 며칠 간격을 두고 검사 도구로 각각 두 번 재면 어느 쪽 값이 대조를 견디는지 분명히 드러납니다.