1 puan yazan GN⁺ 2024-10-08 | 1 yorum | WhatsApp'ta paylaş
  • uBlock Origin commit’i, Firefox ağ işlemede CNAME uncloaking akışını yeniden yazıyor ve DNS sorgusuyla elde edilen IP’nin details.ip içine yansıtılmasını sağlayacak şekilde değiştiriyor
  • Mevcut cnames Map önbelleği kaldırılıyor; yerine dnsList, dnsDict, dnsWritePtr tabanlı 256 öğelik ring buffer ve 60000ms TTL önbelleği geliyor
  • DNS sorgusu browser.dns.resolve(hn, [ 'canonical_name' ]) kullanıyor; sonuçtaki canonicalName ve addresses[0] değerleri sırasıyla CNAME ve IP olarak kullanılıyor
  • CNAME istisna işleme; 1st-party, ignore list ve root document koşullarını koruyor; IPv4 adresleri veya [ ile başlayan host adlarını yeniden sorgulamanın dışında bırakıyor
  • Chromium minimum sürümü 80.0, Opera minimum sürümü 67.0 seviyesine yükseliyor; gizli ayarlardaki cnameMaxTTL varsayılan değeri kaldırılıyor

Firefox DNS önbellek yapısı yeniden yazıldı

  • platform/firefox/vapi-background-ext.js içindeki CNAME uncloaking ile ilgili kod, global Map merkezli yapıdan sınıf içi DNS önbelleği yapısına dönüştü
  • Mevcut global cnameUncloakEnabled durumu ve cnames Map yerine önbellek şu alanlarla yönetiliyor
    • dnsList: ring buffer
    • dnsWritePtr: sonraki yazma konumu
    • dnsMaxCount: maksimum 256
    • dnsDict: host adından ring buffer indeksine eşleme
    • dnsEntryTTL: 60000ms
  • Kurucuda canUncloakCnames ve cnameUncloakEnabled true olarak başlatılıyor

İstek işleme akışı

  • onBeforeSuspendableRequest(details), istek URL’sinden host adını çıkardıktan sonra önce dnsFromCache(hn) ile önbelleği kontrol ediyor
  • Önbellekteki DNS kaydında ip varsa details.ip içine ayarlıyor
  • Temel super.onBeforeSuspendableRequest(details) çağrısının sonucu iptal veya yönlendirme gibi bir sonuçla biterse, bu sonucu aynen döndürüyor
  • Önbellekteki DNS kaydı bir Promise değilse, takip işleme onAfterDNSResolution(hn, details, dnsEntry) ile devam ediyor
  • DNS yeniden sorgulama koşulları sağlanmıyorsa veya details.proxyInfo?.proxyDNS varsa ek DNS işlemi yapılmıyor

DNS sorgusu ve saklama yöntemi

  • dnsShouldResolve(hn), boş host adlarını, [ ile başlayan host adlarını ve IPv4 adresi biçimindekileri DNS sorgusu kapsamı dışında bırakıyor
  • dnsResolve(hn, details), ring buffer’ın geçerli konumuna host adını kaydediyor ve dnsAPI.resolve(hn, [ 'canonical_name' ]) çağrısı yapıyor
  • Sorgu başarılı olursa dnsToCache(hn, rec, details) çalıştırılıyor; başarısız olursa dnsToCache(hn) ile önbellekte boş bir kayıt bırakılıyor
  • dnsToCache, yeni önbellek kaydına hn ve sona erme zamanını kaydediyor
    • cnameFromRecord bir değer döndürürse dnsEntry.cname içine kaydediliyor
    • ipFromRecord bir değer döndürürse dnsEntry.ip içine kaydediliyor
  • dnsFromCache, önbellek kaydı bir Promise ise aynen döndürüyor; süresi dolmuş kayıtları dnsList ve dnsDict içinden kaldırıyor

CNAME ve IP’nin yansıtılma koşulları

  • cnameFromRecord(hn, record, details), record.canonicalName yoksa veya özgün host adıyla aynıysa CNAME döndürmüyor
  • cnameIgnore1stParty açıksa, CNAME ile özgün host adının alan adının aynı olduğu durumları hariç tutuyor
  • cnameIgnoreList varsa, ilgili regex ile eşleşmeyen CNAME’ler hariç tutuluyor
  • cnameIgnoreRootDocument açıksa, istek host adı details.documentUrl || details.url içindeki host adıyla aynı olduğunda hariç tutuluyor
  • ipFromRecord(record), record.addresses bir dizi olduğunda ve boş olmadığında ilk adresi, yani addresses[0] değerini döndürüyor

URL yeniden yazma ve sonraki filtreleme

  • onAfterDNSResolution, DNS kaydında CNAME varsa ve cnameUncloakEnabled açıksa URL’yi uncloakURL ile yeniden yazıyor
  • URL değiştirilirken mevcut URL details.aliasURL içine kaydediliyor, yeni URL ise details.url içine yansıtılıyor
  • DNS kaydında IP varsa ve mevcut details.ip değerinden farklıysa details.ip güncelleniyor
  • Yalnızca CNAME yeniden yazma veya IP değişikliği gerçekleştiğinde temel sınıfın onBeforeSuspendableRequest(details) metodu yeniden çağrılıyor
  • uncloakURL, URL içindeki host adı konumunu bulup CNAME ile değiştiriyor; cnameReplayFullURL değerine göre URL’nin tamamını birleştiriyor veya yalnızca yolun başına kadar olan kısmı koruyor

Ayar ve manifest değişiklikleri

  • setOptions içinde cnameMaxTTL işlemesi kaldırılıyor
  • Seçenekler değiştiğinde mevcut cnames Map’i sıfırlamak yerine dnsList.fill(null) ve dnsDict.clear() ile DNS önbelleği boşaltılıyor
  • src/js/background.js içindeki gizli ayar varsayılanlarından cnameMaxTTL: 120 siliniyor
  • platform/chromium/manifest.json içindeki minimum_chrome_version, 73.0 değerinden 80.0 değerine değiştiriliyor
  • platform/opera/manifest.json içindeki minimum_opera_version, 60.0 değerinden 67.0 değerine değiştiriliyor

1 yorum

 
GN⁺ 2024-10-08
Hacker News yorumları
  • Başlık yanlış gibi görünüyor. uBlock Origin bu özelliği zaten yıllar öncesinden destekliyordu, sadece Firefox'ta mümkündü
    Bu seferki şey tamamen yeni bir özellikten ziyade o kodun refaktör edilmesi gibi görünüyor

    • Şu anda da destekliyor, eskiden de destekliyordu :P
    • Basit bir refaktörden fazlası gibi görünüyor. Artık gerçek istek gönderilmeden önce IP tabanlı engelleme daha erken bir aşamada yapılabiliyor gibi
      Yine de bir alan adının birden fazla IP'si olduğunda tarayıcının hangisini seçeceğini bilmek mümkün olmadığından kusursuz değil
    • Başlığı sayfa başlığına geri çevirdim. Gönderi başlığı “uBlock Origin supports filtering CNAME cloaking sites on Firefox now” idi
      Daha doğru ve tarafsız bir başlık önerirseniz yeniden değiştirilebilir. Yine de ek bağlamı olmayan GitHub commit'leri genelde HN başlığı için pek iyi olmaz
  • Henüz doğrudan zararını görmedim ama Chrome gerçekten uBO'yu kaldırırsa, geçiş yapabilmek için uzantılarımı Firefox için şimdiden yeniden elden geçiriyorum

    • Bu “eğer” değil, “ne zaman” meselesi. 2020'den beri zaten “ne zaman” meselesiydi ve gerçekten geliyor
      Birkaç sürüm içinde olacak, o yüzden hazırlıklı olmak lazım
    • Ailemi Brave'e geçiriyorum. Farkı neredeyse hiç hissetmiyorlar ve tarayıcının kullanıcı odaklı içerik filtrelemeyi desteklemeye devam edeceğine daha çok güveniyorum
    • Zaten Canary sürümünde kaldırıldı
    • “Uzantıları Firefox için yeniden yazmak” derken ne kastedildiğini anlamadım. Firefox da aynı API'yi kullanıyor
      En fazla background.service_worker yerine background.scripts kullanırsın; kelimenin tam anlamıyla sadece anahtar adını değiştirmek yeterli
    • Konuya çok hakim olmayanlar için sorayım: uBO nedir ve çoğu uzantıyı nasıl etkiliyor?
  • uBlock Origin, Firefox'u daha iyi yapan şeylerden biri ve Chrome gibi alternatifler yerine Firefox kullanmamın başlıca nedenlerinden biri
    İnterneti gerçekten gezilebilir hale getiriyor

    • Birkaç yıl önce bu ikiliye geçtim ve ayrılmak için hiç neden görmedim. Android telefonda da aynı şekilde; gördüğüm tek gerçekten kullanılabilir mobil web deneyimi bu
      10 yılı aşkın süredir bazı sitelerde görüntüleme sorunları yaşadım ama o sitelerde Chrome'da da sorun vardı
      Kişisel olarak reklamları modern toplumun kanseri gibi görüyorum. Beyaz yalanlar ve düpedüz yalanlar, manipülasyonla iç içe geçmiş durumda ve işin içinde bu kadar büyük para akması, saygı duyulacak bir şey bırakmıyor
    • Mozilla bir reklam şirketine dönüşüyor gibi, o yüzden bu değişebilir
    • Hem Brave hem Firefox kullandım ve dürüst olmak gerekirse aralarında büyük bir fark hissetmedim. Yine de felsefesi ve kâr amacı gütmeyen bir yapıdan çıkmış olması nedeniyle Firefox'u tercih ediyorum
      Brave de kaliteli bir proje, yedek olarak kullanıyorum; bazen pencere bölme ve çok daha iyi sekme yönetimi için Vivaldi'yi de araya katıyorum
  • CNAME cloaking denilen şey, reklam sitelerinin wildcard kaydını işaret eden rastgele oluşturulmuş alt alan adları kullanması mı demek?

    • Bu onun bir parçası
      Normalde contentsite.com'u ziyaret ettiğinizde reklamlar adsite.com'dan gelir. Reklam engelleme kuralları adsite.com'u engellerse reklam görünmez
      CNAME cloaking, ana sitenin adsite.contentsite.com gibi bir alt alan adını adsite.com'a yönlendirmesi demek. Böylece reklam engelleyici, normal sitenin parçası gibi görünen milyonlarca alt alan adını engellemek gibi neredeyse imkânsız bir işle karşı karşıya kalır
      Normal site alt alan adlarını durmadan değiştirebilir ve reklam engelleyicinin hangi alt alan adının normal içerik, hangisinin reklam olduğunu anlama şansı yoktur. Üstelik içerik aynı alan adından sunulduğu için bazı çerez politikaları da aşılabilir ve kullanıcı daha iyi izlenebilir
      Bu güncelleme, çözümlenmiş IP'ye göre filtreleme yapan kurallar tanımlamayı mümkün kılıyor
    • Evet. Reklam ve analiz sağlayıcıları üçüncü taraf çerez korumalarını aşmak için bu yöntemi kullanmaya başladı
  • Bu, Manifest V3'ün neden kötü olduğunu çok iyi gösteren bir örnek. Tanım gereği böyle şeyler yapamaz ve çalışma anında kod tabanlı sezgisel yöntemler de mümkün değildir
    Bu, reklamcılarla süren bir silahlanma yarışı ve Google her iki tarafa da silah satan tüccar. Kullanıcının kazanması için gereken şeyi vermeyecek

    • Deklaratif Manifest V3 API'sinin böyle bir yetenek sunamaması için bir neden yok. Commit'i doğru okuduysam, gerçek sunucuya hiçbir şey gönderilmeden önce istek akışına daha iyi entegre olup fiilen kullanılacak IP adresine göre engelleyerek daha iyi çalışıyor da olabilir
      Elbette bunların hepsi tarayıcı sağlayıcısının, yani Google'ın bu API'yi eklemek isteyip istememesine bağlı. “Çalışma anında kod” ile emir kipinde işlem yapılabilirse, tarayıcı üreticisi yerleşik destek eklemeden önce kullanıcı alanında yenilik yapılabilir
    • Teknik olarak Manifest V3'ün kendisi, tarayıcının uzantılara sunduğu API'lerden ayrı bir şey. Firefox'ta Manifest V3, engelleyici web istekleri[1] ile birlikte destekleniyor; bu da “Manifest V3”ten önceki filtreleme API'si
      Dolayısıyla belirli bir özelliğin “tanım gereği” imkânsız olduğunu söylemek yanlış
      [1] https://blog.mozilla.org/addons/2022/05/18/manifest-v3-in-fi...
    • Chrome'u bırakıp Firefox'u benimsemek yeterli
  • CNAME gizleme örneğin, SaaS sağlayıcısı A'nın şirket Q'ya havalı bir reklam takip yazılımı sunmak istediğini düşünelim
    Eski yöntemde A, şirket Q'nun https://q-company.example adresindeki sitesine örneğin https://A-ads-tracking.example betiğini eklemesini isterdi
    Böylece uBlock Origin'in kullandığı engelleme listelerinde “A-ads-tracking.example alanına giden istekleri engelle” gibi kurallar oluşur ve reklamlar engellenirdi
    CNAME gizleme ise SaaS sağlayıcısı A'nın reklam takip hizmetini A-ads-tracking.example alanında değil, örneğin 29.1.2.3 gibi belirli bir IP adresinde barındırmasıdır. Kritik nokta da SaaS A'nın şirket Q'dan q-company.example altında bir alt alan oluşturmasını ve onun CNAME kaydının 23.1.2.3'ü göstermesini istemesidir. Buna media.q-company.example gibi makul görünen bir ad verilir
    Şirket Q bu CNAME'i ayarlayıp siteye media.q-company.example betik etiketini eklediğinde, SaaS A o sitenin tüm kullanıcılarını takip edebilir. Bu ara katman nedeniyle, Q şirketinin sahibi ile herkese açık engelleme listeleri arasında fiilen sonsuz bir kedi-fare oyunu ortaya çıkar
    Bu sorundan kaçınmak için, uBlock Origin gibi eklentileri çalıştıran yazılımın tarayıcı isteğinin hedef alanını olduğu kadar, o alanın gerçek IP adresini de görebilmesi gerekir. Bu commit de bunu mümkün kılan ya da en azından o kodun daha iyi çalışmasını sağlayan bir şeyle ilgili görünüyor

    • Aslında tam olarak öyle değil. Adından da anlaşılacağı gibi burada CNAME kullanılıyor; bu, IP'yi gösteren bir A kaydı değil, başka bir kaydı gösteren bir kayıttır
      Örneğin media.q-company.example, q-company.ads-tracking.example adresini gösteren bir CNAME olabilir; ardından q-company.ads-tracking.example IP veren bir A kaydına sahip olur
      Tarayıcının bu ara DNS adını eklentiye verip vermediğini bilmiyorum. Bu yüzden uBlock gibi araçların IP listelerine dayanması gerekebilir; ama pihole gibi DNS tabanlı filtreleme araçları ads-tracking.example için bir kuralla bunu doğrudan engelleyebilir
      Her halükarda hem tarayıcı tabanlı hem de DNS tabanlı kötü amaçlı içerik engelleyicileri birlikte kullanmak iyi olur
    • İşte bu yüzden uBlock gelişmiş modunda tüm JavaScript'i engellemek ve site düzgün çalışana kadar görünen betikleri yavaş yavaş izin listesine almak iyi bir fikirdir
      Yavaş ve hata yapmaya açık bir yöntem ama alışınca kolaylaşıyor ve bu tür saçmalıklara karşı tamamen bağışıklık sağlıyor
  • Chrome, uBO'yu engellemeyi mi planlıyor? En güncel durumu sürekli takip edemiyorum
    Bildiğim kadarıyla artık üçüncü taraf çerezlere izin veriyor, o yüzden belki hâlâ bir ihtimal vardır

    • Mesele doğrudan uBO'nun engellenmesi değil; yeni eklenti API'si olan Manifest V3 getirilirken uBO'nun çalışmasını sağlayan tarayıcı özellikleri kaldırılıyor
      uBO'nun yüklenmemesi gereken şeyleri tespit edip sonra bunların yüklenmesini durdurmak için ihtiyaç duyduğu temel API'ler ortadan kaldırılıyor
      Google bunun “performans” veya “güvenlik” için olduğunu iddia ediyor. Elbette gerçekte ciddi biçimde etkilenen tek “performans” ya da “güvenlik”, zararlı veya reklamla ilgili indirmeleri başlamadan önce tespit edip araya girme ve durdurma yeteneği
    • Tarayıcıyı güncellememek de risklidir. Firefox'a geçmek, hem güncelleme almaya devam etmek hem de uBO için tam destek almak açısından çok daha iyidir
    • Tarayıcı tekeline ilişkin kötü kamuoyunun bir anda patlamasını önlemek için bunu uzun bir döneme yayarak yavaş yavaş kaldırıyorlar. Ama takvim zaten haziranda başladı
      https://developer.chrome.com/docs/extensions/develop/migrate...
      https://www.bleepingcomputer.com/news/google/google-chrome-w...
    • Şu an için Manifest V2'yi destekleyen Chromium tarayıcıları için Chrome Web Store'da uBlock Origin hâlâ mevcut
      Yalnızca Manifest V3 destekleyen bir Chromium sürümü kullanırsanız gizleniyor
    • Açıkçası bu biraz da ABD'nin bu kadar açık tekelci şirketleri mahkemeye taşımaya istekli bir yönetimi sürdürüp sürdürmeyeceğine bağlı olabilir
  • Bazı DNS sunucularında, sunucunun çözdüğü CNAME gibi davranan bir özellik yok muydu? Yani yönetici başka bir DNS adını gösteren bir kayıt giriyor ama istemci sadece A veya AAAA kaydını görüyor

    • Sanırım ALIAS kaydından söz ediyorsunuz
  • uBO'da bu özellik epey uzun süredir vardı. 1.34.0 sürümünden beri vardı, gelişmiş ayarlarda ise 1.25.0'dan beri
    https://github.com/gorhill/uBlock/wiki/Dashboard:-Settings#u...
    Kabaca 2021 civarı diye hatırlıyorum

  • Brave, Edge ve Opera'da uBO durumu nasıl?

    • Adı geçen iki tekelci tarayıcıyla ilgilenmiyorum ama Brave, mümkün olduğunca uzun süre Manifest V2'yi kısmen destekleyip uBO uyumluluğunu korumayı planlıyor
      https://brave.com/blog/brave-shields-manifest-v3/
      Yine de şart değil. Brave'in kendi yerleşik reklam engelleyicisi oldukça güçlü; son baktığımda yerel koda derlenmişti, bu yüzden uBO'dan daha yüksek performans veriyordu ve aynı reklam listelerini de tam olarak destekliyordu