مستوى التقدُّم في "مبادرة حماية الخصوصية" (تشرين الأول/أكتوبر 2021)

مرحبًا بك في إصدار تشرين الأول (أكتوبر) من Progress في "مبادرة حماية الخصوصية"، الذي يتيح تتبُّع المراحل الأساسية في خطوات الإيقاف التدريجي لملفات تعريف الارتباط التابعة لجهات خارجية في Chrome والعمل على تعزيز الخصوصية على الويب. سنشارك كل شهر نظرة عامة على التعديلات التي أُجريت على المخطط الزمني لـ "مبادرة حماية الخصوصية"، بالإضافة إلى أخبار عن المشروع بأكمله.

فعاليات

مؤتمر Chrome Dev Summit: أصبح جدول الأعمال متاحًا الآن، ويمكنك حضوره افتراضيًا اعتبارًا من 3 تشرين الثاني (نوفمبر)

من 3 تشرين الثاني (نوفمبر)، سنستضيف مؤتمر مطوّري Chrome. ستتمكّن من الحصول على آخر الأخبار حول "مبادرة حماية الخصوصية" في الكلمة الافتتاحية، بالإضافة إلى فرصة لطرح أسئلة على فريق القيادة في AMA، والوقت للإجابة عن أسئلة أكثر تفصيلاً مع الفرق الهندسية في Office Hours. يمكنك الاشتراك اليوم ونأمل أن نراك في المنتدى.

يشمل هذا الشهر أيضًا المؤتمر السنوي لرابطة W3C (المعروف باسم TPAC) الذي يلتقي فيه جميع المجموعات المختلفة ضمن رابطة W3C لمناقشة مواضيع متنوعة على مستوى الويب بأكمله. يمكنك عرض الدقائق والفيديوهات الخاصة بالجلسات المصغَّرة، بالإضافة إلى جلسات محدّدة، بما في ذلك مواضيع "مبادرة حماية الخصوصية".

استمرارًا لموسم المؤتمرات، تستضيف فريق دعم مهندسي شبكة الإنترنت (IETF) الندوة العامة الفنية 112 على الإنترنت. على غرار "لجنة تقييم التكنولوجيا (TPAC)"، هناك عدد من الجلسات الفردية التي تتم فيها مناقشة مواضيع "مبادرة حماية الخصوصية"، مثل مجموعات العمل PRIV (حماية الخصوصية للقيم) وPEARG (مجموعة أبحاث الخصوصية والتقييم) وMASQUE (الركائزية المتعددة للتطبيقات بدلاً من تشفير QUIC). هذه مناقشات فنية متعمقة حول تصميمات البروتوكولات - إذا كانت لديك الخبرة المناسبة واهتمام بالمساهمة في هذه المناقشات، يُرجى التفكير في الانضمام.

تعزيز حدود الخصوصية بين المواقع الإلكترونية

إنّ ملفات تعريف الارتباط التابعة لجهات خارجية هي آلية أساسية تتيح تتبُّع إجراءات المستخدم على مواقع إلكترونية متعددة. ونظرًا إلى إمكانية التخلص منها، يُعتبر ذلك معلمًا رئيسيًا، لكننا بحاجة أيضًا إلى التعامل مع أشكال أخرى من التخزين أو الاتصال عبر المواقع.

واجهة برمجة تطبيقات إدارة بيانات الاعتماد الموحّدة

يُعدّ اقتراح إدارة بيانات الاعتماد المتحدّة (FedCM) اسمًا جديدًا أكثر فائدة لمعرّف WebID. الهوية الموحّدة هي خدمة مهمة على الويب، ولكن بما أنّ الأمر يتعلق صراحةً بمشاركة جوانب الهوية مع المواقع الإلكترونية الأخرى، هناك تفاصيل استخدام تتداخل مع تتبّع المواقع الإلكترونية المتعددة.

