1 poin oleh GN⁺ 1 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Sebagian Wandering Thoughts dan CSpace menampilkan halaman pemblokiran jika User-Agent browser lama terkena aturan anti-crawler
  • Pada awal 2025, crawler massal meningkat, dan sebagian tampaknya bertujuan mengumpulkan data untuk pelatihan LLM serta menggunakan User-Agent Chrome lama
  • Untuk mengurangi beban situs, sedang diuji pemblokiran User-Agent browser lama, dan pengguna normal juga bisa salah terdeteksi
  • Jika tetap diblokir meski memakai browser terbaru, Anda bisa menghubungi melalui halaman pribadi University of Toronto dan harus mengirimkan browser yang dipakai serta string User-Agent yang tepat
  • Keluarga archive.* sulit dibedakan karena User-Agent Chrome lama dan IP terdistribusi, sehingga archive.org direkomendasikan untuk arsip Wandering Thoughts

Alasan halaman pemblokiran ditampilkan

  • Saat mengakses sebagian Wandering Thoughts atau CSpace, halaman pemblokiran akan ditampilkan jika versi browser diklasifikasikan sebagai mencurigakan oleh aturan anti-crawler situs
  • Per awal 2025, crawler massal meningkat, dan sebagian tampaknya ditujukan untuk pengumpulan data pelatihan LLM serta menggunakan berbagai User-Agent browser lama termasuk Chrome User-Agent lama
  • Sedang dilakukan eksperimen memblokir User-Agent browser lama untuk mengurangi beban situs, dan pengguna normal juga bisa terkena aturan ini
  • Jika Anda menggunakan browser terbaru tetapi tetap diblokir, Anda dapat menghubungi lewat halaman pribadi University of Toronto dan, jika memungkinkan, kirimkan browser yang digunakan beserta string User-Agent yang tepat

Catatan untuk tiap pengguna

  • Pengguna Inoreader

    • Pengambil feed Inoreader sendiri bukan target pemblokiran, dan memang secara berkala masih mengambil feed
    • Inoreader dapat mengambil feed atau halaman memakai HTTP User-Agent browser lama atau browser lama yang sebenarnya, lalu menampilkan halaman pemblokiran yang diterima kepada pengguna
    • Hasil permintaan HTTP terbaru dapat berbeda tergantung HTTP User-Agent yang digunakan; penjelasan terkait ada di HTTPResultsAndUserAgents
  • Pengguna Vivaldi

    • Karena serangan yang sedang berlangsung, Vivaldi terbaru pun bisa diblokir jika teridentifikasi sebagai Google Chrome
    • Anda mungkin perlu mengubah setelan "User Agent Brand Masking" agar Vivaldi teridentifikasi sebagai Vivaldi, bukan Google Chrome
  • Pengguna archive.*

    • Anda bisa melihat halaman pemblokiran ini melalui archive.today, archive.ph, archive.is, dan sejenisnya
    • archive.* menggunakan User-Agent Chrome lama, merayapi dari blok IP yang tersebar luas, dan sebagian IP memiliki entri reverse DNS palsu yang mengaku sebagai IP googlebot, sehingga sulit dibedakan dari pelaku jahat
    • Jika ingin mengarsipkan Wandering Thoughts, disarankan menggunakan archive.org, crawler arsip yang bekerja lebih baik

