Anubis benar-benar berfungsi

 (xeiaso.net)
3 poin oleh GN⁺ 2025-04-14 | 1 komentar | Bagikan ke WhatsApp
  • Anubis diterapkan di policytoolbox.iiep.unesco.org milik UNESCO, sehingga makin mendapat perhatian sebagai contoh alat penanganan bot yang digunakan organisasi besar
  • Setelah memastikan bahwa unesco.org adalah domain resmi UNESCO, penerapan ini diterima sebagai kasus penggunaan nyata oleh organisasi terkait United Nations
  • Penggunaannya makin meluas bersama lokasi penerapan yang sudah dikenal seperti arsip Linux Kernel Mailing List, SVN FreeBSD, SourceHut, FFmpeg, Wine, dan GNOME GitLab
  • Situasi ketika organisasi-organisasi seperti ini mengadopsi Anubis menunjukkan bahwa masalah trafik bot di internet mungkin lebih serius daripada perkiraan
  • Anubis dan stack di sekitarnya membutuhkan lebih banyak waktu, dan dengan dukungan dana yang cukup, pengembangan penuh waktu hingga perekrutan dapat dilakukan

Konfirmasi penerapan di UNESCO

  • Anubis telah diterapkan di policytoolbox.iiep.unesco.org milik UNESCO, yang berada di bawah United Nations
  • unesco.org tercantum di Wikipedia sebagai domain resmi United Nations Educational, Scientific and Cultural Organization
  • Pihak pengembang ingin menghubungi tim administrator sistem UNESCO untuk memastikan apakah ada masalah saat instalasi, dan membuat proses instalasi lebih mudah

Kasus penerapan yang diketahui dan pekerjaan ke depan

  • Kasus penerapan berskala besar yang telah dikonfirmasi mencakup:
    • Arsip Linux Kernel Mailing List
    • SVN FreeBSD, segera git
    • SourceHut
    • FFmpeg
    • Wine
    • UNESCO
    • The Science Olympiad Student Center
    • Lingkungan desktop Enlightenment
    • GitLab milik GNOME
  • Jika organisasi dengan skala sebesar ini menggunakan Anubis, masalah trafik bot bisa jadi berada pada tingkat yang jauh lebih serius daripada perkiraan sebelumnya
  • Seperti kasus YouTube yang pernah hampir mengalami “the inversion”, ketika trafik bot melebihi trafik manusia, pertanyaan yang tersisa adalah seberapa luas fenomena serupa telah menyebar di seluruh internet
  • Waktu perlu dialokasikan secara serius untuk Anubis dan stack terkait, dan jika dukungan dana yang cukup berhasil diperoleh, pekerjaan dapat dilakukan secara penuh waktu hingga memungkinkan perekrutan
  • Jika Anubis bermanfaat, dukungan melalui Patreon diminta

Bacaan terkait

