User-Agent Açıklandı: UA Dizileri ve Tarayıcı Parmak İzlerinden Client Hints

Tarayıcınızın geliştirici araçlarında Network panelini açın ve neredeyse her zaman User-Agent başlığı bulursunuz. Kısa bir giriş gibi görünüyor: hangi tarayıcı isteği yapıyor, hangi işletim sisteminde çalışıyor ve hangi sürüm olduğunu iddia ediyor.

Bu da başlığı bir cihaz kimliği olarak görmeyi ya da bir satırı değiştirmenin bir tarayıcıyı farklı bir cihaza dönüştürebileceğini varsaymayı cazip kılar. Her iki fikir de sadece kısmen doğru.

Bir User-Agent dizesi, yani UA, istemci tarafından ilan edilen uyumluluk bilgisidir. Bu güvenilir bir kimlik kimliği değildir ve bir istemci bunu değiştirebilir. Yine de bu tek başına var değildir. Bir site, UA Client Hints, JavaScript API'leri, ekran özellikleri, fontlar, Canvas, WebGL, ağ bağlamı ve davranışla karşılaştırabilir. Bu nedenle faydalı soru, sadece bir UA değiştirilip değiştirilemeyeceği değil, tarayıcının tam gözlemlenebilir yüzeyinde ne rol oynadığıdır.

Bu makale, dört soruyu yanıtlamak için HTTP standartları ve tarayıcı parmak izi araştırmalarını kullanır:

1. Neden UA bir ip, tarayıcı arkeolojisi parçası gibi görünüyor?
2. Ne kadar tanımlayıcı bilgi UA katkı sağlayabilir ve araştırmayı nasıl yorumlamalıyız?
3. Neden sadece UA değiştirmek daha bariz bir tutarsızlık yaratabilir?
4. UA Reduction ve User-Agent Client Hints aslında neyi değiştirdi?

Bu makalede UA öncelikle HTTP User-Agent istek başlığı anlamına gelir. Ayrıca navigator.userAgent ve navigator.userAgentData JavaScript'de konuşuyoruz. Bu arayüzler birbiriyle ilişkilidir ancak her tarayıcı ve bağlamda kalıcı olarak aynı değildir.

1. User-Agent nedir?

RFC 9110 Maddesi 10.1.5 User-Agent, talebi başlatan kullanıcı ajanı hakkında bilgi içeren bir alan olarak tanımlar. Basitleştirilmiş dilbilgisi şöyledir:

User-Agent = product *( RWS ( product / comment ) )
product    = token [ "/" product-version ]

Basit dilde, dizi bir ürün adıyla başlar ve bir versiyon içerebilir. Daha fazla ürün veya yorum takip edebilirsiniz. Standart, birlikte çalışabilirlik çözümleri, tanılama ve analitik gibi kullanımları tanımak, ancak uygulamaların gereksiz detayları ortaya çıkarmamasını da tavsiye eder: daha uzun ve daha spesifik bir UA hem istek boyutunu hem de parmak izi riskini artırır.

Modern bir Chromium masaüstü UA şöyle görünebilir:

Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/145.0.0.0 Safari/537.36

Diziyi uzaylara ayırmak, Chrome ile ilgisiz görünen birkaç isim ortaya çıkarır:

Token	Bugün genel olarak ne anlama geliyor	Yaygın bir yanlış okuma
Mozilla/5.0	Tarihsel uyumluluk belirteçleri	Tarayıcı Firefox veya Mozilla bir ürün
Windows NT 10.0	Windows platform kategorisi; İndirilmiş bir UA Windows 10'u 11'den güvenilir şekilde ayırt edemez	Bilgisayar 10 Windows çalışmalı
Win64; x64	Bunun x86-64 mimarisinde 64-bit Windows olduğuna dair bir ipucu	Tam olarak fiziksel CPU modelini kanıtlıyor
AppleWebKit/537.36	Bir motor-soy ve uyumluluk tokenı	Chrome hâlâ Safari'ın tam uygulamasını kullanıyor
KHTML, like Gecko	Tarihsel uyumluluk dili	Hem KHTML hem de Gecko çalışıyor
Chrome/145.0.0.0	Chrome/Chromium ailesi ve ana versiyon; alt sürüm bileşenleri azaltılabilir	Tam olarak yama versiyonunu ortaya çıkarıyor
Safari/537.36	Eski sitelerle uyumluluk için tutulan bir token	Tarayıcı Safari

