ആരും പേര് പറയാനാകാത്ത ട്രാഫിക്
ഒരു application's logs അടുത്തുനോക്കിയാൽ, വിശദീകരിക്കാൻ പ്രയാസമുള്ള requests നിങ്ങൾക്ക് കാണാം. അവ browser context ഇല്ലാത്ത clients-ിൽ നിന്നാണ് വരുന്നത്. അവരുടെ user-agent strings generic ആയിരിക്കാം, ശൂന്യമായിരിക്കാം, അല്ലെങ്കിൽ അറിയപ്പെടുന്ന ഒരു browser-ിൽ നിന്നുള്ള copied string ആയിരിക്കാം. അവർ അവരുടെ requests sign ചെയ്യുന്നില്ല. അവരെ ആരാണ് അയച്ചതെന്ന് അവർ പറയുന്നില്ല. ചിലത് harmless scripts ആണ്. ചിലത് യഥാർത്ഥ users-ക്കായി പ്രവർത്തിക്കുന്ന agents ആണ്. ചിലത് നിങ്ങൾക്ക് ഒരിക്കലും serve ചെയ്യാൻ ഇഷ്ടമില്ലാത്ത tools ആണ്.
ഇതാണ് അജ്ഞാത സ്വയചാലിത ട്രാഫിക്, കൂടാതെ മിക്ക ടീമുകളും ഇത് രണ്ട് വഴികളിൽ ഒന്ന് സ്വീകരിച്ചാണ് കൈകാര്യം ചെയ്യുന്നത്. ഒന്നുകിൽ ഇത് നിശ്ശബ്ദമായി human ആയി എണ്ണപ്പെടുന്നു, അതിലൂടെ analytics തെറ്റിപ്പോകുകയും അപകടകരമായ activity കടന്നുപോകുകയും ചെയ്യും, അല്ലെങ്കിൽ അത് default ആയി hostile ആയി കണക്കാക്കപ്പെടുന്നു, അതിലൂടെ legitimate users-നെയും agents-നെയും മറ്റെല്ലാവരോടൊപ്പം block ചെയ്യുന്നു. രണ്ടും ഒരേ പിഴവാണ് പങ്കിടുന്നത്: അവ missing evidence-നെ ഒരു assumption-കൊണ്ട് മാറ്റിസ്ഥാപിക്കുന്നു.
Proof of Actor ഇതിന് വിരുദ്ധമായ സമീപനമാണ് സ്വീകരിക്കുന്നത്. തെളിവ് വിശ്വസനീയമായ ഒരു determination-നെ പിന്തുണയ്ക്കുന്നില്ലെങ്കിൽ, ശരിയായ ഉത്തരം Unknown ആണ്, കൂടാതെ Unknown ദൃശ്യമാകുകയും, അളക്കാവുന്നതാകുകയും, ഉദ്ദേശപൂർവ്വം കൈകാര്യം ചെയ്യപ്പെടുകയും വേണം. blog post why Unknown is a valid result for AI traffic ഈ വാദം പൂർണമായി വിശദീകരിക്കുന്നു.
Unknown ഒരു first-class result ആകേണ്ടത് എന്തുകൊണ്ട്
Proof of Actor ഓരോ interaction-നെയും നാല് classes-ൽ ഒന്നായി class ചെയ്യുന്നു: Human, Human + AI, Agent അല്ലെങ്കിൽ Unknown. Unknown ഒരു error state അല്ല, അല്ലെങ്കിൽ product-ിലെ ഒരു gap അല്ല. അത് വ്യക്തമായ അർത്ഥമുള്ള ഒരു deliberate result ആണ്: ലഭ്യമായ തെളിവ് വിശ്വസനീയമായ ഒരു determination-നെ പിന്തുണയ്ക്കുന്നില്ല.
ആ സത്യസന്ധതയ്ക്ക് practical benefits ഉണ്ട്.
- നിങ്ങളുടെ analytics കൃത്യമായി നിലനിൽക്കും. Human, Agent counts പിന്തുണയ്ക്കുന്ന തെളിവുള്ള interactions മാത്രം ഉൾപ്പെടുത്തുന്നതിനാൽ അവ പറയുന്നത് തന്നെയാണ് അർത്ഥം.
- നിങ്ങളുടെ coverage അളക്കാവുന്നതാണ്. ഓരോ route-ലുമുള്ള Unknown-ന്റെ share എവിടെയാണ് കൂടുതൽ evidence ആവശ്യമായത് എന്ന് കൃത്യമായി കാണിക്കുന്നു.
- നിങ്ങളുടെ policies കൂടുതൽ സുരക്ഷിതമാണ്. അനിശ്ചിതമായ കേസുകൾ നിങ്ങൾ തിരഞ്ഞെടുത്ത ഒരു fallback-ലേക്ക് ഒഴുകിപ്പോകും, trusted അല്ലെങ്കിൽ blocked എന്നെല്ലാം guess ചെയ്ത് നിശ്ശബ്ദമായി കൈകാര്യം ചെയ്യുന്നതിന് പകരം.
Unknown ഒരിക്കലും Human ആയി മാറുന്നില്ല, കൂടാതെ default ആയി malicious ആയി കണക്കാക്കുകയും ചെയ്യുന്നില്ല. കൂടുതൽ അറിയാൻ Unknown classification glossary entry, Detection & Limitations, കൂടാതെ why Unknown is a valid result for AI traffic എന്നിവ കാണുക. websites ഉം APIs ഉം use cases ടീമുകൾ പ്രായോഗികമായി Unknown fallbacks എങ്ങനെ നിശ്ചയിക്കുന്നു എന്ന് കാണിക്കുന്നു.
അജ്ഞാത സ്വയചാലിത ട്രാഫിക് എവിടെ നിന്നാണ് വരുന്നത്
ഉറവിടങ്ങൾ മനസ്സിലാക്കുന്നത് അത് എങ്ങനെ കൈകാര്യം ചെയ്യണം എന്ന് തീരുമാനിക്കാൻ സഹായിക്കുന്നു.
ഒപ്പില്ലാത്ത സ്വയചാലിത clients
RFC 9421-ൽ നിർവചിച്ചിരിക്കുന്ന HTTP Message Signatures ഉപയോഗിച്ചുള്ള request signing ഐച്ഛികമാണ്, കൂടാതെ IETF Web Bot Auth working group automated clients ഈ രീതിയിൽ എങ്ങനെ authenticate ചെയ്യണം എന്ന് ഇപ്പോഴും standardize ചെയ്യുകയാണ്. ഒരു signature ഇല്ലെങ്കിൽ, ഒരു client's identity അത് സ്വന്തംതായി പറയുന്ന കാര്യങ്ങളിൽ മാത്രമേ ആശ്രയിക്കൂ.
പകർത്തിയ അല്ലെങ്കിൽ generic user agents
User-agent strings ക്രമീകരിക്കുന്നത് വളരെ എളുപ്പമാണ്. ഒരു സുപ്രസിദ്ധ browser അല്ലെങ്കിൽ crawler ആണെന്ന് അവകാശപ്പെടുന്ന ഒരു client അതുതന്നെയാകാം, അല്ലെങ്കിൽ അതിനെ അനുകരിക്കുന്നതാകാം. user-agent spoofing entry ഈ header മാത്രം ഒരു classification വഹിക്കാൻ കഴിയില്ലെന്ന് വിശദീകരിക്കുന്നു. അതുകൊണ്ടുതന്നെ search engines വേർതിരിച്ച verification methods രേഖപ്പെടുത്തുന്നു: Google verifying Googlebot-ക്കായി reverse, forward DNS lookups കൂടാതെ published IP ranges വിശദീകരിക്കുന്നു, Bing verifying Bingbot-ക്കായി അതേ DNS check വിശദീകരിക്കുന്നു.
integration ഇല്ലാത്ത routes
ഒരു route-ന് browser integration ഇല്ലാതെയും അടിസ്ഥാനങ്ങളെക്കാൾ കൂടുതൽ server-side context ഇല്ലാതെയും ആണെങ്കിൽ, നിരീക്ഷിക്കാൻ simply കുറവേ ഉണ്ടാകൂ. ആ routes-ൽ Unknown കാണുന്നത് coverage-ന്റെ ലക്ഷണമാണ്, threat-ന്റെതല്ല.
കാണാതായ അല്ലെങ്കിൽ വൈകിയ evidence
ഒരു timeout, ഒരു blocked script, അല്ലെങ്കിൽ അപൂർണ്ണമായ ഒരു request ഒരു result-ന് മതിയായ evidence ഇല്ലാതാക്കാൻ ഇടയാക്കാം. Proof of Actor അതിലെ ഒഴിവ് പൂരിപ്പിക്കുന്നതിന് പകരം അത് സത്യമായി report ചെയ്യുന്നു.
Proof of Actor Unknown-നെ എങ്ങനെ കൈകാര്യം ചെയ്യാവുന്നതാക്കുന്നു
Proof of Actor തന്റെ പ്രവർത്തനം മൂന്ന് capabilities ആയി ക്രമീകരിക്കുന്നു. ഓരോന്നും അജ്ഞാത സ്വയചാലിത ട്രാഫിക്കുമായി ബന്ധപ്പെട്ട് സഹായിക്കുന്നു.
Detect: Unknown വേർതിരിച്ച് നിലനിർത്തുക
Signals basis പ്രകാരം പരിശോധിക്കപ്പെടുകയും label ചെയ്യപ്പെടുകയും ചെയ്യുന്നു: verified, declared, inferred അല്ലെങ്കിൽ unknown. അവ ഒരു determination-നെ പിന്തുണയ്ക്കുന്നില്ലെങ്കിൽ, result എന്ത് ലഭ്യമായിരുന്നുവെന്നും എന്ത് ലഭ്യമല്ലായിരുന്നുവെന്നും ചുരുക്കത്തോടെ Unknown ആയിരിക്കും. ഒന്നും മറ്റൊരു class-ലേക്ക് guess ചെയ്ത് മാറ്റില്ല.
Understand: Unknown എവിടെ വസിക്കുന്നു എന്ന് കാണുക
Understand view എല്ലാ breakdown-ലും, route അനുസരിച്ചും സമയക്രമത്തിലും Unknown കാണിക്കുന്നു. ഏത് routes-ൽ ആണ് ഏറ്റവും കൂടുതൽ unknown activity ഉള്ളത്, integration ചേർത്തതിന് ശേഷം അത് എങ്ങനെ മാറുന്നു, വ്യക്തിഗത interactions-ന് ഏത് evidence ഉണ്ടായിരുന്നുവെന്ന് നിങ്ങൾക്ക് കാണാം. ഇതിലൂടെ ഒരു മങ്ങിയ ആശങ്ക concrete map ആയി മാറുന്നു.
Route: ഓരോ route-ലും fallback തിരഞ്ഞെടുക്കുക
വ്യത്യസ്ത routes-ക്ക് വ്യത്യസ്ത fallbacks അർഹമാണ്. പല applications-ക്കും നല്ല ഒരു starting point ഇതായിരിക്കും:
- Public pages and documentation: നിങ്ങളുടെ standard rate limits-ോടെ Unknown അനുവദിക്കുക.
- Signup and onboarding: നിങ്ങളുടെ നിലവിലുള്ള checks നിലനിർത്തുക, കൂടാതെ നിങ്ങളുടെ സ്വന്തം conditions ആവശ്യപ്പെടുമ്പോൾ മാത്രം review ചേർക്കുക.
- Account changes and other sensitive actions: നിങ്ങളുടെ നിലവിലുള്ള authentication, step-up controls എന്നിവയിൽ ആശ്രയിക്കുക, ഒരിക്കലും actor guess-ൽ അല്ല.
- High-impact API operations: നിങ്ങളുടെ API already supports ചെയ്യുന്ന ശക്തമായ credentials അല്ലെങ്കിൽ controls ആവശ്യപ്പെടുക.
handling unknown traffic എന്ന guide ഈ fallbacks രൂപകൽപ്പന ചെയ്യുന്നത് വിശദീകരിക്കുന്നു, ഓരോ risk tier-നുമുള്ള fail-open, fail-closed തിരഞ്ഞെടുപ്പുകൾ ഉൾപ്പെടെ.
സമയക്രമത്തിൽ Unknown കുറയ്ക്കുക
ലക്ഷ്യം Unknown നെ ഒരൊറ്റ രാത്രിയിൽ ഇല്ലാതാക്കുക എന്നല്ല. ശരിയായ കാരണങ്ങളാൽ, ഓരോ മാസവും അതിനെ ചെറുതാക്കുക എന്നതാണ്.
- പ്രധാനപ്പെട്ട ഇടങ്ങളിൽ integrations ചേർക്കുക. പ്രധാന pages-ൽ ഒരു browser integration, പ്രധാന routes-ൽ ഒരു server-side integration എന്നിവ ലഭ്യമായ evidence വർദ്ധിപ്പിക്കുന്നു.
- Signed requests പിന്തുണയ്ക്കുക. agent operators HTTP message signatures സ്വീകരിക്കുമ്പോൾ, മുമ്പ് Unknown ആയിരുന്ന ട്രാഫിക് verified Agent traffic ആയി മാറുന്നു.
- നിങ്ങളുടെ സ്വന്തം app-ൽ declarations രേഖപ്പെടുത്തുക. നിങ്ങളുടെ application-ന് AI സഹായം ഉൾപ്പെട്ടിരിക്കുന്നുവെന്ന് അറിയുമ്പോൾ, അത് വ്യക്തമാക്കുക. ആ evidence കൃത്യവും കുറഞ്ഞ ചെലവുള്ളതുമാണ്.
- Agents-ക്ക് ഒരു front door നൽകുക. agents-ക്കായി ഘടിതമായ ഒരു path പ്രസിദ്ധീകരിക്കുന്നത്, അവർ സ്വയം തിരിച്ചറിയുന്നതിനായി പ്രോത്സാഹിപ്പിക്കുന്നു, blend in ചെയ്യുന്നതിനുപകരം.
Proof of Actor route അനുസരിച്ച് Unknown ട്രാക്ക് ചെയ്യുന്നതിനാൽ, ഈ മാറ്റങ്ങൾ ഓരോന്നും നിങ്ങൾക്ക് നമ്പറുകളിൽ കാണാൻ കഴിയും.
ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു
ഓരോ interaction-വും അതേ evidence-first path പിന്തുടരുന്നു, How It Works-ൽ പൂർണ്ണമായി വിവരിച്ചതുപോലെ: നിങ്ങളുടെ application ഒരു request അല്ലെങ്കിൽ event സ്വീകരിക്കുന്നു, integration ആ context-ൽ ലഭ്യമായ signals ശേഖരിക്കുന്നു, signals normalize ചെയ്യപ്പെടുകയും explicit basis-ോടെ class ചെയ്യപ്പെടുകയും ചെയ്യുന്നു, result analytics-ിനായി record ചെയ്യപ്പെടുന്നു, കൂടാതെ നിങ്ങളുടെ application സ്വന്തം policy പ്രയോഗിക്കുന്നു അല്ലെങ്കിൽ simply observe ചെയ്യുന്നു.
Timeouts, missing telemetry എന്നിവ വ്യക്തമായി കൈകാര്യം ചെയ്യപ്പെടുന്നു. നിങ്ങളുടെ integration ആ route-ക്കായി നിങ്ങൾ തിരഞ്ഞെടുത്ത fallback ഉപയോഗിക്കുന്നു, evidence ഇല്ലാതായതിനാൽ result ഒരിക്കലും Human ആയി upgrade ചെയ്യപ്പെടുന്നില്ല.
കുറച്ച് മാസങ്ങൾക്ക് ശേഷം നല്ലത് എങ്ങനെയിരിക്കും
അജ്ഞാത സ്വയചാലിത ട്രാഫിക് നന്നായി കൈകാര്യം ചെയ്യുന്ന ടീമുകൾ സാധാരണയായി ഒരേ ആരോഗ്യകരമായ നിലയിലേക്ക് എത്തുന്നു. മനുഷ്യ, agent activity എന്നിവയ്ക്കൊപ്പം same dashboard-ൽ tracked ചെയ്യുന്ന, ഓരോ പ്രധാന route-ലും ഒരു അറിയപ്പെടുന്ന quantity ആയി Unknown നിലനിൽക്കുന്നു. ഓരോ route-ക്കും product, platform, security ടീമുകൾ ഒരുമിച്ച് അംഗീകരിച്ച ഒരു എഴുതിയ fallback ഉണ്ട്. കൂടുതൽ operators അവരുടെ requests sign ചെയ്യുന്നതിനാൽ verified agent traffic വളരുന്നു, ആ agents pages scrape ചെയ്യുന്നതിന് പകരം structured path വഴിയാണ് serve ചെയ്യപ്പെടുന്നത്. sensitive actions application ഇതിനകം വിശ്വസിക്കുന്ന authentication, step-up controls എന്നിവ കൊണ്ട് protected ആണ്, actor context ഒരു extra input ആയി മാത്രം, gatekeeper ആയി അല്ല.
ഏറ്റവും പ്രധാനമായി, ആരും guess ചെയ്യുന്നില്ല. കഴിഞ്ഞ ആഴ്ചയിലെ ട്രാഫിക്കിന്റെ എത്ര ഭാഗം automated ആയിരുന്നു എന്ന് ആരെങ്കിലും ചോദിക്കുമ്പോൾ, ഉത്തരം അതിന്റെ basis-ോടെയാണ് വരുന്നത്: ഇത്ര verified, ഇത്ര declared, ഇത്ര inferred, ഇത്ര ഇപ്പോഴും Unknown. ഇത് ഒരു team-ന് പദ്ധതിയിടാൻ കഴിയുന്ന ഒരു സംഖ്യയാണ്. കൂടാതെ ഇത് leadership-ുമായുള്ള സംഭാഷണവും മാറ്റുന്നു, കാരണം ചോദ്യം bots ഒരു പ്രശ്നമാണോ എന്നതിൽ നിന്ന്, ഏത് routes-ക്ക് കൂടുതൽ evidence അർഹമാണ്, ഏത് fallbacks പരിഷ്കരിക്കേണ്ടതാണ് എന്നതിലേക്കാണ് മാറുന്നത്.
observation mode-ൽ ആരംഭിക്കുക
Proof of Actor default ആയി ഒന്നും block ചെയ്യുന്നില്ല. observation mode-ൽ, നിങ്ങളുടെ application മുമ്പത്തെപ്പോലെ തന്നെ respond ചെയ്യുമ്പോൾ results record ചെയ്യപ്പെടുന്നു. ഓരോ route-ും എത്ര അജ്ഞാത സ്വയചാലിത ട്രാഫിക് സ്വീകരിക്കുന്നു എന്ന് നിങ്ങളുടെ team കാണുന്നു, നിങ്ങൾ ഇതിനകം അറിയുന്ന outcomes-നൊപ്പം അത് താരതമ്യം ചെയ്യുന്നു, യഥാർത്ഥ patterns അടിസ്ഥാനമാക്കി fallbacks രൂപകൽപ്പന ചെയ്യുന്നു. നിങ്ങളുടെ team അവ യോജിക്കുന്നുവെന്ന് വിശ്വസിക്കുന്നപ്പോൾ മാത്രം, ഒരു route വീതം policies enable ചെയ്യപ്പെടുന്നു.
Founding Developer Program-ിൽ ചേരുക
Proof of Actor private beta-യിലാണ്. തിരഞ്ഞെടുത്ത founding developer ടീമുകൾക്ക്, കൈമുതൽ product feedback-ന്റെ പകരമായി, agreed usage limits-ിന്റെ പരിധിയിൽ, 12 months വരെ free access ലഭിക്കാം, കൂടാതെ നമ്മുടെ engineers-ിൽ നിന്ന് നേരിട്ട integration support ലഭിക്കും.
അജ്ഞാത സ്വയചാലിത ട്രാഫിക് നിങ്ങളുടെ analytics-നെയോ security തീരുമാനങ്ങളെയോ മങ്ങിച്ചെയ്യുന്നുവെങ്കിൽ, apply for early access. നിങ്ങളുടെ application-നെക്കുറിച്ചും Unknown ഏറ്റവും പ്രധാനപ്പെട്ട routes-കളെക്കുറിച്ചും ഞങ്ങളോട് പറയുക.
Proof of Actor അന്വേഷിക്കുക, how it works വായിക്കുക, അല്ലെങ്കിൽ what the evidence can establish കാണുക.
Sources
- RFC 9421: HTTP Message Signatures, IETF, February 2024.
- Web Bot Auth (webbotauth) working group charter, IETF.
- Verifying Googlebot and other Google crawlers, Google Search Central.
- How to verify that Bingbot is Bingbot, Bing Webmaster Blog.