تقرير الملاحظات والآراء - الربع الرابع من العام 2022

تقرير ربع سنوي للربع الرابع من العام 2022 يلخّص الملاحظات التي تم تلقّيها بشأن المنظومة المتكاملة حول اقتراحات "مبادرة حماية الخصوصية" واستجابة Chrome.

في إطار التزاماتها تجاه "مبادرة حماية الخصوصية"، وافقت Google على تقديم تقارير ربع سنوية للجميع عن عملية تفاعل الأطراف المعنية ضمن اقتراحات "مبادرة حماية الخصوصية" (يُرجى الاطّلاع على الفقرتين 12 و17(ج)(2) من الالتزامات). يتم إنشاء تقارير ملخّص ملاحظات "مبادرة حماية الخصوصية" هذه من خلال تجميع الملاحظات التي يتلقاها Chrome من مصادر مختلفة كما هو مُدرَج في نظرة عامة على الملاحظات، بما في ذلك على سبيل المثال لا الحصر: مشاكل GitHub ونموذج الملاحظات المتاح على privacysandbox.com والاجتماعات مع الجهات المعنية في المجال ومنتديات معايير الويب. يرحب Chrome بالملاحظات الواردة من المنظومة المتكاملة ويستكشف بشكل نشط طرقًا لدمج ما تعلّمته في قرارات التصميم.

يتم ترتيب مواضيع الملاحظات والآراء حسب الانتشار حسب واجهة برمجة التطبيقات. ويتم ذلك من خلال تجميع مقدار الملاحظات التي تلقّاها فريق Chrome حول موضوع معيّن والتنظيم بترتيب تنازلي للكمية. تم تحديد موضوعات الملاحظات الشائعة من خلال مراجعة موضوعات المناقشة من الاجتماعات العامة (W3C وPatCG وIETF)، والملاحظات المباشرة، وGitHub، والأسئلة الشائعة التي تظهر من خلال الفرق الداخلية والنماذج العامة في Google.

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

تم تطوير تفسيرات ردود Chrome على التعليقات استنادًا إلى الأسئلة الشائعة المنشورة، والردود الفعلية التي تم تقديمها على المشاكل التي طرحتها الأطراف المعنية، وتحديد الموضع خصيصًا لأغراض تمرين إعداد التقارير العلني هذا. مع التركيز الحالي على التطوير والاختبار، تلقينا أسئلة وتعليقات خاصة في ما يتعلق بـ Topics API وFledge وAttribution Reporting APIs.

إنّ التعليقات التي يتم تلقّيها بعد انتهاء الفترة المشمولة بالتقارير الحالية قد لا تكون قد استجابت Chrome بعين الاعتبار.

مسرد الاختصارات

الشرائح

ملفات تعريف الارتباط في الحالة المقسَّمة المنفصلة

معالِج الإشارات الرقمية (DSP)

منصّة الطلب

FedCM

إدارة بيانات الاعتماد الموحدة

لقطات في الثانية

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

مكتب الإعلانات التفاعلية (IAB)

مكتب الإعلانات التفاعلية

موفِّر الهوية (idP)

موفّر الهوية

مجموعة مهندسي شبكة الإنترنت (IETF)

مجموعة مهندسي شبكة الإنترنت

IP

عنوان بروتوكول الإنترنت

openRTB

عروض الأسعار في الوقت الفعلي

و إ

تجربة المصدر

PatCG

مجموعة منتدى تكنولوجيا الإعلان الخاصة

RP

مجموعة الاعتماد

نظام SSP

منصة جانب المورّد

TEE

بيئة تنفيذ موثوقة

UA

سلسلة وكيل المستخدم

UA-CH

تلميحات إلى عميل وكيل المستخدم

W3C

اتحاد شبكة الويب العالمية

قيد العمل على الإنترنت (WIPB)

العمى النهائي لعناوين IP

ملاحظات عامة بدون تحديد واجهة برمجة التطبيقات أو التكنولوجيا

موضوع الملاحظات	ملخّص	استجابة Chrome
(تم الإبلاغ أيضًا في الربع الثالث) الفائدة على مختلف أنواع الأطراف المعنية	مخاوف من أنّ تقنيات "مبادرة حماية الخصوصية" تفضِّل مطوّري البرامج الكبار، وأنّ المواقع الإلكترونية المتخصصة (الأصغر) تساهم أكثر من المواقع الإلكترونية العامة (الكبيرة)	لم يطرأ أي تغيير على ردّنا اعتبارًا من الربع الثالث: " التزمت Google بـ CMA لتصميم عروض "مبادرة حماية الخصوصية" وتنفيذها بطريقة لا تشوّه المنافسة من خلال الاختيار الذاتي للأنشطة التجارية الخاصة بشركة Google، ولمراعاة التأثير على المنافسة في الإعلان الرقمي وعلى الناشرين والمعلنين، بغض النظر عن الحجم. نواصل العمل عن كثب مع CMA لضمان امتثال عملنا لهذه الالتزامات. مع تقدُّم عملية اختبار "مبادرة حماية الخصوصية"، يكون أحد الأسئلة الرئيسية التي سنقيّمها هو مستوى أداء التكنولوجيات الجديدة للأنواع المختلفة من الجهات المعنيّة. تمثّل الملاحظات أهمية كبيرة في هذا الصدد، لا سيّما الملاحظات المحدّدة والقابلة للتنفيذ التي يمكن أن تساعدنا في تحسين التصاميم الفنية بشكل أكبر. لقد عملنا مع CMA لتطوير نهجنا في ما يتعلق بالاختبار الكمي، وندعم نشر ملاحظة حول تصميم التجربة من أجل توفير مزيد من المعلومات للمشاركين في السوق ومنحنا فرصة للتعليق على الأساليب المقترحة".
(تم الإبلاغ أيضًا في الربع الثالث) طلبات المستندات	طلبات للحصول على مزيد من الموارد التي توضح بالتفصيل كيفية إدارة الاختبار والتحليل والتنفيذ	تعديل في الربع الرابع من العام: ندرك أنّ المواد الحالية مفيدة للمطوّرين، ونحن ملتزمون بتقديم المزيد من المواد حتى يتمكّن المطوّرون من فهم مدى فائدة التكنولوجيات الجديدة. على مدار ربع السنة الماضي، أضفنا قسم "الأخبار والتحديثات" إلى privacysandbox.com ونشرنا مراجعة موسَّعة حول كيفية الاستفادة من "مبادرة حماية الخصوصية" في زيادة مدى صلة الإعلانات بموضوع البحث في المستقبل. عقدنا أيضًا جلسات علنية خلال ساعات عمل المطوّرين لمشاركة أفضل الممارسات والعروض التوضيحية، بالإضافة إلى جلسات أسئلة وأجوبة مع خبراء المنتجات والهندسة للسماح بالمناقشة المباشرة أو طرح الأسئلة.
مؤشرات أداء الويب الأساسية	كيف يؤثّر وقت استجابة Privacy Sandbox API في "مؤشرات أداء الويب الأساسية"؟	إنّ الحدّ من وقت الاستجابة هو هدف رئيسي في تصميم واجهات برمجة تطبيقات "مبادرة حماية الخصوصية". نتوقّع حاليًا أن يكون لوقت استجابة واجهة برمجة التطبيقات تأثيرًا طفيفًا في "مؤشرات أداء الويب الأساسية" للموقع الإلكتروني، إذ يتم استدعاء معظم واجهات برمجة التطبيقات بعد العرض الأوّلي للموقع الإلكتروني. ونواصل التتبُّع وإجراء التحسينات لخفض وقت الاستجابة بشكلٍ أكبر لكل واجهة من واجهات برمجة التطبيقات، ونشجّع على مواصلة إجراء الاختبارات وتقديم الملاحظات. تتم معالجة وقت الاستجابة في عملية تقديم عروض الأسعار في الوقت الفعلي في قسم FLEDGE ضمن "أداء مزادات FLEDGE"
إمكانية التشغيل التفاعلي	مخاوف بشأن إمكانية التشغيل التفاعلي مع الحلول المحتملة الأخرى	تهدف "مبادرة حماية الخصوصية" إلى حماية المستخدمين من التتبُّع في جميع المواقع الإلكترونية مع دعم احتياجات المنظومة المتكاملة على الويب في الوقت نفسه. نسعى لتحقيق ذلك من خلال الابتعاد عن تقنيات المتصفحات القديمة التي تتيح تتبُّع إجراءات المستخدم على مواقع إلكترونية متعددة، مثل ملفات تعريف الارتباط التابعة لجهات خارجية، وتقديم تكنولوجيات جديدة تم تصميمها خصيصًا لدعم حالات استخدام معيّنة. تعمل اقتراحات "مبادرة حماية الخصوصية" على تحسين الخصوصية من خلال الحدّ من البيانات التي تنتقل من جهاز المستخدم. لا تفرض هذه الاقتراحات قيودًا فنية على قدرة الموقع الإلكتروني على مشاركة البيانات أو معالجتها بعد جمعها من المتصفح. ولذلك لا تمنع هذه التقنيات الشركات من إبرام اتفاقيات "إدارة البيانات" أو أي علاقة تعاقدية مماثلة أخرى. وبالمثل، لا تفرض هذه السياسات قيودًا على قدرة المستخدمين على الموافقة على مشاركة بياناتهم بوسائل أخرى. للتوضيح، تلتزم Google بتطبيق تقنيات "مبادرة حماية الخصوصية" بالطريقة نفسها على جميع المواقع الإلكترونية، بما في ذلك منتجات Google وخدماتها. وبعد أن يوقف Chrome إتاحة استخدام ملفات تعريف الارتباط التابعة لجهات خارجية، توضح الالتزامات أيضًا أنّ Google لن تستخدم البيانات الشخصية الأخرى، مثل سجلّ تصفّح Chrome الذي تمت مزامنته، مع المستخدمين بغرض تتبُّع المستخدمين لاستهداف الإعلانات الرقمية أو قياس أدائها.

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

