LinkedIn이 2,953개의 브라우저 확장을 검사함
(github.com/mdp)- LinkedIn 웹사이트가 페이지를 불러올 때마다 2,953개의 Chrome 확장 프로그램 존재 여부를 탐지함
- 저장소는 LinkedIn이 확인하는 모든 확장 ID와 이름, Chrome Web Store 링크를 문서화함
- 전체 확장 중 약 78%는 Chrome Web Store에서, 약 22%는 Extpose를 통해 확인됨
- 제공된 스크립트(fetch_extension_names.js) 는 확장 이름을 자동으로 수집하고, 삭제된 확장은 Extpose에서 대체 조회함
- 이 데이터는 웹사이트가 사용자 브라우저 확장을 식별하는 행위의 규모를 보여주는 자료임
LinkedIn Chrome Extension Fingerprinting
- LinkedIn은 각 페이지 로드 시 2,953개의 Chrome 확장 프로그램을 비밀리에 점검함
- 이 과정은 사용자의 브라우저에 설치된 확장을 식별하기 위한 fingerprinting 형태로 수행됨
- 저장소는 LinkedIn이 점검하는 모든 확장 목록과 관련 도구를 포함함
-
chrome_extensions_with_names_all.csv파일에 확장 ID, 이름, Chrome Web Store 또는 Extpose 링크가 정리되어 있음
-
데이터 구성
- 데이터 파일에는 Extension ID, Name, URL 세 개의 열이 포함됨
- Extension ID는 32자 식별자이며, URL은 Chrome Web Store 또는 Extpose 링크로 연결됨
- 전체 목록은
chrome_extensions_with_names_all.csv파일에서 확인 가능
스크립트
-
fetch_extension_names.js는 Chrome Web Store에서 확장 이름을 가져오고, 삭제되었거나 접근 불가한 경우 Extpose를 통해 대체 조회함
- 명령어 예시:
node fetch_extension_names.js,node fetch_extension_names.js --offset 0 --limit 500
- 명령어 예시:
- test_fetch.js는 처음 3개의 확장을 처리하며, 상세 출력(verbose) 모드로 테스트 가능
통계
- LinkedIn의 fingerprint 목록에는 총 2,953개 확장이 포함됨
- 이 중 약 78%는 Chrome Web Store에서, 약 22%는 Extpose를 통해 확인됨
소스 파일
-
chrome_extension_ids.txt: LinkedIn의fingerprint.js에서 추출한 원시 확장 ID 목록 -
fingerprint.js: LinkedIn 페이지에 포함된 확장 탐지용 스크립트(축약 버전) -
fetch_extension_names.js: 확장 이름을 자동으로 수집하는 보조 스크립트
요약
- LinkedIn이 브라우저 확장 정보를 대규모로 점검하고 있으며,
이 저장소는 그 전체 목록과 수집 방법을 투명하게 공개함
Hacker News 의견들
-
Firefox는 이번 이슈에 면역인 듯함
Chrome은 확장 프로그램의 웹 접근 리소스를chrome-extension://[PACKAGE ID]/[PATH]형태로 노출하지만,
Firefox는moz-extension://<extension-UUID>/myfile.png형태로 접근함.
이때<extension-UUID>는 브라우저마다 무작위로 생성되어 사이트가 설치된 확장 프로그램을 통해 브라우저를 지문 추적(fingerprinting) 하지 못하게 막음
관련 문서: Chrome 문서, Firefox 문서- 시장 점유율 5% 미만 브라우저를 쓴다고 최신 웹 기술을 놓친다고 하더니, 오히려 이런 보안 이점이 있음이라니 아이러니함
- 가끔 내 컴퓨터 팬이 미친 듯이 돌아갈 때가 있는데, 대부분 LinkedIn 탭을 켜둔 Firefox 때문임. 이게 혹시 암호화폐 채굴이라도 하는 건지, 아니면 단순히 비효율적인 건지 궁금함
- 확장 프로그램 ID를 브라우저별로 바꾸면, 브라우저 대신 사용자 자신이 식별되는 거 아닌지 의문임.
“이 브라우저엔 X, Y, Z 확장이 있다”에서 “이건 Jim Bob의 브라우저다”로 바뀌는 셈 아님?
-
확장 목록을 보면 대부분 LinkedIn 데이터 스크래핑이나 자동화 관련 확장임
LinkedIn에서 일할 때도 이런 남용이 심했고, 내부 탐지·방지 시스템을 꽤 정교하게 만들었지만 끝없는 싸움이었음- LinkedIn이 확장 지문 인식을 위해 데이터 소스를 만들려면, 누군가(아마 LinkedIn?)가 Chrome Web Store를 스크래핑했을 가능성이 높음.
이는 Chrome Web Store TOS 위반일 수도 있음 - 리스트를 보면 그리 정교하지 않음. 이름에 “email”이 들어간 확장만 필터링한 수준이고, 대부분은 linkedin.com 접근 권한조차 없음
- LinkedIn 입장에선 문제일 수 있지만, 진짜 문제는 데이터 브로커링을 하는 LinkedIn 같은 기업들임
- 코드상으로는 매칭되면 뭔가를 하진 않고, 단순히 결과를 CSV로 저장해서 지문 데이터로 쓰는 듯함
- 예전에 클라이언트 의뢰로 LinkedIn을 스크래핑한 적이 있는데, 꽤 재미있는 경험이었음
- LinkedIn이 확장 지문 인식을 위해 데이터 소스를 만들려면, 누군가(아마 LinkedIn?)가 Chrome Web Store를 스크래핑했을 가능성이 높음.
-
Chrome은 이제 새로운 IE6 같음
Google은 스스로를 다음 Microsoft로 만들었고, 광고 친화적인 방향으로 가고 있음.
보안 향상보다는 광고 차단기 무력화와 악성 코드 허용 쪽으로 기여한 느낌임- Chrome이 스파이웨어라는 데 동의하지만, 그래도 Site Isolation이나 sandboxing 같은 보안 기능을 가장 먼저 도입한 건 사실임.
패치 속도나 보안 테스트도 나쁘지 않음 - 지금의 Chrome은 IE6보다 훨씬 더 나쁜 존재임. Microsoft는 적어도 사용자 추적이나 광고 판매는 안 했음
- 광고를 통제하는 자가 인터넷을 통제함
- Google은 이미 독점 기업이 되었고, 모든 독점은 결국 이런 식으로 변함
- 2026년에 아직도 Chrome 쓰는 사람이라면 진짜 용감한 개발자일 듯함
- Chrome이 스파이웨어라는 데 동의하지만, 그래도 Site Isolation이나 sandboxing 같은 보안 기능을 가장 먼저 도입한 건 사실임.
-
LinkedIn을 열고 F12를 눌러보면 에러 카운트가 계속 증가함
스크린샷은 여기에서 확인 가능- X 링크가 차단된 경우 xcancel 링크로도 볼 수 있음
-
최근 LinkedIn의 확장 탐지 기법과 부작용이 적은 다른 방법을 블로그에 정리했음
Castle 블로그 글- Firefox를 패치해서
navigator.webdriver가 항상 false가 되게 하면 원격 제어가 가능함.
탐지하기 어렵지만, 입력 속도 패턴으로는 여전히 감지 가능함 - 글 내용이 정확히 이 주제와 일치해서 흥미롭게 읽었음
- Firefox를 패치해서
-
몇 달 전에 관련 기사를 썼음.
왜 이런 일이 가능한지, 그리고 예방 방법까지 설명했음
기사 링크- 혹시 글에서 LinkedIn이 왜 이런 일을 하는지까지 다룬 건지, 아니면 단순히 기술적 가능성만 설명한 건지 궁금함
-
LinkedIn이 최근 이상한 다크 패턴을 많이 쓰고 있음
- Firefox에서 스크롤 속도를 강제로 바꿈
- 모바일 웹에서 프로필을 보고 뒤로 가면 항상 홈페이지로 리디렉션됨
- 분석용 URL이 무작위 경로로 생성되어 차단 회피를 시도함
이런 행동의 이유를 아는 사람이 있는지 궁금함
- LinkedIn이 연락처 데이터베이스 산업과 전면전을 벌이고 있어서, 이런 전술을 쓰는 듯함.
웹 크롤링에서 사람을 고용한 수작업까지 가는 과정에서 다양한 방어 전략을 쓰는 중임
-
이런 방식은 이미 2019년부터 알려져 있었음
Nymeria 블로그 글 -
LinkedIn이 스캔하는 확장 목록은 명확하지만, 오히려 스캔하지 않는 확장이 더 흥미로움
예를 들어 “Contact Out”은 스캔 가능하지만 LinkedIn이 무시하는 듯한 태도를 보임.
뒷거래가 있었던 건 아닌지 의심됨
Contact Out 확장 링크- 해당 확장은 manifest에 content-accessible 리소스를 선언하지 않아 지문 인식이 불가능함
- 흥미롭게도 LinkedIn은 Claude 확장이나 Dassi AI 같은 것도 차단하지 않음. 이유가 궁금함
-
“이 저장소는 LinkedIn이 검사하는 모든 확장을 문서화하고, 이를 식별할 수 있는 도구를 제공한다”고 되어 있는데,
LinkedIn이 이 ID들을 실제로 검사한다는 걸 어떻게 확인한 건지 궁금함.
그리고 이게 비-Chrome 사용자에게도 관련 있는지 알고 싶음- 몇 주 전 한 벤더가 기술적으로 LinkedIn의 방식을 분석한 글을 올렸는데,
자기들의 접근법이 “더 조용하고, 눈에 띄지 않으며, 대규모로 실행하기 쉽다”고 자랑함
Castle 블로그 글
- 몇 주 전 한 벤더가 기술적으로 LinkedIn의 방식을 분석한 글을 올렸는데,