UA uzun oldu çünkü erken web siteleri genellikle tarayıcı isimlerine dallanıyordu. Yeni tarayıcıların doğru sayfayı alabilmek için eski ürünlerle uyumluluk iddiası yapması gerekiyordu. Bu açıklamalar zamanla birikti ve kelimesi kelimesine okunamayacak bir tarihsel kayıt oluşturdu.

UA ayrıştırmanın ilk kuralı bu nedenle basittir: bu bir uyumluluk protokolüdür, katı bir cihaz tanımı değildir.

2. Web siteleri neden hâlâ UA kullanıyor?

UA sadece takip için kullanılmaz. Meşru kullanımlar şunlardır:

• bilinen bir uyumluluk sorunu olan eski bir tarayıcıya geri dönüş sunuyordu;
• uygun bir kurulumcu veya indirme formatı seçmek;
• tanı loglarında sürüme özgü hataları bulmak;
• geniş tarayıcı ailesi, platform ve ana sürüm dağılımlarını ölçmek;
• otomatik veya kötü niyetli trafikte imkansız kombinasyonları tespit etmek.

Sorun, UA koklama dar bir uyumluluk geri dönüşünden ürün adıyla tahmin yeteneklerine geçtiğinde başlar. Kod Chrome görebilir ve belirli bir API'nin var olduğunu varsayabilir. Bu varsayım, gömülü bir WebView, Chromium türettiği bir tarayıcı, kurumsal politikası olan bir tarayıcı, dondurulmuş bir UA veya başlığını değiştiren bir istemci için başarısız olabilir.

Daha sağlam bir işlem sırası şudur:

1. Yeterlilik tespit mümkün olduğunda gerekli API veya davranışı doğrudan test edin.
2. Tarayıcı tanımlaması kaçınılmaz olduğunda, geçici düzenli ifade yerine sürdürülebilir bir ayrıştırıcı kullanın.
3. Sadece ürünün gerçekten ihtiyaç duyduğu kaba kategorileri sakla.
4. Bilinmeyen markalar, bilinmeyen versiyonlar ve eksik alanlar için bir yedek plan oluşturun.

3. UA tarayıcı parmak izi mi?

Daha doğrusu, UA tarayıcı parmak izine bir giriş olur, genellikle tam parmak izi değildir.

Tarayıcı parmak izi için gizli seri numarası gerekmez. Tarayıcı tarafından ortaya çıkarılan nispeten stabil ve ayırt edici özellikler koleksiyonunu ölçür. UA tarayıcı ailesi, sürüm ve platform hakkında ipuçları verir. Ekran boyutları, fontlar, zaman dilimi, Canvas, WebGL, AudioContext ve diğer arayüzler ek bilgi ekler.

Laperdrix ve meslektaşlarının yaptığı anket, Browser Fingerprinting: A Survey, bu teknikleri durumsuz tanıma biçimi olarak tartışıyor. Bir sitenin önce Cookie yazması zorunlu değildir; Ziyaretleri tarayıcının ortaya çıkardığı özelliklerle ilişkilendirmeye çalışabilir. "Durumsuz" kelimesi, sunucunun hiçbir şey depolamadığı anlamına gelmez. Bu, tanıma materyalinin kalıcı bir istemci tarafı tanımlayıcıya bağlı olmadığı anlamına gelir.

1. Kağıdın 10 bitlik sonucu ne anlama geliyor?

2010 Panopticlick çalışmasında How Unique Is Your Web Browser?, Peter Eckersley yaklaşık 470.000 tarayıcı parmak izini analiz etti. Gazete şöyle bildiriyordu:

