الخصوصية افتراضيًا في طبقة HTTP: ترويسات تُقلّص سطح التتبّع لديك
ترويستان للاستجابة — Permissions-Policy وReferrer-Policy — تحدّدان مقدار ما يمكن أن تُسرّبه صفحاتك إلى تقنيات الإعلان والأطراف الثالثة. اضبطهما مرة واحدة فينغلق سطح المراقبة افتراضيًا.
تجري معظم أعمال الخصوصية داخل JavaScript — منطق الموافقة، وتقييد الوسوم، وتدوير المُعرِّفات. لكنّ المتصفّح يمنحك ترويستَي استجابة HTTP تُغلقان سطح المراقبة قبل أن يُشغَّل أي سكربت، ومعظم المواقع لا تُرسل أيًّا منهما. إنّ Permissions-Policy وReferrer-Policy هما الخصوصية بالتصميم في أكثر صورها حرفية: إعداد، لا شيفرة.
وهما أكثر أهمية الآن مما كانتا عليه قبل عام. فمع تقاعد Google في أكتوبر 2025 لمعظم واجهات Privacy Sandbox، لا تزال توجيهات تقنيات الإعلان المتبقّية التي أدخلتها تلك الواجهات موصولةً داخل Chrome — وبات بإمكان الموقع الآن أن يُعطّلها بصورة إيجابية بدل انتظار إزالتها.
Permissions-Policy: امنع الميزات التي لا تستخدمها أبدًا
تتحكّم Permissions-Policy في الميزات التي يجوز لمستند ما ولإطاراته المُضمَّنة استخدامها. وهي الآلية نفسها التي تُقيّد camera وgeolocation وmicrophone — لكنّها تُقيّد أيضًا الواجهات القريبة من التتبّع التي تلجأ إليها تقنيات الإعلان.
قائمة السماح الافتراضية لمعظم هذه الميزات متساهلة. فالتوجيه browsing-topics، الذي يتحكّم في Topics API، قيمته الافتراضية * — أي أنّ لكلّ أصل على الصفحة، بما في ذلك إطارات الأطراف الثالثة، أن يستدعيه ما لم تقل غير ذلك. وتعطيله سطر واحد:
Permissions-Policy: browsing-topics=()
تمنع قائمة السماح الفارغة () الميزة عن الجميع، بما في ذلك أصلك أنت. ويمكنك إقفال المجموعة الكاملة من واجهات اهتمامات الإعلان والقياس في ترويسة واحدة:
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 الكامل فقط في الطلبات من الأصل نفسه، ويُرسل الأصل فقط في الطلبات الآمنة عبر الأصول، ولا يُرسل شيئًا عند الانتقال من HTTPS إلى HTTP. وهكذا يصل https://app.example/orders/4815?token=abc إلى طرف ثالث بصيغة https://app.example/ — أصلٌ فقط، بلا مسار ولا استعلام.
أصبح ذلك الافتراض هو الافتراض المعياري في نوفمبر 2020، لكن ينبغي لك أن تضبط الترويسة صراحةً مع ذلك. فإعدادٌ خاطئ في الأعلى، أو افتراضٌ قديم لإطار عمل، أو وسم referrer من نوع <meta> قد يتجاوزه، والترويسة الصريحة قابلة للتدقيق. وإن كنت لا تُضمِّن شيئًا حسّاسًا في عناوين URL وأردت التشدّد، فإنّ strict-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…