المواضيع

موضوع الملاحظات	ملخّص	استجابة Chrome
التأثير في ترتيب نتائج البحث من Google	الاستفسار عن ما إذا كان موقعك الإلكتروني متوافقًا مع Topics API كإشارة محتملة لترتيب نتائج البحث من Google	قد تختار بعض المواقع الإلكترونية إيقاف Topics API. لم ينسّق فريق "مبادرة حماية الخصوصية" أو يطلب من مؤسسة "بحث Google" استخدام ترتيب الصفحات كحافز للمواقع الإلكترونية لاعتماد Topics API. أكّدت Google لـ CMA أنّ محرّك بحث Google لن يستخدم قرار الموقع الإلكتروني بشأن إيقاف Topics API كمؤشر ترتيب.
مصنِّف المواضيع	أضِف عنوان URL ومحتوى الصفحة بالإضافة إلى اسم المضيف لتحديد موضوع صفحة الويب من أجل تحسين فائدة العديد من الجهات المعنيّة.	يتم حاليًا تصنيف سجلّ تصفّح المستخدم باستخدام أسماء المضيف لموقع إلكتروني. ويواصل Chrome تقييم خيارات مراعاة البيانات الوصفية على مستوى الصفحة (مثل كل أو بعض مكوّنات عنوان URL للصفحة و/أو المحتوى) في تصنيف "المواضيع". ويجب الالتفات إلى أي تحسينات في الأداة مقابل مخاطر الخصوصية وإساءة الاستخدام. على سبيل المثال، في ما يتعلق بالبيانات الوصفية على وجه الخصوص، تشمل بعض المخاطر بعض المخاطر: - المواقع الإلكترونية التي تعدّل البيانات الوصفية على مستوى الصفحة كطريقة لترميز المعاني المختلفة (والمحتمل أن تكون حسّاسة) إلى مواضيع - المواقع الإلكترونية التي تعدِّل البيانات الوصفية على مستوى الصفحة لتقديم وصف مضلّل لمواضيعها بهدف تحقيق مكاسب مالية، - المواقع الإلكترونية التي تعدِّل البيانات الوصفية على مستوى الصفحة بطريقة ديناميكية للتتبُّع على مواقع إلكترونية متعددة
(تم الإبلاغ أيضًا في الربع الثالث) التأثير في إشارات الطرف الأول	قد تكون إشارات المواضيع ذات قيمة عالية، ما يؤدي إلى خفض قيمة الإشارات الأخرى المستندة إلى اهتمامات الطرف الأول.	لم يطرأ أي تغيير على ردّنا اعتبارًا من الربع الثالث: "نحن نعتقد أنّ الإعلانات التي تستهدف الاهتمامات هي أحد حالات الاستخدام المهمة للويب، وقد تم تصميم Topics لتلبية حالة الاستخدام هذه. كما هو موضّح [في تقريرنا للربع الثالث من العام]، أعربت جهات معنيّة أخرى بالمنظومة المتكاملة عن مخاوفها من أنّ المواضيع قد لا تكون مفيدة بما يكفي لتقديم قيمة. وفي جميع الحالات، تمثل التحسينات على التصنيف جهدًا مستمرًا، ونتوقع أن يتطور التصنيف مع اختبار المنظومة المتكاملة وإدخالها".
تحديث التصنيف	كيف سيتم تعديل قائمة التصنيفات؟	ونسعى جاهدين إلى طلب الحصول على ملاحظات بشأن التصنيف الذي قد يكون مفيدًا للغاية للمنظومة المتكاملة. تم تصميم التصنيف المُدرج في الاقتراح الأوّلي لـ Topics API لإتاحة إجراء الاختبار الوظيفي. ويدرس Chrome طُرقًا متعددة لتعديل التصنيف بشكل فعال. على سبيل المثال، قد يستخدم Chrome مفهوم القيمة التجارية لكل موضوع لتحديد الفئة التي سيتم تضمينها في التكرارات المستقبلية.
أداء المصنِّف الإقليمي للمواضيع	أداء مصنِّف المواضيع ضعيف في النطاقات الإقليمية	ويُعد تحسين المصنِّف جهدًا مستمرًا. استنادًا إلى الملاحظات التي تلقيناها، أحد الاحتمالات التي يتم التفكير فيها هو توسيع قائمة تجاوز المواضيع، والتي يُظهر تحليلنا أنّها ستزيد من التغطية العالمية وتحسِّن الدقة. للتوضيح، يتضمن تصنيف Topics API مكوّنَين ذا صلة: (1) قائمة إلغاء تضم أفضل 10 آلاف موقع إلكتروني ومواضيعها، و (2) نموذج تعلُّم الآلة على الجهاز الذي يصنّف أسماء المضيفين إلى مواضيع. ومن خلال توسيع قائمة التجاوز (1)، يمكننا تحسين أداء التصنيف في تلك المناطق التي قد يكون أداء المصنِّف فيها ضعيفًا.
حقبة أسبوع واحد	فترة الأسبوع طويلة جدًا بالنسبة إلى المستخدمين الذين يتطلعون إلى اتخاذ قرارات أقصر مدةً.	ونعمل جاهدين على تحديد المدة المناسبة للحقبة ونرحب بالمزيد من الملاحظات بشأن هذه الحقبة التي ستكون أفضل من هذه الفترة للمنظومة المتكاملة.
استرداد عنوان HTTP	القلق من عدم توفّر معلومات كافية حول استرداد عنوان HTTP للمواضيع	لا يزال العمل جاريًا لاستخدام العناوين وfetch(). ولدينا أيضًا معلومات متاحة هنا. لقد أضفنا أيضًا معلومات حول ملاحظة التخطّي إلى الشرح.
تهدف المواضيع إلى مساعدة المعلنين فقط، وليس المستخدمين	يبدو أنّ المواضيع/"مبادرة حماية الخصوصية" هي نهج يركّز على الصناعة. الفائدة للمستخدمين ليست واضحة مثل الفائدة للصناعة.	نعتقد أنّ Topics تعود بالفائدة على المستخدمين أنّ Topics توفّر الإعلانات التي تستهدِف الاهتمامات التي تحافظ على حرية شبكة الإنترنت ومفتوحة، ونعتقد أيضًا أنّها تحسّن الخصوصية بشكل كبير مقارنةً بملفات تعريف الارتباط التابعة لجهات خارجية. إنّ إزالة ملفات تعريف الارتباط التابعة لجهات خارجية التي لا تتوفّر لها بدائل قابلة للتطبيق قد تؤثّر سلبًا في الناشرين، وقد تؤدّي إلى اتّباع أساليب أسوأ لا تتميّز بالخصوصية ولا تتميّز بالشفافية ولا يمكن للمستخدمين إعادة ضبطها أو التحكّم بها على نحو واقعي. تعمل العديد من الشركات على اختبار Topics وواجهات Sandbox API بفعالية، ونلتزم بتوفير الأدوات اللازمة لتعزيز الخصوصية ودعم الويب. نشرت مجموعة W3C Technical Architecture Group مؤخرًا عرضها الأولي حول Topics API وسنردّ عليها علنًا. في الوقت الحالي، وبعد أن تلقّت Google أسئلة من المنظومة المتكاملة حول ما قد تشير إليه هذه المراجعة في ما يتعلّق بتطوير وإطلاق Topics API، نودّ أن نعيد تأكيد خطتنا لإتاحتها على إصدار Chrome الثابت هذا العام. مع أنّ Google تقدّر الملاحظات المقدَّمة من "مجموعة البنية التقنية" التابعة لـ W3C، فإنّها تعتبر أنّ مواصلة الجهود لتطوير Topics واختبارها بالتشاور مع CMA والمنظومة المتكاملة.
تسرُّب البيانات	القلق من احتمال تسريب Topics إلى مواقع إلكترونية أخرى بدون إذن	إنّ تصميم Topics API يمنع تمامًا تسريب البيانات الواردة من ناشر واحد (وحتى مجموعة أصغر من الناشرين) بأي شكل من الأشكال. وتتحكّم المواقع الإلكترونية للناشرين أيضًا بشكل كامل في Topics API ويمكنها حظر الوصول إلى واجهة برمجة التطبيقات هذه من خلال سياسة الأذونات.
عدم توفّر المعلِنين للاختبار	يخشى الناشرون أنّه يتعذّر عليهم في الوقت الحالي إظهار قيمة Topics للمعلِنين.	في النصف الثاني من عام 2023، نخطط لإتاحة جميع واجهات برمجة التطبيقات المتعلّقة بالإعلانات في اختبار الدمج وتفعيل تحليل المنظومة المتكاملة لقيمة Topics بالنسبة إلى المعلِنين. ستخضع عملية اختبار النتائج ونشرها للإشراف من قِبل "هيئة السوق المحلية" التي ستراجع البيانات والتحليل والمنهجية. نشجّع المنظومة المتكاملة على مشاركة الملاحظات والآراء مع Google وCMA.
المواضيع وFLEDGE	طلب مزيد من المعلومات حول كيفية استخدام Topics ضمن منطق عروض الأسعار في FLEDGE	من الممكن استخدام Topics ضمن منطق عروض الأسعار في FLEDGE. ويتوفّر أيضًا دليل دمج يتضمّن تفاصيل إضافية عن عملية التنفيذ.
الترتيب المخصّص للمتصل بالمواضيع	السماح بأن يخصّص المتصل ترتيبًا معيّنًا	يتمثل التحدي الذي يواجه ترتيب المواضيع المخصّصة أو قيمها في كل تقنية إعلان في أنّ هذه التقنية يمكن أن تصبح آلية يمكن لتكنولوجيا الإعلان من خلالها التأثير في المواضيع التي يتم عرضها، وبالتالي تكون متّجهًا للبصمات الرقمية.
قائمة أولويات المتصلين بالموضوعات	يمكنك السماح للمتصلين بتقديم قائمة ذات أولوية مرتَّبة بالمواضيع التي تعرضها Topics API استنادًا إلى متطلبات الأهلية.	ونعمل حاليًا على مناقشة هذه الفكرة أكثر ونرحّب بالمساهمات الإضافية.

