Playwright மூலம் web-scraping செய்யும் டெவலப்பர்கள், ஒரு முழுமையான Chromium instance-ஐத் தொடங்கி, உண்மையான User-Agent-ஐ அமைத்து, மனிதர்களைப் போன்ற காலதாமதங்களைச் (delays) சேர்த்தும் கூட, அவர்களின் முதல் கோரிக்கை (request) நிராகரிக்கப்படுவதைக் காண்கிறார்கள். TLS handshake எனப்படும் தொழில்நுட்பத்தின் மூலம் சர்வர் அந்த கோரிக்கையைத் தடுக்கிறது; இது TLS fingerprinting என்று அழைக்கப்படுகிறது.

TLS fingerprinting விளக்கம்

ஒரு பிரவுசர் HTTPS இணைப்பைத் திறக்கும்போது, அது ஒரு ClientHello செய்தியை அனுப்புகிறது. அந்த பாக்கெட் (packet) TLS பதிப்பு, ஆதரிக்கப்படும் cipher suites, சில விரிவாக்கங்கள் (extensions - elliptic curves, signature algorithms) மற்றும் பிற புலங்களைக் (fields) பட்டியலிடுகிறது. இந்தத் துல்லியமான கலவையானது அந்த நெட்வொர்க்கிங் ஸ்டேக் (networking stack)-ஐத் தனித்துவமாக அடையாளம் காட்டுகிறது.

ஆராய்ச்சியாளர்கள் அந்த மூலப் புலங்களை (raw fields) JA3 (அல்லது அதன் புதிய பதிப்பான JA4) எனப்படும் ஒரு சுருக்கமான அடையாளமாக (identifier) மாற்றுகிறார்கள் (hash). ஒரு உண்மையான Chrome பிரவுசர் ஒரு hash-ஐ உருவாக்கும்; ஒரு Python HTTP library வேறொரு hash-ஐ உருவாக்கும். சர்வரின் hash, கோரப்பட்ட User-Agent-உடன் பொருந்தவில்லை என்றால், அது அந்த கோரிக்கையை ஒரு ஸ்கிரிப்ட் (scripted) மூலம் வந்ததாகக் குறித்துக் கொள்கிறது.

ஏன் ஒரு சாதாரண Playwright பிரவுசர் இன்னும் கண்டறியப்படலாம் (flagged)

Playwright-ன் இயல்புநிலை Chromium build பொதுவாகச் சரியான Chrome fingerprint-ஐ வெளியிடுகிறது, ஆனால் பல scrapers நிலைத்தன்மையைத் (consistency) பாதிக்கும் சில படிகளைச் சேர்க்கிறார்கள்:

  1. கலப்பு கோரிக்கை உத்திகள் (Mixed request strategies) – டெவலப்பர்கள் பெரும்பாலும் Playwright மூலம் கனமான பக்கங்களை (heavy pages) ரெண்டர் செய்யச் செய்வார்கள், அதே நேரத்தில் ஒரு இலகுவான HTTP client மூலம் துணை ஆதாரங்களை (auxiliary resources - JSON, படங்கள் போன்றவை) எடுப்பார்கள். அந்த வேகமான அழைப்புகள் (calls) Chrome-ன் fingerprint-ஐக் கொண்டிருக்காமல், அந்த library-ன் fingerprint-ஐக் கொண்டிருக்கும்; இதனால் சர்வர் அந்த முரண்பாட்டை உடனடியாகக் கண்டறிந்துவிடும்.
  2. TLS-terminating proxies – சில proxy சேவைகள் TLS stream-ஐ டிகிரிப்ட் (decrypt) செய்து, டிராஃபிக்கை ஆய்வு அல்லது மாற்றியமைத்து, பின்னர் அதை மீண்டும் என்கிரிப்ட் (re-encrypt) செய்கின்றன. இறுதியில் சர்வர் அந்த proxy-ன் fingerprint-ஐப் பார்ப்பதால், அதை ஒரு பிரவுசர் அல்லாத கிளையன்ட் (non-browser client) என்று கருதித் தடுக்கலாம்.
  3. பிற புரோட்டோகால் அடுக்குகள் (Other protocol layers) – Anti-scraping அமைப்புகள் HTTP/2 settings, header வரிசை மற்றும் IP reputation ஆகியவற்றையும் ஒப்பிடுகின்றன. எந்தவொரு அடுக்கிலும் ஏற்படும் முரண்பாடு ஒரு பிளாக்கை (block) தூண்டலாம்.