يستكشف اقتراح "إدارة بيانات الاعتماد الموحّدة" مجموعة من الخيارات بدءًا من مسارات نقل البيانات البسيطة للحلول الحالية إلى الأساليب الأكثر خصوصية للاتصال بالخدمات بالحدّ الأدنى من المعلومات المشتركة.

لا يزال هذا الاقتراح في مرحلة مبكرة، ويمكن متابعة المناقشة فيه في مجموعة مجتمع الهوية الموحّدة التابعة لـ W3C. استضافت المجموعة أيضًا جلسة مصغَّرة في لجنة TPAC تم خلالها استكشاف نظرة عامة على الاقتراح. هناك أيضًا إصدار أولي جدًا من واجهة برمجة التطبيقات متاح خلف علامة في Chrome 89، ولكن هذا فقط من أجل التجريب وسيتغير مع تقدم المناقشة.

بسكويت

مع تقدّم العروض المرتبطة بملفات تعريف الارتباط، يجب مراجعة SameSite=None أو ملفات تعريف الارتباط على مواقع إلكترونية متعددة والتخطيط للإجراء المطلوب اتخاذه على موقعك الإلكتروني.

الشرائح

في حال ضبط ملفات تعريف ارتباط يتم إرسالها في سياقات من عدة مواقع إلكترونية ولكن في علاقات 1:1، مثل عمليات تضمين إطارات iframe أو طلبات البيانات من واجهة برمجة التطبيقات، عليك اتّباع اقتراح CHIPS أو ملفات تعريف الارتباط التي تم تقسيمها بشكل مستقل. ويتيح لك هذا الإجراء وضع علامة "مُقسَّمة" على ملفات تعريف الارتباط من خلال وضعها في حاوية منفصلة لملفات تعريف الارتباط لكل موقع إلكتروني من المستوى الأعلى.

لا يزال العمل قيد التقدم على CHIPS، وعلى الرغم من توفُّر الميزة في خلفيتها chrome://flags/#partitioned-cookies وعلامة واجهة سطر الأوامر --partitioned-cookies، إلا أنها ليست في حالة قابلة للاختبار بالكامل إلى الآن. وسنقدِّم تفاصيل محدّثة عن الاختبار وتصحيح الأخطاء بعد اكتمال عملية التنفيذ.

يتضمّن الموقع الإلكتروني ذو المستوى الأعلى، green.com، إطار iframe إلى red.com.com. يضبط موقع red.com ملف تعريف ارتباطًا باستخدام السمة "مُقسَّم". عندما يكون المتصفح على الموقع blue.com مع استخدام
إطار iframe إلى موقع red.com، لا يتم إرسال أي ملفات تعريف ارتباط! تقوم CHIPS بإنشاء قسم لكل موقع ويب عالي
المستوى.

مجموعات نطاقات الطرف الأول

في حال إعداد ملفات تعريف الارتباط لسياقات من عدة مواقع إلكترونية، ولكن فقط على المواقع الإلكترونية التي تملكها، على سبيل المثال، إذا كنت تستضيف خدمة على .com ويستخدمها .co.uk، عليك اتّباع مجموعات نطاقات الطرف الأول. يحدِّد هذا الاقتراح طريقةً للإعلان عن المواقع الإلكترونية التي تريد إنشاء مجموعة لها، ثم وضع علامة على ملفات تعريف الارتباط على أنها "SameParty" لكي يتم إرسالها فقط للسياقات داخل تلك المجموعة.

تكون مجموعات نطاقات الطرف الأول متاحة لاختبارات المطوّرين المحليين التي تستند إلى علامتَي chrome://flags/#use-first-party-set وchrome://flags/#sameparty-cookies-considered-first-party، ما يتيح لك تحديد مجموعتك الخاصة من المواقع الإلكترونية ذات الصلة وتجربة سلوك ملفات تعريف الارتباط على تلك المواقع.