FLEDGE

موضوع الملاحظات	ملخّص	استجابة Chrome
مدير إعلانات Google	القلق من أنّ "مدير إعلانات Google" هو المحدِّد النهائي لمزادات FLEDGE ويفضّل استخدام علامات "ناشر Google" و"مدير إعلانات Google".	يسمح FLEDGE لكل ناشر باختيار بنية المزاد، بما في ذلك اختيار البائعين من المستوى الأعلى وبائعي المكونات. يعرف كل مشترٍ وبائع في مزاد مكوّن من هو بائع المستوى الأعلى، ويمكنه اختيار ما إذا كان يريد تقديم عرض سعر أم لا.
لا يتوفر عدد كافٍ من المشاركين الذين يختبرون FLEDGE	طلب تشجيع المزيد من الشركات على اختبار FLEDGE، مثلاً من خلال تحسين وظائف واجهة برمجة التطبيقات ومنع استخدام البدائل التي تتعارض مع الخصوصية، مثل البصمات الرقمية	تسير "مبادرة حماية الخصوصية" على مراحل، بالشراكة الوثيقة مع توجيهات CMA وICO، وقد أظهر اختبار FLEDGE الوظيفي الاستقرار والإمكانات اللازمة. تواصل Google تشجيع المنظومة المتكاملة على اختبار واجهات برمجة تطبيقات "وضع الحماية"، حيث نشرت مؤخرًا مستندات "تحقيق الحد الأقصى من مدى صلة الإعلان بالموضوع" لتوضيح كيف يمكن أن يساعد FLEDGE وواجهات برمجة التطبيقات الأخرى في دعم حالات الاستخدام المُهمة لمجال الإعلانات بعد إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا. تتضمّن أجزاء أخرى من "مبادرة حماية الخصوصية" حاليًا إجراءات الحدّ من التتبّع (يمكنك الاطّلاع على UA-CH و"حماية IP" و"إجراءات الحدّ من التتبُّع الارتدادي") ومواصلة تحسين أدائها بمرور الوقت. لا تهدف Google إلى جعل FLEDGE هو حل الاستهداف الوحيد القابل للتطبيق، ولكنها تظل ملتزمة بالعمل بالشراكة مع المجال والجهات التنظيمية لتطوير أفضل تقنيات الإعلانات التي تحافظ على الخصوصية في متصفِّح Chrome.
حالات استخدام تقنية تعلُّم الآلة	مزيد من الإرشادات حول كيفية دعم حالات استخدام تعلُّم الآلة لتدريب خوارزميات عروض أسعار المزادات في FLEDGE وإعداد تقارير الإحالة	ندرك الحاجة إلى مساعدة المختبِرين في العثور على أكثر الطرق فائدة لتطبيق تقنيات "مبادرة حماية الخصوصية". لقد بدأنا في نشر إرشادات تتعلّق تحديدًا باستخدام الجوانب المختلفة لواجهات برمجة تطبيقات "مبادرة حماية الخصوصية" كمدخلات لتعلُّم الآلة. يناقش أحدث مقال بعنوان "زيادة مدى صلة الإعلان بالموضوع إلى أقصى حد" كيف يمكن لمجال الإعلانات الاستفادة من هذه الإشارات لتعلُّم الآلة، ونخطط لمواصلة نشر هذه الإرشادات من الآن فصاعدًا.
الاستعلام عن خادم قيمة مفتاح FLEDGE (K/V)	لماذا يمكن الاستعلام عن خادم K/V بشكل علني؟	يهدف خادم K/V إلى توفير إشارات في الوقت الفعلي لمزادات FLEDGE. وبالتالي، يجب أن تتوفر إمكانية الوصول إلى خادم K/V من مكان تنفيذ مزادات FLEDGE هذه، أي على أجهزة المستخدمين، ما يتطلب أن يكون متاحًا للجميع. لا يمكن استرداد أي قيمة مخزنة في خادم K/V إلا من قِبل جهة تمتلك مفتاحها، ولذلك إذا لم تمنح تقنية الإعلان المفاتيح إلا للمتصفّحات ضمن مجموعة الاهتمامات، ولا تستخدم مفاتيح يمكن تخمينها عشوائيًا، لن تتمكّن من استردادها سوى المتصفّحات التي تحتاج إلى القيمة لإجراء مزاد.
كيف يتم استهداف الوقت أو التاريخ؟	دعم كائنات التاريخ في دالة منطق عرض الأسعار.	وهناك العديد من الطرق لإجراء ذلك. يمكن للمشترين أن يطلبوا من البائع تقديم التاريخ والوقت الحاليين، ويجب أن يكون من السهل على البائعين تقديم هذه المعلومات لجميع المشترين. يمكن للمشترين أيضًا تقديم التاريخ والوقت في ردّهم على القيمة الأساسية في الوقت الفعلي. أخيرًا، يمكن للمشترين تقديم التاريخ والوقت كجزء من الاستجابة السياقية في الإشارات لكل مشترٍ، والتي يمكن للبائع تمريرها إلى النص البرمجي generateBid للمشتري.
الإعدادات المفضّلة لدى المستخدم	قدرة المستخدمين على اختيار حظر تصاميم الإعلانات من قِبل المعلِن عند عرضها من خلال FLEDGE أو حلول بديلة.	يمكن للمستخدمين إيقاف Ads API في Chrome. بالنسبة إلى إعلانات معيّنة، تكون تقنية الإعلان الملائمة هي أفضل جهة تسمح بتوفير عناصر تحكّم في تصميمات الإعلانات التي يتم عرضها أو كيفية اختيارها.
مخططات زمنية أكثر وضوحًا	يمكنك طلب مزيد من المعلومات حول مدى توفّر إجراءات حماية الخصوصية في FLEDGE، مثل طلب استخدام Fenced Frames.	نخطط لنشر مخططات زمنية أكثر تفصيلاً في الربع الأول.
الالتباس في إعداد التقارير	اطلب مزيدًا من التوضيح حول آلية عمل تقارير FLEDGE مع واجهات برمجة التطبيقات الأخرى، مثل Fenced Frames و Private Aggregation API.	نخطط لنشر توضيح حول التفاعل بين Private Aggregation API وFLEDGE وFenced Frames خلال الأسابيع القادمة.
عرض الأسعار في الوقت الفعلي وFLEDGE	إرشادات حول كيفية دمج FLEDGE مع عروض الأسعار العادية في الوقت الفعلي.	الأمران الرئيسيان اللذان يعيقان قدرة تكنولوجيا الإعلان على تقديم عروض الأسعار في الوقت الفعلي هما الوصول إلى البيانات على مستوى الحدث والدمج بسهولة في تقنية ARA. ونخطط لإرسال تعديلات وتوضيحات بشأن كلا الأمرين في الربع الأول.
أداء مزادات FLEDGE	الإبلاغ من المختبِرين عن وقت استجابة مزادات FLEDGE طويل	نحن نقدّر التقارير التي يشاركها المختبِرون لنتائجهم وحالات الاستخدام، وقد شاركنا بعض الاقتراحات حول كيفية تحسين أداء FLEDGE. بالتزامن مع هذه المشكلة، أضفنا أدوات إلى المتصفّح تتيح للمطوّرين تشخيص أفضل العوامل التي تبطئ عمليات المزادات، وتعاملنا بشكل منهجي مع المصادر الأساسية لوقت الاستجابة التي تم رصدها. تتضمّن التحسينات الأخيرة مهلات للمزادات البطيئة وأسلوب فلترة نظام عروض الأسعار السريع وطريقة إعادة استخدام وظائف FLEDGE لتجنُّب دفع تكاليف بدء التشغيل، والعمل المستمر من أجل السماح بتشغيل طلب الإعلان السياقي بالتوازي مع وقت بدء تشغيل FLEDGE واسترداد بيانات الشبكة. نتوقّع أن يستمر تحسين وقت الاستجابة كمحادثة مستمرة بين مطوّري Chrome ومختبِري FLEDGE بناءً على تجربتهم الفعلية في استخدام واجهة برمجة التطبيقات.
حد الذاكرة لحجم مجموعة الاهتمامات	يمكنك طلب زيادة الحد المسموح به لحجم مجموعة اهتمام واحدة من 50 كيلوبايت.	نحن ننظر في الطلب بشكل فعّال ونبحث عن ملاحظات حول حد القيمة المناسب.
دمج بيانات FLEDGE التي يتم عرضها مع ملف تعريف ارتباط الطرف الأول	هل سيدعم FLEDGE الدمج مع بيانات الطرف الأول للمعلن؟	تم إنشاء FLEDGE لدعم الإعلان باستخدام بيانات الطرف الأول التي يمتلكها المعلن من قبل. ومع ذلك، لا يهدف FLEDGE إلى مساعدة المعلِن في معرفة سلوك المستخدِم أثناء التصفُّح على أي موقع إلكتروني غير الموقع الإلكتروني للمعلِن. إنّ إرفاق سلوك التصفُّح خارج الموقع الإلكتروني ببيانات الطرف الأول يتعارض مع أهداف "مبادرة حماية الخصوصية". نخطط لمشاركة أدلة الدمج مع مزيد من التفاصيل حول كيفية دعم FLEDGE للدمج مع بيانات الطرف الأول خلال الأسابيع المقبلة.
قيمة إخفاءية خوارزمية التصنيف	كيف يتم تحديد القيمة من "K" لـ "k-anon" وهل سيتم نشرها؟	لا تزال قيمة "K" قيد الانتهاء وسنشارك المزيد من المعلومات مع وضع خططنا. يهمّنا معرفة المزيد من المعلومات عن كيفية تأثير قيمة k غير المعروفة في عرقلة الاستعداد لاستخدام FLEDGE وتحديد نطاق تدريب نموذج تعلُّم الآلة ونرحب بملاحظاتك الإضافية حول هذا الموضوع.
دعم العديد من مقدِّمي خدمة البريد الإلكتروني (SSP)	كيف سيتم دعم أنظمة SSP متعددة في FLEDGE؟	يدعم FLEDGE المزادات المتعددة البائعين كما هو مذكور في هذا الاقتراح.
رؤية منطق عروض الأسعار	القلق بشأن الكشف عن منطق عرض بيانات DSP في JavaScript	يمكن للآخرين الوصول إلى JavaScript في منطق عروض أسعار التصميم الحالي، ولكننا نرحّب بالمزيد من الملاحظات عن الأسباب التي تجعل ذلك مصدر قلق لموفّري خدمات النظام.
prebid.js	ما هو المخطط الزمني في إتاحة استخدام prebid.js في FLEDGE؟	لا تتوافق سوى وحدة FLEDGE في الإصدار 7.14 والإصدارات الأحدث من Prebid.js. على الناشرين المهتمين بالاختبار إضافة وحدة FLEDGE وترقية مثيل Prebid الخاص بهم.
الدوال التي يحددها المستخدم في FLEDGE	كيف سيتم دعم الدوال التي يحددها المستخدم (UDF) في FLEDGE؟ هذه هي وظائف يمكن برمجتها من قِبل المستخدمين النهائيين لتوسيع وظائف واجهة برمجة التطبيقات.	الشرح متوفّر هنا. ما زلنا نعمل على توضيح هذه المشكلة، لذا نرحب بملاحظات إضافية حول حالات الاستخدام.
تخفيف القيد المفروض على موارد مجموعة الاهتمامات المشتركة	طلب تخفيف القيد المفروض على موارد مجموعة الاهتمامات من أجل إتاحة بعض حالات استخدام تكنولوجيا الإعلان	في التنفيذ الحالي لـ FLEDGE، يجب أن يكون لدى biddingLogicUrl وbiddingWasmHelperUrl وdailyUpdateUrl وtrustedBiddingSignalsUrl المصدر نفسه لمالك مجموعة الاهتمامات. يهدف القيد إلى منع المهاجمين من تنفيذ بعض الاستغلالات، كما هو موضّح هنا.
ملكيّة مجموعة الاهتمام	طلب تحديد ما إذا كان بإمكان إحدى تكنولوجيا الإعلان استخدام ميزة joininterestGroup في مجموعات الاهتمامات نفسها على مختلف المواقع الإلكترونية	ينصب تركيزنا على كيفية استخدام شرائح الجمهور وليس على كيفية إنشائها. نناقش طرقًا محتملة هنا ونرحب بتقديم ملاحظات إضافية.
انتهاء صلاحية مفتاح خادم القيمة الرئيسية	مناقشة حول إزالة مفاتيح الخادم بعد انتهاء صلاحية مجموعات الاهتمامات المقابلة	نستكشف طرقًا للتعامل مع تاريخ انتهاء صلاحية المفتاح ونتطلّع إلى تلقّي ملاحظات هنا.

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

