Anubis의 단점을 보완하려고 대기 증명(proof-of-wait) 챌린지를 써봤는데 꽤 효과가 있었음
기본적으로 전역 요청률이 기준치보다 낮으면 필터를 끄고, 기준치를 넘으면 사용자가 계속 진행하기 전 N초 기다리게 함
그 뒤 해당 IP에 묶인 토큰을 발급해 만료 시간 안에서 소량의 요청만 허용하고, 토큰 자체도 속도 제한을 둠
성공 요청이 계속 들어오면 대기 시간이 점점 늘어남
꽤 성공적이었고, 모바일 기기가 과도하게 불리해지지 않도록 완만하게 성능 저하되며, JavaScript 없이도 동작함

marginalia.nu에서 이 방식이 동작하는 걸 봤는데, 휴대폰 배터리를 작업 증명으로 낭비하지 않아서 마음에 듦

공개 코드의 일부라면 이걸 구현한 소스 코드 링크를 받을 수 있을지 궁금함

멋짐. 이런 방식을 TLS의 일부로 만들려는 노력이 있는지 궁금함. 작업 증명 챌린지에 대해 draft-venhoek-tls-client-puzzles-00가 하려는 것과 비슷한 느낌임
이런 건 TLS나 심지어 운영체제의 IP 스택처럼 훨씬 아래 계층에 있어야 할 것 같음
대기 증명을 깊게 생각해본 적은 없지만, 합법 사용자에게는 자동 스크래퍼보다 대기가 훨씬 더 나쁘게 작용하지 않나? 사람은 기다림에 짜증을 내지만, 스크래퍼는 토큰을 저장해두고 N초 뒤 돌아오면 됨
작업 증명도 양가감정이 있지만, 적어도 스크래퍼에게는 규모에 비례하는 실질 비용을 부과함

설정이 간단한지 궁금함. 내 위키에도 관심 있음

유용한 접근으로 보임. 자세한 내용을 정리할 계획이 있는지 궁금함
대기 증명은 작업 증명에 우려가 있는 사람들을 안심시킬 수도 있겠음

특정 특수 페이지는 한 번 로그인해서 해당 쿠키가 설정된 클라이언트만 접근하게 하고, 아니면 거부하는 방식도 꽤 잘 동작함
대부분의 크롤러가 위키를 훑기 위해 특수 페이지를 노리므로, 로그인 사용자로 제한할 수 있음
이 설정에서는 위키가 사용자 생성을 허용하지 않음
<If "%{REQUEST_URI} =~ m#^/wiki/index.php(?:/.)?$# && %{HTTP_COOKIE} !~ /[-a-zA-Z_]+UserID=/ && ( %{REQUEST_URI} =~ m#^/wiki/index.php/Special(?::|%3A)(MobileDiff|History|Contributions|CreateAccount|ExportTranslations|MessageGroupStats|LanguageStats|Translate|RecentChanges|Log|RecentChangesLinked|WhatLinksHere)(?:/.)?$#i || %{QUERY_STRING} =~ /(Special(%3A|:)(MobileDiff|History|Contributions|CreateAccount|ExportTranslations|MessageGroupStats|LanguageStats|Translate|RecentChanges|Log|RecentChangesLinked|WhatLinksHere)|action=(edit|history|info|pagevalues|purge|formedit)|oldid=)/i )">
ErrorDocument 403 "Access denied, please login."
Require all denied
</If>
이걸로 우리 시스템 부하가 크게 줄었음. 이전에는 특수 페이지를 심하게 크롤링해서 위키가 못 쓸 정도가 되는 피크가 자주 있었음
그 밖에는 알려진 AI 크롤러 사용자 에이전트를 바로 403으로 막고, Alibaba나 Amazon Cloud 같은 특정 IP 대역도 차단함
재미있게도 저쪽이 이를 알아챘음. Diff 보기로 페이지를 훑다가 제한하니 MobileDiff 보기로 같은 시도를 했음
몇 번 오가긴 했지만, 몇 달 전부터는 이 방식으로 순조롭게 돌아감

사용자 에이전트 기반 차단은 사실상 할 수 있는 일 중 거의 최악에 가까움
사용자 에이전트로 막으면 크롤러는 사람처럼 보이는 사용자 에이전트로 다시 시도하며 사이트를 탐색함
차단 트리거가 사용자 에이전트라고 판단하면 지옥 모드로 들어가 식별이 훨씬 어려워지고 사이트를 죽을 때까지 두들김
IP 대역 차단도 도움이 되지만, 모바일 악성코드 프록시로 크롤링하므로 충분하지 않고 전부 잡을 수 없음
애초에 막지 않으면 대체로 비교적 얌전하게 남아 있음
그래서 차단 대신 저렴하게 생성한 쓰레기 데이터를 먹여 지옥 모드를 유발하지 않는 게 요령이고, 나는 https://iocaine.madhouse-project.org/ 를 씀

참고로 MediaWiki 권한으로도 할 수 있음. 기본값을 모든 권한 거부로 두고, 익명 사용자에게 기본 이름공간의 페이지 읽기 정도만 다시 추가하면 고양이와 쥐 게임이 없어짐
다만 그렇게 하면 MediaWiki가 직접 응답을 서빙해야 하므로, Apache에서 처리하는 이점도 있음

바로 알아챘는지가 궁금함. 스크래퍼 작성자들이 이미 여러 대체 기법을 준비해뒀고, 403을 받기 시작하면 봇이 다음 트릭을 순서대로 시도했을 거라고 봄