• Tam parmak izi, o örnekte ortalama yaklaşık 18,1 bit tanımlayıcı bilgi taşıyordu;
• sezgisel olarak, ortalama bir parmak izi yaklaşık 286.777 tarayıcıda bir kez görüldü;
• tablo, yalnızca UA dizisi için yaklaşık 10.0 bit ortalama bilgi rapor etti;
• Flash veya Java etkin olan tarayıcılar arasında ise tam parmak izlerinin %94,2'si benzersizdi.

Öz-bilgi genellikle şu şekilde yazılır:

I(x) = -log₂ P(x)

Belirli bir UA bir popülasyonda 1/1024 olasılıkla gerçekleşirse, gözlemlemek 10 bit bilgi sağlar. Bu, UA'nin tam olarak 1.024 olası değere sahip olduğu veya bir kişiyi benzersiz şekilde tanımladığı anlamına gelmez. Bu gözlemin ortalama olarak ne kadar belirsizliği ortadan kaldırdığını açıklar.

2. 2010 sonucu neden günümüz web için sabit değil?

Sonuç önemli olmaya devam ediyor, ancak en az üç nitelik gerektiriyor:

• Gizlilik testi sayfasına gelen ziyaretçiler, tüm internet kullanıcılarının rastgele bir örneği değildi;
• 2010'da tarayıcı, eklenti ve UA sürüm çeşitliliği bugünkü ekosistemden büyük ölçüde farklıydı;
• UA Reduction, küçülen eklenti yüzeyleri ve parmak izi karşıtı korumalar, gözlemlenebilir özelliklerin dağılımını değiştirdi.

Çalışma, UA ve diğer özelliklerin ölçülebilir ayırt edici bilgi sağlayabileceği iddiasını desteklemektedir. Bugün bir UA her zaman tam olarak 10 bit entropiye sahip olduğunu söylemeyi desteklemez. Parmak izi gücü, nüfusa, zaman aralığına, tarayıcı politikalarına ve sinyallerin kombinasyonuna bağlıdır.

4. Neden sadece UA değiştirmek ters tepebilir?

UA, kriptografik kanıt olmayan bir istemci beyanıdır. Bir sunucu, bu başlıktan cihazın fabrika gerçeğini okuyamaz. Ancak, farklı gözlemlerin makul ölçüde uyumlu olup olmadığını kontrol edebilir.

Diyelim ki bir UA mobil tarayıcı olduğunu iddia ediyor ama sayfa temas noktası gözlemlemiyor, sürekli bir masaüstü ekranına benzeyen bir pencere ve masaüstü platformunu raporlayan Client Hints var. Herhangi bir gözlemin meşru bir istisnası olabilir. Birkaç kararlı çelişki birlikte sınıflandırılabilir bir desen oluşturabilir.

Panopticlick makalesi benzer durumları zaten belgelemişti: bazı tarayıcılar Flash'yi desteklerken iPhone olduğunu iddia etti ve bazı Firefox UA'ler yalnızca Internet Explorer'da bulunan depolama özellikleriyle birlikte ortaya çıktı. 2018 FP-Scanner çalışması bu sorunu sistematik bir şekilde incelemiştir. Bazı parmak izi karşıtı uzantılar ve sahte araçlar, arayüzler arasında tutarsızlıklar yaratarak bir dedektörün değiştirilmiş özellikleri tanımlamasına ve bazı durumlarda orijinal tarayıcı veya işletim sistemi ailesini çıkarmasına olanak tanıdı.

Her tutarsızlık kötü niyetli değildir. Uzak masaüstüler, erişilebilirlik araçları, kurumsal politikalar, uyumluluk katmanları ve nadir donanımlar alışılmadık kombinasyonlar yaratabilir. Dikkatli bir risk sistemi, tutarsızlığı otomatik olarak engellemek için otomatik bir neden değil, olasılıksal kanıt olarak ele almalıdır.

Tarayıcı profili yönetimi için üç özellik önemlidir:

• İçsel tutarlılık: UA, Client Hints, platform, mimari, dokunmatik ve ekran sinyalleri doğrudan birbirine çelişmemelidir.
• Zaman içinde istikrar: Uzun ömürlü bir profil, her lansmanda sebepsiz yere dramatik şekilde değişmemelidir.
• Makulu çeşitlilik: profiller farklı olabilir, ancak nadir mekanik olarak oluşturulan kombinasyonlar mutlaka daha güvenli değildir.

