যার নাম কেউ জানে না এমন ট্র্যাফিক
একটি application-এর logs ভালো করে দেখলে এমন request পাবেন, যেগুলিকে ব্যাখ্যা করা কঠিন। এগুলি browser context ছাড়া client থেকে আসে। এদের user-agent string generic, empty বা কোনো জনপ্রিয় browser থেকে copied। এরা নিজেদের request sign করে না। এরা বলে না কে এটি পাঠিয়েছে। কিছু harmless script। কিছু real user-এর হয়ে কাজ করা agent। কিছু এমন tool, যাকে আপনি একেবারেই serve করতে চাইবেন না।
এটি অজানা স্বয়ংক্রিয় ট্র্যাফিক, এবং বেশিরভাগ team এটি সামলায় দুইভাবে। হয় এটিকে নীরবে human হিসেবে গণনা করা হয়, যা analytics বিকৃত করে এবং ঝুঁকিপূর্ণ activity-কে পার হতে দেয়, অথবা default হিসেবে hostile ধরা হয়, যা legitimate user এবং agent-কে অন্য সব কিছুর সঙ্গে block করে। উভয় পদ্ধতির একই ত্রুটি আছে: তারা missing evidence-এর জায়গায় একটি অনুমান বসিয়ে দেয়।
Proof of Actor বিপরীত দৃষ্টিভঙ্গি নেয়। যদি evidence নির্ভরযোগ্য determination-কে সমর্থন না করে, সঠিক উত্তর হল Unknown, এবং Unknown দৃশ্যমান, পরিমাপযোগ্য এবং উদ্দেশ্যমূলকভাবে handled হওয়া উচিত। blog post why Unknown is a valid result for AI traffic এই বিষয়টি পূর্ণভাবে ব্যাখ্যা করে।
কেন Unknown একটি first-class result
Proof of Actor প্রতিটি interaction-কে চারটি class-এর একটিতে classifies করে: Human, Human + AI, Agent বা Unknown. Unknown কোনো error state বা product-এর ফাঁক নয়। এটি একটি deliberate result, যার অর্থ নির্দিষ্ট: available evidence নির্ভরযোগ্য determination-কে সমর্থন করে না।
এই সততা থেকে বাস্তব সুবিধা মেলে।
- আপনার analytics সঠিক থাকে। Human এবং Agent count কেবল সেই interaction-ই অন্তর্ভুক্ত করে, যেগুলির supporting evidence আছে, তাই তারা যা বোঝায় সেটাই বোঝায়।
- আপনার coverage পরিমাপযোগ্য হয়। প্রতিটি route-এ Unknown-এর share দেখায় আপনি ঠিক কোথায় আরও evidence প্রয়োজন।
- আপনার policy আরও নিরাপদ হয়। অনিশ্চিত case-গুলো আপনি যে fallback বেছে নিয়েছেন তাতে যায়, অনুমান করে trusted বা blocked হিসেবে নীরবে treated হয় না।
Unknown কখনও Human-এ রূপান্তরিত হয় না, এবং default হিসেবে এটিকে malicious ধরা হয় না। আপনি Unknown classification glossary entry-তে, Detection & Limitations-এ, এবং why Unknown is a valid result for AI traffic-এ আরও পড়তে পারেন। websites এবং APIs use case দেখায় কীভাবে team বাস্তবে Unknown fallback সেট করে।
অজানা স্বয়ংক্রিয় ট্র্যাফিক কোথা থেকে আসে
উৎসগুলো বোঝা থাকলে এটিকে কীভাবে সামলাতে হবে তা নির্ধারণ করা সহজ হয়।
unsigned automated client
HTTP Message Signatures দিয়ে request signing, যা RFC 9421-এ সংজ্ঞায়িত, ঐচ্ছিক, এবং IETF Web Bot Auth working group এখনও automated client-রা কীভাবে এইভাবে authenticate করবে তা standardize করছে। signature না থাকলে, client-এর পরিচয় নির্ভর করে সে নিজের সম্পর্কে যা বলতে বেছে নেয় তার ওপর।
copied বা generic user agent
user-agent string সেট করা খুবই সহজ। যে client নিজেকে একটি well-known browser বা crawler বলে দাবি করছে, সেটি ঠিক সেটাই হতে পারে, অথবা সেটির অনুকরণও হতে পারে। user-agent spoofing entry ব্যাখ্যা করে কেন এই header একা classification বহন করতে পারে না। এ কারণেই search engine-গুলো আলাদা verification method নথিভুক্ত করে: Google verifying Googlebot-এর জন্য reverse এবং forward DNS lookup-এর পাশাপাশি প্রকাশিত IP range বর্ণনা করে, এবং Bing verifying Bingbot-এর জন্য একই DNS check বর্ণনা করে।
যেসব route-এ integration নেই
যদি কোনো route-এ browser integration না থাকে এবং মৌলিক বিষয়ের বাইরে কোনো server-side context না থাকে, তাহলে observation-এর সুযোগ স্বাভাবিকভাবেই কমে যায়। সেই route-গুলিতে Unknown হলো coverage-এর ইঙ্গিত, threat-এর নয়।
missing বা delayed evidence
timeout, blocked script বা incomplete request কোনো result-কে যথেষ্ট evidence ছাড়া রেখে দিতে পারে। Proof of Actor তা সৎভাবে রিপোর্ট করে, ফাঁকটি পূরণ করে না।
Proof of Actor কীভাবে Unknown-কে manageable করে
Proof of Actor তার কাজকে তিনটি capability-তে organize করে। প্রতিটিই অজানা স্বয়ংক্রিয় ট্র্যাফিকের ক্ষেত্রে সাহায্য করে।
Detect: Unknown-কে আলাদা রাখুন
signal-গুলো basis অনুযায়ী checked এবং labeled হয়: verified, declared, inferred বা unknown। যখন তারা কোনো determination-কে সমর্থন করে না, result Unknown থাকে এবং কী উপলভ্য ছিল আর কী ছিল না তার একটি summary দেয়। কিছুই অন্য class-এ আন্দাজ করে ফেলা হয় না।
Understand: Unknown কোথায় আছে দেখুন
Understand view-এ route অনুযায়ী এবং সময়ের সঙ্গে Unknown প্রতিটি breakdown-এ দেখা যায়। আপনি দেখতে পারেন কোন route-এ সবচেয়ে বেশি unknown activity আছে, আপনি integration যোগ করার পর তা কীভাবে বদলায়, এবং individual interaction-এর জন্য কী evidence উপস্থিত ছিল। এতে অস্পষ্ট উদ্বেগ একটি স্পষ্ট মানচিত্রে পরিণত হয়।
Route: প্রতি route-এর জন্য fallback বেছে নিন
বিভিন্ন route-এর জন্য ভিন্ন fallback প্রয়োজন। অনেক application-এর জন্য একটি যুক্তিসঙ্গত শুরু হতে পারে:
- Public page এবং documentation: আপনার standard rate limit-এর সঙ্গে Unknown allow করুন।
- Signup এবং onboarding: আপনার বিদ্যমান check বজায় রাখুন, এবং আপনার নিজের condition প্রয়োজন হলে তবেই review যোগ করুন।
- Account change এবং অন্যান্য sensitive action: আপনার বিদ্যমান authentication এবং step-up control-এর ওপর ভরসা করুন, কখনও actor guess-এর ওপর নয়।
- High-impact API operation: আপনার API ইতিমধ্যে যে stronger credential বা control support করে, সেগুলিই প্রয়োজন করুন।
handling unknown traffic-এর guide-টি এই fallback ডিজাইন করার ধাপ দেখায়, যার মধ্যে প্রতিটি risk tier-এর জন্য fail-open এবং fail-closed বাছাইও রয়েছে।
সময়ের সঙ্গে Unknown কমানো
লক্ষ্য Unknown-কে এক রাতে মুছে ফেলা নয়। লক্ষ্য হল সঠিক কারণে প্রতি মাসে এটিকে ছোট করা।
- যেখানে দরকার সেখানে integration যোগ করুন। key page-এ browser integration এবং key route-এ server-side integration উপলভ্য evidence বাড়ায়।
- signed request support করুন। agent operator-রা যখন HTTP message signatures গ্রহণ করে, তখন যে ট্র্যাফিক Unknown ছিল তা verified Agent ট্র্যাফিকে পরিণত হয়।
- আপনার নিজের app-এ declaration record করুন। আপনার application যখন জানে যে AI assistance জড়িত, তখন তা জানান। সেই evidence নির্ভুল এবং সস্তা।
- agent-দের জন্য একটি front door দিন। agent-দের জন্য একটি structured path প্রকাশ করলে তারা নিজেদের শনাক্ত করতে উৎসাহিত হয়, মিশে যেতে নয়।
কারণ Proof of Actor route অনুযায়ী Unknown track করে, আপনি এই প্রতিটি পরিবর্তন সংখ্যায় দেখতে পারেন।
এটি কীভাবে কাজ করে
প্রতিটি interaction একই evidence-first path অনুসরণ করে, যা How It Works-এ পূর্ণভাবে বর্ণিত: আপনার application একটি request বা event receive করে, integration সেই context-এ available signal সংগ্রহ করে, signal normalize এবং explicit basis-সহ classify করা হয়, result analytics-এর জন্য record করা হয়, এবং আপনার application নিজের policy প্রয়োগ করে বা কেবল observe করে।
timeout এবং missing telemetry স্পষ্টভাবে handled হয়। আপনার integration সেই route-এর জন্য আপনার বেছে নেওয়া fallback ব্যবহার করে, এবং evidence missing ছিল বলে result কখনও Human-এ upgrade হয় না।
কয়েক মাস পর ভালো অবস্থা কেমন দেখায়
যে team অজানা স্বয়ংক্রিয় ট্র্যাফিক ভালোভাবে handle করে, তারা সাধারণত একই সুস্থ অবস্থায় পৌঁছে। Unknown প্রতিটি গুরুত্বপূর্ণ route-এ একটি জানা quantity হয়ে যায়, human এবং agent activity-র সঙ্গে একই dashboard-এ tracked হয়। প্রতিটি route-এর একটি লিখিত fallback থাকে, যেটিতে product, platform এবং security team একসঙ্গে সম্মত হয়েছে। আরও operator request sign করার ফলে verified agent traffic বাড়ে, এবং সেই agent-দের page scrape করার বদলে একটি structured path দিয়ে serve করা হয়। Sensitive action-গুলো application ইতিমধ্যে যেসব authentication এবং step-up control-কে trust করে, সেগুলির দ্বারা protected থাকে, যেখানে actor context gatekeeper নয় বরং একটি অতিরিক্ত input।
সবচেয়ে গুরুত্বপূর্ণ, কেউ অনুমান করছে না। যখন কেউ জিজ্ঞেস করে গত সপ্তাহের traffic-এর কতটা automated ছিল, উত্তরটি তার basis-সহ আসে: এতটা verified, এতটা declared, এতটা inferred, এবং এতটা এখনও Unknown। এটি এমন একটি সংখ্যা, যার ভিত্তিতে team পরিকল্পনা করতে পারে। এটি leadership-এর সঙ্গে conversation-ও বদলে দেয়, কারণ প্রশ্নটি আর bot সমস্যা কি না সে দিকে থাকে না, বরং কোন route আরও evidence deserves এবং কোন fallback refine করা দরকার, সেই দিকে সরে যায়।
observation mode-এ শুরু করুন
Proof of Actor default হিসেবে কিছুই block করে না। observation mode-এ result record হয়, আর আপনার application আগের মতোই respond করে। আপনার team দেখে প্রতিটি route কতটা অজানা স্বয়ংক্রিয় ট্র্যাফিক পায়, আপনি ইতিমধ্যে জানা outcome-এর সঙ্গে তা compare করেন, এবং বাস্তব pattern-এর ভিত্তিতে fallback ডিজাইন করেন। আপনার team যখন নিশ্চিত হয় যে policy মানানসই, তখন route একে একে enable করা হয়।
founding developer program-এ যোগ দিন
Proof of Actor private beta-তে আছে। নির্বাচিত founding developer team agreed usage limit-এর মধ্যে hands-on product feedback-এর বিনিময়ে up to 12 months free access পেতে পারে, এবং আমাদের engineer-দের সরাসরি integration support পাবে।
যদি অজানা স্বয়ংক্রিয় ট্র্যাফিক আপনার analytics বা security decision-কে অস্পষ্ট করে দেয়, early access-এর জন্য apply করুন। আপনার application এবং কোন route-এ Unknown সবচেয়ে গুরুত্বপূর্ণ, তা আমাদের জানান।
Proof of Actor explore করুন, 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.