Agresif yapay zeka kazıyıcıları wiki işletimini ciddi biçimde zorlaştırıyor

 (weirdgloop.org)
5 puan yazan GN⁺ 2 시간 전 | 2 yorum | WhatsApp'ta paylaş
  • Yapay zeka kazıyıcı trafiği, herkese açık wikilerin maliyetini ve istikrarını sarsıyor; hafifletilmezse tüm insan etkinliğinin toplamından yaklaşık 10 kat fazla hesaplama kaynağı tüketebiliyor
  • Botlar, GPTBot gibi tanınabilir User Agent’ların ötesine geçip başlıklarını güncel Chrome gibi gösteriyor ve günde 1 milyon IP döndüren konut proxy’leriyle engelleri aşıyor
  • Wikiler, makalelerden çok daha fazla sayıda eski sürüm, düzenleme ekranı ve özel sayfa URL’si açığa çıkardığı için, naif tarama önbelleği atlayabiliyor ve normal isteklere göre 50–100 kat daha pahalıya mal olabiliyor
  • Cloudflare Challenge, Anubis, manuel güvenlik duvarı kuralları ve insan davranışı isteği tabanlı tespit etkili olsa da yanlış pozitifler, bakım yükü ve okur sürtünmesi yaratıyor
  • Giriş zorunluluğu ya da herkese challenge uygulamak gibi aşırı engellemeler yeni katkıları azaltabileceğinden, yöneticiler arasında açık tartışma ve bot toplama teşviklerini değiştiren API yaklaşımları gerekiyor

Yapay zeka kazıyıcılarının wiki işletimine getirdiği yük

  • LLM eğitim verisi için bot kazıması benzeri görülmemiş ölçekte artarken herkese açık web sitelerinin maliyetini ve istikrarını sarsıyor: ilgili sorunlar FOSS infrastructure is under attack by AI companies, Are AI bots knocking cultural heritage offline?, Smart TV web crawler AI yazılarında da ele alınıyor
  • Weird Gloop, Minecraft Wiki, OSRS Wiki, League Wiki gibi büyük oyun wikilerini barındırıyor ve son 3 yıldır bot trafiğiyle mücadeleye giderek daha fazla zaman ayırıyor
  • Sürekli hafifletme yapılmazsa botlar, on milyonlarca insan sayfa görüntülemesi ve günde on binlerce düzenleme dahil geri kalan her şeyin toplamından yaklaşık 10 kat fazla hesaplama kaynağı kullanabiliyor
  • Wikimedia Foundation da tarayıcıların operasyonlar üzerindeki etkisini ele alan bir yazı yayımladı; büyük wiki çiftlikleri farklı düzeylerde kesinti yaşadı ve bazı küçük bağımsız wikiler tamamen çevrimdışı kaldı
  • Bu yıl wiki ekosistemindeki sunucu sorunlarının yaklaşık %95’inin kötü niyetli kazıyıcılardan kaynaklandığı tahmin ediliyor

İnsan gibi görünmeye çalışan kazıyıcılar

  • GPTBot, ClaudeBot, PerplexityBot gibi büyük yapay zeka şirketlerinin “resmî” botları zaman zaman robots.txt kurallarına uymasa da genelde User Agent dizgesinden ayırt edilebiliyor; bu yüzden Cloudflare’in AI bot engellemesi ya da nginx ile engellenmeleri kolay
  • Web yöneticileri User Agent tabanlı engelleme yapmaya başlayınca botlar için insan trafiği gibi görünmek güçlü bir teşvik haline geldi
  • Son dönemde wikilere ulaşan yapay zeka kazıyıcı trafiğinin çoğu, başlıklarını güncel Google Chrome gibi gösterecek şekilde gönderiyor ve istekleri daha sofistike biçimde kurguluyor
  • Eskiden kullanılan açık “bot mu gerçek insan mı” sinyalleri ortadan kalktığı için engelleme zorlaştı