FP-STALKER çalışması ayrıca, değişen özelliklerin bağlantıyı otomatik olarak engellemediğini gösterdi. Bir model, daha önceki ve sonraki parmak izlerini bağlamak için kararlı özellikler ve makul versiyon değişiklikleri kullanabilir.

5. UA Reduction hangi sorunu çözer?

Geleneksel bir UA neredeyse her istekle birlikte gönderilir. İsteyi alan herhangi bir birinci taraf veya üçüncü taraf uç noktası pasif olarak okuyabilir. Dizide ne kadar hassas olursa, her alıcı varsayılan olarak o kadar ayırt edici bilgi elde eder.

Chromium'nin User-Agent Reduction planı bu varsayılan ayrıntıyı azaltıyor:

• Chrome 101'den itibaren masaüstü minor, build ve patch sürümleri 0.0.0'a indirildi;
• sonraki aşamalarda birleşik masaüstü işletim sistemi sürümleri, CPU detayları ve Android cihaz bilgileri;
• azaltılmış Android UA sabit platform ve model değerleri gibi Android 10; K kullanır;
• Gerçekten daha fazla detay isteyen siteler User-Agent Client Hints talep edebilir.

İndirilmiş format şöyle özetlenebilir:

Mozilla/5.0 (<unified platform information>)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/<major version>.0.0.0 Safari/537.36

İndüksiyon, eski UA'ın pasif parmak izi yüzeyini azaltır. Tarayıcı parmak izini ortadan kaldırmaz. Ana sürüm, geniş platform ve mobil durum görünür kalabilirken, diğer API'ler, ağ özellikleri ve davranışlar hâlâ bilgi sağlayabilir.

6. User-Agent Client Hints nasıl çalışır?

Genel mekanizma RFC 8942'da tanımlanırken, WICG User-Agent Client Hints taslak UA-spesifik alanları tanımlar. Bu yaklaşım, bir zamanlar yapılandırılmamış bir dizide yaşayan bilgileri yapılandırılmış alanlara ayırır ve varsayılan olarak gönderilebilen düşük entropili ipuçlarını, bir sitenin normalde açıkça talep ettiği yüksek entropili ipuçlarından ayırır.

Basitleştirilmiş bir ilk istek şu şekilde görünebilir:

GET /download HTTP/1.1
User-Agent: Mozilla/5.0 (...) Chrome/145.0.0.0 Safari/537.36
Sec-CH-UA: "Chromium";v="145", "Not_A Brand";v="99"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Platform: "Windows"

Sunucu gerçekten bir kurulumcu seçmek için mimari ve bitlik gerektiriyorsa, şu şekilde yanıt verebilir:

HTTP/1.1 200 OK
Accept-CH: Sec-CH-UA-Arch, Sec-CH-UA-Bitness
Vary: Sec-CH-UA-Arch, Sec-CH-UA-Bitness

Tarayıcı mekanizmayı desteklediğinde ve güvenlik ile politika gereksinimleri karşılandığında, sonraki bir talep şunları içerebilir:

Sec-CH-UA-Arch: "x86"
Sec-CH-UA-Bitness: "64"

Yaygın UA Client Hints şunlardır:

Alan	Tipik amaç	Bilgi seviyesi
Sec-CH-UA	Marka ve ana versiyon listesi	Genellikle düşük entropi
Sec-CH-UA-Mobile	Müşterinin mobil deneyimi tercih edip etmediği	Genellikle düşük entropi
Sec-CH-UA-Platform	Geniş platform kategorisi	Genellikle düşük entropi
Sec-CH-UA-Arch	CPU mimarisi	Yüksek entropi; Gerektiğinde talep
Sec-CH-UA-Bitness	Mimari bitlik	Yüksek entropi; Gerektiğinde talep
Sec-CH-UA-Platform-Version	Platform sürümü	Yüksek entropi; Gerektiğinde talep
Sec-CH-UA-Full-Version-List	Bildirilen markalar için tam sürümler	Yüksek entropi; Gerektiğinde talep
Sec-CH-UA-Model	Cihaz modeli	Yüksek entropi; Gerektiğinde talep

