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

تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

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

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

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

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

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

قد لا يتم النظر في الملاحظات التي يتم تلقّيها بعد انتهاء فترة إعداد التقارير الحالية.

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

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

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

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

وسيط عرض الطلب

FedCM

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

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

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

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

Interactive Advertising Bureau

IDP

موفِّر الهوية

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

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

عنوان IP

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

openRTB

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

الوقت بدل الضائع

فترة التجربة في Origin

PatCG

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

RP

جهة الاعتماد

SSP

وسيط عرض إعلانات المورّدين

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

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

UA

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

UA-CH

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

W3C

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

WIPB

إخفاء عناوين IP عن قصد

ملاحظات عامة، ما مِن واجهة برمجة تطبيقات/تقنية محدّدة

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

FLEDGE

موضوع الملاحظات	ملخّص	استجابة Chrome
مدير إعلانات Google	القلق من أنّ "مدير إعلانات Google" هو الجهة النهائية التي تحدّد مزادات FLEDGE، وأنّه سيفضّل علامات "ناشر Google" و"مدير إعلانات Google"	تسمح مبادرة FLEDGE لكل ناشر باختيار بنية المزاد، بما في ذلك اختيار بائعي المكونات والبائعين من المستوى الأعلى. يعرف كلّ من المشتري والبائع في مزاد المكوّنات هوية البائع من المستوى الأعلى، ويمكن لكلّ منهما اختيار تقديم عروض أسعار أو عدم تقديمها.
عدم توفّر عدد كافٍ من المشاركين في اختبار FLEDGE	طلب تشجيع المزيد من الشركات على اختبار FLEDGE، على سبيل المثال من خلال تحسين وظائف واجهة برمجة التطبيقات وتشجيع استخدام بدائل أقل انتهاكًا للخصوصية، مثل تقنية البصمة الرقمية	يتم تنفيذ "مبادرة حماية الخصوصية" على مراحل، وذلك في إطار شراكة وثيقة مع إرشادات هيئة المنافسة والأسواق (CMA) وهيئة حماية الخصوصية (ICO)، وقد أثبت اختبار FLEDGE الوظيفي الاستقرار والقدرة اللازمَين. تواصل Google تشجيع المنظومة المتكاملة على اختبار واجهات برمجة تطبيقات Sandbox، وقد نشرت مؤخرًا مستندات زيادة مدى صلة الإعلانات لعرض كيفية مساعدة FLEDGE وواجهات برمجة التطبيقات الأخرى في دعم حالات الاستخدام المهمة لصناعة الإعلانات بعد إيقاف ملفّات تعريف الارتباط التابعة لجهات خارجية نهائيًا. تتيح أجزاء أخرى من "مبادرة حماية الخصوصية" حاليًا إجراءات تخفيف لتغطية التتبّع (راجِع UA-CH وحماية عنوان IP وإجراءات تخفيف تتبُّع عمليات الارتداد)، وسنواصل تحسينها بمرور الوقت. لا يهدف فريق Google إلى جعل FLEDGE هو الحلّ الوحيد المتاح لاستهداف الإعلانات، بل يبقى ملتزمًا بالعمل بالشراكة مع الجهات التنظيمية في المجال لتقديم أفضل تقنيات الإعلانات التي تحافظ على الخصوصية في متصفّح Chrome.
حالات استخدام تعلُّم الآلة	مزيد من الإرشادات حول كيفية استخدام حالات تعلُّم الآلة لتدريب خوارزميات عروض أسعار المزاد في FLEDGE وتقارير تحديد المصدر	ندرك الحاجة إلى مساعدة المختبِرين في العثور على الطرق الأكثر فائدة لتطبيق تقنيات "مبادرة حماية الخصوصية". لقد بدأنا بنشر إرشادات متعلّقة تحديدًا باستخدام الجوانب المختلفة لواجهات برمجة تطبيقات "مبادرة حماية الخصوصية" كمدخلات لخدمة تعلُّم الآلة. تتناول المقالة الأخيرة، زيادة مدى صلة الإعلانات بالموضوع، كيفية استخدام مجال الإعلانات لهذه الإشارات في تعلُّم الآلة، ونخطّط لمواصلة نشر هذه الإرشادات من الآن فصاعدًا.
طلب البحث من خادم FLEDGE Key Value (K/V)	لماذا يمكن للجميع إجراء طلب بحث على خادم "مفتاح/قيمة"؟	يهدف خادم "مفتاح/قيمة" إلى تقديم إشارات في الوقت الفعلي لمزادات FLEDGE. وبالتالي، يجب أن يكون خادم "مفتاح/قيمة" متاحًا للوصول إليه من مكان تنفيذ مزادات FLEDGE، وهو على أجهزة المستخدمين، ما يتطلّب أن يكون متاحًا للجميع. لا يمكن لأيّ طرف استرداد قيمة مخزّنة في خادم "مفتاح/قيمة" إلّا إذا كان يمتلك المفتاح الخاص به. ولذلك، إذا كانت تقنية عرض الإعلانات لا تمنح المفاتيح إلّا للمتصفّحات التي تندرج ضمن "مجموعة الاهتمامات"، ولا تستخدم مفاتيح يمكن تخمينها بشكل عشوائي، لن يتمكّن من استردادها سوى المتصفّحات التي تحتاج إلى "القيمة" لتنفيذ مزاداتها.
كيف يمكنني الاستهداف حسب التاريخ أو الوقت؟	إتاحة عناصر التاريخ في دالة منطق عروض الأسعار	وهناك عدة طرق لإجراء ذلك. يمكن للمشترين أن يطلبوا من البائع تقديم التاريخ والوقت الحاليَين، ومن المفترض أن يكون من السهل على البائعين تقديم هذه المعلومات لجميع المشترين. يمكن للمشترين أيضًا تقديم التاريخ والوقت في ردّ مفتاح القيمة في الوقت الفعلي. أخيرًا، يمكن للمشترين تقديم التاريخ والوقت كجزء من الردّ السياقي في الإشارات لكلّ مشتري، والذي يمكن للبائع تمريره إلى نصّ generateBid الخاص بالمشتري.
الإعدادات المفضّلة للمستخدم	إمكانية اختيار المستخدمين حظر تصميمات الإعلانات حسب المعلِن عند عرضها من خلال FLEDGE أو حلول بديلة	يمكن للمستخدمين إيقاف واجهات برمجة تطبيقات "إعلانات Google" في Chrome. بالنسبة إلى إعلانات معيّنة، تكون تكنولوجيا الإعلان ذات الصلة هي الجهة الأنسب لتقديم عناصر تحكّم في المواد الإبداعية التي يتم عرضها أو كيفية اختيارها.
مخططات زمنية أكثر وضوحًا	طلب الحصول على مزيد من المعلومات حول مدى توفّر إجراءات حماية الخصوصية في FLEDGE، مثل طلب استخدام "الإطارات المحدود"	نخطّط لنشر مخططات زمنية أكثر تفصيلاً في الربع الأول من العام.
الارتباك في الإبلاغ	طلب الحصول على مزيد من الوضوح حول كيفية عمل تقارير 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 وتحديد نطاق تدريب نماذج الذكاء الاصطناعي، ونرحّب بآرائك الإضافية حول هذا الموضوع.
إتاحة استخدام منصّات عرض الإعلانات المتعدّدة	كيف سيتمّ إتاحة منصّات عرض الإعلانات المتعدّدة في FLEDGE؟	تتيح FLEDGE مزادات متعددة البائعين كما هو موضّح في هذا الاقتراح.
مستوى ظهور منطق عروض الأسعار	القلق من أنّه سيتم عرض منطق عروض الأسعار في نظام إدارة الطلبات في JavaScript	بموجب منطق عروض الأسعار الحالي للتصميم، يمكن للآخرين الوصول إلى JavaScript، ولكننا نرحب بمزيد من الملاحظات حول سبب قلق منصّات عرض الإعلانات من ذلك.
prebid.js	ما هو المخطط الزمني لدعم prebid.js في FLEDGE؟	لا تتيح سوى الإصدارات 7.14 والإصدارات الأحدث من Prebid.js استخدام وحدة FLEDGE. على أيّ ناشر مهتم بالاختبار إضافة وحدة FLEDGE وترقية مثيل Prebid.
الدوالّ المحدَّدة من قِبل المستخدِم في FLEDGE	كيف سيتمّ توفير الدوالّ المعرَّفة من قِبل المستخدِم (UDF) في FLEDGE؟ هذه هي الوظائف التي يمكن للمستخدمين النهائيين برمجةها لتوسيع وظائف واجهة برمجة التطبيقات.	يتوفّر شرح هنا. لا يزال هذا الإجراء قيد التطوير، لذا نرحب بملاحظاتك الإضافية حول حالات الاستخدام.
تخفيف قيود المصدر نفسه على موارد "المجموعات ذات الاهتمامات المشتركة"	طلب إزالة قيود المصدر نفسه على موارد "مجموعة الاهتمامات" لتفعيل حالات استخدام معيّنة لتكنولوجيا الإعلان	في التنفيذ الحالي لواجهة برمجة التطبيقات FLEDGE، يجب أن يكون لكل من biddingLogicUrl وbiddingWasmHelperUrl وdailyUpdateUrl وtrustedBiddingSignalsUrl المصدر نفسه الخاص بمالك مجموعة الاهتمامات. يهدف هذا القيد إلى منع المهاجمين من تنفيذ بعض عمليات الاستيلاء، كما هو موضّح هنا.
interestGroup Ownership	طلب تقييد ما إذا كان بإمكان تكنولوجيا الإعلان استخدام joinInterestGroup لمجموعات الاهتمامات نفسها على مستوى المواقع الإلكترونية	نركّز على كيفية استخدام شرائح الجمهور، وليس على كيفية إنشائها. نحن نناقش الأساليب المحتملة ونرحّب بملاحظاتك الإضافية.
انتهاء صلاحية مفتاح خادم "مفتاح/قيمة"	مناقشة حول إزالة مفاتيح الخادم بعد انتهاء صلاحية مجموعات الاهتمامات المقابلة	نحن بصدد استكشاف طرق للتعامل مع انتهاء صلاحية المفاتيح ونبحث عن ملاحظات.

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