On milyonlarca IP ve proxy ile aşma

  • 2023 öncesinde sorunlu kazımanın %95’i tek bir IP adresinden ya da küçük veri merkezi alt ağlarından geliyordu; bu nedenle IP veya ISP özelliklerine dayalı engelleme çoğunlukla işe yarıyordu
  • Konut proxy’leri kullanıldığında yalnızca bir kredi kartıyla milyonlarca IP adresinden oluşan bir ağ üzerinden kazıma istekleri aklanabiliyor
  • Wikiler bazen günde 1 milyon IP döndüren kazıyıcı çalıştırmalarıyla karşılaşıyor; bunlar Comcast, AT&T, Charter gibi konut tipi ISP’lerden gelen meşru istekler gibi görünüyor
  • Bu müşteriler kendi IP’lerinin konut proxy çıkış düğümü olarak kullanıldığını büyük olasılıkla bilmiyor
  • Bazı kötü niyetli aktörler, facebookexternalhit bağlantı önizlemesi ya da Google Translate kullanarak isteğin Google/Facebook sunucularından geliyormuş gibi görünmesini sağlıyor ve gerçek kaynağı gizliyor
  • Google Translate URL aracı üzerinden gelen isteklerin %99,99’unun kötüye kullanım niteliğinde olduğu durumlar bile görüldü; bu yüzden bir dönem tüm wikilerde bu araç bozulmak zorunda kaldı

Wikiler için özellikle pahalı olan “aptal URL” taraması

  • Birçok yapay zeka kazıyıcısı wiki ana sayfasını ziyaret ettikten sonra o sayfadaki tüm bağlantılara, ardından o sayfalardaki tüm bağlantılara giderek URL seçiyor
  • robots.txt ve site haritası kazımaya değer URL’leri gösterse de bunları fark etmiyormuş gibi davranıyorlar
  • OSRS Wiki’de yaklaşık 40 bin makale var ve sitenin faydalı bilgilerinin büyük kısmını bu URL’ler oluşturuyor
  • Ancak eski sürümler, düzenleme ekranları, özel sayfalar dahil edildiğinde gezilebilir URL sayısı en az 1 milyara ulaşıyor
  • Bu tür naif tarama hiç bitmiyor ve LLM eğitim verisi için yararlı olmayan URL’lerde çok fazla kaynak harcandığı görülüyor
  • Garip istekler, gerçek kullanıcı isteklerinin kullandığı MediaWiki parser cache gibi önbellek katmanlarını atlayarak hizmet maliyetini artırıyor
  • Önbellek isabetli istekler genelde 20 milisaniyeden kısa sürede işlenirken, eski diff gibi istekler sık sık 1–2 saniye sürüyor
  • “Günde 8 milyon bot isteği”, “botlar bant genişliğinin %65’ini kullanıyor” gibi üst düzey metrikler sorunu olduğundan küçük gösteriyor
  • Gerçek darboğaz çoğu zaman CPU kapasitesi; tuhaf sorgu parametreleri taşıyan bot isteklerinin işleme maliyeti normal isteklere göre sık sık 50–100 kat daha yüksek oluyor

Ortalama metriklerde görünmeyen trafik sıçramaları

  • Aylık bot isteği yaklaşık 250 milyon, saniye başına ortalama yaklaşık 100 düzeyinde; ancak bu yalnızca uzun dönem ortalaması
  • Kazıyıcılar kısa sürelerde saniyede 1.000’den fazla istek göndermeyi sık yapıyor ve bunu geleneksel DDoS saldırılarından ayırmak neredeyse imkânsız
  • Uzun vadede botlar toplam CPU kullanımının yalnızca yaklaşık %50’sini oluşturuyor olsa bile, kötü niyetli trafik sıçramaları wiki yavaşlamalarının ve kesintilerinin yaklaşık %95’ine neden oluyor