Üç mühendislik detayı kolayca gözden kaçırılabilir.

1. Client Hints hepsi otomatik gönderilmez

Düşük entropili ipuçları varsayılan olarak görünebilir. Yüksek entropili ipuçları genellikle Accept-CH bir yanıt gerektirir. İlk navigasyon, alt kaynaklar, izinler politikası, güvenli taşıma ve tarayıcı desteği gelenleri etkileyebilir. Bir sunucu, tüm isteğe bağlı alanların yok olmasına izin vermek zorundadır.

2. Marka listesi kasıtlı olarak ayrıştırıcının dayanıklılığını test ediyor

Sec-CH-UA birden fazla marka ve uyumluluğu test etmek için kullanılan sentetik bir marka içerebilir. Kod, ilk girişin her zaman ürün adı olduğunu varsaymamalı ve bilinmeyen bir marka ortaya çıktığında başarısız olmamalıdır. Yapılandırılmış alanı ayrıştırın, tanımadığınız girişleri görmezden gelin ve gelecekteki markalar için alan bırakın.

3. İpucu konusunda farklı yanıtlar doğru önbellek işlemesi gerektirir

Mimari, platform veya başka bir ipucu yanıtı değiştirirse, Vary veya eşdeğer bir önbellek anahtarı stratejisini doğru şekilde yapılandırın. Aksi takdirde, paylaşılan bir önbellek bir cihaz sınıfı için üretilen içeriği diğerine sunabilir.

7. Client Hints geleneksel UA kadar özel midir?

Bilgilerin nasıl ortaya çıkarıldığını iyileştirirler, ancak parmak izi almadan bağışıklık sağlamazlar.

Geleneksel UA, pasif ve varsayılan olarak büyük, yapılandırılmamış bir demeti ortaya çıkarır. Client Hints paketi alanlara ayırır, daha yüksek entropili bilgi taleplerini daha açık hale getirir ve tarayıcıya politika, izin veya gizlilik bütçesi kontrollerini uygulama fırsatı verir.

Ancak mimari, tam sürümler, platform sürümleri ve cihaz modelleri ayırt edilebilirliği artırabilir. RFC 8942, gizlilik ve performansı tasarım kısıtlamaları olarak açıkça ele alır. Geliştiriciler şunları sormalı:

• Bu özellik gerçekten alanı gerektiriyor mu?
• Yetenek algılama veya kullanıcı seçimi bunun yerini alabilir mi?
• Uygulama sadece kaba bir kategoriyi mi depolayabilir?
• Ham değerler ne kadar süre korunur ve kimler erişebilir?
• Üçüncü taraf kaynaklar da aynı ipuçlarını alacak mı?

8. Sunucu tarafı UA yönetimi için mühendislik rehberliği

1. Kimlik veya otorite kanıtı olarak asla UA kullanmayın

UA sunum seçimlerini ve uyumluluk geri dönüşlerini destekleyebilir. Kimlik, yetki, ödeme güveni veya güvenlik sınırını belirlememelidir. İstemci tarafından kontrol edilen bir değer, erişim kontrol kimliği olarak hizmet veremez.

2. Tarayıcı listelerine göre yetenek algılamayı tercih edin

Bir ön uç API'ye ihtiyaç duyduğunda, bu yeteneği doğrudan test edin:

if ('share' in navigator) {
  // Offer the system share feature.
} else {
  // Fall back to copying a link.
}

Yetenek algılama, türeden türetilmiş tarayıcıları, deneysel özellikleri, kurumsal politikaları ve gelecekteki sürümleri "bunu 145 Chrome için etkinleştir" gibi kurallardan daha iyi yönetir.

3. Miras UA, Client Hints ve bilinmeyen devletleri kabul etmek

Göç sırasında, bir sunucu yalnızca UA ve Client Hints olan eski UA veya her ikisinin de çok azaltılmış biçimlerini alabilir. Veri modeli, tam bir işletim sistemi veya cihaz modeli tahmin etmek yerine unknown her alanı doldurmasına izin vermelidir.