تقسيم مساحة التخزين

يشتمل النظام الأساسي للويب على أشكال أخرى من التخزين قد تمكّن تتبع المواقع المتقاطعة. تقدّم الجلسة المصغّرة لبروتوكول TPAC حول حالة تقسيم مساحة تخزين المتصفّح نظرة عامة على مستوى تقدم Chrome إلى جانب مناقشة مجريات من مورّدي المتصفحات الآخرين.

ليس هناك حاجة فورية لاتخاذ إجراء من المطوِّر، ولكن إذا استفدت من SharedWorker أو Web Storage أو IndexedDB أو CacheStorage أو FileSystem API(واجهات برمجة التطبيقات في FileSystem) أو BroadcastChannel أو Web Locks API أو حِزم التخزين أو غير ذلك من أشكال التخزين أو واجهة برمجة التطبيقات للاتصالات التي تعتمد على الوصول إلى تلك البيانات من خلال عدة مواقع إلكترونية، عليك تتبُّع هذا الموضوع لتلقّي آخر الأخبار في المستقبل.

منع التتبُّع السري

في إطار تقليل الخيارات المتاحة للتتبُّع الصريح على مستوى المواقع الإلكترونية، نحتاج أيضًا إلى معالجة المساحات المتاحة في منصة الويب التي تكشف معلومات تعريفية تتيح استخدام البصمات الرقمية أو التتبُّع الخفي للمستخدمين.

تقليل سلاسل وكيل المستخدم وتلميحات برنامج وكيل المستخدم

لقد وسّعنا مرحلة مرحلة التجربة والتقييم لاختبار تنسيق وكيل المستخدم المخفّض في Chrome لتضمين عمليات التضمين التابعة لجهات خارجية. إذا كنت توفّر بشكل أساسي محتوًى من مواقع إلكترونية متعددة لخدمات أخرى، يمكنك تفعيل خيار الجهة الخارجية عند التسجيل في مرحلة التجربة والتقييم لتلقّي التنسيق المخفّض للطلبات المُرسَلة إلى مواردك.

يمكنك تتبُّع المخطط الزمني الكامل لخفض وكيل المستخدم من Chrome، من خلال الاطّلاع على مزيد من الأمثلة وتفاصيل حول مراحل الطرح. وستحتاج أيضًا إلى نقل البيانات إلى تعديلات برنامج وكيل المستخدم (UA-CH) إذا كنت تعتمد على إصدار النظام الأساسي أو الجهاز أو معلومات الإصدار الكامل بتنسيق User-Agent الحالي.

نواصل توحيد الأسماء الحالية لتلميحات العملاء من خلال إضافة بادئة العنوان Sec-CH- إذا كانت غير متوفّرة. وفي انتظار الموافقة، نأمل توسيع نطاق أحرف GREASE لخدمة UA-CH.

عرض محتوى وإعلانات ملائمة

بينما ننطلق نحو الإيقاف التدريجي لملفات تعريف الارتباط التابعة لجهات خارجية، نحتاج إلى تقديم واجهات برمجة التطبيقات التي تسمح بحالات الاستخدام التي تعتمد عليها ولكن بدون السماح بتتبّع إجراءات المستخدم على مواقع إلكترونية متعددة.

التعلُّم الموحّد للمجموعات النموذجية (FLoC)

