Siapa sebenarnya yang dihentikan Anubis?

 (fzakaria.com)
1 poin oleh GN⁺ 3 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Anubis, yang mewajibkan Proof-of-Work sebelum akses HTTP, membebankan biaya berkelanjutan yang lebih besar kepada pengguna biasa, perangkat berspesifikasi rendah, dan klien tanpa dukungan JavaScript dibandingkan kepada scraper AI
  • anubis-fetch yang dibuat oleh LLM memecahkan proof-of-work secara langsung, menjalankan Chromium bila perlu, serta meniru fingerprint TLS/JA3 Chrome untuk melewati pemblokiran manual Cloudflare
  • Scraper dapat men-cache dan menggunakan kembali cookie yang diterbitkan untuk mengamortisasi biaya ke banyak permintaan, tetapi manusia harus menanggung penantian beberapa detik dan konsumsi baterai setiap kali berkunjung
  • Tingkat kesulitan default 4 rata-rata membutuhkan 65.536 hash; implementasi Go native memakan sekitar 1,3 ms, JavaScript di browser sekitar 130 ms, tetapi waktu tunggu yang benar-benar terasa sekitar 1–5 detik
  • Jika diasumsikan waktu terasa 2 detik dan energi 20 J per percobaan, 1 juta challenge per hari menghabiskan sekitar 23 tahun-manusia·2 MWh per tahun, sedangkan 100 juta per hari menghabiskan sekitar 2.300 tahun-manusia·200 MWh

Anubis yang ditembus AI

  • Saat mengerjakan patch untuk mendukung $ORIGIN pada interpreter PT_INTERP melalui bpf binfmt_misc di kernel Linux, penulis meminta LLM membaca thread Linux Kernel Mailing List
  • lore.kernel.org saat itu sudah menerapkan proxy HTTP Anubis yang mewajibkan proof-of-work sebelum akses resource
  • LLM membuat anubis-fetch untuk menangani batasan ini
    • Pertama, ia memecahkan proof-of-work secara native; jika gagal, ia mengunjungi URL dengan Chromium
    • Dengan req, ia meniru fingerprint TLS/JA3 Chrome sungguhan sehingga juga lolos dari pemblokiran manual Cloudflare
    • anubis-fetch <URL> mengirim HTML ke standard output, dan opsi --text menampilkan teks biasa yang mudah dibaca
  • AI dan bot yang menjadi sasaran Anubis dapat dengan mudah melewatinya setelah dukungan proof-of-work ditambahkan sekali saja
    • Scraper menyelesaikan challenge, lalu men-cache dan menggunakan kembali cookie yang diterima untuk mengamortisasi biaya ke banyak permintaan
    • Sebaliknya, manusia harus menunggu spinner setiap kali berkunjung dan menghabiskan baterai, dan biaya ini tidak bisa dibagi dengan pengguna lain
    • Bebannya makin besar pada perangkat berspesifikasi rendah dan smartphone, sementara w3m·lynx·screen reader·RSS reader yang tidak menggunakan JavaScript tidak dapat mengaksesnya
  • Mekanisme yang dimaksudkan untuk memblokir AI justru mudah ditembus oleh AI, sementara bagi manusia dan web terbuka ia berfungsi sebagai beban regresif yang terus mengenakan biaya