Kimin yaptığını anlamanın zor olduğu yapı

  • Trafiğe “yapay zeka kazıyıcısı” deniyor ama hepsi Google Chrome gibi göründüğü için gerçekte kimin sorumlu olduğunu ya da wiki verisini ne için kullandığını anlamak zor
  • Olası aktörler arasında veri broker’ları, frontier lab’lerin yinelenen veri toplaması ya da konut proxy’lerine erişebilen bağımsız projeler bulunabilir
  • Giriş eşiğinin gerçekte ne kadar düştüğü de belirsiz
  • Daha iyi bir yöntem varsa, gerçek veri toplayıcılarla doğrudan iletişim kurup daha az verimsiz yollar bulmak istiyorlar

Şimdiye kadar işe yarayan önlemler

  • Cloudflare Challenge ve Anubis

    • Web sitesini Cloudflare challenge ya da Anubis gibi araçların arkasına koymak, son 1 yılda internette yaygın biçimde kullanılan bir yöntem haline geldi
    • Bir ölçüde etkili olsa da bazı botlar belirli dönemlerde challenge’ı düzenli olarak geçebiliyor
    • Cloudflare ile bot geliştiricileri arasında görünmez bir silahlanma yarışı var gibi görünüyor; Cloudflare yaklaşık %90 oranında kazanıyor ama kalan %10 operasyon açısından zorlayıcı bir alan yaratıyor
    • Gerçek okurlar wikiye ulaşmadan önce challenge görmeyi sevmiyor
    • Çoğu insanı etkilememek için challenge’ın hangi trafiğe uygulanacağına karar veren iyi sezgisel kurallar gerekiyor; ancak otomatik trafiği güvenilir biçimde tespit etmek zaten başlı başına zor

  • Manuel güvenlik duvarı kuralları

    • Çoğu işletmecinin kendi altyapısına ve geçmiş saldırılarına göre uyarlanmış manuel güvenlik duvarı kuralları var
    • Bu filtreler genelde belirli User Agent dizgelerine, IP gruplarına veya ASN’lere dayanıyor
    • Weird Gloop bunların çoğunu Cloudflare/CDN katmanında ele alıyor, başka wikiler ise bunu nginx ya da web sunucusu tarafında yapıyor
    • Bugün User Agent/IP tek başına çoğu durumda yeterli olmuyor; HTTP sürümü, başlıklar, TLS cipher, ja4 ile ilişkili hash’ler gibi daha karmaşık istek özelliklerine bakmak gerekiyor

  • “İnsanların yaptığı ama botların yapmadığı şeyleri” bulmak

    • Yararlı bir yaklaşım, insanların topluca yaptığı davranışlardan botların yapmadıklarını bulmak
    • MediaWiki tabanlı wikilerde gerçek tarayıcı kullanıcıları wikiyi kullanırken sık sık birkaç farklı türde HTTP isteği üretiyor, botlar ise genelde bunu yapmıyor
    • Başlıklar, ja4 hash’leri vb. ile ayrılabilen bir trafik kümesi çok sayıda makaleyi ziyaret ederken tipik “insan” isteklerini üretmiyorsa, bu o trafiğe challenge uygulamak için güçlü bir sinyal oluyor
    • Bot trafiğinde bulunmayan insan davranışı isteklerine bakmak güçlü bir yöntem
    • “Eksik” trafiği analiz ederek hangi trafiğe challenge uygulanacağına dair karar ağacı tabanlı sezgisel kuralları otomatik öneren bir sistem oluşturmaya başlanmış durumda
    • Testlerde bunun neredeyse tüm kazıyıcıları iyi yakaladığı görüldü; ancak NoScript kullanıcıları, ekran okuyucu kullanıcıları ya da beklenmedik cihazlar kullanan kişiler gibi alışılmadık gezinme alışkanlıklarına sahip insanlarda ne tür yanlış pozitifler çıkacağı net değil
    • Kendi ML/veri analizi altyapısını kurmak ve bunu kalıcı biçimde sürdürmek de ayrıca yük oluşturuyor

  • Daha egzotik tespit teknikleri

