Buksan ang panel ng Network sa mga tool ng developer ng iyong browser at halos palaging makakahanap ka ng isang header ng User-Agent. Mukhang isang maikling pagpapakilala: kung aling browser ang gumagawa ng kahilingan, kung aling operating system ang pinapatakbo nito, at kung aling bersyon ang inaangkin nito.
Ginagawa nitong nakatutukso na ituring ang header bilang isang ID ng aparato - o ipalagay na ang pagbabago ng isang linya ay maaaring gawing ibang aparato ang isang browser. Ang parehong mga ideya ay bahagyang tama lamang.
Ang isang User-Agent string, o UA, ay impormasyon ng pagiging tugma na ipinahayag ng kliyente. Hindi ito isang pinagkakatiwalaang kredensyal ng pagkakakilanlan, at maaaring baguhin ito ng isang kliyente. Ngunit hindi ito umiiral nang hiwalay. Maaaring ihambing ng isang site ang UA sa Client Hints, JavaScript API, mga katangian ng screen, mga font, Canvas, WebGL, konteksto ng network, at pag-uugali. Ang kapaki-pakinabang na tanong ay samakatuwid ay hindi lamang kung ang isang UA ay maaaring baguhin, ngunit kung ano ang papel na ginagampanan nito sa kumpletong nakikitang ibabaw ng browser.
Ang artikulong ito ay gumagamit ng mga pamantayan ng HTTP at pananaliksik sa browser-fingerprinting upang sagutin ang apat na katanungan:
- Bakit ang isang UA string ay mukhang isang piraso ng arkeolohiya ng browser?
- Gaano karaming impormasyon ang maaaring mag-ambag UA, at paano natin dapat bigyang-kahulugan ang pananaliksik?
- Bakit ang pagbabago lamang ng UA ay maaaring lumikha ng isang mas malinaw na hindi pagkakapare-pareho?
- Ano nga ba talaga ang nagbago UA Reduction at User-Agent Client Hints?
Sa artikulong ito, ang UA ay pangunahing nangangahulugang ang HTTP
User-Agentna header ng kahilingan. Tinatalakay din namin angnavigator.userAgentatnavigator.userAgentDatasa JavaScript. Ang mga interface na ito ay may kaugnayan ngunit hindi permanenteng magkapareho sa bawat browser at konteksto.
1. Ano ang isang User-Agent?
Seksyon 10.1.5 ng RFC 9110 ay tumutukoy sa User-Agent bilang isang patlang na naglalaman ng impormasyon tungkol sa ahente ng gumagamit na nagmula sa kahilingan. Ang pinasimpleng gramatika nito ay:
User-Agent = product *( RWS ( product / comment ) )
product = token [ "/" product-version ]
Sa simpleng wika, ang string ay nagsisimula sa isang pangalan ng produkto at maaaring magsama ng isang bersyon. Higit pang mga produkto o komento ay maaaring sundin. Kinikilala ng pamantayan ang mga gamit tulad ng interoperability workarounds, diagnostics, at analytics, ngunit pinapayuhan din nito ang mga pagpapatupad na huwag ibunyag ang hindi kinakailangang detalye: ang mas mahaba, mas tiyak na UA ay nagdaragdag ng parehong laki ng kahilingan at panganib sa fingerprinting.
Ang isang modernong Chromium desktop UA ay maaaring magmukhang ganito:
Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/145.0.0.0 Safari/537.36
Ang paghahati ng string sa pamamagitan ng mga puwang ay nagpapakita ng ilang mga pangalan na lumilitaw na walang kaugnayan sa Chrome:
| Token | Ano ang karaniwang kahulugan nito ngayon | Isang karaniwang maling pagbasa |
|---|---|---|
Mozilla/5.0 | Isang makasaysayang token ng pagiging tugma | Ang browser ay dapat na Firefox o isang Mozilla na produkto |
Windows NT 10.0 | Isang kategorya ng Windows platform; Ang isang pinababang UA ay hindi maaasahan na makilala ang Windows 10 mula sa 11 | Dapat tumakbo ang computer Windows 10 |
Win64; x64 | Isang pahiwatig na ito ay 64-bit na Windows sa isang x86-64 na arkitektura | Pinatutunayan nito ang eksaktong pisikal na modelo ng CPU |
AppleWebKit/537.36 | Isang engine-lineage at compatibility token | Ginagamit pa rin Chrome ang kumpletong pagpapatupad ng Safari |
KHTML, like Gecko | Wika ng pagkakatugma sa kasaysayan | Parehong tumatakbo sina KHTML at Gecko |
Chrome/145.0.0.0 | Ang pamilya ng Chrome / Chromium at pangunahing bersyon; Ang mga bahagi ng mas mababang bersyon ay maaaring mabawasan | Ipinapakita nito ang eksaktong bersyon ng patch |
Safari/537.36 | Isang token na napanatili para sa pagiging tugma sa mga mas lumang site | Ang browser ay dapat na Safari |
Ang UA ay naging verbose dahil ang mga unang website ay madalas na branched sa mga pangalan ng browser. Ang mga bagong browser ay kailangang mag-angkin ng pagiging tugma sa mga mas lumang produkto upang matanggap ang tamang pahina. Ang mga deklarasyong ito ay naipon sa paglipas ng panahon, na lumilikha ng isang makasaysayang talaan na hindi maaaring basahin nang literal.
Ang unang panuntunan ng pag-parse ng UA ay samakatuwid ay simple: ** ito ay isang protocol ng pagiging tugma, hindi isang mahigpit na paglalarawan ng aparato.
2. Bakit ginagamit pa rin ng mga website ang UA?
UA ay hindi lamang ginagamit para sa pagsubaybay. Kabilang sa mga lehitimong paggamit ang:
- paghahatid ng isang fallback sa isang mas lumang browser na may isang kilalang problema sa pagiging tugma;
- pumili ng naaangkop na installer o format ng pag-download;
- paghahanap ng mga pagkabigo na tukoy sa bersyon sa mga diagnostic log;
- pagsukat ng malawak na browser-pamilya, platform, at pangunahing bersyon ng pamamahagi;
- Pagtukoy sa mga imposibleng kumbinasyon sa awtomatikong o nakakahamak na trapiko.
Ang problema ay nagsisimula kapag ang UA sniffing ay gumagalaw mula sa isang makitid na pagkakatugma fallback sa paghula ng mga kakayahan sa pamamagitan ng pangalan ng produkto. Maaaring makita ng code ang Chrome at ipagpalagay na umiiral ang isang partikular na API. Ang palagay na iyon ay maaaring mabigo sa isang naka-embed na WebView, isang browser na nagmula sa Chromium, isang browser na may patakaran sa enterprise, isang frozen na UA, o isang kliyente na nagbago ng header nito.
Ang isang mas matibay na pagkakasunud-sunod ng mga operasyon ay:
- Subukan ang kinakailangang API o pag-uugali nang direkta tuwing posible ang pagtuklas ng kakayahan.
- Kapag hindi maiiwasan ang pagkakakilanlan ng browser, gumamit ng isang pinapanatiling parser sa halip na isang ad hoc regular na expression.
- Mag-imbak lamang ng magaspang na kategorya na talagang kailangan ng produkto.
- Magbigay ng isang fallback para sa mga hindi kilalang tatak, hindi kilalang mga bersyon, at nawawalang mga patlang.
3. UA ba isang fingerprint ng browser?
Mas tiyak, UA ay ** isang input sa isang fingerprint ng browser **, hindi karaniwang ang kumpletong fingerprint.
Ang fingerprinting ng browser ay hindi nangangailangan ng isang lihim na serial number. Sinusukat nito ang isang koleksyon ng medyo matatag, natatanging mga katangian na nakalantad sa pamamagitan ng browser. Nag-aambag UA ng mga pahiwatig tungkol sa pamilya ng browser, bersyon, at platform. Ang mga sukat ng screen, mga font, timezone, Canvas, WebGL, AudioContext, at iba pang mga interface ay nagdaragdag ng karagdagang impormasyon.
Ang survey ni Laperdrix at mga kasamahan, Browser Fingerprinting: A Survey, ay tinatalakay ang mga pamamaraang ito bilang isang anyo ng pagkilala sa stateless. Ang isang site ay hindi kinakailangang magsulat ng isang Cookie muna; Maaari itong subukang iugnay ang mga pagbisita mula sa mga katangian na inilalantad ng isang browser. Ang "stateless" ay hindi nangangahulugan na ang server ay nag-iimbak ng wala. Nangangahulugan ito na ang materyal ng pagkilala ay hindi nakasalalay sa isang patuloy na identifier ng client-side.
1. Ano ang ibig sabihin ng 10-bit na resulta ng papel?
Sa 2010 Panopticlick pag-aaral How Unique Is Your Web Browser?, sinuri ni Peter Eckersley ang humigit-kumulang 470,000 mga fingerprint ng browser. Iniulat ng pahayagan na:
- ang kumpletong fingerprint ay nagdala ng isang average ng tungkol sa ** 18.1 bit ** ng pagkakakilanlan ng impormasyon sa sample na iyon;
- Ilagay intuitively, ang isang average na fingerprint ay naganap nang humigit-kumulang isang beses sa 286,777 browser;
- Ang talahanayan ay nag-ulat tungkol sa ** 10.0 bit ** ng average na impormasyon para sa UA string lamang;
- sa mga browser na pinagana ang Flash o Java, 94.2% ng kumpletong mga fingerprint ay natatangi.
Ang impormasyon sa sarili ay karaniwang nakasulat bilang:
I(x) = -log₂ P(x)
Kung ang isang partikular na UA ay nangyayari na may posibilidad 1/1024 sa isang populasyon, ang pagmamasid nito ay nagbibigay ng 10 bits ng impormasyon. Hindi ito nangangahulugan na ang UA ay may eksaktong 1,024 na posibleng mga halaga o na natatanging kinikilala nito ang isang tao. Inilalarawan nito kung gaano karaming kawalan ng katiyakan ang pagmamasid na iyon ay nag-aalis sa karaniwan.
2. Bakit ang resulta ng 2010 ay hindi isang pare-pareho para sa web ngayon?
Ang resulta ay nananatiling mahalaga, ngunit nangangailangan ito ng hindi bababa sa tatlong kwalipikasyon:
- Ang mga bisita sa isang pahina ng pagsubok sa privacy ay hindi isang random na sample ng lahat ng mga gumagamit ng internet;
- browser, plugin, at pagkakaiba-iba ng UA-bersyon sa 2010 ay naiiba nang malaki mula sa ecosystem ngayon;
- UA Reduction, ang pag-urong ng mga ibabaw ng plugin, at mga proteksyon ng anti-fingerprinting ay nagbago sa pamamahagi ng mga nakikipag-ugnay na katangian.
Sinusuportahan ng pag-aaral ang pag-angkin na ang UA at iba pang mga katangian ay maaaring mag-ambag ng masusukat na impormasyong nagpapakilala. Hindi nito sinusuportahan ang pagsasabi na ang isang UA ay palaging may eksaktong 10 bits ng entropy ngayon. Ang kapangyarihan ng fingerprinting ay nakasalalay sa populasyon, window ng oras, mga patakaran sa browser, at ang kumbinasyon ng mga signal.
4. Bakit ang pagbabago ay maaaring mag-backfire lamang UA?
UA ay isang deklarasyon ng kliyente na walang cryptographic proof. Hindi mababasa ng isang server ang katotohanan ng pabrika ng isang aparato mula sa header na ito. Gayunman, maaari nitong suriin kung ang iba't ibang obserbasyon ay makatwirang magkatugma.
Ipagpalagay na ang isang UA ay nag-aangkin na isang mobile browser, ngunit ang pahina ay hindi nagmamasid ng mga touch point, isang window na palaging kahawig ng isang desktop display, at Client Hints na nag-uulat ng isang desktop platform. Anumang obserbasyon ay maaaring magkaroon ng lehitimong eksepsiyon. Ang ilang matatag na kontradiksyon nang magkasama ay maaari pa ring bumuo ng isang maiuri na pattern.
Ang papel ng Panopticlick ay naidokumento na ang mga maihahambing na kaso: ang ilang mga browser ay nag-angkin na isang iPhone habang sumusuporta sa Flash, at ang ilang Firefox UAs ay lumitaw kasama ang mga tampok ng imbakan na magagamit lamang sa Internet Explorer. Sinuri ng 2018 FP-Scanner pag-aaral ang problemang ito nang sistematiko. Ang ilang mga extension ng anti-fingerprinting at mga tool sa spoofing ay nagpakilala ng mga hindi pagkakapare-pareho sa mga interface, na nagpapahintulot sa isang detektor na makilala ang mga binagong katangian at, sa ilang mga kaso, ipahiwatig ang orihinal na browser o pamilya ng operating system.
Hindi lahat ng hindi pagkakapare-pareho ay malisyoso. Ang mga remote desktop, mga tool sa pag-access, mga patakaran sa enterprise, mga layer ng pagiging tugma, at hindi pangkaraniwang hardware ay maaaring lumikha ng mga hindi pangkaraniwang kumbinasyon. Ang isang maingat na sistema ng panganib ay dapat ituring ang isang hindi pagkakapare-pareho bilang probabilistic na katibayan, hindi isang awtomatikong dahilan upang harangan ang isang gumagamit.
Para sa pamamahala ng profile ng browser, tatlong katangian ang mahalaga:
- ** Panloob na pagkakapare-pareho: ** Ang mga signal ng UA, Client Hints, platform, arkitektura, touch, at screen ay hindi dapat direktang sumalungat sa isa't isa.
- Katatagan sa paglipas ng panahon: Ang isang pangmatagalang profile ay hindi dapat magbago nang malaki sa bawat paglulunsad nang walang dahilan.
- ** Kapani-paniwala pagkakaiba-iba: ** Ang mga profile ay maaaring magkakaiba, ngunit ang mga bihirang mekanikal na nabuo na kumbinasyon ay hindi kinakailangang mas ligtas.
Ipinakita rin ng FP-STALKER na pag-aaral na ang pagbabago ng mga katangian ay hindi awtomatikong pumipigil sa pag-uugnay. Ang isang modelo ay maaaring gumamit ng matatag na mga katangian at kapani-paniwala na mga pagbabago sa bersyon upang kumonekta sa mas maaga at mamaya fingerprints.
5. Anong problema ang tinutugunan UA Reduction?
Ang isang tradisyunal na UA ay ipinapadala sa halos lahat ng kahilingan. Ang anumang first-party o third-party na endpoint na tumatanggap ng kahilingan ay maaaring basahin ito nang pasibo. Ang mas tumpak na string, mas natatanging impormasyon ang nakukuha ng bawat tatanggap bilang default.
Chromium User-Agent Reduction plan binabawasan ang default na granularity na ito:
- Simula sa Chrome 101, ang mga bersyon ng desktop minor, build, at patch ay nabawasan sa
0.0.0; - mga susunod na yugto pinag-isang mga bersyon ng operating system ng desktop, mga detalye ng CPU, at impormasyon ng aparato ng Android;
- Ang isang pinababang Android UA ay gumagamit ng mga nakapirming platform at mga halaga ng modelo tulad ng
Android 10; K; - Ang mga site na tunay na nangangailangan ng karagdagang detalye ay maaaring humiling ng User-Agent Client Hints.
Ang pinababang format ay maaaring ibuod bilang:
Mozilla/5.0 (<unified platform information>)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/<major version>.0.0.0 Safari/537.36
Ang pagbawas ay binabawasan ang passive fingerprinting surface ng legacy UA. Hindi nito inaalis ang fingerprinting ng browser. Ang pangunahing bersyon, malawak na platform, at estado ng mobile ay maaaring manatiling nakikita, habang ang iba pang mga API, mga katangian ng network, at pag-uugali ay maaari pa ring magbigay ng impormasyon.
6. Paano gumagana User-Agent Client Hints?
Ang pangkalahatang mekanismo ay tinukoy sa RFC 8942, habang ang WICG User-Agent Client Hints draft ay naglalarawan ng mga patlang na tukoy sa UA. Ang diskarte ay naghahati ng impormasyon na dating nakatira sa isang hindi nakabalangkas na string sa mga nakabalangkas na patlang, na nakikilala ang mga pahiwatig na mababa ang entropy na maaaring ipadala bilang default mula sa mga pahiwatig na may mataas na entropy na karaniwang hinihiling ng isang site nang malinaw.
Ang isang pinasimpleng paunang kahilingan ay maaaring magmukhang ganito:
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"
Kung ang server ay tunay na nangangailangan ng arkitektura at bitness upang pumili ng isang installer, maaari itong tumugon sa:
HTTP/1.1 200 OK
Accept-CH: Sec-CH-UA-Arch, Sec-CH-UA-Bitness
Vary: Sec-CH-UA-Arch, Sec-CH-UA-Bitness
Kapag sinusuportahan ng browser ang mekanismo at natutugunan ang mga kinakailangan sa seguridad at patakaran, ang isang kahilingan sa ibang pagkakataon ay maaaring magsama ng:
Sec-CH-UA-Arch: "x86"
Sec-CH-UA-Bitness: "64"
Kabilang sa mga karaniwang UA Client Hints ang:
| Patlang | Tipikal na layunin | Antas ng impormasyon |
|---|---|---|
Sec-CH-UA | Listahan ng tatak at pangunahing bersyon | Karaniwang mababang entropy |
Sec-CH-UA-Mobile | Kung mas gusto ng kliyente ang isang karanasan sa mobile | Karaniwang mababang entropy |
Sec-CH-UA-Platform | Malawak na kategorya ng platform | Karaniwang mababang entropy |
Sec-CH-UA-Arch | Arkitektura ng CPU | Mataas na entropy; Humiling kapag kinakailangan |
Sec-CH-UA-Bitness | Arkitektura bitness | Mataas na entropy; Humiling kapag kinakailangan |
Sec-CH-UA-Platform-Version | Bersyon ng platform | Mataas na entropy; Humiling kapag kinakailangan |
Sec-CH-UA-Full-Version-List | Buong bersyon para sa mga iniulat na tatak | Mataas na entropy; Humiling kapag kinakailangan |
Sec-CH-UA-Model | Modelo ng aparato | Mataas na entropy; Humiling kapag kinakailangan |
Tatlong detalye ng engineering ang madaling makaligtaan.
1. Hindi lahat ng Client Hints ay awtomatikong ipinapadala
Ang mga pahiwatig na mababa ang entropy ay maaaring lumitaw bilang default. Ang mga pahiwatig na may mataas na entropy ay karaniwang nangangailangan ng isang Accept-CH na tugon. Ang paunang pag-navigate, subresources, patakaran sa pahintulot, ligtas na transportasyon, at suporta sa browser ay maaaring makaapekto sa kung ano ang dumating. Dapat payagan ng isang server ang bawat opsyonal na patlang na wala.
2. Ang listahan ng tatak ay sadyang sumusubok sa tibay ng parser
Sec-CH-UA ay maaaring maglaman ng maraming mga tatak at isang sintetikong tatak na ginagamit upang subukan ang pagiging tugma. Ang code ay hindi dapat ipalagay na ang unang entry ay palaging ang pangalan ng produkto, at hindi ito dapat mabigo kapag lumitaw ang isang hindi kilalang tatak. I-parse ang nakabalangkas na patlang, huwag pansinin ang mga entry na hindi mo nakikilala, at mag-iwan ng puwang para sa mga tatak sa hinaharap.
3. Ang mga tugon na nag-iiba sa mga pahiwatig ay nangangailangan ng tamang paghawak ng cache
Kung binabago ng arkitektura, platform, o iba pang pahiwatig ang tugon, i-configure nang tama ang Vary o isang katumbas na diskarte sa cache-key. Kung hindi man, ang isang ibinahaging cache ay maaaring maghatid ng nilalaman na nabuo para sa isang klase ng aparato sa isa pa.
7. Mas pribado ba Client Hints kaysa sa tradisyunal na UA?
Pinapabuti nila kung paano nakalantad ang impormasyon, ngunit hindi sila nagbibigay ng kaligtasan sa sakit mula sa fingerprinting.
Ang tradisyunal na UA ay nagpapakita ng isang malaking hindi nakabalangkas na bundle nang pasibo at bilang default. Client Hints hatiin ang bundle na iyon sa mga patlang, gawing mas malinaw ang mga kahilingan para sa impormasyon na may mas mataas na entropy, at bigyan ang browser ng pagkakataon na mag-aplay ng mga kontrol sa patakaran, pahintulot, o badyet sa privacy.
Gayunpaman, ang arkitektura, buong bersyon, mga bersyon ng platform, at mga modelo ng aparato ay maaari pa ring dagdagan ang kakayahang makilala. Malinaw na itinuturing ng RFC 8942 ang privacy at pagganap bilang mga hadlang sa disenyo. Dapat magtanong ang mga developer:
- Talagang kailangan ba ng tampok na ito ang field?
- Maaari bang palitan ito ng capability detection o ng user choice?
- Maaari bang mag-imbak ang application ng isang magaspang na kategorya?
- Gaano katagal pinapanatili ang mga raw na halaga, at sino ang maaaring ma-access ang mga ito?
- Makakatanggap ba ang mga mapagkukunan ng third-party ng parehong mga pahiwatig?
8. Patnubay sa engineering para sa paghawak ng UA sa server-side
1. Huwag kailanman gamitin UA bilang patunay ng pagkakakilanlan o awtoridad
Maaari UA suportahan ang mga pagpipilian sa pagtatanghal at mga fallback ng pagiging tugma. Hindi nito dapat matukoy ang pagkakakilanlan, awtorisasyon, tiwala sa pagbabayad, o hangganan ng seguridad. Ang isang halaga na kinokontrol ng kliyente ay hindi maaaring magsilbing isang kredensyal ng kontrol sa pag-access.
2. Mas gusto ang pagtuklas ng kakayahan kaysa sa mga listahan ng browser
Kapag ang isang front end ay nangangailangan ng isang API, subukan para sa kakayahang iyon nang direkta:
if ('share' in navigator) {
// Offer the system share feature.
} else {
// Fall back to copying a link.
}
Ang pagtuklas ng kakayahan ay humahawak ng mga nagmula na browser, mga tampok na pang-eksperimento, mga patakaran sa enterprise, at mga paglabas sa hinaharap na mas mahusay kaysa sa isang panuntunan tulad ng "paganahin ito para sa Chrome 145."
3. Tanggapin ang legacy UA, Client Hints, at hindi kilalang mga estado
Sa panahon ng paglipat, ang isang server ay maaaring makatanggap lamang ng mga legacy UA, parehong UA at Client Hints, o lubos na pinaliit na mga anyo ng pareho. Ang modelo ng data ay dapat payagan ang unknown sa halip na hulaan ang isang eksaktong operating system o modelo ng aparato upang punan ang bawat patlang.
4. Bawasan ang log granularity
Kung ang analytics ay nangangailangan lamang ng desktop kumpara sa mobile, pamilya ng browser, at pangunahing bersyon, huwag panatilihin ang mga raw na string ng UA at bawat pahiwatig ng mataas na entropy nang walang hanggan. Ang pag-minimize ng data ay binabawasan ang panganib sa privacy at pinipigilan ang isang pipeline ng analytics mula sa pagtrato sa menor de edad na pagkakaiba-iba bilang isang makabuluhang sukat.
5. Tratuhin ang mga anomalya bilang katibayan, hindi hatol
Ang isang UA na nag-aangkin Windows habang ang isang API ay kumikilos nang iba ay, sa karamihan, isang signal ng panganib. Ang mga kapaligiran ng enterprise, virtualization, remote session, mga layer ng pagiging tugma, at mga teknolohiyang pantulong ay maaaring makabuo ng mga lehitimong anomalya. Ang pag-on ng isang hindi pagkakatugma sa isang awtomatikong desisyon sa pandaraya ay lumilikha ng mga maling positibo.
9. Paano dapat i-configure UA sa mga kapaligiran ng multi-profile?
Para sa pagsubok sa cross-rehiyon, mga preview ng advertising, mga operasyon ng account, at paghihiwalay ng privacy, ang layunin ay hindi dapat lumikha ng pinaka-hindi pangkaraniwang UA. Ang isang profile ay dapat na maipaliwanag, matatag, at katugma sa nakapalibot na kapaligiran nito.
Suriin ang mga sumusunod ayon sa pagkakasunud-sunod:
- ** Bersyon ng browser: ** ang UA pangunahing bersyon ay dapat na kapani-paniwala para sa aktwal na engine at mga kakayahan nito.
- ** Operating system: ** ang UA platform, Client Hints platform, at JavaScript-nakikitang kategorya ng platform ay dapat na magkatugma.
- ** Arkitektura at bitness: ** Ang UA, Client Hints, at ang maipapatupad na kapaligiran ay hindi dapat gumawa ng direktang magkasalungat na mga pag-angkin.
- ** Device form factor: ** Ang isang mobile na deklarasyon ay dapat magkaroon ng kahulugan kasama ang suporta sa touch, viewport, pixel ratio, at mga pattern ng pakikipag-ugnayan.
- ** Konteksto ng rehiyon: ** Ang wika, timezone, geolocation, at proxy egress ay hindi kailangang tumugma sa mekanikal, ngunit dapat silang magkaroon ng kahulugan para sa tunay na daloy ng trabaho.
- Katatagan ng profile: kapag ang isang account o pagkakakilanlan ng pagsubok ay muling gumagamit ng isang pangmatagalang profile, iwasan ang paglipat ng platform at pangunahing bersyon nang walang dahilan.
Ang kasalukuyang conversion ng profile ng PurpleMark ay nagma-map ng napiling operating system sa isang platform ng UA at unang sinusubukang kunin ang bersyon ng browser mula sa isang naka-configure na token ng Chrome/ o CriOS/. Kapag walang magagamit na bersyon na umiiral, nakakakuha ito ng isang makatwirang fallback mula sa pangunahing bersyon ng kasalukuyang engine. Ang layunin ay hindi upang i-spoof ang isang nakahiwalay na string, ngunit upang ilagay ang UA configuration sa loob ng isang pare-pareho na modelo ng browser-profile.
Ang paghihiwalay ng profile at pagkakapare-pareho ng parameter ay maaaring mabawasan ang teknikal na kaugnayan at bias sa pagsubok. Hindi nila magagarantiyahan na ang mga account ay hindi kailanman mai-link, at hindi nila pinapalitan ang mga patakaran ng platform, data ng account, impormasyon sa pagbabayad, o responsableng mga kasanayan sa pagpapatakbo. Gamitin lamang ang mga kakayahang ito para sa ligal na proteksyon sa privacy, awtorisadong pagsubok, at sumusunod na aktibidad sa negosyo.
10. Mga Madalas Itanong
Q1: Ang pagbabago ba ng UA ay lumiliko ang browser sa ibang browser?
Hindi. Binabago nito ang bahagi ng ipinahayag ng customer. Hindi nito pinapalitan ang JavaScript engine, pipeline ng pag-render, stack ng network, o suportadong Web API.
Q2: Maaari bang basahin ng isang website ang "tunay na UA"?
Walang unibersal na antas ng hardware na "tunay na UA" na maaaring i-bypass ng bawat website ang browser upang mabasa. Gayunpaman, ang isang site ay maaaring ihambing ang mga Client Hints, mga pagsubok sa kakayahan, at iba pang mga signal ng fingerprint, makahanap ng mga hindi tugma na mga claim, at gumawa ng isang probabilistic inference.
Q3: Maaari bang makilala ng isang pinababang UA ang Windows 10 mula sa Windows 11?
Ang nabawasan na pamana UA karaniwang hindi maaaring gawin ito nang maaasahan dahil pareho silang maaaring mag-ulat ng Windows NT 10.0. Ang isang browser na sumusuporta sa UA Client Hints ay maaaring magbigay ng mas detalyadong impormasyon sa bersyon ng platform pagkatapos hilingin ito ng isang site. Dapat pa ring hawakan ng mga server ang mga nawawalang patlang at mga pagkakaiba sa pagmamapa.
Q4: Pinipigilan ba ng pag-disable JavaScript UA pagkakalantad?
Hindi ganap. Ang HTTP User-Agent ay isang header ng kahilingan at maaaring ipadala kasama ang kahilingan sa pahina bago tumatakbo ang pahina JavaScript. Ang hindi pagpapagana ng JavaScript ay nag-aalis ng ilang mga ibabaw ng koleksyon ngunit sinisira din ang malaking bahagi ng modernong web.
Q5: Ganap bang papalitan Client Hints User-Agent?
Huwag ipagpalagay na sa malapit na termino. Maraming mga kliyente at server ang nakasalalay pa rin sa legacy UA, habang ang suporta UA Client Hints ay nag-iiba. Tratuhin ang Client Hints bilang progresibong pagpapahusay: mas gusto ang nakabalangkas na impormasyon kapag magagamit, ngunit panatilihin ang mga fallback para sa mga legacy UA at hindi kilalang mga estado.
Q6: Pinapabuti ba ng isang random na nabuo na UA ang pagkawala ng lagda?
Hindi kinakailangan. Ang pag-randomize ng isang patlang ay maaaring lumikha ng mga kontradiksyon sa bersyon, platform, touch, at rendering signal. Para sa isang pangmatagalang profile, ang isang karaniwan, matatag, panloob na katugmang pagsasaayos ay karaniwang mas maipagtatanggol kaysa sa madalas na mga random na pagbabago.
11. Konklusyon
User-Agent ay hindi isang mapagkakatiwalaang kredensyal ng pagkakakilanlan o isang walang kabuluhang string. Nakaupo ito sa intersection ng pagiging tugma sa web, privacy, at pagsusuri sa panganib. Para sa mga developer, ito ay isang input ng pagiging tugma na nabibigatan ng kasaysayan. Para sa mga mananaliksik sa fingerprinting, ito ay isang katangian na may nasusukat na impormasyong istatistika. Para sa mga vendor ng browser, ito ay isang default na ibabaw ng pagkakalantad na kailangang mabawasan.
Ang mga pangunahing ideya ay magkasya sa tatlong pahayag:
- Huwag basahin ang isang UA nang literal; Naglalaman ito ng maraming mga makasaysayang token ng pagiging tugma.
- Huwag suriin ang UA nang hiwalay; Ang praktikal na pagkilala ay nagmumula sa mga kumbinasyon ng mga signal at ang kanilang ebolusyon sa paglipas ng panahon.
- Huwag isipin na ang Client Hints ay "mas UA na mga bukid" lamang; Ang kanilang halaga ay namamalagi sa nakabalangkas, hinihimok ng kahilingan, at pamamahala ng pagsisiwalat.
Kapag ang isang sistema ay gumagalaw mula sa pagtukoy ng isang pangalan ng browser sa pagsubok ng kakayahan na kailangan nito-at mula sa pagkolekta ng bawat magagamit na detalye sa paghiling lamang kung ano ang kinakailangan-UA ay bumalik sa tamang papel nito: isang pahiwatig ng pagiging tugma, hindi isang katotohanan ng pagkakakilanlan.
Mga sanggunian at pamantayan
- Peter Eckersley. How Unique Is Your Web Browser?. Privacy Enhancing Technologies Symposium, 2010.
- Pierre Laperdrix, Nataliia Bielova, Benoit Baudry, Gildas Avoine. Browser Fingerprinting: A Survey. ACM Transactions on the Web, 2020.
- Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, Romain Rouvoy. FP-Scanner: The Privacy Implications of Browser Fingerprint Inconsistencies. USENIX Security Symposium, 2018.
- Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, Romain Rouvoy. FP-STALKER: Tracking Browser Fingerprint Evolutions. IEEE Symposium on Security and Privacy, 2018.
- IETF. RFC 9110: HTTP Semantics, 2022.
- IETF. RFC 8942: HTTP Client Hints, 2021.
- WICG. User-Agent Client Hints, Draft Community Group Report.
- Chromium. User-Agent Reduction.
- Chrome for Developers. Improve user privacy and developer experience with User-Agent Client Hints.