FLoC هو اقتراح لتفعيل الإعلانات التي تستهدف الاهتمامات بدون الحاجة إلى إجراء تتبُّع فردي على عدة مواقع إلكترونية. كنّا نراجع الملاحظات الواردة من مرحلة التجربة والتقييم السابقة لميزة FLoC قبل الانتقال إلى مزيد من اختبارات المنظومة المتكاملة. وبينما نواصل العمل على الخطوات التالية والقرارات التالية بشأن تقنية "التعلُّم الموحّد للناشرين"، من المفترض أن ترى بعض الرموز الاستكشافية حول مفهوم المواضيع (المشار إليها سابقًا) لتظهر في قاعدة رموز Chromium قريبًا. وبما أن جميع عمليات تطوير Chrome تتم من خلال التطبيق المفتوح، سيكون هذا العمل مرئيًا، ولكن لا يتوفّر أي إجراء يمكن تنفيذه على الفور لاختبار المطوِّرين (ولا ينطبق ذلك على المستخدمين أيضًا). ونأمل أن نواصل مشاركة هذه المناقشات والتعديلات في مجموعة منتدى تكنولوجيا الإعلان الخاصة (PATCG) الجديدة.

قياس أداء الإعلانات الرقمية

وبوصفنا المنتج المصاحب لعرض الإعلانات بدون تتبُّع إجراءات المستخدم على مواقع إلكترونية متعددة، نحتاج إلى آليات للحفاظ على الخصوصية لقياس مدى فعالية هذه الإعلانات.

Attribution Reporting API

تمنحك Attribution Reporting API إمكانية قياس الأحداث على موقع إلكتروني معيّن، مثل النقر على إعلان أو مشاهدته، والتي تؤدي إلى إحالة ناجحة على موقع إلكتروني آخر، بدون تفعيل تتبُّع إجراءات المستخدم على مواقع إلكترونية متعددة.

نريد مواصلة اختبار Attribution Reporting API ونخطط لتمديد مرحلة التجربة والتقييم إلى Chrome 97. انتهت صلاحية الرموز المميّزة لإصدار الفترة التجريبية الحالية في 12 تشرين الأول (أكتوبر)، لذا عليك تقديم طلب للحصول على الرموز المميّزة المحدّثة لمواصلة الاختبار.

مكافحة المحتوى غير المرغوب فيه والاحتيال على الويب

يتمثل التحدي الآخر في تقليل مساحات العرض المتاحة لتتبُّع المواقع الإلكترونية في أنّ تقنيات البصمات الرقمية نفسها غالبًا ما يتم استخدامها للحماية من الرسائل غير المرغوب فيها والحماية من الاحتيال. نحتاج هنا أيضًا إلى بدائل تحافظ على الخصوصية.

الرموز المميّزة Trust

تتيح واجهة برمجة التطبيقات Trust Token لأحد المواقع الإلكترونية مشاركة ادّعاء بشأن أحد الزوّار، على سبيل المثال "أعتقد أنّه شخص"، مع السماح للمواقع الإلكترونية الأخرى بإثبات صحة هذا الادعاء بدون تحديد هويّة هذا الشخص.

الرموز المميّزة للثقة هي جزء من الاستراتيجية الشاملة لمكافحة المحتوى غير المرغوب فيه والاحتيال على الويب. خلال الجلسة المصغَّرة بعنوان"مكافحة الاحتيال على الويب" التي انتشرت في اللجنة الكورية لإدارة وتقييم الألعاب، ناقش ممثلون من المنظومة المتكاملة بعض التحديات والأساليب الحالية.

إضافة ملاحظات

بينما نواصل نشر هذه الأخبار الشهرية والتقدم المحرز من خلال "مبادرة حماية الخصوصية" ككل، نودّ التأكّد من حصولك كمطوّر على المعلومات والدعم اللازمَين. يُرجى إعلامنا على @ChromiumDev Twitter إذا كان هناك أيّ اقتراحات يمكننا تحسينها في هذه السلسلة. سنستخدم المعلومات التي قدّمتها لمواصلة تحسين التنسيق.

أضفنا أيضًا الأسئلة الشائعة حول "مبادرة حماية الخصوصية"، وسنواصل توسيع نطاقها استنادًا إلى المشاكل التي ترسلها إلى تقرير دعم المطوّرين. إذا كان لديك أي أسئلة حول الاختبار أو التنفيذ لأي من هذه الاقتراحات، يمكنك التواصل معنا هناك.