Developers Playwright ಬಳಸಿ ವೆಬ್-ಸ್ಕ್ರೇಪಿಂಗ್ ಮಾಡುವಾಗ, ತಮ್ಮ ಸ್ಕ್ರಿಪ್ಟ್ ಪೂರ್ಣ ಪ್ರಮಾಣದ Chromium ಇನ್‌ಸ್ಟೆನ್ಸ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದರೂ, ನೈಜ User-Agent ಅನ್ನು ಹೊಂದಿದ್ದರೂ ಮತ್ತು ಮಾನವನಂತಹ ವಿಳಂಬಗಳನ್ನು (delays) ಸೇರಿಸಿದ್ದರೂ ಸಹ, ತಮ್ಮ ಮೊದಲ ವಿನಂತಿಯನ್ನೇ (request) ತಿರಸ್ಕರಿಸಲ್ಪಡುವುದನ್ನು ನೋಡುತ್ತಿದ್ದಾರೆ. ಸರ್ವರ್ TLS handshake ಸಮಯದಲ್ಲಿ ವಿನಂತಿಯನ್ನು ತಡೆಹಿಡಿಯುತ್ತದೆ, ಇದನ್ನು TLS fingerprinting ಎಂಬ ತಂತ್ರ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ.

TLS fingerprinting ವಿವರಣೆ

ಬ್ರೌಸರ್ ಒಂದು HTTPS ಸಂಪರ್ಕವನ್ನು (connection) ತೆರೆದಾಗ ಅದು ClientHello ಸಂದೇಶವನ್ನು ಕಳುಹಿಸುತ್ತದೆ. ಈ ಪ್ಯಾಕೆಟ್ TLS ಆವೃತ್ತಿ, ಬೆಂಬಲಿತ cipher suites, ಎಕ್ಸ್‌ಟೆನ್ಷನ್‌ಗಳ ಗುಂಪು (elliptic curves, signature algorithms) ಮತ್ತು ಇತರ ಕೆಲವು ಫೀಲ್ಡ್‌ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ. ಈ ನಿಖರವಾದ ಸಂಯೋಜನೆಯು ನೆಟ್‌ವರ್ಕಿಂಗ್ ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ವಿಶಿಷ್ಟವಾಗಿ ಗುರುತಿಸುತ್ತದೆ.

ಸಂಶೋಧಕರು ಆ ಕಚ್ಚಾ ಫೀಲ್ಡ್‌ಗಳನ್ನು JA3 (ಅಥವಾ ಅದರ ಹೊಸ ರೂಪವಾದ JA4) ಎಂದು ಕರೆಯಲಾಗುವ ಸಂಕ್ಷಿಪ್ತ ಐಡೆಂಟಿಫೈಯರ್‌ಗೆ ಹ್ಯಾಶ್ (hash) ಮಾಡುತ್ತಾರೆ. ನೈಜ Chrome ಬ್ರೌಸರ್ ಒಂದು ಹ್ಯಾಶ್ ಅನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ; Python HTTP ಲೈಬ್ರರಿ ಮತ್ತೊಂದನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ. ಸರ್ವರ್‌ನ ಹ್ಯಾಶ್claimed User-Agent ಗೆ ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ, ಅದು ವಿನಂತಿಯನ್ನು ಸ್ಕ್ರಿಪ್ಟ್ ಮಾಡಲಾಗಿದೆ ಎಂದು ಗುರುತಿಸುತ್ತದೆ.

ಸಾಮಾನ್ಯ Playwright ಬ್ರೌಸರ್ ಅನ್ನು ಏಕೆ ಇನ್ನೂ ಫ್ಲ್ಯಾಗ್ ಮಾಡಬಹುದು