JA3 முதல் JA4 வரை: ஒரு தொழில்நுட்பப் போட்டி (arms race)

JA3 என்பது பரவலாக ஏற்றுக்கொள்ளப்பட்ட முதல் TLS fingerprint ஆகும். Chrome இப்போது ஒவ்வொரு முறை தொடங்கும் போதும் அதன் extensions வரிசையைத் தன்னிச்சையாக (randomize) மாற்றுகிறது, இது உண்மையான பிரவுசருக்கு JA3 hash-ஐ நிலையற்றதாக (unstable) மாற்றுகிறது. JA4 இதைத் தீர்க்கிறது; இது hash செய்வதற்கு முன் extension பட்டியலை வரிசைப்படுத்துகிறது, இதனால் Chrome வரிசையை மாற்றினாலும் ஒரு நிலையான அடையாளத்தை (stable identifier) வழங்குகிறது. JA4-ஐப் பயன்படுத்தும் கண்டறியும் கருவிகள் (detection tools), உண்மையான Chrome instances-களையும், ஒரு நிலையான JA3 hash-ஐ மட்டும் நகலெடுக்கும் ஸ்கிரிப்ட் கிளையன்ட்களையும் நம்பகமான முறையில் பிரித்தறிய முடியும்.

டெவலப்பர்கள் இன்று என்ன செய்யலாம்

ஒரு சர்வரை எப்போதும் ஏமாற்றக்கூடிய எந்தவொரு "மேஜிக் ஸ்ட்ரிங்கும்" (magic string) இல்லை. கோரிக்கையின் (request) ஒவ்வொரு அடுக்கும் ஒரே மாதிரியான தகவலைத் தெரிவிப்பதே நம்பகமான அணுகுமுறையாகும்:

  • User-Agent, TLS handshake, HTTP/2 settings, மற்றும் header வரிசை ஆகியவற்றை ஒரே பிரவுசர் பதிப்பு மற்றும் OS-உடன் சீரமைக்கவும் (Align).
  • ஒரு முழுமையான பிரவுசர் automation கருவியையும், தனித்த ஒரு HTTP client-ஐயும் கலந்து பயன்படுத்துவதை நிறுத்துங்கள். வேகம் முக்கியமென்றால், மிகச் சிறிய அழைப்புகள் (trivial calls) உட்பட அனைத்து நெட்வொர்க் அழைப்புகளையும் Playwright மூலம் கையாளச் செய்யுங்கள்.
  • இணைப்பைத் துண்டிக்காமல் (terminating) TLS-ஐ அப்படியே கடத்தும் (pass TLS through) proxy-களைத் தேர்ந்தெடுக்கவும், அல்லது அசல் TLS handshake-ஐ மாற்றாமல் அப்படியே அனுப்பும் வகையில் அவற்றை உள்ளமைக்கவும் (configure).
  • IP-reputation சேவைகளைக் கண்காணிக்கவும்; சுத்தமான IP pool பயன்படுத்துவது, முந்தைய தவறான பயன்பாடுகளின் (historical abuse) அடிப்படையில் பிளாக் செய்யப்படும் வாய்ப்பைக் குறைக்கும்.

Fingerprint நிலைத்தன்மையைப் புறக்கணிப்பதன் விளைவுகள்