Attribution Reporting (وواجهات برمجة التطبيقات الأخرى)

موضوع الملاحظات	ملخّص	استجابة Chrome
عدد الزيارات خلال الفترة التجريبية المجانية	إنّ عدد زيارات الإصدار التجريبي الحالي المنشأ غير كافٍ لإجراء اختبار الخدمات.	إنّ الإصدارات التجريبية من المصدر الحالي مصمَّمة لكي تتمكّن الجهات الفاعلة من المنظومة المتكاملة من إجراء اختبارات وظيفية لضمان عمل واجهة برمجة التطبيقات على النحو المطلوب. نحن ندرك أنّه سيُطلب منك زيادة عدد الزيارات لإجراء اختبار الأداة بعد أن يصبح تطوير واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" المختلفة أكثر نضجًا. يتوقّع المخطط الزمني الحالي للاختبارات أن تتم العملية حسب مدى التوفّر للجمهور العام (أي عندما يتم إطلاق التكنولوجيا الخاصة بحالات الاستخدام وتوفّرها لجميع زيارات Chrome) في الربع الثالث من عام 2023 (يُرجى الاطّلاع على المخطط الزمني المحدَّث على privacysandbox.com). ونرحّب بأي ملاحظات إضافية بشأن اختبار حالات الاستخدام التي تتطلّب زيارات إضافية.
التداخل في وظائف واجهات برمجة التطبيقات المختلفة لقياس "مبادرة حماية الخصوصية"	ستؤدي المخاوف من تداخل مناهج قياس متعدّدة من خلال "مبادرة حماية الخصوصية" إلى زيادة التعقيد، على سبيل المثال، Attribution Reporting API و Private Aggregation API.	نعمل على إعداد مستندات أفضل لتوضيح حالات الاستخدام المختلفة لواجهات برمجة التطبيقات ونرحب بملاحظات إضافية حول المجالات التي تحتاج إلى شرح. على سبيل المثال، تم تصميم Attribution Reporting API خصيصًا لإتاحة قياس الإحالات الناجحة، في حين أنّ واجهة برمجة التطبيقات Private Aggregation API و"مساحة التخزين المشتركة" هما واجهات برمجة تطبيقات للأغراض العامة تهدفان إلى دعم مجموعة أكبر من حالات استخدام القياس على عدة مواقع إلكترونية.
إعادة محاولة طلب التقرير الذي تعذّر تحميله	توضيح بشأن عدد المرات التي تتم فيها محاولة طلب تقرير في حال تعذّر تنفيذه.	وقد نشرنا إرشادات حول هذا الموضوع. خلاصة القول، لا يتم إرسال التقارير إلا عند تشغيل المتصفِّح أو الاتصال بالإنترنت. بعد تعذّر إرسال التقرير للمرة الأولى، تتم إعادة المحاولة بعد 5 دقائق. وبعد الإخفاق الثاني، تتم إعادة محاولة الإبلاغ بعد 15 دقيقة. وبعد ذلك لا يتم إرسال التقرير.
تأخير إعداد التقارير	ما هو التأخير المتوقع في إعداد التقارير؟	نتطلّع إلى الاطّلاع على المزيد من الملاحظات من المنظومة المتكاملة حول أي تأخيرات في إعداد التقارير قد تواجهها أثناء جمع البيانات لتقييم حالات التأخير هذه بشكل أكبر بالتوازي.
الصفحات المعروضة مُسبقًا	هل سيعمل تحديد مصدر ARA على صفحات العرض المُسبَق؟	يتم تأجيل تسجيل تحديد المصدر على صفحات العرض المُسبَق إلى أن يتم التفعيل (يتم إجراء نقرة أو مشاهدة فعلية). وهذا يعني أننا سنؤجل فحص اتصال طلب `attributionsrc`.
قياس تحسين الإحالات الناجحة	كيفية قياس تحسين الإحالات الناجحة باستخدام اختبار AB على النطاق نفسه	يمكن للمواقع الإلكترونية قياس مستوى تحسين الإحالات الناجحة باستخدام اختبار أ/ب على النطاق نفسه من خلال إعداد تقارير الإحالة. ويمكنهم ترميز مَعلمات A/B كمفاتيح باستخدام واجهة برمجة التطبيقات المجمّعة، ثمّ تلقّي تقارير تلخيصية لقيم الإحالات الناجحة من خلال هذه المجموعات الرئيسية.
(تم الإبلاغ أيضًا في الربع الثالث) عن الإحالات الناجحة عبر النطاقات	كيفية تتبُّع الإحالات الناجحة التي تتم في جميع النطاقات، مثل الإحالات الناجحة مع وجهتين أو أكثر	تعديل في الربع الرابع من العام: لقد نشرنا اقتراحًا لإزالة القيد المفروض على وجهة الصفحة المقصودة، ما يتيح تتبُّع المحادثات على جميع النطاقات. تم تنفيذ هذا الاقتراح.
(تم الإبلاغ أيضًا في الربع الثالث) إعداد انتهاء الصلاحية في تقرير الإحالات الناجحة	طلب إتاحة فلتر التقرير / تاريخ انتهاء الصلاحية لأقل من 24 ساعة	تعديل في الربع الرابع من العام: لقد شاركنا طلب السحب هذا الذي سيؤدي إلى فصل فترات انتهاء الصلاحية وإعداد التقارير للحدّ من الفوائد المترتبة على تأخير إعداد التقارير مقابل انتهاء صلاحية الإحالة الناجحة. تم إطلاق هذه الميزة الآن في الإصدار M110.
الاحتيال وإساءة الاستخدام	طلبات المعلنين وجهات التسويق التي تمكّنهم من تقسيم البيانات وتجميعها استنادًا إلى مواقع الناشرين التي تعرض إعلاناتهم، ما يمنح أيضًا مزيدًا من المعرفة بشأن الممارسات الإعلانية الاحتيالية المحتملة	تتم مناقشة هذه الملاحظات بنشاط هنا ونرحب بالمزيد من الملاحظات.
(تم الإبلاغ أيضًا في الربع الثالث) تأخير إعداد التقارير على مستوى الحدث	وقد يكون التأخير لمدة يومَين إلى 30 يومًا في إعداد التقارير على مستوى الحدث طويلاً جدًا بالنسبة إلى حالات استخدام معيّنة.	تتضمّن التقارير على مستوى الحدث فترات إعداد تقارير تلقائية تبلغ يومَين و7 و30 يومًا. يمكن تعديل هذا العنوان باستخدام المعلمة "expiry". يمكن لتقنيات الإعلانات ضبط تاريخ انتهاء الصلاحية، الذي لا يقل عن يوم واحد، للحصول على التقارير المحتملة في أقل من يومين. ونحدّ من دقة انتهاء الصلاحية بيوم واحد كآلية لحماية الخصوصية، لأنّ إعداد التقارير الأكثر دقة قد يؤدي إلى هجمات متعلّقة بالتوقيت. إضافةً إلى ذلك، نسمح بضبط معلَمات مستقلة "انتهاء الصلاحية" على مستوى الحدث والتقارير المجمّعة. يُرجى الاطّلاع على المعلومات الواردة هنا. إضافةً إلى ذلك، لن تحصل "إعلانات Google" على أيّ فترات إعداد تقارير خاصة لا تتوفّر لتكنولوجيا الإعلان الأخرى من خلال Attribution Reporting API.
نفس متطلبات أصل إعداد التقارير	طلب إزالة شرط أن يكون مصدر تسجيل المصدر مطابقًا لمصدر تسجيل الإحالة الناجحة	ونقترح استخدام عمليات إعادة توجيه HTTP لتفويض التسجيل لحل حالة الاستخدام هذه. نرحّب بأي ملاحظات إضافية حول الإرشادات الجديدة.
تتبُّع الإحالات الناجحة	تحتاج إلى التمييز بين ما إذا كانت الإحالة الناجحة قد حدثت قبل/بعد ساعات معيّنة حدّدها المعلن	تتيح Attribution Reporting API ضبط فترة انتهاء صلاحية وأولوية لتحديد المصدر بالاستناد إلى المصدر. وباستخدامهما معًا، يمكن من الناحية الفنية تحديد مصدر إحالة ناجحة حدثت خلال فترة X يوم بشكلٍ منفصل عن الإحالة الناجحة التي حدثت بعد X.
محاكاة الضوضاء	طلب الحصول على إمكانية محاكاة الحجم المختلف للإحالات الناجحة لكل مجموعة بيانات، وذلك لفهم تأثير ذلك على المعلِنين الذين يسجّلون عددًا أقل من الإحالات الناجحة	ونحن نتطلّع إلى إضافة طرق لمحاكاة ذلك في الإصدارات المستقبلية من Noise Lab. نرحب بأي ملاحظات إضافية.
إعداد التقارير على الأجهزة الجوّالة	هل سيستمر إرسال التقرير عند تشغيل Chrome في الخلفية على جهاز جوّال؟	في الوقت الحالي، لن يتم إرسال التقرير حتى على الأجهزة الجوّالة عندما يكون Chrome في الخلفية. من المرجّح أن يتغيّر ذلك عندما تتكامل واجهة برمجة التطبيقات مع "مبادرة حماية الخصوصية" على Android. يُرجى الاطّلاع على المعلومات الواردة هنا. تجدر الإشارة إلى أنّ "مبادرة حماية الخصوصية" على Android ليست جزءًا من الالتزامات التي وافقت عليها "مؤسسة CMA".
مدى توفُّر البيانات	المخاوف من إمكانية وصول Google بشكل إضافي إلى البيانات من خلال واجهات برمجة تطبيقات "مبادرة حماية الخصوصية"	أولاً، لا تحصل "إعلانات Google" على أي إذن وصول تفضيلي إلى البيانات من Attribution Reporting API أو غيرها من واجهات برمجة تطبيقات "مبادرة حماية الخصوصية". تتم معالجة هذه المشكلة أيضًا في قسم "الملاحظات العامة" ضمن "إمكانية التشغيل التفاعلي" الذي يتضمّن المزيد من التفاصيل عن التزامات Google. ثانيًا، بسبب الاختلاف بين المواقع الإلكترونية الكبيرة والصغيرة، تدرك Google أنّ إجراءات حماية الخصوصية المستندة إلى التشويش قد يكون لها تأثير أكبر على شرائح البيانات الأصغر حجمًا. ومع ذلك، هناك بعض التخفيفات المحتملة: على سبيل المثال، طرق مثل التجميع على مدى فترات زمنية أطول من شأنها حل هذه المشكلة. مع ذلك، لم يتّضح لنا ما إذا كانت الاستنتاجات التي تستند إلى شرائح بيانات صغيرة جدًا (مثل عملية شراء واحدة أو عمليتَي شراء) مفيدة على الإطلاق بالنسبة إلى المعلِنين. خلال مرحلة التجربة والتقييم، شجّعت Google المختبِرين على الاستفادة من إمكانية تجربة مجموعة واسعة من مَعلمات الخصوصية والضوضاء ليتمكنوا من تقديم ملاحظات أكثر تحديدًا حول هذه المشكلة.

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