Okurlar için kötü olan aşırı seçenekler

  • Yapay zeka kazıyıcılarını durdurmak için kullanılan “nükleer seçenekler”, gerçek kullanıcılar için çok daha yıkıcı
  • Yaygın yöntemlerden biri, üretilmesi maliyetli olabilecek sayfaları görmek için giriş yapma zorunluluğu getirmek
  • Fandom birkaç ay önce tüm wikilerinde böyle bir önlem uyguladı
  • Başka bir yöntem tüm trafiğe Cloudflare challenge sunmak
  • Web yöneticisinin bakış açısından anlaşılır olsa da wiki ve topluluğun uzun vadeli sağlığı için kötü
  • 16 yıldır wiki topluluğu inşa ederken öğrenilen temel ders şu: yeni katkıcı çekmenin en iyi yolu sürtünmeyi azaltmak
  • Düzenlemeyi kolaylaştırmak, wiki içi yapının gezinmesini kolaylaştırmak ve okurla editör arasındaki giriş bariyerini düşürmek gerekiyor
  • Aşırı anti-bot teknikleri yeni sürtünmeler yaratıyor ve öngörülebilir sonuçlar doğuruyor
  • Fandom, hesapsız okurların %95’inden fazlasına “iç sayfaları” gizledikten sonra, Fandom genelinde yeni kullanıcı katkılarının yaklaşık %40 azaldığı görüldü
  • Bu tür ödünleşimlerin değerli olduğunu düşünmek zor

İleriye dönük yön

  • Weird Gloop hâlâ wiki barındırmayı sürdürüyor ve Fandom’dan ayrılmak isteyen wikilere yardım etmeye da devam ediyor
  • Uzun vadede “AI Overviews”, wiki okurlarını wiki katkıcılarına dönüştüren hattı öldürebilir; ancak bu ayrı bir sorun olarak bırakılıyor
  • Bazı tanıdıklar bot dalgasının Weird Gloop’un lehine olabileceğini düşünüyor, ancak insanlar kolayca wiki barındıramazsa internet daha kötü bir yer olur
  • Wikileri istikrarlı biçimde barındırmak için nöbet rotasyonu, ML mühendisleri ve kurumsal ürünler gerektiren bir senaryo, bağımsız wiki toplulukları için çok kötü haber olur
  • Bot sahipleri ile web yöneticileri arasındaki silahlanma yarışının, kazımanın yapısal teşviklerini değiştiren akıllı bir yöntem ortaya çıkana kadar sürmesi muhtemel
  • Cloudflare’in yeni crawling API’si, botlar robots.txt’yi görmezden gelip sorun çıkaran kendi sistemlerini kurmak yerine API kullanmayı daha kolay bulursa dengeleri değiştirebilir
  • Kazımanın hiç olmaması daha iyi olurdu, ancak yaşanmış olanı geri almak zor

Açık tartışma ve işbirliği ihtiyacı

  • Binlerce işletmeci kendi web sitelerini yönetiyor ve botlarla başa çıkmak için daha akıllı teknikler arıyor
  • Başka sistem yöneticileriyle yapılan özel konuşmalarda somut ve iyi fikirler çıktı; Slack, Discord ve küçük gruplar içinde de büyük olasılıkla çok sayıda tartışma dönüyor
  • Gerçek operasyonel ayrıntılar üzerine daha fazla açık tartışma gerekiyor
  • Birçok sistem yöneticisi yaşadığı sorunun başka işletmecilerin sorunlarıyla neredeyse aynı olduğunun yeterince farkında değil
  • Herkes kendi savunma yöntemlerini açıklamak istemiyor; açıklandığında avantajın kaybolacağı endişesi de var
  • Yine de insanların birlikte düşünmesine yardımcı olunabiliyorsa, bazı taktiklerin etkisini azaltma riski alınmaya değer
  • Yapay zeka kazıyıcılarıyla uğraşan sistem yöneticileri, kendileri için işe yarayan yöntemleri uygun gördükleri alanlarda paylaşmalı
  • Bot sorunu çözen ürünler satan şirketler, yapay olmayan koşullarda precision and recall oranlarına dair gerçek veriler içeren vaka çalışmalarını daha fazla yayımlamalı
  • Satın alma kararı verenler için önemli olan kutucuk doldurmak değil, gerçek sonuçlar
  • Wiki ya da bağımsız bir web sitesi işletiyor ve bot tespiti üzerine konuşmak istiyorsanız e-posta veya Discord mesajı ile iletişime geçebilirsiniz