ஒரு scraper handshake நிலையில் பிளாக் செய்யப்படும்போது, அது பக்கத்தின் லாஜிக்கிற்கு (page logic) சென்றடைவதில்லை; எனவே எந்தத் தரவும் சேகரிக்கப்படுவதில்லை மற்றும் JavaScript-ஐ இயக்குவதற்கும் நேரம் செலவிடப்படுவதில்லை. பெரிய அளவிலான தரவு சேகரிப்பைச் சார்ந்திருக்கும் நிறுவனங்கள், மீண்டும் மீண்டும் முயற்சிக்கும் (retry loops) போது கிளவுட்-கம்ப்யூட்டிங் (cloud-compute) செலவுகள் அதிகரிப்பதைப் பார்ப்பார்கள். தொடர்ச்சியான பிளாக்குகள், அதே நெட்வொர்க்கிலிருந்து வரும் பிற முறையான டிராஃபிக்கையும் பாதிக்கும் வகையில் IP bans-க்கும் வழிவகுக்கும்.

மாற்றுக்கருத்து: ஏன் இணையதளங்கள் TLS fingerprinting-ஐப் பயன்படுத்துகின்றன

இணையதள உரிமையாளர்கள் TLS fingerprinting-ஐ ஒரு முறையான பாதுகாப்பாகக் கருதுகிறார்கள். தானியங்கி scraping முறையானது சர்வர்களை அதிகச் சுமைக்குள்ளாக்கலாம் (overload), paywalls-களைத் தவிர்க்கலாம் அல்லது தனிப்பட்ட தரவுகளைப் பெருமளவில் சேகரிக்கலாம். TLS fingerprint, கோரப்பட்ட பிரவுசருடன் ஒத்துப்போகிறதா என்று சரிபார்ப்பதன் மூலம், ஒரு இணையதளம் உண்மையான பயனர்களைப் பாதிக்காமல், குறைந்த முயற்சியுடன் செயல்படும் பல வகை பாட்களை (low-effort bots) வடிகட்டுகிறது. இந்தத் தொழில்நுட்பம் CAPTCHA-க்களை விடக் குறைவான இடையூறுகளைக் கொண்டது, இதனால் பயனர் அனுபவம் (user experience) பாதிக்கப்படுவதில்லை.

அடுத்து கவனிக்க வேண்டியவை

  • JA4-ன் பயன்பாடு – வரும் மாதங்களில் அதிகப்படியான பாதுகாப்பு விற்பனையாளர்கள் (security vendors) மற்றும் CDN வழங்குநர்கள் JA4 அடிப்படையிலான கண்டறிதல் முறைகளை அறிமுகப்படுத்துவார்கள் என்று எதிர்பார்க்கலாம்.
  • பிரவுசர் அளவிலான ரேண்டமைசேஷன் (Browser-level randomization) – Chrome மற்றும் பிற பிரவுசர்கள் TLS அளவுருக்களை (parameters) தொடர்ந்து மாற்றிக்கொண்டே இருக்கலாம், இது fingerprinting கருவிகளை டிராஃபிக் டைமிங் (traffic timing) அல்லது JavaScript இயங்கும் முறைகள் போன்ற மிகவும் சிக்கலான சிக்னல்களை நோக்கித் தள்ளும்.
  • Proxy சந்தையின் பதில் – மாற்றமில்லாத handshakes-களுக்கான scraping சமூகத்தின் தேவையைப் பூர்த்தி செய்யும் வகையில், "TLS-transparent" ரூட்டிங்கை (routing) வழங்கும் சேவைகள் உருவாக வாய்ப்புள்ளது.

சுருக்கம் (Takeaway)

உங்கள் Playwright scraper எந்தப் பக்கமும் லோட் ஆவதற்கு முன்பே நிராகரிக்கப்பட்டால், அதற்கு மிக முக்கியமான காரணம் TLS fingerprint-இல் உள்ள முரண்பாடு தான். இதற்கு ஒரு உடனடித் தீர்வு (quick patch) போதாது; ஒவ்வொரு புரோட்டோகால் லேயரையும் (protocol layer) அறிவிக்கப்பட்ட பிரவுசர் ப்ரொஃபைலுடன் (browser profile) முறையாகச் சீரமைப்பது அவசியமாகும். User-Agent, TLS handshake, HTTP/2 settings, header order மற்றும் proxy behavior ஆகியவற்றில் ஒரு சீரான தன்மையைப் பேணுவதே நவீன anti-scraping பாதுகாப்புகளின் பார்வையில் சிக்காமல் இருப்பதற்கான ஒரே நம்பகமான வழியாகும்.