تقليل وكيل المستخدم

موضوع الملاحظات	ملخّص	استجابة Chrome
تأخير تقليل وكيل المستخدم إلى أن تصبح المنظومة المتكاملة على الويب جاهزة بشكلٍ أكبر	ليس هناك ما يكفي من الوقت للتكيّف مع التغييرات القادمة التي ستطرأ على استراتيجية تقليل وكيل المستخدم.	وسنتناول هذه الملاحظات في التقرير الكامل ضمن "مخاوف الأطراف المعنية" ضمن القسم الذي يحمل عنوان "تفاعل Google مع CMA".
تأخير تقليل وكيل المستخدم إلى أن تصبح المنظومة المتكاملة على الويب جاهزة بشكلٍ أكبر	طلب تأخير طرح ميزة "تقليل معلومات وكيل المستخدم" إلى أن يتم نشر برامج وكيل المستخدم المنظَّمة (SUA)	اقترح فريق "إعلانات Google" إضافة وكيل المستخدم المنظَّم (اطّلِع على المواصفات) على OpenRTB في تشرين الأول (أكتوبر) 2021، وتم تضمينها في تحديث المواصفات 2.6 الذي تم إصداره في نيسان (أبريل) 2022. لدينا بعض الأدلة على أنّ ميزة SUA تم نشرها وأصبحت متاحة اليوم، كما أوضحت في مشاركة مدونة Scientia Mobile التي توضّح كيفية استخدام تقنية UA-CH وWURFL API لإنشاء اتفاقية Universal Analytics.