4. Log granülarlığını azaltın

Eğer analitik sadece masaüstü ile mobil, tarayıcı ailesi ve ana sürüm gerektiriyorsa, ham UA dizelerini ve her yüksek entropi ipucunu sonsuza kadar saklamayın. Veri minimize etme gizlilik riskini azaltır ve analitik bir boru hattının küçük varyasyonları anlamlı bir boyut olarak ele almasını engeller.

5. Anormallikleri karar olarak değil, delil olarak ele alın

Bir API farklı davranırken Windows iddia eden bir UA en fazla bir risk sinyali olur. Kurumsal ortamlar, sanallaştırma, uzaktan oturumlar, uyumluluk katmanları ve yardımcı teknolojiler meşru anormallikler üretebilir. Bir uyumsuzluğu otomatik dolandırıcılık kararına dönüştürmek yanlış pozitifler yaratır.

9. Çok profilli ortamlarda UA nasıl yapılandırılmalıdır?

Bölgeler arası testler, reklam önizlemeleri, hesap işlemleri ve gizlilik izolasyonu için amaç en sıra dışı UA yaratmak olmamalıdır. Bir profil açıklanabilir, stabil ve çevresiyle uyumlu olmalıdır.

Aşağıdakileri sırayla gözden geçirin:

1. Tarayıcı sürümü: UA ana sürüm, gerçek motor ve yetenekleri için makul olmalı.
2. İşletim sistemi: UA platform, Client Hints platform ve JavaScript-görünür platform kategorisi uyumlu olmalıdır.
3. Mimari ve bitlik: UA, Client Hints ve yürütülebilir ortam doğrudan çelişkili iddialarda bulunmamalıdır.
4. Cihaz form faktörü: mobil bir beyan, dokunmatik destek, görüntü alanı, piksel oranı ve etkileşim desenleriyle birlikte mantıklı olmalıdır.
5. Bölgesel bağlam: dil, saat dilimi, coğrafi konum ve vekil çıkış mekanik olarak eşleşmek zorunda değil, ancak gerçek iş akışı için mantıklı olmalıdır.
6. Profil kararlılığı: Bir hesap veya test kimliği uzun ömürlü bir profili tekrar kullandığında, platform ve ana sürüm gerekçesiz yere geçmekten kaçının.

PurpleMark'nin mevcut profil dönüşümü, seçilen işletim sistemini UA bir platforma eşlendirir ve önce bir Chrome/ veya CriOS/ token'dan tarayıcı sürümünü çıkarmaya çalışır. Kullanılabilir bir versiyon olmadığında, mevcut motorun ana versiyonundan makul bir geri dönüş noktası elde eder. Amaç, izole bir diziyi sahteleştirmek değil, UA yapılandırmayı tutarlı bir tarayıcı profili modelinin içine yerleştirmektir.

Profil izolasyonu ve parametre tutarlılığı, teknik korelasyon ve test yanlılığını azaltabilir. Hesapların asla bağlanmayacağını garanti edemezler ve platform kurallarını, hesap verilerini, ödeme bilgilerini veya sorumlu işletim uygulamalarını değiştirmezler. Bu yetenekleri yalnızca yasal gizlilik koruması, yetkili testler ve uygun iş faaliyetleri için kullanın.

10. Sıkça Sorulan Sorular

S1: Tarayıcıyı değiştirmek UA başka bir tarayıcıya mı dönüştürür?

Hayır. Bu, müşterinin beyanının bir kısmını değiştirir. JavaScript motorunu, rendering pipeline'ı, ağ yığınını veya desteklenen Web API'lerini yerine geçirmez.

S2: Bir web sitesi "gerçek UA"yi okuyabilir mi?

Her web sitesinin tarayıcıyı atlayıp okuyabileceği evrensel donanım düzeyinde "gerçek UA" yoktur. Yine de bir site Client Hints, yetenek testleri ve diğer parmak izi sinyallerini karşılaştırabilir, uyumsuz iddialar bulabilir ve olasılıksal çıkarımda bulunabilir.

