Playwright નો ઉપયોગ કરીને વેબ-સ્ક્રેપિંગ કરતા ડેવલપર્સનો પહેલો રિક્વેસ્ટ રિજેક્ટ થઈ રહ્યો છે, ભલે સ્ક્રિપ્ટ સંપૂર્ણ Chromium ઇન્સ્ટન્સ લોન્ચ કરે, અસલી User-Agent સેટ કરે અને માનવ જેવી વિલંબતા (delays) ઉમેરે. સર્વર TLS handshake દરમિયાન રિક્વેસ્ટને બ્લોક કરે છે, જેને TLS fingerprinting કહેવામાં આવે છે.
TLS fingerprinting ની સમજૂતી
જ્યારે બ્રાઉઝર HTTPS કનેક્શન ખોલે છે, ત્યારે તે ClientHello મેસેજ મોકલે છે. આ પેકેટમાં TLS વર્ઝન, સપોર્ટેડ cipher suites, એક્સટેન્શનનો સેટ (elliptic curves, signature algorithms) અને અન્ય કેટલાક ફીલ્ડ્સની યાદી હોય છે. આ ચોક્કસ સંયોજન નેટવર્કિંગ સ્ટેકને અનન્ય રીતે ઓળખે છે.
સંશોધકો આ કાચા (raw) ફીલ્ડ્સને JA3 (અથવા તેના નવા વર્ઝન JA4) તરીકે ઓળખાતા કોમ્પેક્ટ આઈડેન્ટિફાયરમાં હેશ કરે છે. એક અસલી Chrome બ્રાઉઝર એક હેશ બનાવે છે; જ્યારે Python HTTP લાઈબ્રેરી બીજો હેશ બનાવે છે. જો સર્વરનો હેશ ક્લેમ કરેલા User-Agent સાથે મેળ ખાતો નથી, તો તે રિક્વેસ્ટને સ્ક્રિપ્ટેડ તરીકે ફ્લેગ કરે છે.
શા માટે એક સાધારણ (vanilla) Playwright બ્રાઉઝરને હજુ પણ ફ્લેગ કરી શકાય છે
Playwright નું ડિફોલ્ટ Chromium બિલ્ડ સામાન્ય રીતે સાચું Chrome fingerprint આપે છે, પરંતુ ઘણા સ્ક્રેપર્સ એવા સ્ટેપ્સ ઉમેરે છે જે સુસંગતતા (consistency) તોડી નાખે છે:
- મિશ્ર રિક્વેસ્ટ વ્યૂહરચનાઓ (Mixed request strategies) – ડેવલપર્સ ઘણીવાર Playwright ને ભારે પેજ રેન્ડર કરવા દે છે જ્યારે એક લાઇટવેઇટ HTTP ક્લાયન્ટ સહાયક સંસાધનો (JSON, images, વગેરે) મેળવે છે. આ ઝડપી કોલ્સ લાઈબ્રેરીનું fingerprint ધરાવે છે, Chrome નું નહીં, અને સર્વર તરત જ આ વિસંગતતા પકડી લે છે.
- TLS-terminating proxies – કેટલીક પ્રોક્સી સેવાઓ TLS સ્ટ્રીમને ડિક્રિપ્ટ કરે છે, ટ્રાફિકનું નિરીક્ષણ અથવા તેમાં ફેરફાર કરે છે, અને પછી તેને ફરીથી એન્ક્રિપ્ટ કરે છે. સર્વર અંતે પ્રોક્સીનું fingerprint જુએ છે અને તેને નોન-બ્રાઉઝર ક્લાયન્ટ તરીકે બ્લોક કરી શકે છે.
- અન્ય પ્રોટોકોલ લેયર્સ – એન્ટી-સ્ક્રેપિંગ સિસ્ટમ્સ HTTP/2 સેટિંગ્સ, હેડર ઓર્ડર અને IP રેપ્યુટેશનની પણ સરખામણી કરે છે. કોઈપણ લેયરમાં વિસંગતતા બ્લોકનું કારણ બની શકે છે.
JA3 થી JA4 સુધી: એક હથિયારોની સ્પર્ધા (arms race)
JA3 એ વ્યાપકપણે અપનાવવામાં આવેલ પ્રથમ TLS fingerprint હતું. Chrome હવે દરેક લોન્ચ પર તેના એક્સટેન્શનનો ક્રમ રેન્ડમાઇઝ કરે છે, જેનાથી અસલી બ્રાઉઝર માટે JA3 હેશ અસ્થિર બને છે. JA4 હેશિંગ કરતા પહેલા એક્સટેન્શન લિસ્ટને સોર્ટ કરીને આ સમસ્યાનું સમાધાન કરે છે, જેનાથી Chrome ક્રમ બદલે તો પણ એક સ્થિર આઈડેન્ટિફાયર મળે છે. JA4 અપનાવતા ડિટેક્શન ટૂલ્સ અસલી Chrome ઇન્સ્ટન્સને માત્ર સ્ટેટિક JA3 હેશની નકલ કરતા સ્ક્રિપ્ટેડ ક્લાયન્ટ્સથી વિશ્વસનીય રીતે અલગ કરી શકે છે.
ડેવલપર્સ આજે શું કરી શકે છે
સર્વરને કાયમ માટે છેતરી શકે તેવો કોઈ "મેજિક સ્ટ્રિંગ" નથી. વિશ્વસનીય અભિગમ એ છે કે રિક્વેસ્ટના દરેક લેયર એક જ વાર્તા કહે તે રીતે સેટ કરવામાં આવે:
- User-Agent, TLS handshake, HTTP/2 settings, અને header order ને સમાન બ્રાઉઝર વર્ઝન અને OS સાથે સુસંગત બનાવો.
- ફૂલ બ્રાઉઝર ઓટોમેશન ટૂલને અલગ HTTP ક્લાયન્ટ સાથે મિક્સ કરવાનું બંધ કરો. જો ઝડપ મહત્વની હોય, તો Playwright ને તમામ નેટવર્ક કોલ્સ હેન્ડલ કરવા દો, ભલે તે સામાન્ય કે નાના હોય.
- એવા પ્રોક્સી પસંદ કરો જે કનેક્શન ટર્મિનેટ કર્યા વિના TLS ને પાસ થવા દે (pass TLS through), અથવા તેમને મૂળ TLS handshake ને બદલ્યા વિના ફોરવર્ડ કરવા માટે કોન્ફિગર કરો.
- IP-reputation સેવાઓ પર નજર રાખો; ક્લીન IP પૂલ જૂના દુરુપયોગના આધારે બ્લોક થવાની શક્યતા ઘટાડે છે.
ફિંગરપ્રિન્ટ સુસંગતતાને અવગણવાની કિંમત
જ્યારે સ્ક્રેપરને handshake સ્ટેજ પર જ બ્લોક કરવામાં આવે છે, ત્યારે તે ક્યારેય પેજ લોજિક સુધી પહોંચતું નથી, તેથી કોઈ ડેટા એકત્રિત થતો નથી અને JavaScript એક્ઝિક્યુટ કરવામાં કોઈ સમય બગડતો નથી. જે એન્ટરપ્રાઇઝ મોટા પાયે ડેટા કલેક્શન પર આધાર રાખે છે, તેમના ક્લાઉડ-કમ્પ્યુટ ખર્ચમાં વધારો જોવા મળે છે કારણ કે રિટ્રાય લૂપ્સ ચાલુ રહે છે. વારંવારના બ્લોક્સને કારણે IP બેન પણ થઈ શકે છે જે તે જ નેટવર્ક પરના અન્ય કાયદેસરના ટ્રાફિકને અસર કરે છે.
વિરોધ પક્ષ: સાઇટ્સ TLS fingerprinting નો ઉપયોગ શા માટે કરે છે
સાઇટ માલિકો TLS fingerprinting ને કાયદેસરના બચાવ તરીકે જુએ છે. ઓટોમેટેડ સ્ક્રેપિંગ સર્વર પર લોડ વધારી શકે છે, પેવોલ (paywalls) ને બાયપાસ કરી શકે છે અથવા મોટા પાયે વ્યક્તિગત ડેટા ચોરી શકે છે. TLS fingerprint ક્લેમ કરેલા બ્રાઉઝર સાથે મેળ ખાય છે કે નહીં તે તપાસીને, સાઇટ વાસ્તવિક વપરાશકર્તાઓને નુકસાન પહોંચાડ્યા વિના ઓછા પ્રયત્ન કરતા બોટ્સના મોટા વર્ગને ફિલ્ટર કરે છે. આ ટેકનિક CAPTCHAs કરતા ઓછી આક્રમક છે, જે યુઝર એક્સપિરિયન્સ જાળવી રાખે છે.
આગળ શું જોવું
- JA4 નો સ્વીકાર – આગામી મહિનાઓમાં વધુ સુરક્ષા વેન્ડર્સ અને CDN પ્રોવાઈડર્સ દ્વારા JA4-આધારિત ડિટેક્શન રજૂ કરવામાં આવશે તેવી અપેક્ષા રાખવી.
- બ્રાઉઝર-લેવલ રેન્ડમાઇઝેશન – Chrome અને અન્ય બ્રાઉઝર્સ TLS પેરામીટર્સમાં ફેરફાર કરવાનું ચાલુ રાખી શકે છે, જે ફિંગરપ્રિન્ટિંગ ટૂલ્સને ટ્રાફિક ટાઈમિંગ અથવા JavaScript એક્ઝિક્યુશન પેટર્ન જેવા વધુ જટિલ સિગ્નલ્સ તરફ ધકેલી શકે છે.
- પ્રોક્સી માર્કેટ પ્રતિસાદ – "TLS-transparent" રાઉટિંગનું વચન આપતી સેવાઓ બહાર આવવાની શક્યતા છે, જે સ્ક્રેપિંગ સમુદાયની બદલાયા વગરના (unchanged) handshakes ની જરૂરિયાત પૂરી કરશે.
મુખ્ય વાત (Takeaway)
જો તમારું Playwright સ્ક્રૅપર કોઈપણ પેજ લોડ થાય તે પહેલાં જ રિજેક્ટ થઈ જાય છે, તો તેનું કારણ લગભગ નિશ્ચિતપણે TLS ફિંગરપ્રિન્ટમાં રહેલી અસંગતતા છે. આનો ઉકેલ કોઈ તાત્કાલિક પેચ નથી; તેના માટે જાહેર કરેલ બ્રાઉઝર પ્રોફાઇલ સાથે દરેક પ્રોટોકોલ લેયરનું શિસ્તબદ્ધ રીતે સંરેખણ કરવું જરૂરી છે. User-Agent, TLS handshake, HTTP/2 સેટિંગ્સ, હેડર ઓર્ડર અને પ્રોક્સી બિહેવિયર વચ્ચેની સુસંગતતા એ આધુનિક એન્ટી-સ્ક્રૅપિંગ ડિફેન્સથી બચી રહેવાનો એકમાત્ર વિશ્વસનીય માર્ગ છે.