Biaya waktu dan energi yang diciptakan proof-of-work

  • Tingkat kesulitan d adalah jumlah karakter heksadesimal nol di awal yang harus dimiliki hash, dan beban kerja yang diharapkan per penyelesaian adalah W = 16^d hash
    • Tingkat kesulitan 4, nilai default yang umum, membutuhkan 65.536 hash
      • Implementasi Go native sekitar 50 MH/s: sekitar 1,3 ms
      • JavaScript browser sekitar 0,5 MH/s: sekitar 130 ms
      • Waktu yang terasa termasuk pemuatan halaman, eksekusi worker, dan reload: sekitar 1–5 detik
    • Tingkat kesulitan 5 membutuhkan 1.048.576 hash
      • Implementasi Go native: sekitar 20 ms
      • JavaScript browser: sekitar 2 detik
      • Waktu yang terasa: sekitar 5–15 detik
  • Anggap jumlah penyelesaian challenge Anubis harian di seluruh dunia adalah C, waktu terasa per percobaan t = 2 detik, dan energi perangkat termasuk layar serta CPU E = 20 J
    • Waktu manusia per tahun dihitung sebagai C × t × 365 / 3.15×10⁷
    • Energi per tahun dihitung sebagai C × E × 365 / 3.6×10⁶ kWh
  • Dengan asumsi ini, biaya tahunannya adalah sebagai berikut
    • 1 juta kali per hari: sekitar 23 tahun-manusia, sekitar 2 MWh
    • 10 juta kali per hari: sekitar 230 tahun-manusia, sekitar 20 MWh
    • 100 juta kali per hari: sekitar 2.300 tahun-manusia, sekitar 200 MWh
  • Semua angka adalah estimasi kasar, dan karena bot farm serta alat AI menggunakan energi beberapa orde magnitudo lebih besar, perhitungan ini bukan untuk mengajukan argumen lingkungan
  • Bagi robot, waktu bukanlah kendala, tetapi waktu manusia terbatas; akibatnya, pengguna secara kolektif menghabiskan waktu signifikan untuk menunggu akses situs web, sesuatu yang tidak ada sebelum era AI

Bacaan terkait