곁가지지만 Weird Gloop은 훌륭한 서비스임. 운영하는 위키 품질이 매우 높고, 팬들이 만든 콘텐츠를 Fandom의 끔찍한 플랫폼에서 옮겨오는 일은 세상에 도움이 됨

이렇게 말하긴 싫지만, 사람 행동에 맞춰 튜닝하자는 제안은 나중에 발목을 잡을 것 같음
봇이 페이지의 모든 정적 자산까지 요청하기 시작할 테고, 그게 사람을 식별하는 행동의 일부라고 가정함
흥미로운 게임이군요, Falken 교수님

스크래퍼가 일반적인 <a href=...> 링크를 재귀적으로 따라가며 이런 페이지에 도달한다면, 기록 차이처럼 비싸고 캐시되지 않는 페이지를 <form method="POST" action=...> 제출로만 접근 가능하게 해서 부드럽게 다른 곳으로 유도할 수 있지 않을까 싶음
아무것도 차단하지 않고, 사실상 스크래퍼 입장에서도 거의 무한한 중복 정보를 재귀적으로 섭취하지 않게 해주므로 이익임
일반 사용자도 차이를 거의 못 느낄 수 있고, 수고 대비 효과가 괜찮을 듯함. 익명 사용자에게는 Anubis보다 나을 수 있음
이건 스크래퍼가 method="POST"인 HTTP 폼을 제출하지 않는다는 가정에 달려 있음
그게 대체로 사실이 아니라면, AI 스크래퍼가 익명 편집을 대량 제출해 Wikipedia 내용을 무작위 쓰레기로 바꿨다는 헤드라인을 이미 봤을 것 같음

그렇게 하면 응답도 캐시 불가가 되어, CDN에 의존한다면 문제가 될 수 있음
봇이 <form method="GET">도 누를지 궁금함. 이러면 캐시와 잘 맞고 크롤러에는 추가 로직을 요구할 수 있음

내 작은 블로그 트래픽의 95%는 Singapore와 China의 LLM 스크래퍼에서 옴

몇 년이나 지났는데도 아무도 IP를 뒤져서 연락하고 직접 찾아갈 수 있는 작은 ISP의 IP 하나를 못 찾았나? 그 사용자에게 찾아가 컴퓨터를 점검해도 되는지 정중히 묻지도 않았나? 실제로 어떤 소프트웨어가 크롤링하는지 아무도 밝혀내지 못했나?
사이트 운영자들이 이 정도도 못 한다면 더는 신경 쓰고 싶지 않음. 실제로 지저분한 사람 간 접촉을 피하려고 안간힘을 쓰니 봇을 얻는 것임
그리고 주거용 봇넷에서 돌아가는 봇은 가끔 CAPTCHA나 Anubis를 통과할 만큼의 연산 자원을 당연히 갖고 있음
서버 쪽에서 영구적으로 이기는 건 불가능함. 그 컴퓨터의 사용자도 합법 트래픽을 만들기 때문임
그러니 원격 증명을 원하는 게 아니라면 그 IP들로 찾아가야 함

주거용 봇넷의 규모를 과소평가하는 것 같음

문제는 수만 개의 서로 다른 IP에서 트래픽이 온다는 것임
전 세계를 운전해 다니는 기름값 같은 현실 문제를 빼더라도, 엄청난 외판원 문제가 됨

정말 놀라울 정도로 형편없는 견해임
봇 몇 개가 시스템 관리자에게 조금 더 얌전하게 굴도록 주말 내내 어디든 운전해 가면 된다는 발상은, 특히 대부분이 대형이거나 외국계 ISP에서 온다는 점을 생각하면 웃길 뿐임
뭘 피웠는지 궁금할 정도임
요즘 어떤 소프트웨어가 크롤링하느냐고? 누군가 챗봇에게 “이걸 스크래핑하는 걸 만들어줘”라고 시키고, 각 스크래퍼가 개별적으로 만들어지는 식임

“아무도”라는 질문은 누가 그 일을 할 능력과 동기 또는 책임을 갖는지 말할 수 있을 때만 합리적임
그렇지 않으면 그냥 추상적으로 온 우주를 탓하는 셈임

작은 ISP에 연락해서 찾아간다는 건 현실성이 낮음
대부분의 서비스 제공자는 자기 IP가 어떤 웹사이트 스크래핑에 쓰이는지 전혀 신경 쓰지 않는다고 장담할 수 있음
게다가 그 제공자들이 IP에 연결된 주소를 알려줄 일도 없다고 장담함
훨씬 잘 먹히는 건 Alibaba, AWS 같은 여러 제공자와 관련된 ASN 트래픽을 통째로 버리는 것임
항상 가능한 선택지는 아님. 예를 들어 Atom 피드가 있는 블로그라면 피드 리더도 함께 막을 수 있음
하지만 많은 경우 쓰레기 트래픽의 80%를 없앨 수 있음

이런 동작이 왜 발생하는지 아는 사람이 있나? 특히 스파이크가 왜 생기는지 궁금함

들은 가설로는 봇넷이 신뢰성이 낮고, 주거용 프록시로 봇넷 접근을 파는 사람들이 그 불안정성을 중복 요청으로 보완한다는 것임
사실인지는 모르겠지만 적어도 그럴듯함
인프라를 더 잘 이해하지 못하면 말하기 어려움. 명령·제어 한계일 수도 있음
봇넷이 DDoS용으로 만들어졌다면 구조상 세밀한 제어가 부족할 수도 있음