Anubis, 1년 작업 끝에 WebAssembly 기반 PoW 솔버 배포

PoW로 봇을 가르는 건 결국 쓸데없는 연산을 태우는 일이라 좀 씁쓸함. 암호화폐는 적어도 팔 수 있는 토큰이 남는데.

그렇게 되면 목적이 깨짐. 스크래핑을 수익화하는 게 아니라 비싸게 만들어야 함.

PoW는 원래 안티스팸 기술이었음. CoinHive도 6-7년 전에 비슷한 일을 했지만 남용이 너무 심했지.

이미 WASM으로 Anubis 솔버를 가속하는 pow-buster 확장이 있음. anubis_webgpu는 GPU에 따라 한 자릿수 이상 더 빠르게 돌릴 수 있음.

Argon2를 쓰면 GPU가 그렇게 유리하지는 않을 듯함.

PoW를 미리 계산해 뒀다가 필요할 때 쓰면 기다리는 일이 줄어들 텐데.

나도 비공개 프로토타입으로 작업 중임. Service Worker가 낮은 난도로 챌린지를 갱신하게 하는 쪽을 생각하고 있음.

Privacy Pass가 네가 말한 방식과 비슷한 일을 이미 함.

CUDA 솔버를 AI로 뽑는 길이 Argon2 조금 넣는다고 막힐 거라고는 안 봄. Anubis가 스크래퍼와 일반 기기의 연산 여건이 다르다는 가정도 약점이 있음.

결국 스크래퍼가 소비자 기기 쪽으로 연산 일부를 옮길 가능성이 큼. 이그레스 프록시는 이미 있으니 거기에 연산을 붙이면 됨.

목표는 스크래퍼를 없애는 게 아님. 분산 네트워크가 사이트마다 초당 1만 페이지씩 요청하는 비용을 올리는 거임.

장기적으로 Anubis가 어떻게 유지될지는 여전히 모르겠음. AI 기업이 메모리가 부족하다는 가정을 하는 건가?

문제를 많이 일으키는 건 지금은 가장 적은 노력만 들이는 행위자들임. 20%만 막아도 운영자가 겪는 실무 문제는 크게 줄어듦.

페이지 하나 보려는 사람에게 1초 연산을 요구하는 것과 초당 1,000페이지를 긁는 쪽에 같은 비용을 물리는 건 다름. 크롤링이 실제로 줄어든다면 그게 목적 달성임.

봇을 막으려면 robots.txt도 루트에 두면 좋겠음. 내 개인 크롤러는 그 규칙을 지키니 Anubis 감지 시 차단 목록에 넣을 수도 있음.

표준 라이브러리 규칙 하나는 기본으로 robots.txt 통과를 켬. 운영자가 그 규칙을 선택하지 않는 건 내가 통제할 수 없음.

좋은 봇만 robots.txt를 지키는 시대임. 제한적인 robots.txt를 둬도 얻는 이득이 없음.

브라우저 호환성을 미리 시험할 곳이 필요함. WASM 기능 일부가 없어서 느린 순수 JS 경로로 떨어지고 진행률도 안 보이면 페이지를 포기하게 될 듯.

Chrome 66까지 겨냥한 하위 호환성 작업은 좋았음. 오래된 브라우저까지 맞추려면 당시 도구체인을 쓰거나 변화가 느린 도구체인을 쓰는 편이 낫다고 봄.

난도에 1을 더하면 최악의 경우 1,024배 어려워진다는 설명은 단위가 이상함. 비트와 니블 차이라면 16배 아닌가?

그건 내가 쓴 오류임. 고치겠음.

봇 완화는 경제 문제임. 스크래핑을 불가능하게 할 필요 없이 남용 트래픽의 채산성을 깨면 됨.

스크래퍼는 온갖 쓸모없는 것까지 긁음. Git 호스트의 모든 diff를 긁는 걸 보면 합리성만 기대하긴 어려움.

Rust에서 표준 라이브러리까지 다시 빌드하려면 build-std 기능을 찾으면 됨. 멀티스레드 WASM도 비슷한 이유로 그 플래그가 필요함.