###

تلميحات العميل لوكيل المستخدم

موضوع الملاحظات	ملخّص	استجابة Chrome
اختبار UA-CH باستخدام أساليب تتبُّع أخرى لمكافحة التخفي	إرشادات حول كيفية اختبار جميع واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" وأساليب البصمات الرقمية المقترَحة معًا في نهج شامل	تم تصميم خطة الاختبار لتعكس المخططات الزمنية غير المتزامنة لتطوير بعض إجراءات مكافحة البصمات الرقمية مقارنةً بباقي اقتراحات Sandbox. وهو يعالج حقيقة أنّ بعض إجراءات مكافحة البصمات الرقمية (مثل ميزانية الخصوصية، وحماية عنوان IP، وإجراءات الحدّ من التتبُّع الارتدادي) ستكون قيد التطوير بالكامل وستكون جاهزة للإطلاق في نموذج مدى التوفّر للجمهور العام فقط بعد إيقاف ملفّات تعريف الارتباط التابعة لجهات خارجية نهائيًا. على الرغم من أنّ إجراءات مكافحة البصمات الرقمية هذه لن تكون مضمّنة في الاختبارات الكمية، ستخضع للتقييم النوعي استنادًا إلى الحقائق المتوفّرة في وقت التوقف عن العمل.
(تم الإبلاغ أيضًا في الربع الثاني) الأداء	مخاوف بشأن وقت استجابة الحصول على التلميحات عبر عملية المعالجة الحرجة (عند تحميل الصفحة الأولى)	راجِع قسم UA-CH المخصّص أدناه.
ملاحظات غير كافية	قد لا تكون التعقيبات الواردة من المنظومة المتكاملة حول تغيير UA-CH كافية، ما يؤدي إلى مخاوف بشأن نقص الوعي لدى المنظومة المتكاملة.	حرصنا على مشاركة خططنا بشكل استباقي لضمان إجراء الطرح بعناية للحدّ من انقطاع الخدمة. في 18 آذار (مارس) 2022، تم تقديم خطط الحدّ من وكيل المستخدم وواجهة برمجة التطبيقات UA-CH إلى مجموعة منتدى مكافحة الاحتيال في W3C في 18 آذار (مارس) 2022، وعلى كل من فريق عمل Web Payments ومجموعة إبداء الاهتمام بالأمان في خدمات الدفع على الويب في 20 كانون الثاني (يناير) 2022. لم يتم إبداء مخاوف كبيرة أثناء العروض التقديمية أو بعدها. تفاعلت Google بشكل استباقي مع أكثر من 100 عامل تشغيل للمواقع الإلكترونية للحصول على ملاحظات بشأنها. بالإضافة إلى ذلك، استخدمت Google أيضًا قنوات Blink-Dev للإعلان بشكل علني عن طرح برنامج خفض وكيل المستخدم استنادًا إلى ملاحظات الجهات المعنيّة بالمنظومة المتكاملة.
التوقيت	المخاوف المثارة بشأن توقيت الطرح والاستعداد للمجال	راجِع قسم UA-CH المخصّص أدناه.
حالة النظام الأساسي Chrome	تم طلب تعديل صفحة حالة chrome لمنصة UA-CH.	تم تعديل إدخال chromestatus في 19 كانون الأول (ديسمبر) إلى "إشارات مختلطة".

حماية IP (المعروفة سابقًا باسم Gnatcatcher)

موضوع الملاحظات	ملخّص	استجابة Chrome
تفعيل أو إيقاف	هل يتم تفعيل أو إيقاف خصوصية عنوان IP؟	هدفنا هو توفير حماية الملكية الفكرية لجميع المستخدمين. ومن هذا المنطلق، نعمل حاليًا على تقييم خيارات المستخدم لحماية الملكية الفكرية.
حالة استخدام عنوان IP لبيانات الطرف الأول	هل من الممكن استخدام عناوين IP لتجميع تجارب المستخدمين عبر نطاقات الطرف الأول بعد حماية عنوان IP؟	كما نشرنا سابقًا، ستركّز ميزة "حماية IP" في البداية على التتبّع في سياق الجهة الخارجية، ما يعني أنّ نطاقات الطرف الأول لن تتأثر.
حالات استخدام تكنولوجيا الإعلان	كيف يمكن للشركات وضع تدابير لمكافحة الاحتيال في حماية حقوق الملكية الفكرية؟	نحن ندرك أهمية عنوان IP كإشارة إلى جهود مكافحة عمليات الاحتيال في الويب اليوم. في إطار التزاماتنا بـ CMA (الفقرة 20)، وضّحنا أنّنا لن نطبّق حماية IP بدون بذل جهود معقولة لدعم قدرة المواقع الإلكترونية على تنفيذ جهود مكافحة المحتوى غير المرغوب فيه والاحتيال. من أهم أولوياتنا فهم كيفية تأثير حماية حقوق الملكية في حالات الاستخدام وإمكانات الكشف عن عمليات الاحتيال، كي نتمكّن من الاستثمار بشكل أكبر في تقنيات الحفاظ على الخصوصية التي تساعد الشركات في الحفاظ على أمان الويب. نشجّع على إرسال ملاحظات وتقديم اقتراحات جديدة تهدف إلى تلبية احتياجات الشركات في مجال الأمان ومكافحة الاحتيال، حتى مع تغيّر الإشارات بمرور الوقت.
الاحتيال وإساءة الاستخدام	هل تشمل الحماية من عناوين IP الحماية من الحرمان من الخدمات؟	نلتزم بتحسين الخصوصية مع الحفاظ على أمان الويب في الوقت نفسه، كما أن الحماية من هجمات الحرمان من الخدمات هي إحدى حالات الاستخدام المهمة لمكافحة إساءة الاستخدام. نأمل أن نحدّ من التأثير في إجراءات الحماية من الحرمان من الخدمات من خلال تصميم وسائل حماية الملكية الفكرية نفسها ومن خلال حلول جديدة لمكافحة إساءة الاستخدام. نظرًا لأن حماية IP تركّز في البداية على الخدمات المضمّنة التابعة لجهات خارجية، أشارت بعض الجهات المعنيّة إلى أنه يجب أن يكون لذلك تأثير محدود في حماية منع الخدمة للمواقع الإلكترونية التابعة للطرف الأول. ومع ذلك، نواصل طلب الحصول على ملاحظات علنية لتقييم المخاطر التي تهدد حالات استخدام الحرمان من الخدمات، وخاصةً الخدمات المضمَّنة التابعة لجهات خارجية. بالتزامن مع ذلك، نحن نستكشف آليات لتقديم ملاحظات عن إساءة استخدام وحظر العملاء من شأنها السماح للمواقع الإلكترونية أو الخدمات بحظر أي مستخدم غير مرغوب فيه بدون تحديد هويته.
تصفية المحتوى	فلترة المحتوى باستخدام حماية بروتوكول الإنترنت (IP)	لدى الشركات المختلفة احتياجات مختلفة فيما يتعلق بتصفية المحتوى وتخصيص تجربة المستخدم. ولا تعتمد العديد من حالات الاستخدام هذه على عناوين IP في الوقت الحالي، ومن ثم يجب ألا تتأثر بحماية IP. على سبيل المثال، قد يستخدم الناشر الذي يسعى إلى تخصيص المحتوى وزيادة التفاعل ملفات تعريف الارتباط للطرف الأول أو ملفات تعريف الارتباط المقسّمة التابعة لجهات خارجية (الشرائح) لفهم اهتمامات المستخدم وتفاعلاته السابقة مع الناشر. أو يمكن لشريك تكنولوجيا الإعلان الذي يركّز على عرض الإعلان المناسب للمستخدم المناسب دمج FLEDGE وTopics، على سبيل المثال، لتحقيق نتائج إعلانية مماثلة كما يحدث حاليًا باستخدام ملفات تعريف الارتباط التابعة لجهات خارجية أو غيرها من تقنيات التتبّع على المواقع الإلكترونية. نعمل أيضًا على استكشاف إمكانات جديدة للحفاظ على الخصوصية في إطار "حماية حقوق الملكية"، مثل رصد الموقع الجغرافي التقريبي، لتوفير مزيد من الدعم لفلترة المحتوى عندما لا تكون الآليات الحالية كافية. نرحب بملاحظات إضافية بشأن حالات استخدام فلترة المحتوى التي قد تتأثر بحماية IP.
(تم الإبلاغ أيضًا في الربع الثالث) حالات استخدام رصد الموقع الجغرافي	قد تمنع حماية بروتوكول IP حالات الاستخدام المشروعة لرصد الموقع الجغرافي في المستقبل، مثل تخصيص المحتوى استنادًا إلى رصد الموقع الجغرافي.	آخر المعلومات عن الربع الرابع من العام: نحن نعمل مع الجهات المعنيّة لضمان استمرار Chrome في إتاحة حالات الاستخدام المشروعة لعناوين IP. نتطلّع إلى تلقّي ملاحظات من المنظومة المتكاملة بشأن دقة رصد الموقع الجغرافي حسب عنوان IP هنا.