İlgili okumalar

2 yorum

 
xguru 41 분 전

Temelde GeekNews’a da çok sayıda crawler geliyor; bu yüzden çeşitli yöntemler devreye alıp bunları engelliyor ve maliyetleri optimize ediyoruz. Çin tarafındaki AI botları gerçekten son derece agresif şekilde crawl ediyor.

Ama bir yandan, CDN tarafında engelleme yapmaya çalışınca bunun da ek maliyet yaratması ayrı bir sorun.
 
GN⁺ 2 시간 전
Lobste.rs görüşleri

  • Anubis'in eksiklerini tamamlamak için bekleme kanıtı (proof-of-wait) challenge'ını denedim ve oldukça etkili oldu
    Temelde, genel istek oranı eşik değerin altındaysa filtreyi kapatıyor, eşiği aşarsa kullanıcı devam etmeden önce N saniye bekletiyorum
    Ardından o IP'ye bağlı bir token verip, süresi dolana kadar yalnızca az sayıda isteğe izin veriyorum; token'ın kendisine de hız sınırı uyguluyorum
    Başarılı istekler gelmeye devam ettikçe bekleme süresi kademeli olarak artıyor
    Oldukça başarılı oldu; mobil cihazları aşırı derecede dezavantajlı duruma düşürmeden yumuşak şekilde performans düşürüyor ve JavaScript olmadan da çalışıyor

    • Bunun marginalia.nu'da çalıştığını gördüm; telefon bataryasını proof-of-work için harcamadığı için hoşuma gidiyor
    • Bu, açık kod tabanının bir parçasıysa, bunu uygulayan kaynak kodu bağlantısını alıp alamayacağımı merak ediyorum
    • Harika. Böyle bir yaklaşımı TLS'in parçası haline getirmeye yönelik bir çaba olup olmadığını merak ediyorum. Proof-of-work challenge'ları için draft-venhoek-tls-client-puzzles-00'ın yapmaya çalıştığı şeye benziyor
      Bunun TLS ya da hatta işletim sisteminin IP yığını gibi çok daha alt katmanlarda olması gerektiğini düşünüyorum
      Bekleme kanıtını derinlemesine düşünmedim ama meşru kullanıcılar için bu, otomatik scraper'lardan daha kötü değil mi? İnsanlar beklemekten rahatsız olur ama scraper token'ı saklayıp N saniye sonra geri gelir
      Proof-of-work konusunda da ikilemliyim ama en azından scraper'lara ölçekle orantılı gerçek bir maliyet yüklüyor
    • Kurulumunun kolay olup olmadığını merak ediyorum. Kendi wikim için de ilgimi çekti
    • Yararlı bir yaklaşım gibi görünüyor. Detayları yazıya dökmeyi planlıyor musunuz, merak ediyorum
      Bekleme kanıtı, proof-of-work konusunda endişeleri olan kişileri rahatlatabilir

  • Bazı özel sayfaları, bir kez giriş yapıp ilgili çerezi almış istemcilerle sınırlamak; aksi halde reddetmek de oldukça iyi çalışıyor
    Çoğu crawler wiki'yi taramak için özel sayfaları hedeflediğinden, bunları giriş yapmış kullanıcılarla sınırlayabiliyorsunuz
    Bu yapılandırmada wiki kullanıcı oluşturulmasına izin vermiyor
    <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 "Erişim reddedildi, lütfen giriş yapın."
    Require all denied
    </If>
    Bu sayede sistem yükümüz ciddi biçimde azaldı. Önceden özel sayfalar o kadar yoğun taranıyordu ki wiki'nin kullanılamaz hale geldiği zirveler sık yaşanıyordu
    Bunun dışında, bilinen AI crawler user-agent'larını doğrudan 403 ile engelliyor, Alibaba ya da Amazon Cloud gibi belirli IP bloklarını da kapatıyoruz
    İlginç olan, karşı tarafın bunu fark etmesi oldu. Diff görünümünden sayfaları tararken kısıtlayınca aynı şeyi MobileDiff görünümünden denediler
    Birkaç tur gidip geldik ama birkaç aydır bu yöntemle sorunsuz ilerliyor

    • User-agent tabanlı engelleme, pratikte yapabileceğiniz en kötü şeylerden biri sayılır
      User-agent ile engellerseniz crawler, insan gibi görünen bir user-agent ile tekrar dener ve siteyi keşfetmeye başlar
      Engelleme tetikleyicisinin user-agent olduğunu anlarsa cehennem moduna geçer; tespiti çok daha zorlaşır ve siteyi canı çıkana kadar döver
      IP aralığı engelleme de yardımcı olur ama mobil kötü amaçlı yazılım proxy'leri üzerinden tarama yaptıkları için yeterli değildir ve hepsini yakalayamaz
      Başta engellemezseniz genelde nispeten uslu kalırlar
      Bu yüzden püf nokta engellemek yerine onlara ucuza üretilmiş çöp veri yedirmek ve cehennem modunu tetiklememektir; ben https://iocaine.madhouse-project.org/ kullanıyorum
    • Bilginiz olsun, bunu MediaWiki izinleriyle de yapabilirsiniz. Varsayılanı tüm izinler reddedildi şeklinde bırakıp anonim kullanıcılara yalnızca ana ad alanındaki sayfaları okuma iznini geri eklerseniz kedi-fare oyunu ortadan kalkar
      Ancak o durumda yanıtları doğrudan MediaWiki'nin sunması gerekir; Apache'de halletmenin de avantajı var
    • Bunu hemen fark edip etmediklerini merak ediyorum. Bence scraper yazarları zaten çeşitli alternatif teknikleri hazır tutuyordu ve 403 almaya başlayınca bot bunları sırayla denemiştir

  • Konudan biraz sapacağım ama Weird Gloop mükemmel bir hizmet. İşlettikleri wikilerin kalitesi çok yüksek ve hayran yapımı içeriği Fandom'un korkunç platformundan taşımak dünyaya faydalı bir iş

  • Gergely Nagy, a.k.a. algernon ve iocaine geliştiricisi bu sorunla bir süredir uğraşıyor; Weird Gloop için faydalı içgörülere sahip olma ihtimali yüksek

  • Bunu söylemekten hoşlanmıyorum ama insan davranışına göre ayarlama önerisi sonunda geri tepecek gibi geliyor
    Botlar yakında sayfanın tüm statik varlıklarını da istemeye başlayacak ve bunun insanı ayırt eden davranışın parçası olduğu varsayılacak
    İlginç bir oyun, Profesör Falken

  • Eğer scraper sıradan <a href=...> bağlantılarını özyinelemeli biçimde takip ederek bu tür sayfalara ulaşıyorsa, geçmiş farkları gibi pahalı ve önbelleğe alınmayan sayfaları yalnızca <form method="POST" action=...> gönderimiyle erişilebilir yapıp nazikçe başka yöne yönlendirebilir miyiz diye düşünüyorum
    Böylece hiçbir şeyi engellememiş oluruz; hatta scraper açısından da neredeyse sonsuz tekrarlı bilgiyi özyinelemeli biçimde yutmamış olur, yani onun da lehine
    Normal kullanıcılar da farkı neredeyse hiç hissetmeyebilir; emek/etki oranı fena görünmüyor. Anonim kullanıcılar için Anubis'ten daha iyi olabilir
    Bu, scraper'ın method="POST" olan HTTP formlarını göndermediği varsayımına dayanıyor
    Eğer bu genel olarak doğru olmasaydı, AI scraper'ların anonim düzenlemeleri topluca gönderip Wikipedia içeriğini rastgele çöpe çevirdiğine dair manşetleri çoktan görmüş olurduk

    • Bunu yaparsanız yanıt da önbelleğe alınamaz hale gelir; CDN'e güveniyorsanız bu sorun olabilir
      Botların <form method="GET">e de basıp basmayacağını merak ediyorum. Bu, önbellekle daha uyumlu olur ve crawler'dan ek mantık gerektirebilir

  • Benim küçük blog trafiğimin %95'i Singapore ve China'dan gelen LLM scraper'larından oluşuyor

  • Aradan bunca yıl geçti de kimse IP'leri araştırıp iletişime geçilebilecek küçük bir ISP'ye ait tek bir IP bile bulamadı mı? O kullanıcıya ulaşıp bilgisayarı inceleyip inceleyemeyeceğini kibarca soran olmadı mı? Hangi yazılımın gerçekten tarama yaptığını kimse ortaya çıkaramadı mı?
    Site yöneticileri bunu bile yapamıyorsa artık umursamak istemiyorum. Gerçek hayattaki o kirli insanlar arası temastan kaçınmak için bu kadar çabalarsanız elbette bot elde edersiniz
    Ve konut tipi botnet üzerinde çalışan botlar bazen CAPTCHA ya da Anubis'i geçmeye yetecek hesaplama kaynağına zaten sahiptir
    Sunucu tarafında kalıcı olarak kazanmak mümkün değil. Çünkü o bilgisayarın kullanıcısı da meşru trafik üretiyor
    Bu yüzden uzaktan doğrulama istemiyorsanız o IP'lerin peşine düşmeniz gerekir

    • Konut tipi botnet'in ölçeğini küçümsüyor gibisiniz
    • Sorun şu ki trafik on binlerce farklı IP'den geliyor
      Dünyayı arabayla dolaşmanın yakıt maliyeti gibi pratik sorunları bir kenara bıraksanız bile bu devasa bir gezgin satıcı problemi haline geliyor
    • Gerçekten şaşırtıcı derecede kötü bir görüş
      Birkaç bot yüzünden sistem yöneticisinin biraz daha uslu davranmaları için hafta sonu boyunca her yere araba sürmesi gerektiği fikri, özellikle çoğunun büyük ya da yabancı ISP'lerden geldiğini düşününce, sadece gülünç
      Ne kullandığınızı merak ettiriyor
      Hangi yazılımın tarama yaptığını mı soruyorsunuz? Biri bir sohbet botuna “bunu scrape eden bir şey yap” diyor ve her scraper ayrı ayrı üretiliyor
    • “Kimse” sorusu ancak bunu kimin yapabilecek yetkiye, motivasyona ya da sorumluluğa sahip olduğunu söyleyebiliyorsanız anlamlıdır
      Aksi halde sadece soyut biçimde tüm evreni suçlamış olursunuz
    • Küçük ISP'lerle iletişime geçip yerlerine gitmek pek gerçekçi değil
      Çoğu servis sağlayıcının, kendi IP'lerinin hangi web sitelerini scrape etmekte kullanıldığına zerre kadar aldırmadığını garanti ederim
      Dahası, bu sağlayıcıların IP'ye bağlı adresi size vermeyeceğini de garanti ederim
      Çok daha iyi sonuç veren şey, Alibaba, AWS gibi çeşitli sağlayıcılara ait ASN trafiğini topluca çöpe atmaktır
      Bu her zaman uygulanabilir bir seçenek değil. Örneğin Atom feed'i olan bir blogunuz varsa feed okuyucuları da engelleyebilirsiniz
      Ama birçok durumda çöp trafiğin %80'ini ortadan kaldırabiliyor

  • Bunun neden olduğunu bilen var mı? Özellikle neden ani sıçramalar olduğunu merak ediyorum

    • Duyduğum bir hipotez şu: botnet güvenilir değil ve botnet erişimini konut tipi proxy olarak satanlar bu istikrarsızlığı yinelenen isteklerle telafi ediyor
      Doğru mu bilmiyorum ama en azından kulağa makul geliyor
      Altyapıyı daha iyi anlamadan bir şey söylemek zor. Komuta-kontrol sınırları da olabilir
      Eğer botnet DDoS için tasarlandıysa, mimarisi gereği ince taneli kontrol yeteneği zayıf olabilir