Playwright ನ ಡಿಫಾಲ್ಟ್ Chromium ಬಿಲ್ಡ್ ಸಾಮಾನ್ಯವಾಗಿ ಸರಿಯಾದ Chrome fingerprint ಅನ್ನು ನೀಡುತ್ತದೆ, ಆದರೆ ಅನೇಕ ಸ್ಕ್ರೇಪರ್‌ಗಳು ಸ್ಥಿರತೆಯನ್ನು (consistency) ಹಾಳುಮಾಡುವ ಹಂತಗಳನ್ನು ಸೇರಿಸುತ್ತಾರೆ:

  1. ಮಿಶ್ರಿತ ವಿನಂತಿ ತಂತ್ರಗಳು (Mixed request strategies) – ಡೆವಲಪರ್‌ಗಳು ಹೆಚ್ಚಾಗಿ Playwright ಅನ್ನು ಭಾರೀ ಪೇಜ್‌ಗಳನ್ನು ರೆಂಡರ್ ಮಾಡಲು ಬಿಡುತ್ತಾರೆ, ಆದರೆ ಪೂರಕ ಸಂಪನ್ಮೂಲಗಳನ್ನು (JSON, ಚಿತ್ರಗಳು ಇತ್ಯಾದಿ) ಪಡೆಯಲು ಲೈಟ್‌ವೇಯ್ಟ್ HTTP ಕ್ಲೈಂಟ್ ಅನ್ನು ಬಳಸುತ್ತಾರೆ. ಆ ವೇಗದ ಕರೆಗಳು Chrome ನ ಬದಲಿಗೆ ಲೈಬ್ರರಿಯ fingerprint ಅನ್ನು ಹೊಂದಿರುತ್ತವೆ ಮತ್ತು ಸರ್ವರ್ ತಕ್ಷಣವೇ ಈ ವ್ಯತ್ಯಾಸವನ್ನು ಪತ್ತೆಹಚ್ಚುತ್ತದೆ.
  2. TLS-terminating proxies – ಕೆಲವು ಪ್ರೊಕ್ಸಿ ಸೇವೆಗಳು TLS ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಡಿಕ್ರಿಪ್ಟ್ ಮಾಡಿ, ಟ್ರಾಫಿಕ್ ಅನ್ನು ಪರೀಕ್ಷಿಸುತ್ತವೆ ಅಥವಾ ಮಾರ್ಪಡಿಸುತ್ತವೆ, ನಂತರ ಅದನ್ನು ಮರು-ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡುತ್ತವೆ. ಸರ್ವರ್ ಅಂತಿಮವಾಗಿ ಪ್ರೊಕ್ಸಿಯ fingerprint ಅನ್ನು ನೋಡುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಬ್ರೌಸರ್ ಅಲ್ಲದ ಕ್ಲೈಂಟ್ ಎಂದು ತಡೆಹಿಡಿಯಬಹುದು.
  3. ಇತರ ಪ್ರೋಟೋಕಾಲ್ ಪದರಗಳು (Other protocol layers) – ಆಂಟಿ-ಸ್ಕ್ರೇಪಿಂಗ್ ವ್ಯವಸ್ಥೆಗಳು HTTP/2 ಸೆಟ್ಟಿಂಗ್‌ಗಳು, ಹೆಡರ್ ಕ್ರಮ (header order) ಮತ್ತು IP ರೆಪ್ಯುಟೇಶನ್ ಅನ್ನು ಸಹ ಹೋಲಿಕೆ ಮಾಡುತ್ತವೆ. ಯಾವುದೇ ಪದರದಲ್ಲಿನ ವ್ಯತ್ಯಾಸವು ಬ್ಲಾಕ್ ಆಗಲು ಕಾರಣವಾಗಬಹುದು.

JA3 ನಿಂದ JA4 ವರೆಗೆ: ಶಸ್ತ್ರಾಸ್ತ್ರ ಸ್ಪರ್ಧೆ (the arms race)

JA3 ಮೊದಲಿಗೆ ವ್ಯಾಪಕವಾಗಿ ಅಳವಡಿಸಿಕೊಳ್ಳಲಾದ TLS fingerprint ಆಗಿತ್ತು. Chrome ಈಗ ಪ್ರತಿ ಲಾಂಚ್ ಮಾಡುವಾಗ ತನ್ನ ಎಕ್ಸ್‌ಟೆನ್ಷನ್‌ಗಳ ಕ್ರಮವನ್ನು ಯಾದೃಚ್ಛಿಕಗೊಳಿಸುತ್ತದೆ (randomize), ಇದು ನೈಜ ಬ್ರೌಸರ್‌ನ 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 ಪೂಲ್ ಇರುವುದು ಹಿಂದಿನ ದುರುಪಯೋಗದ ಆಧಾರದ ಮೇಲೆ ಬ್ಲಾಕ್ ಆಗುವ ಸಾಧ್ಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