ميزانية الخصوصية

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

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

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

موضوع الملاحظات	ملخّص	استجابة Chrome
(تم الإبلاغ أيضًا في الربع الثالث)	طلب زيادة عدد النطاقات المرتبطة	تعديل في الربع الرابع من العام: لقد أطلقنا FPS للاختبار المحلي، بما في ذلك عملية إرسال مجموعة نموذجية على GitHub وعلامة لاختبار rSA وrSAFor على الجهاز. لقد استضفنا أيضًا اجتماعَين مفتوحَين لمطوّري البرامج حول FPS لمواصلة الإجابة عن الأسئلة المتعلّقة بحالات الاستخدام للمجموعة الفرعية المرتبطة بها. ونشجّع المطوّرين على اختبار وظائف الإطارات في الثانية لتقديم ملاحظات وآراء حول مدى تأثير حدّ النطاق للمجموعة الفرعية المرتبطة في سهولة استخدام هذه اللقطات في حالات الاستخدام. أوضحنا في مكالمات WICG أنّ Chrome ملتزم بتوفير حل قابل للاستخدام يأخذ في الاعتبار أيضًا اهتمامات الخصوصية للمستخدمين. وفي هذا الصدد، نشكرك على الملاحظات الواردة من المنتدى حول حالات استخدام معيّنة قد تتأثر بحدود النطاق، كي يتمكّن الفريق من التفكير في طرق للتعامل مع حالات الاستخدام هذه مع الاستمرار في حماية خصوصية المستخدم.
طلب المزيد من التفاصيل حول إجراءات الحدّ من إساءة الاستخدام	ماذا يحدث في حال إضافة نطاق إلى مجموعة لم يوافقوا عليها؟	لقد نشرنا إرشادات إرسال مجموعات نطاقات الطرف الأول هنا في 2 كانون الأول (ديسمبر) 2022. كما هو موضّح في إرشادات الإرسال، أي إدارة تغيير محدّدة ستتّبع عملية التحقق من الصحة على GitHub وتلتزم بها، بما في ذلك التحقق من الملكية، ما من شأنه أن يخفف من هذه المخاطر.
الحد من إساءة الاستخدام	القلق بشأن احتمال استغلال مجموعات نطاقات الطرف الأول	نحن نبحث عن طرق لتوسيع نطاق عمليات الفحص الفنية لأنواع المجموعات الفرعية ونسعى جاهدين إلى الحصول على ملاحظات إضافية من المنتدى هنا.
حالات استخدام الإعلانات	أسئلة حول ما إذا كان يجب استخدام مجموعات نطاقات الطرف الأول لإتاحة استهداف الإعلانات	لا نحاول إتاحة حالات استخدام استهداف الإعلانات لمجموعات نطاقات الطرف الأول، وننصح باستخدام واجهات برمجة تطبيقات "إعلانات Google" المتاحة لحالات الاستخدام هذه.
السياسة (تم الإبلاغ أيضًا في الربع الثالث)	القلق من أنّ عدد اللقطات في الثانية غير متوافق مع التزامات "هيئة حماية البيانات السارية" في ما يتعلّق بـ "تشريعات حماية البيانات السارية"، لأنّ "اللائحة العامة لحماية البيانات" لا تفرض حدًا على عدد المواقع الإلكترونية في المجموعة، بينما تشترط FPS تحديد 3 مواقع إلكترونية	لم يطرأ أي تغيير على ردّنا اعتبارًا من الربع الثالث: "تواصل Google الالتزام بـ CMA لتصميم اقتراحات "مبادرة حماية الخصوصية" وتنفيذها بطريقة لا تشوّه المنافسة من خلال الاختيار الذاتي للأنشطة التجارية الخاصة بشركة Google، ولمراعاة التأثير في الإعلانات الرقمية والناشرين والمعلنين، وكذلك التأثير على نتائج الخصوصية والامتثال لمبادئ حماية البيانات كما هو موضّح في "حماية البيانات السارية". ولا تفصح المشكلة المعنيّة عن أي عدم توافق مع "اللائحة العامة لحماية البيانات". نواصل العمل عن كثب مع CMA لضمان امتثال عملنا لهذه الالتزامات".
اقتراح بديل	المجموعات التي تم التحقّق من صحتها باللائحة العامة لحماية البيانات	بالإضافة إلى الملاحظات المقدَّمة من المنظومة المتكاملة بشأن اقتراح استخدام "المجموعات التي تم التحقّق من صحتها بموجب اللائحة العامة لحماية البيانات"، فإنّ Chrome لديه مخاوف بشأن القيود التالية المفروضة على هذا الاقتراح البديل: تدّعي "المجموعات التي تم التحقّق من صحتها باللائحة العامة لحماية البيانات" أنّها "متوافقة مع" اللائحة العامة لحماية البيانات (على الرغم من أنّ المقصود بذلك ليس واضحًا تمامًا). في المقابل، تتطلب التزامات Google أن تراعي "التأثير في نتائج الخصوصية" بشكل عام. وفي قرارها لقبول الالتزامات، تشير "هيئة حماية البيانات" إلى أنّ هذا يختلف عن التزام Google بمراعاة "الامتثال لمبادئ حماية البيانات على النحو المنصوص عليه في "تشريعات حماية البيانات السارية"، والذي يعكس حقيقة أنّ Google تلتزم بـ "تشريعات حماية البيانات السارية"، سواء من خلال تطبيقها على الالتزامات أو بشكل عام. لدينا مخاوف بشأن الخصوصية بشأن اقتراح السماح للنطاقات بالظهور في مجموعات متعددة. تهدف مجموعات الطرف الأول إلى دعم حالات استخدام معيّنة تعتمد حاليًا على ملفات تعريف الارتباط التابعة لجهات خارجية بدون تفعيل التتبُّع الواسع النطاق على مواقع إلكترونية متعددة. عند السماح للنطاقات بالانضمام إلى مجموعات متعدّدة، ستتم إزالة حماية الخصوصية الأساسية المضمَّنة في اقتراح مجموعات نطاقات الطرف الأول، بدون فرض أي قيود أخرى مفيدة. تقترح المجموعات التي تم التحقّق منها بموجب "اللائحة العامة لحماية البيانات" أيضًا "تحديد مجموعة كمجموعة من مسؤولي التحكّم بالبيانات ومعالجي البيانات الذين يتشاركون سياسة الاستخدام الشائع". يشبه هذا الشرط الوارد في اقتراحنا الأصلي الخاص بمجموعات نطاقات الطرف الأول والذي ينص على أنّ جميع الأطراف في المجموعة يجب أن تتشارك سياسة خصوصية مشتركة. ومنذ ذلك الحين، أزلنا هذا الشرط بناءً على ملاحظات وآراء كبيرة من المنظومة المتكاملة، ما يثير مخاوف بشأن المتطلبات المستندة إلى سياسة الخصوصية. على سبيل المثال، وصلتنا ملاحظات من ناشري المواقع الإلكترونية مفادها أنّه من غير الممكن الحفاظ على سياسة خصوصية مشترَكة بسبب الاختلافات في المنتجات والمواقع الجغرافية، بالإضافة إلى تحديات أخرى طرحها أعضاء منتدى W3C (1 و 2 و3). نحن نعتقد أن نفس التحديات ستنطبق على هذا الاقتراح. نظرًا لطرح هذا البديل، عدَّل Chrome اقتراح مجموعات نطاقات الطرف الأول ونشر إرشادات الإرسال لإنشاء مجموعات جديدة.

واجهة برمجة تطبيقات Fenced Frames

