HTTP लेयर पर डिफ़ॉल्ट रूप से प्राइवेसी: वे हेडर जो आपके ट्रैकिंग सरफ़ेस को सिकोड़ देते हैं
दो रिस्पॉन्स हेडर — Permissions-Policy और Referrer-Policy — तय करते हैं कि आपके पेज ऐड-टेक और थर्ड पार्टीज़ को कितना लीक कर सकते हैं। इन्हें एक बार सेट कीजिए और सर्विलांस सरफ़ेस डिफ़ॉल्ट रूप से बंद हो जाता है।
प्राइवेसी का अधिकांश काम JavaScript में होता है — कंसेंट लॉजिक, टैग गेटिंग, आइडेंटिफ़ायर रोटेशन। लेकिन ब्राउज़र आपको दो HTTP रिस्पॉन्स हेडर देता है जो एक भी स्क्रिप्ट चलने से पहले सर्विलांस सरफ़ेस को बंद कर देते हैं, और अधिकांश साइटें इनमें से एक भी नहीं भेजतीं। Permissions-Policy और Referrer-Policy अपने सबसे शाब्दिक रूप में प्राइवेसी-बाय-डिज़ाइन हैं: कॉन्फ़िगरेशन, कोड नहीं।
ये एक साल पहले की तुलना में अब और भी अधिक मायने रखते हैं। Google द्वारा अक्टूबर 2025 में अधिकांश Privacy Sandbox APIs को रिटायर किए जाने के बाद भी, उन APIs के साथ आए बचे हुए ऐड-टेक डायरेक्टिव्स अब भी Chrome में जुड़े हुए हैं — और एक साइट अब इन्हें हटाए जाने का इंतज़ार करने के बजाय सक्रिय रूप से बंद कर सकती है।
Permissions-Policy: उन फ़ीचर्स को मना कीजिए जिन्हें आप कभी इस्तेमाल नहीं करते
Permissions-Policy यह नियंत्रित करता है कि कोई डॉक्यूमेंट और उसके एम्बेडेड फ़्रेम किन ब्राउज़र फ़ीचर्स का इस्तेमाल कर सकते हैं। यह वही तंत्र है जो camera, geolocation और microphone को गेट करता है — लेकिन यह उन ट्रैकिंग-संबंधी APIs को भी गेट करता है जिन तक ऐड-टेक पहुँचता है।
इनमें से अधिकांश की डिफ़ॉल्ट अनुमति-सूची उदार है। browsing-topics, जो Topics API को नियंत्रित करने वाला डायरेक्टिव है, डिफ़ॉल्ट रूप से * होता है — पेज पर मौजूद हर ऑरिजिन, जिसमें थर्ड-पार्टी फ़्रेम भी शामिल हैं, इसे कॉल कर सकता है जब तक आप कुछ और न कहें। इसे डिसेबल करना एक लाइन है:
Permissions-Policy: browsing-topics=()
एक खाली अनुमति-सूची () इस फ़ीचर को सबके लिए मना कर देती है, जिसमें आपका अपना ऑरिजिन भी शामिल है। आप ऐड-इंटरेस्ट और मेज़रमेंट APIs के पूरे समूह को एक ही हेडर में लॉक कर सकते हैं:
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: अपने URLs को लीक होने से रोकिए
हर नेविगेशन और सबरिसोर्स रिक्वेस्ट एक Referer हेडर ले जा सकती है जो उस पेज का नाम बताता है जहाँ से यूज़र आया। पूरे URLs क्वेरी स्ट्रिंग्स, पाथ में एन्कोडेड आइडेंटिफ़ायर्स, सर्च टर्म्स और आंतरिक पेज संरचना को हर उस थर्ड पार्टी तक लीक कर देते हैं जिसे आप लोड करते हैं — एनालिटिक्स वेंडर्स, फ़ॉन्ट्स, CDNs, ऐड पिक्सेल।
आधुनिक ब्राउज़र डिफ़ॉल्ट रूप से 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/ के रूप में पहुँचता है — सिर्फ़ ऑरिजिन, कोई पाथ नहीं, कोई क्वेरी नहीं।
वह डिफ़ॉल्ट नवंबर 2020 में स्पेक डिफ़ॉल्ट बना, लेकिन फिर भी आपको हेडर को स्पष्ट रूप से सेट करना चाहिए। एक ग़लत कॉन्फ़िगर्ड अपस्ट्रीम, किसी फ़्रेमवर्क का पुराना डिफ़ॉल्ट, या एक <meta> referrer टैग इसे ओवरराइड कर सकता है, और एक स्पष्ट हेडर ऑडिट किया जा सकता है। यदि आप URLs में कुछ भी संवेदनशील एम्बेड नहीं करते और सख़्त रहना चाहते हैं, तो 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…