1 komentar

 
GN⁺ 2025-04-14
Komentar Hacker News

  • Tulisan terkait: Anubis: proksi proof-of-work untuk memblokir crawler AI (100 points, 23 days ago, 58 comments) https://news.ycombinator.com/item?id=43427679

  • Menarik bahwa Xe mengubah sesuatu yang dulu nyaris seperti lelucon/postingan iseng menjadi produk yang benar-benar berguna. Memang selalu dibilang timing adalah segalanya
    Agak mengejutkan bahwa begitu banyak situs menginginkan atau membutuhkan ini. Saya paham masalah halaman Git yang lambat di sebagian server Git yang sangat dalam, tidak punya cache, dan disajikan dari disk yang lambat
    UNESCO agak di luar dugaan. Sub-situs itu cukup besar dengan ribuan dokumen, tapi karena kontennya statis, seharusnya mudah disajikan. Setelah dilihat, ternyata itu WordPress yang dideploy secara serampangan di atas Apache, tanpa cache, tanpa kompresi konten, dan tanpa HTTP/2·HTTP/3
    Kemungkinan besar mudah memperbaikinya agar bisa disajikan sangat murah bahkan di mesin yang sangat kecil, tapi tentu saja butuh keahlian, dan keahlian tetap tidak murah
    Bisa saja bertanya ke LLM, tapi kalau bahkan tidak tahu harus bertanya apa, itu belum terlalu membantu. Kalau tidak tahu dari awal bahwa situsnya lambat, kenapa akan bertanya. Mungkin hanya mendengar bahwa situs kewalahan oleh trafik lalu mencari pelindung furry

    • “Butuh keahlian, dan keahlian tetap tidak murah” memang benar, tapi di saat yang sama saya masih heran karena sepertinya orang yang tahu cara mengonfigurasi Anubis jauh lebih sedikit daripada orang yang berpengalaman mengelola WordPress
      Maksudnya bukan sulit, melainkan bahkan orang yang tahu keberadaannya saja sedikit
      Kalau menebak, alasan mereka tidak menyentuh WordPress mungkin bukan masalah teknis, melainkan karena tidak ingin mengutak-atik instance yang rapuh, masalah kewenangan organisasi, atau adminnya sudah berasumsi WP sudah dikonfigurasi dengan baik
    • Situs saya yang ingin saya pasangi ini punya banyak tulisan, dan lewat pencarian faset berbasis tag, jumlah kombinasi serta halaman yang mungkin praktis menjadi tak terbatas
      Ini tidak bisa di-cache, dan bot juga tidak mematuhi file robots, jadi mereka terus meminta URL dan mengambil tulisan berulang-ulang dengan berbagai angka dan kombinasi. Benar-benar bikin pusing
    • AI scraper bukan cuma implementasinya buruk, mereka juga sengaja melakukan invalidasi cache
      Solusi yang sejauh ini saya lihat hanyalah Cloudflare, mewajibkan login, Anubis, atau infrastruktur berskala tidak masuk akal
      Ada situs yang bilang 60% trafiknya berasal dari bot, dan untuk situs yang lebih kecil mungkin rasionya jauh lebih tinggi
    • Pertahanan bot/scraping/DDoS berbasis proof-of-work sudah ada bahkan 10 tahun lalu, jadi saya tidak tahu kenapa baru sekarang menyebar
      Saya juga ingat ada proyek yang mencoba menjadikan proof-of-work sebagai komputasi yang berguna

  • Kalau bingung ini apa, ini untuk memblokir scraping AI
    “Anubis menggunakan tantangan proof-of-work untuk memastikan klien memakai browser modern dan mampu menghitung checksum SHA-256”
    https://anubis.techaro.lol/docs/design/how-anubis-works
    Cukup keren, dan mungkin bisa membantu satu atau dua proyek saya

    • Sejak beberapa tahun lalu saya bertanya-tanya apakah web itu untuk manusia atau untuk mesin. Saya tidak bisa memikirkan alasan bagus untuk secara khusus memblokir bot dalam penyajian konten
      Membiarkan mereka menerbitkan konten atau menjalankan aksi tentu bisa bermasalah dalam banyak situasi
      Tapi untuk penyajian konten sederhana, biasanya manusia atau bot bukanlah kriteria yang ingin difilter atau diblokir. Kalau klien tertentu tidak menyalahgunakan sistem, kenapa harus peduli apakah klien itu manusia?

  • “Ia juga menggunakan waktu sebagai input. Karena sifat garis waktu linear, baik server maupun peminta tahu apa itu waktu”
    Ini kalimat lucu di dokumentasinya

    • Astaga, saya lupa pernah membiarkan itu tetap ada. Lucu juga. Sepertinya akan saya pertahankan saja
    • Sayangnya, jika dicabut dari konteks, pernyataan ini salah. Anubis membulatkan waktu ke minggu terdekat, dan jika minggu di sebelahnya juga valid, mungkin itu sudah cukup
      Karena berbagai alasan, ketidaksinkronan jam itu umum. Kita tidak bisa berharap 10% pengguna terbawah akurat bahkan pada skala tanggal, dan bahkan 25% terbawah bisa meleset sekitar 5 menit

  • Gambar-gambar halaman perantara yang muncul sampai pemeriksaan Anubis selesai benar-benar imut. Saya selalu merasa gambar dan karakter di blog Xe indah
    Sebagai catatan sampingan, saya juga penasaran ini akan berdampak seperti apa pada mesin pencari umum, dan apa bedanya dengan solusi Cloudflare untuk memblokir crawler AI; ternyata dijelaskan di halaman GitHub [1]
    “Jika Anda memasang dan menggunakan ini, besar kemungkinan beberapa mesin pencari tidak akan mengindeks situs web Anda. Ini dianggap sebagai fitur Anubis, bukan bug”
    “Ini memang respons yang agak seperti serangan nuklir, tetapi bot AI scraper mengeruk terlalu agresif sehingga tidak ada pilihan lain”
    “Dalam kebanyakan kasus Anda tidak perlu memakai ini, dan kemungkinan besar melindungi server origin tertentu dengan Cloudflare sudah cukup. Namun jika Anda tidak bisa atau tidak ingin memakai Cloudflare, ada Anubis”
    [1]: https://github.com/TecharoHQ/anubis/

    • Benar. Untuk saat ini, sayangnya ini memblokir indeks pencarian. Nantinya mungkin bisa memasukkan IP mesin pencari ke allowlist
      Namun tempat seperti Google kadang memakai IP yang sama untuk AI dan indeks pencarian
      Meski begitu, kami sedang memperbaikinya, misalnya dengan meloloskan tag Open Graph, supaya setidaknya rich preview bisa berfungsi
    • Saya setuju gambar-gambar halaman perantaranya imut. Tapi ngeri membayangkan suatu hari nanti seseorang akan menilai itu “bermasalah” dengan satu atau lain cara, lalu akhirnya dihapus

  • Saya sudah membaca tentang Anubis, dan ini proyek yang keren. Sayangnya, seperti yang disebutkan di komentar, pengunjung situs harus mengaktifkan JavaScript™
    Kalau situsnya memang membutuhkan JavaScript™ untuk meningkatkan pengalaman pengguna, itu sepenuhnya oke, tetapi kurang cocok untuk situs statis yang sama sekali tidak membutuhkan JS
    Saya membuat solusi sendiri yang efektif memblokir “bot jahat” semacam ini di level jaringan. Dengan database MaxMind serta WAF dan reverse proxy buatan sendiri, saya memblokir seluruh jaringan besar “Big Tech / Big LLM” pada level ASN(BGP)

    • Sebagian besar traffic bot yang ingin dibahas tulisan ini berasal dari rentang IP rumahan biasa
      Tentu ada juga permainan ASN dan penipuan reputasi, tetapi itu sangat sulit ditangani. Dari pemeriksaan log secara kasar, bot seperti ini biasanya hanya melakukan satu request dari IP rumahan tertentu, dan rentangnya kemungkinan juga dipakai pengguna manusia sungguhan
      Singkatnya, ada risiko memblokir traffic normal. Solusi ini juga punya risiko, tetapi risiko nyata bagi kebanyakan manusia jauh lebih rendah
      Akan bagus kalau JavaScript tidak diperlukan dan pengguna yang menonaktifkannya juga bisa didukung, tetapi pelanggan atau pengguna akhir belum pernah sekali pun mengeluhkan perlunya mengaktifkan JavaScript
      Yang menentang kewajiban JavaScript adalah minoritas yang vokal, dan sebagian besar dari mereka ketika menemui situs yang membutuhkan JavaScript tinggal mengaktifkannya. Bahkan saat itu, saya rasa hanya sangat sedikit yang sampai menghela napas kalah
    • Bagi yang penasaran, merek dagang “JavaScript” dimiliki oleh Oracle: https://javascript.tm/
    • Bagaimana tahu itu LLM atau VPN? Bagaimana memisahkan traffic LLM dengan database MaxMind?
    • Ada tautan ke solusi buatan sendiri itu?

  • Saya suka idenya, tetapi setelah sifat tantangannya lebih jelas, sepertinya ini mungkin harus turun ke level protokol
    Dari sisi aksesibilitas, pada akhirnya akan lebih baik jika tantangan proof-of-work menjadi bagian yang lebih dekat ke TCP, daripada diimplementasikan terpisah dengan JavaScript di tiap situs web

    • Ada Cloudflare PrivacyPass yang sudah menjadi standar IETF [0], tetapi cukup aneh dan implementasi referensinya adalah tumpukan bug
      [0] https://datatracker.ietf.org/wg/privacypass/about/
    • Cukup kirim tantangan arbitrer sebagai black box SPIR-V atau MLIR. Jika pertukaran tantangan-respons diintegrasikan dengan HTTP, ini akan memungkinkan dukungan luas dan akselerasi hardware yang fleksibel
      Solusi yang “cukup baik” adalah SHA(seed, nonce) yang sudah banyak dipakai. Jika perusahaan teknologi raksasa menginginkannya, ini bisa dengan mudah diintegrasikan ke lapisan yang lebih rendah dalam stack

  • Di ponsel saya, penyelesaian deteksi bot memakan waktu sampai 5 detik

    • Saya memakai Fennec, fork Firefox dari F-Droid, dan Pixel 9 Pro XL; pada tingkat kesulitan 4 butuh sekitar 8 detik
      Secara pribadi, karena saya tidak perlu melakukan apa pun, menurut saya pengalaman penggunanya tidak terlalu buruk. Jelas lebih saya sukai daripada CAPTCHA
    • Jauh lebih baik daripada loop CAPTCHA Cloudflare tanpa akhir
    • Beruntung. Saya butuh 30 detik
    • Menarik, pada saya sekitar 0,5 detik

  • Saya sedang membuat prototipe yang sekarang saya sebut “Enigma webfont”. Saya ingin menerapkan seed dan nilai rotasi kustom per sesi pengguna pada webfont yang disajikan dan di-cache
    Tujuannya adalah membuat web scraping menjadi tidak praktis karena biaya komputasi OCR. Saat ini ini permainan kucing-kucingan, dan saya ingin sedikit mengubah keadaan
    Tanpa sesi pengguna, source HTML pada dasarnya menjadi tidak bermakna, dan jika cache aset hilang dengan perilaku seperti OTP, halaman web juga bisa dibuat tidak terbaca
    Dengan begitu, kita bisa membuat CAPTCHA yang secara efektif meminta pengguna menyesuaikan jendela seed lokal sampai mereka bisa membaca kata tertentu. Misalnya, “Geser slider sampai kata Foxtrott terbaca”
    Saya sangat ingin mendengar pendapat Xe. Bisakah kita menggabungkan kekuatan?
    Tech stack-nya Go, karena itulah satu-satunya bahasa yang memudahkan saya mengubah file webfont secara langsung tanpa masalah

    • Di luar masalah aksesibilitas yang jelas, bukankah itu paling-paling hanya sandi substitusi? Dengan korpus yang cukup, dekripsinya sepertinya akan jauh lebih mudah
    • Masalahnya bukan sekadar situs web di-scrape, melainkan volume request yang menjatuhkan infrastruktur atau menaikkan biaya. Mesin pencari sudah melakukan hal ini selama lebih dari 30 tahun
      Merusak teks tidak akan membantu. Mereka tetap akan terus menghajar. Kalau melihat pola traffic-nya, orang yang membuat bot-bot ini cuma... <https://www.youtube.com/watch?v=ulIOrQasR18>
      Mengenai “Saya ingin mendengar pendapat Xe. Bisakah kita menggabungkan kekuatan?”, sejauh yang saya pahami, proyek ini tampaknya lebih membutuhkan bantuan untuk membuatnya lebih berkelanjutan dalam waktu dekat maupun jangka panjang, bukan menambahkan lebih banyak fitur. Anubis tampaknya sudah bekerja dengan baik

  • Jelas ini bekerja dengan baik untuk memblokir pengguna yang menonaktifkan JavaScript

    • Benar. Sebagai upaya membuatnya terlihat menarik bagi lebih banyak orang, ini benar-benar lemah. Kecuali mereka merilis versi nojs, dalam hal merusak web, ini tidak berbeda dari scraper “AI”