S3: Azaltılmış UA Windows 10'u Windows 11'den ayırt edebilir mi?

Azaltılmış miras genellikle bunu güvenilir şekilde UA yapamaz çünkü her ikisi de Windows NT 10.0 rapor edebilir. UA Client Hints destekleyen bir tarayıcı, bir site talep ettikten sonra daha ayrıntılı platform sürümü bilgisi sağlayabilir. Sunucular hâlâ eksik alanlar ve haritalama farklılıklarını yönetmek zorunda.

S4: JavaScript devre dışı bırakmak UA maruziyeti durdurur mu?

Tam olarak değil. HTTP User-Agent bir istek başlığıdır ve sayfa isteği ile birlikte sayfa JavaScript çalışmadan önce gönderilebilir. Devre dışı bırakmak JavaScript bazı toplama yüzeylerini kaldırır ama aynı zamanda modern ağın önemli bölümlerini de bozar.

S5: Client Hints tamamen User-Agent değiştirecek mi?

Yakın vadede bunu varsaymayın. Birçok istemci ve sunucu hâlâ eski UA'ye bağımlı, UA Client Hints destek ise farklılık gösteriyor. Client Hints aşamalı geliştirme olarak değerlendirin: mevcut olduğunda yapılandırılmış bilgileri tercih edin, ancak eski UA ve bilinmeyen durumlar için yedek önlemleri kalın.

S6: Rastgele oluşturulan UA anonimliği artırır mı?

Mutlaka değil. Bir alanı rastgele yapmak versiyon, platform, dokunma ve render sinyalleriyle çelişkiler yaratabilir. Uzun ömürlü bir profil için, yaygın ve kararlı ve içsel uyumlu bir konfigürasyon genellikle sık rastgele değişikliklerden daha savunulabilir.

11. Sonuç

User-Agent ne güvenilir bir kimlik belgesi ne de alakasız bir dizidir. Web uyumluluğu, gizlilik ve risk analizinin kesişiminde yer alır. Geliştiriciler için bu, tarihle yüklenmiş bir uyumluluk girdisidir. Parmak izi araştırmacıları için ölçülebilir istatistiksel bilgiye sahip bir özelliktir. Tarayıcı üreticileri için bu, azaltılması gereken varsayılan bir maruz kalma yüzeyidir.

Ana fikirler üç ifadeye uymaktadır:

• Bir UA kelimesi kelimesine okumayın; birçok tarihsel uyumluluk tokenı içerir.
• UA tek başına değerlendirmeyin; Pratik tanıma, sinyallerin kombinasyonlarından ve zamanla evrimlerinden gelir.
• Client Hints sadece "daha UA alan" olarak düşünmeyin; Değerleri yapılandırılmış, talep odaklı ve yönetilebilir açıklamada yatmaktadır.

Bir sistem, bir tarayıcı adını tanımlamaktan, ihtiyaç duyduğu yeteneği test etmeye ve her mevcut detayı toplamaktan sadece gerekli olanı talep etmeye geçtiğinde, UA gerçek rolüne geri döner: bir kimlik gerçeği değil, uyumluluk ipucu.

Referanslar ve standartlar

1. Peter Eckersley. How Unique Is Your Web Browser?. Privacy Enhancing Technologies Symposium, 2010.
2. Pierre Laperdrix, Nataliia Bielova, Benoit Baudry, Gildas Avoine. Browser Fingerprinting: A Survey. ACM Transactions on the Web, 2020.
3. Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, Romain Rouvoy. FP-Scanner: The Privacy Implications of Browser Fingerprint Inconsistencies. USENIX Security Symposium, 2018.
4. Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, Romain Rouvoy. FP-STALKER: Tracking Browser Fingerprint Evolutions. IEEE Symposium on Security and Privacy, 2018.
5. IETF. RFC 9110: HTTP Semantics, 2022.
6. IETF. RFC 8942: HTTP Client Hints, 2021.
7. WICG. User-Agent Client Hints, Draft Community Group Report.
8. Chromium. User-Agent Reduction.
9. Chrome for Developers. Improve user privacy and developer experience with User-Agent Client Hints.