تقارير تحديد المصدر (وواجهات برمجة التطبيقات الأخرى)

موضوع الملاحظات	ملخّص	استجابة Chrome
عدد زيارات مرحلة التجربة والتقييم	لا تكفي زيارات "الإصدار التجريبي من المصدر" الحالية لإجراء اختبار الأداة.	تهدف تجارب Origin الحالية إلى أن يجري اللاعبون في المنظومة المتكاملة اختبارًا وظيفيًا لضمان عمل واجهة برمجة التطبيقات على النحو المطلوب. ندرك أنّه ستُستخدَم أعداد أكبر من الزيارات لإجراء اختبار الأداة بعد أن يكتمل تطوير واجهات برمجة التطبيقات المختلفة في "مبادرة حماية الخصوصية". يتوقّع المخطط الزمني الحالي للاختبار أن يحدث ذلك بحلول وقت التوفّر العام (أي عندما يتم إطلاق تقنيات حالات الاستخدام وتصبح متاحة بنسبة% 100 من عدد زيارات Chrome) في الربع الثالث من عام 2023 (اطّلِع على المخطط الزمني المحدَّث على privacysandbox.com). نرحب بأي ملاحظات إضافية حول اختبار حالات الاستخدام التي تتطلّب عدد زيارات إضافيًا.
تداخل في وظائف واجهات برمجة التطبيقات المختلفة لقياس أداء "مبادرة حماية الخصوصية"	ستزيد المخاوف من تداخل أساليب القياس المتعدّدة من خلال "مبادرة حماية الخصوصية" من التعقيد، على سبيل المثال، Attribution Reporting API وPrivate Aggregation API.	نعمل على توفير مستندات أفضل لتوضيح حالات الاستخدام المختلفة لواجهات برمجة التطبيقات، ونرحب بملاحظات إضافية حول الجوانب التي لا تتوفّر لها شرح. على سبيل المثال، تهدف Attribution Reporting API إلى توفير إمكانية قياس الإحالات الناجحة على وجه التحديد، في حين أنّ Private Aggregation API وShared Storage هما واجهات برمجة تطبيقات للأغراض العامة تهدف إلى توفير إمكانية استخدام مجموعة أكبر من حالات قياس الأداء على مستوى المواقع الإلكترونية.
إعادة محاولة طلب التقرير الذي تعذّر إكماله	توضيح حول عدد المرات التي تتم فيها محاولة إرسال طلب الإبلاغ في حال تعذّر إرسال الطلب	لقد نشرنا إرشادات حول هذا الموضوع. باختصار، لا يتم إرسال التقارير إلا عندما يكون المتصفّح قيد التشغيل/متصلاً بالإنترنت. بعد المحاولة الأولى غير الناجحة لإرسال التقرير، تتم إعادة المحاولة بعد 5 دقائق. بعد المحاولة الثانية غير الناجحة، تتم إعادة إرسال التقرير بعد 15 دقيقة. وبعد ذلك، لا يتم إرسال البلاغ.
تأخير الإبلاغ	ما هو التأخير المتوقّع في إعداد التقارير؟	نسعى إلى سماع المزيد من الملاحظات من المنظومة المتكاملة بشأن أي تأخيرات في إعداد التقارير تواجهها أثناء جمع البيانات لتقييم هذه التأخيرات بشكل موازٍ.
صفحات العرض المُسبَق	هل سيعمل تحديد المصدر بالاستناد إلى الإحالات الناجحة على صفحات التقديم المُسبَق؟	يتم تأجيل تسجيل عملية الإحالة في صفحات التقديم المُسبَق إلى أن يتم التفعيل (أي حدوث النقرة أو العرض الفعلي). وهذا يعني أنّنا سنؤجل إرسال طلب "attributionsrc".
قياس تأثير الإعلانات	كيفية قياس زيادة الإحالات الناجحة باستخدام اختبار أ/ب على النطاق نفسه	يمكن للمواقع الإلكترونية قياس ارتفاع الإحالات الناجحة باستخدام اختبار أ/ب على النطاق نفسه من خلال تقارير تحديد المصدر. ويمكنهم ترميز مَعلمات اختبار أ/ب كمفاتيح باستخدام واجهة برمجة التطبيقات المجمّعة، ثمّ تلقّي تقارير تلخيصية لقيم الإحالات الناجحة حسب مجموعات المفاتيح هذه.
(تم الإبلاغ عنها أيضًا في الربع الثالث) الإحالات الناجحة على مستوى نطاقات متعددة	كيفية تتبُّع الإحالات الناجحة على مستوى نطاقات متعددة، مثل وجهتَين أو أكثر	تعديل في الربع الرابع: نشرنا اقتراحًا لإزالة القيود المفروضة على وجهات الصفحة المقصودة، ما يتيح تتبُّع المحادثات على مستوى النطاقات. تم تنفيذ هذا الاقتراح.
(تم الإبلاغ عن ذلك أيضًا في الربع الثالث) إعدادات انتهاء الصلاحية في تقرير الإحالات الناجحة	طلب إتاحة فلترة التقارير أو انتهاء الصلاحية لمدة أقل من 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. لدينا بعض الأدلّة على أنّه تمّ نشر وحدات تحليلات Universal Analytics للموقع الإلكتروني (UA-CH) وأنّها متاحة حاليًا، كما هو موضّح في مقالة مدوّنة Scientia Mobile التي توضّح كيفية استخدام UA-CH وWURFL API لإنشاء وحدة تحليلات Universal Analytics للموقع الإلكتروني.

###

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

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

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

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

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

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

تعزيز حدود الخصوصية على جميع المواقع

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

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

Fenced Frames API

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

Shared Storage API

موضوع الملاحظات	ملخّص	استجابة Chrome
مساحة التخزين المشتركة لتكنولوجيا الإعلان	عدم اليقين المحيط باستخدام مساحة التخزين المشتركة في حالات استخدام تقنية الإعلان	يمكن استخدام Shared Storage وPrivate Aggregation API لأنواع مختلفة من أغراض القياس التي تتطلّب قياس مساحة التخزين على مستوى المواقع الإلكترونية. يمكنك الاطّلاع على بعض الأمثلة هنا. نتوقع أن يكون مزوّدو منصّات إدارة الأداء وحلول القياس هم الجهة المدمجة الرئيسية لحالات استخدام الإعلانات.

CHIPs

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

FedCM

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

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

Private State Token API

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