관리자인 나에게 어떤 사용자가 도움을 요청하는 일이 있었습니다. 그래서 해당 사용자가 겪고 있는 문제를 정확히 이해하기 위해 그 사용자로 사칭(impersonate)하여 확인해 보았습니다.
그런데 이제 저와 그 사용자가 지문(fingerprint)을 공유하는 것으로 등록되어 있습니다. 해당 지문을 숨겼지만, 지문 표시 화면에서는 여전히 노이즈로 남아 있습니다.
관리자가 사용자로 사칭할 수 있는 기능을 고려할 때, 지문 매칭에서 스태프, 또는 최소한 관리자를 제외하는 설정을 추가하는 것이 합리적일까요?
이 플러그인을 비즈니스 호스팅에 추가할 계획이 있나요? 이렇게 하면 소켓퍼펫을 훨씬 더 쉽게 식별할 수 있습니다. 만약 계획이 없다면, 다른 대안으로 무엇을 추천하시나요?
정말 멋진 플러그인인 것 같네요. 지금 바로 사용해보겠습니다.
지금까지 내가 관찰한 내용입니다.
의심스러운 중복 계정을 찾기 위해 살펴봐야 할 매치와 데이터가 매우 많습니다. 제 생각에는, 회원 중 한 명이 금지(ban)되거나 음소거(silence)된 경우, 지문 목록에서 해당 기기의 매치를 강조(또는 우선순위 처리)한다면 이 플러그인이 훨씬 더 유용해질 것입니다. 금지되지 않은 상태에서 보조 계정을 만드는 경우는 거의 없지만, 금지된 회원은 항상 슬쩍 들어오려 합니다. 이러한 항목이 목록에 표시된다면 이 플러그인의 유용성이 크게 높아질 가능성이 높습니다.
그 점에는 동의하기 어렵습니다. 일부 커뮤니티에서는 소켓펫팅(서브 계정 사용)이 큰 문제가 될 수 있습니다. 또한 어떤 사용자는 거의 어디를 가든 그런 행동을 더 자주 하는 경향이 있습니다. 저는 직접 그런 사례를 목격한 적이 있습니다.
또한 차단된 멤버들에 대해 "항상 몰래 들어오려 한다"는 부분에도 확신이 서지 않습니다.
물론, 그 제안이 유용하지 않다는 뜻은 아닙니다.
생각해보니 말대로인 것 같네요. 특정 의제를 밀어붙이려고 보조 계정을 만드는 사용자들을 깜빡했네요. 그게 뭐든 말입니다.
일치하는 지문으로 사이트를 다시 방문하는 사용자는 다음에 침묵 조치될 수 있습니다.
이러한 오류는 수정되어야 합니다.
app.yml에서 해당 줄을 제거하고 인스턴스를 다시 빌드하는 것만으로도 충분해야 합니다.
어떤 오류가 발생하고 있나요?
그렇게 할 수 있는 옵션을 추가할 수 있을 것 같습니다.
[quote=“WorldIsMine, post:25, topic:114890”]\n의심스러운 중복 계정을 찾기 위해 살펴봐야 할 매칭 항목과 데이터가 너무 많습니다. 제 생각에, 회원 중 한 명이 BAN되었거나/침묵 조치된 경우 해당 장치를 강조(또는 우선순위화)하도록 지문 목록을 개선하면 이 플러그인이 훨씬 더 유용해질 것입니다. BAN되지 않은 상태에서 보조 계정을 설정하는 이유는 매우 드물지만, BAN된 회원은 항상 몰래 들어오려 시도합니다. 이것이 목록에 표시되면 이 플러그인이 더 유용해질 가능성이 높습니다.
[/quote]
동의하며, BAN된 사용자를 강조 표시할 수 있는 어떤 지표든 구현할 수 있다고 생각합니다.
음, 데이터가 실제로 존재하지 않는 한 해당 메서드가 호출되지 않도록 확인하는 로직이 이미 있는 상황에서 흥미로운 오류네요. 최신 버전을 실행 중이신가요?
한때 새 링크 스팸 사용자가 계정 차단이 이루어지기 _이전_에 _다섯 개_의 소크펫 계정으로 들어온 적이 있습니다. 실제로 존재하는 현상입니다. 검색 트래픽을 받고 가입이 개방된 사이트라면 거의 모든 곳에서 SEO 스팸 소크펫이 들어올 것으로 예상됩니다. 유일한 질문은 관리자들이 그것을 발견하고 있는가 하는 것입니다. 
@dan 이 플러그인을 더 사용해본 후 한 가지 더 제안할 것이 있습니다. 지문(fingerprint)과 일치하는 사용자 목록에서 저는 사용자의 아바타를 계속 클릭하게 되는데, 이는 관리 페이지나 프로필로 연결되는 링크라고 기대하기 때문입니다. 이렇게 하면 우연한 일치인지, 아니면 실제로 소크펫인지를 쉽게 조사할 수 있습니다. 그 조사를 위해 관리 페이지가 더 유용할 것 같지만, 어느 쪽이든 호버 텍스트를 읽고, 호버 텍스트에서 사용자 ID를 기억한 다음, 사용자 검색에 올바르게 입력하기를 바라면서 마침내 실제 사용자 데이터에 도달하는 것보다 훨씬 쉬울 것입니다. 
이 플러그인이 정말 훌륭합니다… VPN IP를 계속 바꿔가며 도배하던 트롤들을 많이 잡아냈거든요.
이 기능은 Discourse에 기본 내장되어야 한다고 생각합니다 ( @codinghorror ). 2020년 현재, 반복적인 트롤 공격을 차단하는 데 쿠키, 캐시, IP만으로는 역부족입니다.
하지만 사용자들이 아이폰을 사용하는 경우 완전히 실패합니다. 이는 치명적인 약점이며 극복할 수 없습니다.
결국 스팸 공격자들이 아이폰을 사용하지 않는다는 사실이 밝혀졌습니다. 우리는 데이터 탐색기를 활용해 “무해한 텍스트로 시작하다가 나중에 링크 스팸으로 수정하는” 공격을 추적했으며, 지문(Fingerprint) 기능은 이러한 스팸 공격자를 식별하는 데 큰 도움이 되어 공격을 더 빠르게 차단하는 데 기여했습니다. 이것이 기본적으로 포함되어야 한다고 주장하는 것은 아닙니다. 저는 개인 정보(PII) 수집을 좋아하지 않으며, 정당한 사유 없이 이를 수집하지 않습니다. 스팸이나 트롤 문제가 없다면 서비스 제공과 관련된 필요성 없이 개인 정보를 수집하고 싶지 않으므로, 이 기능을 절대 사용하지 않았을 것입니다. 그것이 악의적이어서가 아니라, 서비스 제공과 무관한 개인 정보 수집을 원치 않기 때문입니다. 따라서 이 기능은 유용하지만, 코어 기능이 아닌 플러그인 형태인 것이 더 합리적이라고 생각합니다. 의식적인 선택을 요구하는 것이 프라이버시 측면에서 이점이 됩니다. 구현하기 전에 전체 모더레이터 커뮤니티에 이 기능에 대한 의견을 물었고, 사전에 이러한 대화를 나눌 수 있어 좋았습니다.
문제없습니다. 저는 기꺼이 실험을 진행할 의향이 있지만, 모든 브라우저가 지문 추출(fingerprinting) 방식을 전면적으로 제한하는 방향으로 강력하게 흐르고 있다는 점을 모두가 인지해야 합니다. 이 추세는 iOS에서 가장 진전되어 있지만, 시간이 지나면 거의 모든 브라우저와 플랫폼으로 확대될 것으로 예상됩니다.
여기가 바로 Discourse의 반 스레딩(half-threading)이 혼란스러운 부분입니다. 누가 대상인지 불분명해서, 지시 대상이 명확하지 않네요. @dylanh724에게 답하고 있는 건지, 아니면 저에게 답하고 있는 건지 확신이 서지 않습니다…
어쨌든, 현재 상태를 유지하면서 플러그인으로 두는 것이 좋은 아이디어라고 생각합니다.
문맥은 명확합니다. 저는 해당 주제(브라우저 지문 기술의 근본적인 취약점)에 대한 답변을 하고 있으며, 제가 말한 내용이 본인에게 관련 있다고 느끼는 모든 분에게도 말씀드리는 것입니다.
관련 뉴스 몇 가지
Firefox(그리고 Safari도 마찬가지라고 생각합니다)가 이제 지문 추적을 차단하고 있는 상황에서, Google Chrome이 기본적으로 지문 추적을 차단하는 순간이 관을 못 박는 일격이 될 것입니다. 그러면 나머지 Chromium 기반 브라우저들도 뒤따라 올 것입니다.
두 사람이 컴퓨터를 함께 사용하는 경우, 이 방법으로 오탐이 발생할 수 있나요?
같은 컴퓨터이고 같은 브라우저라면, 당연히 그렇습니다. 긍정적이며, 그 안에는 거짓된 내용이 전혀 없습니다 
(이것은 키보드 뒤의 사용자가 아니라 브라우저를 분석합니다)
그건 Tor나 다른 방법을 통해 우회하는 것이 꽤 쉬울 것 같지 않나요?
모든 것을 우회할 수 있습니다. 여기서는 IP 주소(Tor나 VPN이 도움이 되는 부분)와 연결되어 있지 않고, 브라우저에 기반합니다. 이를 우회하는 가장 쉬운 방법은 다른 브라우저를 사용하거나, 직접 다른 장치를 사용하는 것입니다(IP 주소로 탐지되지 않도록 하기 위해 Tor/VPN 사용과 함께 추가로 이 작업을 수행해야 합니다).