موضوع الملاحظات	ملخّص	استجابة Chrome
قيود Fenced Frames أثناء الوقت الإضافي	ما هي القيود الحالية بشأن Fenced Frames خلال الفترة التجريبية Origin؟	نعمل حاليًا على إعداد مستندات بشأن القيود وحالة التنفيذ ونخطط لمشاركتها خلال الربع الأول من عام 2023.
إعلانات متعددة في إطار واحد مضمّن مستقل	طلب عرض عدة معلِنين في إطار Fenced Frame واحد في مزاد واحد	لا يجري حاليًا تطوير هذا الطلب بشكل نشط، ولكننا نرحب بملاحظات إضافية إذا اعتبرت الجهات الفاعلة في المنظومة المتكاملة هذه الميزة مهمة.
حِزم الويب	ما هي المتطلبات والدعم المخطط له لحِزم الويب المزوّدة بإطارات Fenced Frame؟	ليس لدينا حاليًا معلومات عما إذا كان هذا الإجراء مطلوبًا في المستقبل أم لا. وسيتم الإعلان عن أي تغييرات مسبقًا، ولن يتم تنفيذها قبل إيقاف ملفّات تعريف الارتباط التابعة لجهات خارجية. يُرجى الاطّلاع على هذا الشرح لمعرفة الحالة الحالية.

واجهة برمجة تطبيقات مساحة التخزين المشتركة

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

الشرائح

موضوع الملاحظات	ملخّص	استجابة Chrome
(تم الإبلاغ أيضًا في الربع الثالث) المتطلبات المقسَّمة	أضِف شرط السلوك الصريح للسمة "مقسم" في ملفات تعريف الارتباط الخاصة بالطرف الأول.	تعديل الربع الرابع من العام: بعد مناقشات حول طلبات GitHub وPrivacyCG، تشير السلوك الذي اتفقنا إليه إلى أنّ ملفات تعريف الارتباط المقسَّمة التي تم ضبطها على ملفات تعريف الارتباط للطرف الأول ستستخدم مفتاح تقسيم (A، A) حيث يكون "A" هو الموقع الإلكتروني ذي المستوى الأعلى. سنوثِّق هذا السلوك في الشرح والمواصفات.
إدارة ملفات تعريف الارتباط	هل هناك أدوات لإدارة/التحكّم في ملفات تعريف الارتباط الخاصة بالطرف الأول أو الطرف الثالث؟	يمكن استخدام "أدوات مطوري البرامج في Chrome" و NetLog لاختبار المواقع الإلكترونية التي تم تفعيل حظر ملفات تعريف الارتباط التابعة لجهات خارجية فيها. وتُبلغ كلتا الأداتين عن الحالات التي يتم فيها حظر ملفات تعريف الارتباط بسبب إعدادات المستخدم. ونحن نرحب بملاحظاتك حول أي نوع من مواقع الويب الخاصة بالتدقيق الإضافية التي تود أن تراها.

FedCM

موضوع الملاحظات	ملخّص	استجابة Chrome
يتطلّب موفِّر الهوية معرفة الجهة المحظورة للسماح بالجلسة.	مشكلة عندما يحاول المستخدم تسجيل الدخول إلى موفِّر هوية Feide من جهة محظورة مختلفة	نناقش الحلول المحتملة لهذه المشكلة هنا.
إمكانية التشغيل التفاعلي	مخاوف بشأن تأثير برنامج FedCM على العلاقة بين المستخدمين والمواقع الإلكترونية التي يسجلون الدخول إليها باستخدام برنامج FedCM، و "إمكانية التشغيل التفاعلي" بين المواقع الإلكترونية	يهدف FedCM إلى مواصلة دعم خدمات الهوية الموحدة التي تعتمد حاليًا على ملفات تعريف الارتباط التابعة لجهات خارجية بعد إزالة ملفات تعريف الارتباط التابعة لجهات خارجية من Chrome. نتوقّع أن يكون برنامج FedCM خيارًا واحدًا فقط لهذه الخدمات، ويمكن لمزوّدي الهوية (IdP) والأطراف المعتمدة (RP) استخدام تقنيات أخرى قد تناسب احتياجاتهم بشكل أفضل. يبدو أنّ المخاوف المتعلّقة بالعلاقة بين المستخدم والجهة المحظورة و "إمكانية التشغيل التفاعلي" ترجع إلى سوء فهم اقتراح FedCM. يترك FedCM الأمر لموفِّري الهوية لتحديد المعلومات التي ستتم مشاركتها مع الجهة المحظورة، وبأي شكل منها، بمجرد أن يختار المستخدم تسجيل الدخول إلى الموقع الإلكتروني للجهة المحظورة تلك. لا يشترط برنامج FedCM على موفّري الهوية "إنشاء معرّف فريد بدون صاحبه لكل [RP] الذي يقوم المستخدم بالمصادقة معه". وبدلاً من ذلك، يُفتح برنامج FedCM لكل موفِّر هوية من أجل اختيار ما إذا كان يريد مشاركة المعرّف الفعلي للمستخدم أو نسخة من هذا المعرّف لكل موقع إلكتروني أو نسخة أخرى من هذه المعلومات. (تحدّد مواصفات برنامج FedCM الارتباط بين المواقع الإلكترونية باعتباره أحد مخاطر الخصوصية المرتبطة بواجهة برمجة التطبيقات، وتناقش المعرّفات الموجّهة (لكل موقع إلكتروني) كوسيلة ممكنة للتخفيف من حدة الأثر. ومع ذلك، يبقى قرار استخدام المعرّفات الموجّهة مفروضًا على موفِّري الهوية، ولا يفرضها المتصفّح). توفّر خدمة FedCM أيضًا إمكانية اختيار المستخدم في ما يتعلّق بالهوية. على سبيل المثال، في حال كان للمستخدم هويات متعددة بموفِّر الهوية نفسه (مثل الملف الشخصي للعمل والملف الشخصي)، يوفِّر برنامج FedCM طريقة للمستخدم لاختيار تلك التي يريد استخدامها لتسجيل الدخول إلى الموقع الإلكتروني للجهة المحظورة. بالإضافة إلى ذلك، يقرر كل جهة محظورة لنفسه موفِّري الهوية (IdP) الذين يريدون توفيره على موقعه الإلكتروني. أحد جوانب هذا القرار هو مراعاة الآلية التي يعتمد عليها موفِّر الهوية، سواء كانت في برنامج FedCM أو تقنية مختلفة. مرة أخرى، لا يملي المتصفِّح هذه الخيارات على الجهات المحظورة أو موفِّري الهوية.

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

واجهة برمجة التطبيقات للرموز المميّزة للحالة الخاصة

موضوع الملاحظات	ملخّص	استجابة Chrome
برامج التتبّع	ماذا يحدث إذا اكتشفت جهة الإصدار أنّه تم إصدار الرموز المميّزة للحالة الخاصة لبرامج التتبّع؟	لتجنُّب بقاء الرموز المميّزة التي يتم إصدارها لبرامج التتبّع في المنظومة المتكاملة لفترة طويلة، على جهات الإصدار تغيير المفاتيح التي تستخدمها لتوقيع الرموز المميّزة بانتظام حتى تنتهي صلاحية الرموز المميّزة القديمة التي يتم إصدارها بموجب منطق إصدار يُحتمَل أن يكون معطّلاً، وتسترد المواقع الإلكترونية رموزًا مميّزة جديدة باتّباع منطق الإصدار المعدَّل.
عمليات إرسال النماذج في الموقع الإلكتروني نفسه	هل يمكن استخدام الرموز المميّزة للحالة الخاصة لعمليات إرسال النماذج على الموقع الإلكتروني نفسه التي تتضمّن التنقّل في الصفحة الكاملة (أي نوع المحتوى: application/x-www-form-urlcipher) بدلاً من طلب من واجهات برمجة تطبيقات الجلب/XMLHttpRequest؟	هذا الإجراء غير متاح حاليًا في الإصدار الأول من الرموز المميّزة للحالة الخاصة. نرحّب بآراء المستخدمين من المنظومة المتكاملة إذا كان هناك طلب كبير على حالة الاستخدام هذه.
التحقّق من جهة الخادم	أسئلة حول ما إذا كان يمكن التحقّق من الرموز المميّزة للحالة الخاصة من جهة الخادم	يتم تحصيل قيمة الرموز المميّزة مقابل جهة الإصدار، ثم تنشئ جهة الإصدار سجلّ تحصيل القيمة الذي يمكن أن يحتوي على الرمز المميّز نفسه أو بعض القيم الموقَّعة المستمدة من الرمز المميّز. ويمكن للخوادم استخدام سجلّ تحصيل القيمة هذا لإثبات صحة الرمز المميّز، ونتوقّع أن تطرح الأنظمة المتكاملة لدى جهات الإصدار معايير مختلفة حول كيفية تفسير سجلات تحصيل القيمة.