Fingerprint ಸ್ಥಿರತೆಯನ್ನು ನಿರ್ಲಕ್ಷಿಸುವುದರಿಂದ ಆಗುವ ನಷ್ಟ

ಸ್ಕ್ರೇಪರ್ ಅನ್ನು handshake ಹಂತದಲ್ಲೇ ತಡೆಹಿಡಿದಾಗ, ಅದು ಪೇಜ್ ಲಾಜಿಕ್ ಅನ್ನು ತಲುಪುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಯಾವುದೇ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ ಮತ್ತು JavaScript ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸಮಯ ವ್ಯರ್ಥವಾಗುವುದಿಲ್ಲ. ದೊಡ್ಡ ಪ್ರಮಾಣದ ಡೇಟಾ ಸಂಗ್ರಹಣೆಯನ್ನು ಅವಲಂಬಿಸಿರುವ ಉದ್ಯಮಗಳು, ರಿಟ್ರೈ ಲೂಪ್‌ಗಳು (retry loops) ಚಲಿಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ ಕ್ಲೌಡ್-ಕಂಪ್ಯೂಟ್ ವೆಚ್ಚಗಳು ಹೆಚ್ಚಾಗುವುದನ್ನು ನೋಡುತ್ತಾರೆ. ಪದೇ ಪದೇ ಬ್ಲಾಕ್ ಆಗುವುದರಿಂದ ಒಂದೇ ನೆಟ್‌ವರ್ಕ್‌ನ ಇತರ ಕಾನೂನುಬದ್ಧ ಟ್ರಾಫಿಕ್ ಅನ್ನು અસરಿಸುವ IP ಬ್ಯಾನ್‌ಗಳು ಕೂಡ ಸಂಭವಿಸಬಹುದು.

ವಿರೋಧಾತ್ಮಕ ಅಂಶ: ಸೈಟ್‌ಗಳು TLS fingerprinting ಅನ್ನು ಏಕೆ ಬಳಸುತ್ತವೆ

ಸೈಟ್ ಮಾಲೀಕರು TLS fingerprinting ಅನ್ನು ಒಂದು ಕಾನೂನುಬದ್ಧ ರಕ್ಷಣೆಯಾಗಿ ನೋಡುತ್ತಾರೆ. ಸ್ವಯಂಚಾಲಿತ ಸ್ಕ್ರೇಪಿಂಗ್ ಸರ್ವರ್‌ಗಳ ಮೇಲೆ ಹೊರೆ ಹಾಕಬಹುದು, ಪೇವಾಲ್‌ಗಳನ್ನು (paywalls) ಬೈಪಾಸ್ ಮಾಡಬಹುದು ಅಥವಾ ದೊಡ್ಡ ಪ್ರಮಾಣದಲ್ಲಿ ವೈಯಕ್ತಿಕ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಬಹುದು. TLS fingerprintclaimed ಬ್ರೌಸರ್ ಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುವ ಮೂಲಕ, ಸೈಟ್ ನೈಜ ಬಳಕೆದಾರರಿಗೆ ತೊಂದರೆ ನೀಡದೆ ಕಡಿಮೆ ಶ್ರಮದ ಬಾಟ್‌ಗಳ (low-effort bots) ದೊಡ್ಡ ಗುಂಪನ್ನು ಫಿಲ್ಟರ್ ಮಾಡುತ್ತದೆ. ಈ ತಂತ್ರವು CAPTCHAs ಗಿಂತ ಕಡಿಮೆ ತೊಂದರೆ ನೀಡುವಂತಿದ್ದು, ಬಳಕೆದಾರರ ಅನುಭವವನ್ನು ಕಾಪಾಡುತ್ತದೆ.