1 komentar

 
GN⁺ 1 jam lalu
Komentar Lobste.rs
  • Bergantung pada bahasanya, saran untuk memulai Eglot secara otomatis bisa jadi sangat buruk. Banyak server LSP untuk berbagai bahasa tidak aman digunakan pada kode yang tidak tepercaya, dan hanya dengan membuka file dari proyek Rust atau Elixir yang dikendalikan penyerang saja mesin bisa dikompromikan
    Kecuali untuk bahasa yang punya server LSP yang diketahui aman, sebaiknya hindari mengaktifkan LSP otomatis. Referensi: https://rust-analyzer.github.io/book/security.html

    • Jika melihat kode yang mungkin bersifat adversarial, pada akhirnya seluruh pekerjaan harus dilakukan di dalam batas keamanan yang nyata. Bahkan git status pun bisa menjadi permukaan serangan: https://github.com/justinsteven/advisories/…
      Bedanya, pada kasus di atas eksploit harus ada di repositorinya sendiri, sedangkan pada LSP masalah juga bisa muncul dari sisi dependensi. Tetap saja, kalau sudah terbiasa menyalakan LSP secara refleks, sepertinya sulit mencegah diri menjadi kebal terhadap peringatan
    • Alasan lain untuk menghindari auto-start adalah karena kebutuhan sumber daya beberapa language server sangat besar. Di proyek Rust skala menengah, hanya dengan membuka file sebentar saja proses rust-analyzer sebesar 4GB bisa berjalan selama beberapa menit, dan direktori target/debug/ berukuran lebih dari 1GB bisa muncul
    • Toh begitu menjalankan cargo build, semuanya pada dasarnya sudah terlanjur terjadi. Tentu ada perbedaan besar antara memuat LSP otomatis dan perintah yang dijalankan pengguna secara eksplisit, tetapi dalam praktik nyata perbedaannya mungkin lebih kecil dari yang dibayangkan
    • Jika menginginkan otomatisasi, lebih baik seperti lsp-mode: tanya dulu sebelum aktif lalu tambahkan proyek ke allowlist. Jika sudah ada hook yang “berjalan otomatis”, cukup sekitar 10 baris untuk membuatnya lebih dulu menanyakan “apakah Anda memercayai folder ini?” lewat read-from-minibuffer, dan jika direktori acuan ditentukan dengan sesuatu seperti projectile, sebagian besar manfaat keamanannya bisa didapat
      Konfigurasi saya memakai allowlist lsp-mode tetapi dibersihkan setiap sesi, jadi setiap kali Emacs dibuka lagi saya harus menyetujui ulang per proyek. Awalnya saya tampaknya melakukan ini karena alasan performa, dan kadang lsp-mode meluncurkan beberapa proses bahkan sebelum benar-benar membuka proyek tertentu. Risiko keamanannya nyata, tetapi membuat alur kerja yang masuk akal juga tidak terlalu sulit
  • Hal yang paling mengganggu dari Eglot adalah kebanyakan perintah tidak diekspos sebagai fungsi, melainkan didefinisikan di atas antarmuka Emacs seperti xref. Saat ada backend xref dari CIDER dan clojure-lsp sekaligus, seperti pada Clojure, saya cenderung lebih memilih sisi CIDER yang mengetahui keadaan runtime sebenarnya dari kode yang sedang dimuat
    Analisis statis clojure-lsp bisa kehilangan sinkronisasi, terutama pada alur kerja REPL jarak jauh. Di lsp-mode, fitur seperti pergi ke definisi bisa dipanggil langsung sebagai perintah sambil tetap memakai xref, tetapi di Eglot cukup merepotkan untuk menyingkirkan hanya backend xref tertentu. Perintah lain yang ada di lsp-mode juga tidak ada di Eglot, padahal sebenarnya merupakan fitur yang bisa disediakan lewat titik integrasi Emacs yang mirip dengan xref

  • Saya pernah mencoba lsp-mode, tetapi langsung menghapusnya karena terlalu banyak popup dan notifikasi yang membingungkan. Eglot memberi pengalaman LSP yang jauh lebih senyap
    Tinggal dibiarkan aktif lalu gunakan fiturnya saat sudah siap. Menarik melihat bagaimana ~cks mengambil pendekatan dari arah sebaliknya sambil menyebutkan berbagai tip dan alternatif

    • Saya memakai lsp-mode dengan banyak fitur dimatikan sehingga antarmukanya cukup tenang. Saya sempat mau pindah ke Eglot, tetapi saat itu tampaknya tidak punya fitur integrasi yang saya inginkan, jadi tidak saya lanjutkan
      Yang benar-benar ingin saya temukan adalah server LSP yang bisa menangani repositori yang sangat besar. Ini sering menjadi batas yang terasa, dan saya sempat berpikir apakah perlu membuat sesuatu yang mengerjakan sebagian besar pengindeksan sumber sekali saja lalu memakainya ulang untuk berbagai pekerjaan bergaya LSP, tetapi saya juga khawatir jangan-jangan itu cuma usaha merebus lautan yang lain
  • Eglot dan lsp-mode adalah klien LSP untuk Emacs yang paling terkenal, tetapi ada juga alternatif seperti lspce dan lsp-bridge
    Saya sudah memakai Eglot dengan puas selama beberapa tahun, tetapi ada keterbatasan desain yang bisa makin jadi masalah ke depan. Eglot mengasumsikan satu klien per buffer; saat Eglot dibuat itu masuk akal, tetapi sekarang makin umum ada kasus ketika kita ingin menjalankan beberapa server LSP dalam satu buffer. [Rekomendasi] saat ini adalah memakai program terpisah sebagai multiplekser LSP

    • Untuk tujuan itu ada this
  • Empat hari lalu saya pindah dari lsp-mode ke Eglot untuk Python dan puas sejauh ini
    Saya membagikan versi minimum dari konfigurasi saya saat ini di sini: https://discuss.afpy.org/t/configuration-emacs-minimale-en-2026/3001

    • Hampir setahun lalu saya beralih dari elpy ke eglot + basedpyright, dan saya juga cukup puas
      Hanya saja ada sedikit gangguan soal completion. Misalnya saat menekan foo<tab><tab>, kadang basedpyright malah mengimpor otomatis sesuatu yang aneh padahal ada simbol yang cocok di scope saat ini, dan saya masih belum menemukan cara agar completion hanya sampai string umum terpanjang. Selain itu, sejauh ini cukup bagus
  • Saya iri pada orang-orang yang berhasil membuat Emacs terasa seperti IDE modern. Saya memang memakai key binding Emacs, tetapi meski sudah menghabiskan 6–8 jam saya tidak pernah bisa membuat Emacs bekerja seperti IDE
    Dulu saya mencoba menyesuaikannya dengan FB Flow, yang saya pakai sebagai pengganti TypeScript di lingkungan pengembangan Linux dan FreeBSD, lalu menyerah; akhir pekan lalu saya juga kembali menyerah saat mencoba membuat lingkungan Python full-featured di Windows lengkap dengan tree-sitter. Terlalu banyak yang harus dikonfigurasi, dan terlalu banyak DLL seperti parser tree-sitter yang juga harus diunduh terpisah, jadi yang dibutuhkan untuk menjadikannya seperti IDE sungguhan terasa berlebihan. Sekarang saya tidak ingin lagi menginvestasikan waktu sebanyak itu, tetapi sesekali menyenangkan juga ketika saya mengetik emacs -nw di terminal mana pun dan lingkungan penyuntingan yang familier langsung muncul

    • Untuk Python, konfigurasi minimal seperti fido-vertical-mode, which-key-mode, global-completion-preview-mode, yasnippet, eglot-ensure, dan basedpyright sudah cukup untuk mulai
      Jika basedpyright ada di path, completion dan syntax highlighting yang layak tetap bisa didapat bahkan tanpa grammar tree-sitter. Itu versi yang dipangkas seminimal mungkin dari konfigurasi penuh saya, dan konfigurasi lengkapnya ada di my full config
    • doom emacs layak dicoba. Konfigurasinya sangat mudah dan dalam keadaan bawaan pun sebagian besar sudah berjalan baik. Kalau tidak suka evil-mode, Anda juga bisa kembali ke key binding Emacs