HTTP লেয়ারে ডিফল্টভাবে প্রাইভেসি: যে হেডারগুলো আপনার ট্র্যাকিং সারফেস ছোট করে দেয়
দুটি রেসপন্স হেডার — Permissions-Policy এবং Referrer-Policy — নির্ধারণ করে আপনার পেজগুলো অ্যাড-টেক ও থার্ড পার্টিকে কতটা ফাঁস করতে পারে। একবার সেট করুন, আর সার্ভেইলেন্স সারফেস ডিফল্টভাবেই বন্ধ হয়ে যায়।
প্রাইভেসির অধিকাংশ কাজ হয় JavaScript-এ — কনসেন্ট লজিক, ট্যাগ গেটিং, আইডেন্টিফায়ার রোটেশন। কিন্তু ব্রাউজার আপনাকে দুটি HTTP রেসপন্স হেডার দেয় যা একটিও স্ক্রিপ্ট চলার আগেই সার্ভেইলেন্স সারফেস বন্ধ করে দেয়, অথচ অধিকাংশ সাইট এর একটিও পাঠায় না। Permissions-Policy এবং Referrer-Policy হলো সবচেয়ে আক্ষরিক অর্থে প্রাইভেসি-বাই-ডিজাইন: কনফিগারেশন, কোড নয়।
এগুলো এক বছর আগের তুলনায় এখন আরও বেশি গুরুত্বপূর্ণ। Google যখন ২০২৫ সালের অক্টোবরে অধিকাংশ Privacy Sandbox API অবসরে পাঠাল, সেই API-গুলো যে অবশিষ্ট অ্যাড-টেক ডিরেক্টিভগুলো এনেছিল তা এখনও Chrome-এর সঙ্গে যুক্ত — আর একটি সাইট এখন এগুলো সরিয়ে দেওয়ার অপেক্ষা না করে নিজে থেকেই বন্ধ করে দিতে পারে।
Permissions-Policy: যে ফিচার আপনি কখনও ব্যবহার করেন না, তা অস্বীকার করুন
Permissions-Policy নিয়ন্ত্রণ করে একটি ডকুমেন্ট ও তার এমবেডেড ফ্রেমগুলো কোন কোন ব্রাউজার ফিচার ব্যবহার করতে পারবে। এটি সেই একই ব্যবস্থা যা camera, geolocation এবং microphone-কে গেট করে — কিন্তু এটি অ্যাড-টেক যে ট্র্যাকিং-সংলগ্ন API-গুলোর কাছে পৌঁছায় সেগুলোকেও গেট করে।
এদের অধিকাংশের ডিফল্ট অনুমতি-তালিকা উদার। browsing-topics, যে ডিরেক্টিভ Topics API নিয়ন্ত্রণ করে, ডিফল্টভাবে * থাকে — পেজের প্রতিটি অরিজিন, থার্ড-পার্টি ফ্রেমসহ, এটি কল করতে পারে যতক্ষণ না আপনি অন্যথা বলছেন। এটি নিষ্ক্রিয় করা মাত্র এক লাইনের কাজ:
Permissions-Policy: browsing-topics=()
একটি খালি অনুমতি-তালিকা () ফিচারটি সবার কাছে অস্বীকার করে, আপনার নিজের অরিজিনসহ। আপনি অ্যাড-ইন্টারেস্ট ও মেজারমেন্ট API-গুলোর পুরো গুচ্ছকে একটিমাত্র হেডারে লক করে দিতে পারেন:
Permissions-Policy: browsing-topics=(), join-ad-interest-group=(), run-ad-auction=(), attribution-reporting=(), shared-storage=(), private-aggregation=()
যেকোনো স্ক্রিপ্ট — ফার্স্ট-পার্টি হোক বা এমবেডেড — যা document.browsingTopics() কল করে বা Sec-Browsing-Topics রিকোয়েস্ট হেডার পাঠায়, তা এখন NotAllowedError দিয়ে ব্যর্থ হবে। আপনি থার্ড পার্টিরা ভালো আচরণ করবে বলে বিশ্বাস করছেন না; আপনি প্ল্যাটফর্ম স্তরেই সক্ষমতাটি সরিয়ে দিচ্ছেন।
এই ডিরেক্টিভগুলো Privacy Sandbox-এর সঙ্গেই ডিপ্রিকেটেড, তাই আসন্ন রিলিজগুলোতে এদের কিছু Chrome থেকে অদৃশ্য হয়ে যাবে। এগুলো ()-তে সেট করা সেগুলো চলে যাওয়ার পরে নিরীহ এবং তার আগ পর্যন্ত সুরক্ষাকর।
Referrer-Policy: আপনার URL ফাঁস হওয়া বন্ধ করুন
প্রতিটি নেভিগেশন ও সাবরিসোর্স রিকোয়েস্ট একটি Referer হেডার বহন করতে পারে যা ব্যবহারকারী যে পেজ থেকে এসেছেন তার নাম জানায়। পূর্ণ URL কোয়েরি স্ট্রিং, পাথে এনকোড করা আইডেন্টিফায়ার, সার্চ টার্ম এবং অভ্যন্তরীণ পেজ গঠন প্রতিটি থার্ড পার্টির কাছে ফাঁস করে দেয় যা আপনি লোড করেন — অ্যানালিটিক্স ভেন্ডর, ফন্ট, CDN, অ্যাড পিক্সেল।
আধুনিক ব্রাউজারগুলো ডিফল্টভাবে strict-origin-when-cross-origin ব্যবহার করে, যা ইতিমধ্যেই একটি যুক্তিসঙ্গত ন্যূনতম মান:
Referrer-Policy: strict-origin-when-cross-origin
এই পলিসির অধীনে ব্রাউজার পূর্ণ URL পাঠায় শুধুমাত্র same-origin রিকোয়েস্টে, ক্রস-অরিজিন সিকিওর রিকোয়েস্টে পাঠায় শুধু অরিজিন, এবং HTTPS থেকে HTTP-তে ডাউনগ্রেডের সময় পাঠায় কিছুই না। ফলে https://app.example/orders/4815?token=abc একটি থার্ড পার্টির কাছে পৌঁছায় https://app.example/ রূপে — শুধু অরিজিন, কোনো পাথ নেই, কোনো কোয়েরি নেই।
সেই ডিফল্টটি ২০২০ সালের নভেম্বরে স্পেক ডিফল্ট হয়েছিল, তবু আপনার হেডারটি স্পষ্টভাবে সেট করা উচিত। একটি ভুল কনফিগার করা আপস্ট্রিম, কোনো ফ্রেমওয়ার্কের পুরোনো ডিফল্ট, কিংবা একটি <meta> referrer ট্যাগ এটিকে ওভাররাইড করতে পারে, আর একটি স্পষ্ট হেডার অডিটযোগ্য। আপনি যদি URL-এ সংবেদনশীল কিছু এমবেড না করেন এবং কঠোর হতে চান, তবে strict-origin same-origin রিকোয়েস্টেও পাথ বাদ দেয়।
কেন এটি কুকি-ফ্রি অ্যানালিটিক্সের সঙ্গে মানানসই
এই হেডারগুলো এবং একটি প্রাইভেসি-ফার্স্ট ট্র্যাকার একই সমস্যা দুই দিক থেকে সমাধান করে। ট্র্যাকার নিয়ন্ত্রণ করে আপনার অ্যানালিটিক্স কী সংগ্রহ করে; হেডারগুলো নিয়ন্ত্রণ করে পেজের বাকি সবাই কী পর্যন্ত পৌঁছাতে পারে।
একটি কুকি-ফ্রি ট্র্যাকার যা পরিচয় তৈরি করে একটি ওয়ান-ওয়ে দৈনিক হ্যাশ থেকে — SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD) — তার কাজ করতে কখনও পূর্ণ রেফারার URL বা Topics API-র প্রয়োজন হয় না। এটি document.referrer পড়ে শুধু ভিজিটের উৎস নির্ধারণ করতে, আর তার জন্য অরিজিনই যথেষ্ট। তাই Referrer-Policy কঠোর করা আপনার অ্যানালিটিক্সের কিছুই খরচ করায় না, অথচ এটি পেজের প্রতিটি অন্য রিকোয়েস্টের জন্য একটি ফাঁস বন্ধ করে দেয়।
একই সঙ্গতি পারফরম্যান্সের ক্ষেত্রেও বজায় থাকে। হেডারগুলো JavaScript-এর শূন্য বাইট এবং শূন্য মেইন-থ্রেড সময় খরচ করে; ব্রাউজার এগুলো পার্সিংয়ের আগেই মূল্যায়ন করে। আপনি Largest Contentful Paint বা Interaction to Next Paint-এ কোনো প্রভাব ছাড়াই একটি পরিমাপযোগ্য প্রাইভেসি উন্নতি পান — যা একটি কনসেন্ট-ম্যানেজমেন্ট প্ল্যাটফর্মের বিপরীত সমঝোতা, যেটি এমন অনুমতি ব্যবস্থাপনার জন্য স্ক্রিপ্টের ভার যোগ করে যা একটি হেডার সরাসরি অস্বীকার করতে পারত।
এগুলো এজে পাঠান
দুটি হেডারই আপনার এজ বা অরিজিন সার্ভারে সেট করুন যাতে প্রতিটি রেসপন্স এগুলো বহন করে, স্ট্যাটিক অ্যাসেট ও HTML-সহ:
Permissions-Policy: browsing-topics=(), join-ad-interest-group=(), run-ad-auction=(), attribution-reporting=(), shared-storage=()
Referrer-Policy: strict-origin-when-cross-origin
Cloudflare-এ, এগুলো একটি Transform Rule বা Worker-এ যোগ করুন; Next.js-এ, headers() কনফিগে; যেকোনো রিভার্স প্রক্সিতে, একটিমাত্র add_header লাইনে। এতে কোনো রোলআউট ঝুঁকি নেই: আপনি যে সক্ষমতা ব্যবহার করেন না তা অস্বীকার করছেন এবং যে ডেটা আপনি কখনও পাঠাতে চাননি তা ছেঁটে ফেলছেন।
প্রাইভেসি-বাই-ডিজাইনকে সাধারণত একটি আর্কিটেকচার সিদ্ধান্ত হিসেবে দেখা হয়। HTTP লেয়ারে এটি কনফিগারেশনের দুটি লাইন, আর এগুলো আপনি বন্ধ না করা পর্যন্ত ডিফল্টভাবে খোলা থাকে।
Comments
Loading comments…