ಮುಂದೆ ಏನನ್ನು ಗಮನಿಸಬೇಕು

  • JA4 ಅಳವಡಿಕೆ – ಮುಂಬರುವ ತಿಂಗಳುಗಳಲ್ಲಿ ಹೆಚ್ಚಿನ ಸೆಕ್ಯೂರಿಟಿ ವೆಂಡರ್‌ಗಳು ಮತ್ತು CDN ಪ್ರೊವೈಡರ್‌ಗಳು JA4 ಆಧಾರಿತ ಡಿಟೆಕ್ಷನ್ ಅನ್ನು ಪರಿಚಯಿಸುವ ನಿರೀಕ್ಷೆಯಿದೆ.
  • ಬ್ರೌಸರ್-ಮಟ್ಟದ ಯಾದೃಚ್ಛಿಕೀಕರಣ (Browser-level randomization) – Chrome ಮತ್ತು ಇತರ ಬ್ರೌಸರ್‌ಗಳು TLS ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ಬದಲಾಯಿಸುತ್ತಿರಬಹುದು, ಇದು fingerprinting ಪರಿಕರಗಳನ್ನು ಟ್ರಾಫಿಕ್ ಟೈಮಿಂಗ್ ಅಥವಾ JavaScript ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮಾದರಿಗಳಂತಹ ಹೆಚ್ಚು ಸಂಕೀರ್ಣ ಸಂಕೇತಗಳತ್ತ ತಳ್ಳಬಹುದು.
  • ಪ್ರೊಕ್ಸಿ ಮಾರುಕಟ್ಟೆಯ ಪ್ರತಿಕ್ರಿಯೆ – ಸ್ಕ್ರೇಪಿಂಗ್ ಸಮುದಾಯದ ಬದಲಾಗದ handshakes ಅಗತ್ಯಕ್ಕೆ ಅನುಗುಣವಾಗಿ, "TLS-transparent" ರೂಟಿಂಗ್ ಅನ್ನು ಭರವಸೆ ನೀಡುವ ಸೇವೆಗಳು ಹೊರಹೊಮ್ಮುವ ಸಾಧ್ಯತೆಯಿದೆ.

ಸಾರಾಂಶ (Takeaway)

ನಿಮ್ಮ Playwright scraper ಯಾವುದೇ ಪುಟ ಲೋಡ್ ಆಗುವ ಮೊದಲೇ ತಿರಸ್ಕರಿಸಲ್ಪಟ್ಟರೆ, ಅದಕ್ಕೆ ಕಾರಣ ಬಹುಶಃ TLS fingerprint ನಲ್ಲಿನ ವ್ಯತ್ಯಾಸವೇ ಆಗಿರುತ್ತದೆ. ಇದಕ್ಕೆ ಪರಿಹಾರವು ಕೇವಲ ಒಂದು ಕ್ಷಣಿಕ ಪ್ಯಾಚ್ ಅಲ್ಲ; ಇದು ಘೋಷಿತ ಬ್ರೌಸರ್ ಪ್ರೊಫೈಲ್‌ನೊಂದಿಗೆ ಪ್ರತಿಯೊಂದು ಪ್ರೊಟೊಕಾಲ್ ಲೇಯರ್ ಅನ್ನು ಶಿಸ್ತುಬದ್ಧವಾಗಿ ಹೊಂದಿಸುವುದನ್ನು ಬಯಸುತ್ತದೆ. User-Agent, TLS handshake, HTTP/2 settings, header order ಮತ್ತು proxy behavior ಇವುಗಳ ನಡುವಿನ ಸ್ಥಿರತೆಯೇ ಆಧುನಿಕ anti-scraping ರಕ್ಷಣಾ ವ್ಯವಸ್ಥೆಗಳ ಕಣ್ಣಿಗೆ ಬೀಳದೆ ಇರಲು ಇರುವ ಏಕೈಕ ವಿಶ್ವಾಸಾರ್ಹ ಮಾರ್ಗವಾಗಿದೆ.