1 komentar

 
GN⁺ 3 jam lalu
Opini di Lobste.rs

  • Sulit setuju dengan anggapan bahwa target yang dibidik Anubis bisa dengan mudah melumpuhkannya. Sasaran utama Anubis bukan agen LLM atau program hasil vibe coding, melainkan web scraper sembrono yang dipakai perusahaan LLM
    Memang ada cara untuk mengakalinya dan bisa juga memanfaatkan agen atau LLM, tetapi kebanyakan scraper itu sederhana, dan operatornya pun biasanya tidak repot-repot membypass segelintir situs yang memakai Anubis. Tujuannya lebih ke sedikit menaikkan biaya bypass agar pengumpulan data jadi tidak sepadan

    • Anubis tampaknya efektif untuk mencegah scraper yang memakai proxy residensial sampai melumpuhkan server. Permintaan dari agen individual pada dasarnya tidak jauh berbeda dari pengguna yang benar-benar menjelajahi situs
      Namun untuk tujuan ini, Anubis terlalu direkayasa. Cukup minta pengguna menekan tombol sekali lalu terbitkan cookie akses, dan efek perlindungannya sudah sama; saya pernah menerapkannya di Apache, dan itu bekerja cukup baik tanpa proof-of-work yang rumit
    • Sasarannya bukan scraper milik perusahaan LLM secara khusus, melainkan web scraper kasar dan abusif secara umum. Hanya ada dugaan bahwa sebagian di antaranya dijalankan oleh perusahaan LLM
    • Lalu lintas yang meningkat ke situs web bukan datang dari OpenAI, Anthropic, atau Meta, melainkan dari pihak lain, jadi tidak jelas apa yang dimaksud dengan perusahaan LLM
      Dalam pekerjaan data mining saya juga, alat scraping modern cukup canggih untuk menembus hampir semua rintangan, dan Anubis pun mudah dibypass
    • Saya juga ingin memblokir akses RAG ke situs pribadi dan perangkat lunak saya, jadi saya menerapkan pemblokiran user-agent dasar. Saya mengujinya dengan meminta akses situs langsung dari ChatGPT, dan itu terblokir dengan baik
      Konfigurasi yang sangat khusus mungkin masih bisa lolos, tetapi targetnya bukan lawan yang berniat jahat, melainkan lawan yang malas
    • Yang terutama dihentikan Anubis adalah scraper Python requests yang sangat dasar dan asal menyamar sebagai Chrome; efek pemblokiran lainnya nyaris hanya bonus

  • Anubis bukan menyaring bot, melainkan membatasi laju permintaan klien

  • Anubis lebih mirip alat pertahanan terhadap serangan denial-of-service daripada mekanisme untuk memblokir akses agen AI, dan secara realistis pun sulit membedakan lalu memblokir agen AI
    Namun pengguna seperti saya yang mengunjungi situs asing dari perangkat mobile dengan JavaScript dimatikan juga ikut terblokir

  • Dari hasil operasional nyata, saya sulit setuju dengan kesimpulan tulisan itu. Saya menjalankan situs web homelab lewat proxy publik fly.io dan forwarding Tailscale, dan scraper termasuk Facebook menyebabkan sekitar biaya bandwidth 20 dolar per bulan
    Setelah menerapkan Anubis pada proxy, pemakaian kembali turun ke tier gratis. Tidak masalah kalau secara teori bisa dibypass; cukup jika sebagian besar trafik scraping massal dari sedikit pelaku jahat yang mengabaikan robots.txt bisa diblokir

  • Untuk scraping yang memanfaatkan botnet perangkat berspesifikasi rendah seperti smart TV, proof-of-work Anubis tampaknya bisa menjadi hambatan nyata. Masalah ini juga sedikit dibahas di https://lobste.rs/s/kpaxih/update_on_scraper_situation

    • Kalau saya tidak salah paham, smart TV itu hanya dipakai sebagai proxy, dan tidak benar-benar menjalankan proof-of-work itu sendiri

  • Bagian yang paling mengganggu dari Anubis adalah benturannya dengan web terbuka. Situs web saya terutama dikonsumsi lewat feed RSS; jika RSS dilindungi dengan Anubis, feed tidak akan berfungsi, dan jika tidak dilindungi, seluruh konten terekspos ke scraper dalam bentuk yang mudah dibaca mesin
    Penghalang proof-of-work seperti ini pada dasarnya sulit didamaikan dengan web terbuka atau indieweb yang dulu ingin kita bangun

    • Selama setahun terakhir saya terjebak di antara kompromi yang mustahil seperti ini, dan saya juga belum menemukan jawaban yang baik

  • Terlihat jelas sikap yang tidak menghormati pilihan yang dibuat orang lain

  • Hal yang paling menjijikkan adalah bahwa ini tampak sebagai tindakan yang jelas melanggar hukum seperti CFAA, tetapi mereka tetap menyembunyikan identitas layaknya layanan DDoS kriminal lainnya
    Lucu juga mengharapkan perusahaan yang seluruh model bisnisnya bergantung pada pencurian karya orang lain dan pencucian kode open source untuk mematuhi hukum

  • Anubis biasanya tidak memblokir Dillo, tetapi tergantung konfigurasi situs kadang tetap diblokir, dan ini sangat menjengkelkan karena mendorong suasana bahwa kalau tanpa JavaScript, Anda tidak pantas eksis: https://paste.rs/jNgwd.png
    Saya sedang mempertimbangkan apakah mungkin mengumpulkan dan mengelola daftar semua IP yang termasuk dalam proxy residensial lalu memblokirnya untuk jangka waktu tertentu; ipset mungkin sanggup menangani skala sebesar ini. Dari log terlihat bahwa bot mudah dikenali karena mereka menelusuri semua file di semua commit repositori Dillo tanpa memuat resource lain seperti CSS atau gambar
    Di tiap situs mungkin hanya terlihat satu permintaan per IP, tetapi besar kemungkinan IP yang sama mengambil banyak situs, jadi IP yang dilaporkan berkali-kali bisa diblokir. Daripada sekadar memutus koneksi, sebaiknya alihkan ke halaman informasi di port terpisah yang menjelaskan alasan pemblokiran dan cara mengatasinya
    Dengan begitu, insentif untuk menanam backdoor reverse proxy di ekstensi browser atau aplikasi ponsel juga berkurang. Karena pengguna akan mulai benar-benar terdampak pemblokiran
    Memang disayangkan harus bergantung pada sistem reputasi IP, tetapi saya tidak melihat banyak langkah efektif lain. Perangkat yang rentan bisa direbut kembali oleh penyerang berikutnya dan dimasukkan ke botnet baru bahkan setelah server command-and-control botnet sebelumnya dihapus

  • Di tulisan itu ada kalimat “tentu saja saya melakukan ini dengan bantuan LLM”, jadi saya penasaran kenapa tidak diberi tag vibe coding

    • Sama seperti penulis tidak menambahkan tag itu hanya karena memakai compiler atau editor, topik tulisan ini bukan tentang vibe coding. Tag vibecoding dihapus oleh pushcx
    • Saat diposting, tulisan itu memang menyebut bahwa ada sesuatu yang dibuat dengan vibe coding untuk membypass pemblokiran, jadi tag itu ditambahkan. Saya cukup terkejut tag itu dihapus, karena pada tulisan lain yang bahkan lebih sedikit menyebut AI coding pun tag itu sering dipakai; jadi saya menerima bahwa kriteria penerapan tag ini sama sekali tidak konsisten