مرحبًا بك في إصدار تشرين الأول (أكتوبر) من "التقدّم في مبادرة حماية الخصوصية"، الذي يتتبّع الإنجازات التي تمّ تحقيقها في مسار إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا في Chrome والعمل على توفير شبكة ويب أكثر خصوصية. سنشارك كل شهر نظرة عامة على آخر الأخبار حول المخطط الزمني لـ "مبادرة حماية الخصوصية"، بالإضافة إلى أخبار من مختلف مجالات المشروع.
الفعاليات
اعتبارًا من 3 تشرين الثاني (نوفمبر)، سنستضيف قمة مطوّري Chrome. ستتمكّن من الحصول على آخر المعلومات عن "مبادرة حماية الخصوصية" في الخطاب الرئيسي، بالإضافة إلى فرصة لطرح أسئلة على فريق القيادة في جلسة الأسئلة والأجوبة، ووقت لطرح أسئلة أكثر تفصيلاً مع الفِرق الهندسية في جلسة مكتبي. يُرجى الاشتراك اليوم ونتطلّع إلى لقائك هناك.
شهد هذا الشهر أيضًا المؤتمر السنوي لمنظمة W3C (المعروف باسم TPAC) الذي تلتقي فيه جميع المجموعات المختلفة في W3C لمناقشة مجموعة متنوعة من المواضيع على مستوى الويب بالكامل. يمكنك الاطّلاع أدناه على دقائق الفيديوهات الخاصة بالجلسات المخصّصة للمجموعات الصغيرة وجلسات معيّنة، بما في ذلك جلسات "مبادرة حماية الخصوصية".
في إطار موسم المؤتمرات، تستضيف مجموعة مهندسي شبكة الإنترنت (IETF) الجلسة العامة التقنية رقم 112 على الإنترنت. على غرار TPAC، هناك عدد من الجلسات الفردية التي تتم فيها مناقشة مواضيع "مبادرة حماية الخصوصية"، مثل PRIV (Privacy respecting incorporation of values) وPEARG (Privacy enhancements and assessments research group) وMASQUE (Multiplexed application substrate over QUIC encryption). هذه مناقشات فنية معمّقة حول تصاميم البروتوكول. إذا كانت لديك العميقة المناسبة وكنت مهتمًا بالمساهمة في هذه المناقشات، يُرجى الانضمام.
تعزيز حدود الخصوصية على جميع المواقع
تُعدّ ملفات تعريف الارتباط التابعة لجهات خارجية آلية رئيسية تتيح التتبّع على مستوى المواقع الإلكترونية. إنّ التمكّن من التوقف عن استخدامها نهائيًا هو إنجاز كبير، ولكن علينا أيضًا معالجة أشكال أخرى من التخزين أو التواصل على مستوى المواقع الإلكترونية.
Federated Credentials Management API
مقترح إدارة بيانات الاعتماد المُدمَجة (FedCM) هو الاسم الجديد والأكثر ملاءمةً ل WebID. إنّ الهوية الموحّدة هي خدمة مهمة للويب، ولكن بما أنّه يتعلق الأمر صراحةً بمشاركة جوانب الهوية مع مواقع إلكترونية أخرى، هناك تفاصيل تنفيذ تتداخل مع التتبّع على مستوى المواقع الإلكترونية.
يستكشف اقتراح "إدارة بيانات الاعتماد الموحّدة" مجموعة من الخيارات بدءًا من مسارات نقل البيانات البسيطة للحلول الحالية إلى طُرق أكثر خصوصية ل الاتصال بالخدمات باستخدام الحد الأدنى من المعلومات التي تتم مشاركتها.
لا يزال هذا الاقتراح في مرحلة مبكرة ويمكن متابعة المناقشة في مجموعة منتدى الهوية الفيدرالية في W3C. استضافت المجموعة أيضًا جلسة مفصّلة في TPAC استكشافت نظرة عامة على الاقتراح. يتوفّر أيضًا إصدار أولي جدًا من واجهة برمجة التطبيقات، وهو متاح باستخدام علامة من الإصدار 89 من Chrome، ولكن هذا الإصدار مخصّص للتجربة فقط وسيتغيّر مع تقدّم المناقشة.
بسكويت
مع تقدّم الاقتراحات المتعلّقة بملفات تعريف الارتباط، عليك تدقيق ملفّات تعريف الارتباط الخاصة بك
SameSite=None أو ملفّات تعريف الارتباط على جميع المواقع الإلكترونية والتخطيط للإجراء الذي يجب
اتّخاذه على موقعك الإلكتروني.
ملفات تعريف الارتباط في الحالة المقسَّمة المنفصلة (CHIPS)
في حال ضبط ملفات تعريف ارتباط يتم إرسالها في سياقات على مستوى مواقع إلكترونية متعددة، ولكن في علاقات تعادل 1:1، مثل عمليات تضمين إطار iframe أو طلبات بيانات من واجهة برمجة التطبيقات، عليك اتّباع اقتراح CHIPS أو ملفات تعريف الارتباط التي تتضمّن حالة مجزّأة مستقلة. يتيح لك ذلك وضع علامة "مقسّمة" على ملفات تعريف الارتباط ووضعها في علبة ملفات تعريف ارتباط منفصلة لكل موقع إلكتروني من المستوى الأعلى.
يتواصل العمل على CHIPS، وعلى الرغم من توفّر الميزة من خلال chrome://flags/#partitioned-cookies وعلامة --partitioned-cookies CLI،
لم تصل بعد إلى حالة قابلة للاختبار بالكامل. سنقدّم تفاصيل محدّثة عن الاختبار و
تصحيح الأخطاء بعد اكتمال عملية التنفيذ بشكل أكبر.
مجموعات نطاقات الطرف الأول
إذا كنت تضبط ملفات تعريف الارتباط في سياقات على مستوى المواقع الإلكترونية، ولكن على مستوى المواقع الإلكترونية التي تملكها فقط، على سبيل المثال، إذا كنت تستضيف خدمة على النطاق .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 أو BroadcastChannel أو Web Locks API أو Storage Buckets أو أي شكل آخر من أشكال واجهة برمجة التطبيقات للتخزين أو واجهة برمجة التطبيقات للتواصل حيث تعتمد على الوصول إلى هذه البيانات على مواقع إلكترونية متعددة، عليك تتبُّع هذا الموضوع للاطّلاع على آخر الأخبار.
منع التتبّع الخفي
بينما نعمل على تقليل خيارات التتبّع الصريح على جميع المواقع الإلكترونية، علينا أيضًا معالجة الجوانب في منصة الويب التي تكشف معلومات تعريفية تسمح باستخدام تقنية البصمة الرقمية أو التتبّع الخفي للمستخدمين.
تقليل المعلومات في سلسلة وكيل المستخدم وتعديلات برنامج وكيل المستخدم
لقد وسّعنا نطاق مرحلة التجربة والتقييم لاختبار تنسيق وكيل المستخدم المُعدَّل في Chrome لتشمل عمليات تضمين المحتوى التابعة لجهات خارجية. إذا كنت تقدّم بشكل أساسي محتوى على مستوى الموقع الإلكتروني لخدمات أخرى، يمكنك تفعيل خيار الجهة الخارجية عند التسجيل في الفترة التجريبية للإصدار الأصلي لتلقّي التنسيق المنخفض في طلبات الوصول إلى مواردك.
يمكنك تتبُّع المخطط الزمني الكامل لتقليل دقة "وكيل المستخدم" في Chrome،
مع مزيد من الأمثلة والتفاصيل حول مراحل الطرح. ستحتاج أيضًا إلى
نقل البيانات إلى User-Agent Client Hints (UA-CH)
إذا كنت تعتمد على معلومات إصدار المنصة أو الجهاز أو الإصدار الكامل للإصدار
بتنسيق User-Agent الحالي.
نحن نواصل توحيد الأسماء الحالية لرسائل العميل
التلميحات من خلال
إضافة بادئة العنوان Sec-CH- في حال عدم توفّرها. في انتظار الموافقة، نأمل أن تتم
توسيع نطاق أحرف GREASE
لـ UA-CH.
عرض المحتوى والإعلانات ذات الصلة
في إطار سعينا إلى إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا، نحتاج إلى تقديم واجهات برمجة تطبيقات تسمح بحالات الاستخدام التي تعتمد عليها، ولكن بدون السماح بالتتبّع على مستوى المواقع الإلكترونية.
التعلُّم الموحّد للمجموعات النموذجية (FLoC)
FLoC هو اقتراح لتفعيل الإعلانات التي تستهدف الاهتمامات بدون الحاجة إلى التتبّع الفردي على جميع المواقع الإلكترونية. لقد كنا قيد تقييم الملاحظات الواردة من التجربة الأولى لـ FLoC قبل الانتقال إلى مرحلة متقدمة من اختبار المنظومة المتكاملة. بينما نواصل العمل على الخطوات التالية والقرارات المتعلّقة بـ FLoC، من المفترض أن تظهر لك قريبًا بعض الرموز البرمجية الاستكشافية حول مفهوم topics (المُشار إليها سابقًا) في قاعدة رموز Chromium البرمجية. بما أنّ جميع عمليات تطوير Chrome تتم علنًا، سيكون هذا العمل مرئيًا، ولكن لا يمكن اتّخاذ أي إجراء بشأنه في الحال لاختبار المطوّرين (ولا ينطبق ذلك على المستخدمين). نأمل أن نواصل مشاركة هذه المناقشات والتحديثات في PATCG (مجموعة منتدى تكنولوجيا الإعلان الخاصة) الجديدة.
قياس الإعلانات الرقمية
وبما أنّ عرض الإعلانات بدون تتبُّع على مستوى المواقع الإلكترونية هو أمر ملازم، نحتاج إلى آليات الحفاظ على الخصوصية لقياس مدى فعالية هذه الإعلانات.
Attribution Reporting API
تمنحك Attribution Reporting API إمكانية measuredقياس الأحداث على موقع إلكتروني واحد، مثل النقر على إعلان أو مشاهدته، والتي تؤدي إلى تسجيل إحالة ناجحة على موقع إلكتروني آخر، بدون تفعيل التتبّع على مستوى المواقع الإلكترونية.
نريد مواصلة اختبار واجهة برمجة التطبيقات Attribution Reporting API ونخطّطلإبقاء الإصدار العلني قيد الاختبار حتى الإصدار 97 من Chrome. انتهت صلاحية الرموز المميّزة الحالية لإصدار الإصدار التجريبي من المصدر في 12 تشرين الأول (أكتوبر)، لذا عليك تقديم طلب للحصول على رموز مميّزة معدّلة لمواصلة الاختبار.
مكافحة الرسائل غير المرغوب فيها والاحتيال على الويب
يتمثل التحدي الآخر الذي نواجهه عند تقليل مساحات العرض المتاحة للتتبّع على مستوى المواقع الإلكترونية في أنّ تقنيات وضع البصمات الرقمية نفسها غالبًا ما تُستخدَم لحماية المستخدمين من المحتوى غير المرغوب فيه والاحتيال. نحتاج إلى بدائل تحافظ على الخصوصية هنا أيضًا.
رموز Trust Tokens
Trust Token API هو اقتراح يسمح لموقع إلكتروني واحد بمشاركة مطالبة بشأن زائر، مثل "أعتقد أنّه شخص"، والسماح للمواقع الإلكترونية الأخرى بإثبات صحة هذه المطالبة، مرة أخرى بدون تحديد هوية الفرد.
تشكّل الرموز المميزة Trust Tokens جزءًا من الاستراتيجية العامة للتعامل مع المحتوى غير المرغوب فيه والاحتيال على الويب. في جلسة "مكافحة الاحتيال على الويب" ضمن فعاليات TPAC، discussed ممثّلون من جميع أنحاء المنظومة المتكاملة بعض الصعوبات والطرق الحالية التي يتم اتّباعها في مكافحة التحايل.
الملاحظات
بينما نواصل نشر هذه التعديلات الشهرية ونخطو خطوات إلى الأمام في إطار "برنامج Sandbox" للخصوصية بشكل عام، نريد التأكّد من حصولك بصفتك مطوّرًا على المعلومات والدعم اللازمَين. يُرجى إعلامنا على @ChromiumDev Twitter إذا كان هناك أيّ محتوى يمكننا تحسينه في هذه السلسلة. سنستخدم ملاحظاتك لمواصلة تحسين التنسيق.
أضفنا أيضًا الأسئلة الشائعة حول "مبادرة حماية الخصوصية" والتي سنواصل توسيع نطاقها استنادًا إلى المشاكل التي ترسلها إلى مستودع دعم المطوّرين. إذا كانت لديك أي أسئلة حول اختبار أي من الاقتراحات أو تنفيذها، يُرجى التواصل معنا.