تقرير ربع سنوي للربع الأول من عام 2025 يلخّص الملاحظات التي تمّ تلقّيها من المنظومة المتكاملة بشأن اقتراحات "مبادرة حماية الخصوصية" وردّ Chrome عليها.
أعدّت Google هذا التقرير الربع سنوي كجزء من التزاماتها تجاه هيئة المنافسة والأسواق (CMA) بموجب الفقرات 12 و17(ج)(2) و32(أ). يتناول هذا التقرير مستوى تقدّم Google في ما يتعلّق باقتراحات "مبادرة حماية الخصوصية"، وتوقّعات التوقيت المعدّلة، وتفسيرات جوهرية حول كيفية أخذ Google في الاعتبار الملاحظات التي أدلى بها أطراف ثالثة، وملخّصًا للتفاعلات بين Google وهيئة CMA، بما في ذلك الملاحظات الواردة من هيئة CMA وطريقة Google في التعامل مع هذه الملاحظات.
تُطلع Google هيئة CMA على آخر المعلومات المتعلّقة بتقدّم اقتراحات "مبادرة حماية الخصوصية" في اجتماعات الحالة العادية التي يتم تحديد موعدها وفقًا للفقرة 17(ب) من "الالتزامات". بالإضافة إلى ذلك، يحافظ الفريق على مستندات المطوّرين التي تقدّم نظرة عامة على ميزات الإعلانات الخاصة الأساسية وتغييرات ملفات تعريف الارتباط، بالإضافة إلى تنفيذ واجهة برمجة التطبيقات ومعلومات الحالة. تتم مشاركة آخر الأخبار المهمة على مدوّنة المطوّرين، بالإضافة إلى آخر الأخبار المستهدفة التي تتم مشاركتها مع قوائم المطوّرين البريدية الفردية.
مسرد الاختصارات
- ARA
- Attribution Reporting API
- ملفات تعريف الارتباط في الحالة المقسَّمة المنفصلة (CHIPS)
- ملفات تعريف الارتباط في الحالة المقسَّمة المنفصلة
- معالِج الإشارات الرقمية (DSP)
- وسيط عرض الطلب
- FedCM
- إدارة بيانات الاعتماد الموحّدة
- مكتب الإعلانات التفاعلية (IAB)
- Interactive Advertising Bureau
- IDP
- موفِّر الهوية
- مجموعة مهندسي شبكة الإنترنت (IETF)
- مجموعة مهندسي شبكة الإنترنت
- عنوان IP
- عنوان بروتوكول الإنترنت
- openRTB
- عرض الأسعار في الوقت الفعلي
- الوقت بدل الضائع
- فترة التجربة في Origin
- PA API
- Protected Audience API (المعروفة سابقًا باسم FLEDGE)
- PatCG
- مجموعة منتدى تكنولوجيا الإعلانات الخاصة
- RP
- جهة الاعتماد
- RWS
- مجموعات المواقع الإلكترونية المرتبطة (المعروفة سابقًا باسم "مجموعات نطاقات الطرف الأول")
- SSP
- وسيط عرض إعلانات المورّدين
- UA
- سلسلة وكيل المستخدم
- UA-CH
- تعديلات برنامج وكيل المستخدم
- W3C
- اتحاد شبكة الويب العالمية
- WIPB
- إخفاء عناوين IP عن قصد
ملاحظات عامة، ما مِن واجهة برمجة تطبيقات/تقنية محدّدة
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| خيار المستخدم | من غير الواضح كيف سيبدو نهج Google المعدَّل لتعزيز خيار المستخدم، وكيف سيتم تقديمه للمستخدمين، ومعدّلات الموافقة أو الإيقاف المتوقّعة. يجب تقديم مزيد من المعلومات لتمييز ذلك عن الإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية. | في نيسان (أبريل) 2025، نشرت Google منشور مدوّنة حول الخطوات التالية بشأن "مبادرة حماية الخصوصية" ووسائل الحماية من التتبّع في Chrome، معلِنةً أنّ Google اتّخذت قرارًا بالاحتفاظ بالنهج الحالي لتقديم ملفات تعريف الارتباط التابعة لجهات خارجية في Chrome، ولن يتم طرح إشعار مستقل جديد بشأن ملفات تعريف الارتباط التابعة لجهات خارجية. سنشارك المزيد من المعلومات عند توفّرها. |
| البصمات الرقمية | لم تشارك Google أي معلومات مع الناشرين أو جهات التسويق حول كيفية الاعتماد على أي بدائل لأنظمة Google الإعلانية بدون استخدام هوية المستهلك الأكثر خطورة كمفتاح مطابقة شائع (أي بصمة رقمية). | لقد سلّطنا الضوء على العديد من أنظمة الإعلانات غير التابعة لشركة Google التي توفّر حلولاً للناشرين وجهات التسويق، وهي حلول تستند جزئيًا إلى واجهات برمجة تطبيقات "مبادرة حماية الخصوصية". ويشمل ذلك أنظمة الإعلانات التي لا تتبع Google في جميع الأسواق والقنوات. تتوفّر المزيد من التفاصيل ودراسات الحالة في قسم "موارد الأنشطة التجارية" على privacysandbox.com هنا. |
| مبادرة حماية الخصوصية | ستستبدِل واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" مكوّنات بيانات الإنترنت بمنتجات Google النهائية. بما أنّ البديل الذي تقدّمه Google هو واجهة برمجة تطبيقات، فإنّها توفّر إمكانية الوصول إلى منتج تملكه وتتحكم فيه، وهو منتج يخضع لبنود وشروط تملك Google السلطة التقديرية بشأنها. ولا يشكّل ذلك بديلاً عن المكوّنات التي يستخدمها الآخرون لصنع منتجاتهم النهائية. | تم تطوير واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" وتنفيذها بعد تفاعل مكثّف مع الجهات التنظيمية ومجموعة كبيرة من الجهات المعنيّة بالمنظومة المتكاملة. كما هو الحال مع تقنيات المنصات الأخرى، يجب أن تأخذ واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" في الاعتبار أنّه سيتم استخدامها كمكوّنات في المنتجات النهائية التابعة لجهات أخرى، ونرحب بجهود المنظومة المتكاملة لتطوير تقنيات إضافية للعمل جنبًا إلى جنب مع واجهات برمجة تطبيقات "مبادرة حماية الخصوصية". |
| خيار المستخدم | طلب الحصول على معلومات حول ما إذا كان النهج المعدَّل الذي تتّبعه Google بشأن ملفات تعريف الارتباط التابعة لجهات خارجية على Chrome سيستوفي متطلبات تنظيمية معيّنة، ما قد يؤثر في تجربة المنصة لإدارة موافقة الجهات المعنية | في نيسان (أبريل) 2025، نشرت Google منشور مدوّنة حول الخطوات التالية بشأن "مبادرة حماية الخصوصية" ووسائل الحماية من التتبّع في Chrome، معلِنةً أنّ Google اتّخذت قرارًا بالاحتفاظ بالنهج الحالي لتقديم ملفات تعريف الارتباط التابعة لجهات خارجية في Chrome، ولن يتم طرح إشعار جديد مستقل عن ملفات تعريف الارتباط التابعة لجهات خارجية. سنشارك المزيد من المعلومات عند توفّرها. |
| المخطط الزمني لـ "مبادرة حماية الخصوصية" واستخدامها | أوقفت تكنولوجيات الإعلان اختبار واجهات برمجة التطبيقات في "مبادرة حماية الخصوصية" مؤقتًا وتبحث عن أسباب أقوى لإعادة الاستثمار في هذه التقنيات لأنشطة المنتجات والتسويق. وتتأثر قرارات إعادة الاستثمار هذه بشكل كبير بالحاجة إلى مزيد من الوضوح بشأن المخطط الزمني لميزة "خيار المستخدِم"، بالإضافة إلى المخاوف بشأن وقت استجابة Protected Audience API (PA API) وخارطة الطريق المتعلّقة بميزة "الموافقة والامتناع". بالإضافة إلى ذلك، هناك مخاوف بشأن المراجعة القادمة لالتزامات هيئة المنافسة والأسواق (CMA)، لا سيما بشأن دور Google كمحرك أساسي لتكنولوجيات "مبادرة حماية الخصوصية" بدون الاعتماد على معرّفات الجهات الخارجية، والاتجاه المستقبلي العام للمبادرة لتوجيه استراتيجيات الاستثمار. | في نيسان (أبريل) 2025، نشرت Google منشور مدوّنة حول الخطوات التالية بشأن "مبادرة حماية الخصوصية" ووسائل الحماية من التتبّع في Chrome، معلِنةً أنّ Google اتخذت قرارًا بالاحتفاظ بالنهج الحالي لتقديم ملفات تعريف الارتباط التابعة لجهات خارجية في Chrome، ولن يتم طرح إشعار مستقل جديد بشأن ملفات تعريف الارتباط التابعة لجهات خارجية. سنشارك المزيد من المعلومات عند توفّرها. أصبحت مزادات Chrome PA API أسرع بنسبة% 35 مقارنةً بالعام السابق. بالإضافة إلى ذلك، لاحظنا زيادة كبيرة في استخدام المزادات المجمّعة، ما يحقّق مكاسب أكبر لهذه المزادات. يمكنك الاطّلاع على خارطة الطريق الحالية لميزة "الإعلانات" و"الحملات" هنا. |
| المخطط الزمني لـ "مبادرة حماية الخصوصية" | ما الذي تم تعديله في صفحة "المخطط الزمني لمبادرة حماية الخصوصية"؟ | تمت مؤخرًا إضافة نظرة عامة على Topics API إلى صفحة "المخطط الزمني لمبادرة حماية الخصوصية". |
| مبادرة حماية الخصوصية | هل هناك أي أوراق بحثية حول الخصوصية مقابل الفائدة للمساعدة في فهم تأثير "مبادرة حماية الخصوصية" في الأرباح؟ | تتوفّر هنا دراسات السوق ذات الصلة التي تتناول هذه الأسئلة، وتتوفّر هنا نتائج اختبار واجهات برمجة التطبيقات في "مبادرة حماية الخصوصية". |
| استخدام "مبادرة حماية الخصوصية" | أبلغ أحد المستخدمين الأوائل عن تحديات أولية في واجهات برمجة التطبيقات في "مبادرة حماية الخصوصية" بسبب الاعتماد البطيء من قِبل الشركات الأكبر حجمًا، ما يؤثّر في عمليات الإطلاق التجريبية. ومع ذلك، تم تقدير النهج التعاوني لفريق "مبادرة حماية الخصوصية" والاستجابة للملاحظات. | نحن نقدّر ملاحظات المستخدمين الأوائل. نحن ملتزمون بالتعاون مع المستخدمين الأوائل، وسنواصل التفاعل مع المنظومة المتكاملة وجمع الملاحظات أثناء تقييم دور تقنيات "مبادرة حماية الخصوصية" في دعم المنظومة المتكاملة. |
| اختبار Chrome | القلق بشأن إمكانية مواصلة اختبار "مبادرة حماية الخصوصية" بفعالية بعد إزالة تصنيفات الاختبار التي تُبرز اختلافًا كبيرًا في جودة الزيارات بين متصفّح Chrome الذي تم إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية فيه (الوضع ب) والمستخدمين الذين أوقفوا ملفات تعريف الارتباط التابعة لجهات خارجية بأنفسهم في إعدادات Chrome | ردّنا مشابه للردّ الذي قدّمناه في الربع الأول: يتفهّم فريق "مبادرة حماية الخصوصية" أنّ الشركات تريد مواصلة استخدام تصنيفات إيقاف ملفات تعريف الارتباط نهائيًا. تشبه عملية تمديد مدى توفّر التصنيفات عملية تمديد مرحلة التجربة والتقييم. تم تمديد فترة استخدام التصنيفات في عدة مناسبات. ننوي اقتراح توسيع نطاق التوافق مع تصنيفات إيقاف ملفات تعريف الارتباط نهائيًا، وسنشارك آخر الأخبار على blink-dev عند توفّرها. |
التسجيل والإقرار
لم يتم تلقّي أي ملاحظات هذا الربع.
عرض المحتوى والإعلانات ذات الصلة
المواضيع
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| تفعيل الميزة أو إيقافها | هل سيؤدي تأكيد Google بأنّ "بحث Google" لن يستخدم قرار الموقع الإلكتروني بإيقاف Topics API كإشارة لترتيب نتائج البحث إلى منع Google من استخدام قرار الموقع الإلكتروني بالموافقة على Topics API كإشارة لترتيب نتائج البحث؟ | لا يختلف ردّنا عن الردود التي قدّمناها في الربع سنوية السابقة: لم ينسق فريق "مبادرة حماية الخصوصية" مع فريق "بحث Google" أو يطلب منه استخدام ترتيب الصفحة كحافز للمواقع الإلكترونية على استخدام Topics API. لن يستخدم محرّك بحث Google قرار الموقع الإلكتروني بتفعيل واجهة برمجة التطبيقات Topics API (أو عدم تفعيلها) كمؤشر لترتيب نتائج البحث. |
| إمكانية تتبُّع الاستخدام | طلب آلية مراقبة لوسيط عرض إعلانات مورّدين أو تكنولوجيا إعلانية عامة لمعرفة ما إذا كان يتم استخدام تنفيذ Topics API على الويب | نحن بصدد تقييم إمكانية توفير هذه الوظيفة، ونرحب بملاحظات إضافية من المنظومة المتكاملة إذا كانت هذه الميزة ذات أولوية عالية. |
| الخصوصية | أسئلة حول الموافقة وإمكانية إعادة تحديد الهوية | نحن نناقش حاليًا هذه المشكلة هنا ونرحّب بملاحظات إضافية. |
Protected Audience API
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| PA API و"مدير إعلانات Google"/AdX | لن ترسل Google أيّ طلب من "مدير إعلانات Google" أو AdX إلى ناشر يريد الاعتماد على خادم إعلانات ناشر منافس. على Google السماح للناشرين المنافسين باختيار بائعي مزادات PA API بديلة من المستوى الأعلى للتحكّم في المزاد النهائي. ستكون المعلومات الواردة من PA API متاحة لخدمة "مدير إعلانات Google"، ولكن سيتم حظرها على منصّات عرض الإعلانات المنافسة. نتيجةً لذلك، لا يتمكّن الناشرون من مقارنة أداء الطلبات المستندة إلى PA API في "مدير إعلانات Google"، مثل الطلبات الواردة من AdX أو من منصّات عرض الإعلانات المدمجة في PA API. | ردّ Chrome: تم تصميم معيار PA API ليكون مرنًا ويسمح لجهات مختلفة بإجراء المزاد على المستوى الأعلى. يعتمد هذا الاختيار على عمليات التنفيذ والإمكانات المحدّدة التي يوفّرها خادم إعلانات الناشر (سواء كان "مدير إعلانات Google" أو غيره) والشركات الأخرى المشاركة في المنظومة المتكاملة. يحدّ التصميم المرتكز على الخصوصية في PA API من إعداد التقارير الدقيقة لجميع المشاركين بشكلٍ متسق. تخضع البيانات المحدّدة التي يتم الإبلاغ عنها من مزاد Protected Audience API نفسه للقواعد والقيود نفسها التي تحدّدها واجهة برمجة التطبيقات للحفاظ على الخصوصية لجميع المشاركين، بما في ذلك أيّ منصّات عرض إعلانات. يستخدم الناشرون التقارير المجمّعة التي تحافظ على الخصوصية في PA API لتقييم الأداء. يتيح ذلك تقييم المساهمة الإجمالية للطلب الذي يتم الحصول عليه من خلال PA API، كما يتيح المقارنة مع قنوات الطلب الأخرى، بما يتوافق مع مبادئ الخصوصية من خلال التصميم في واجهة برمجة التطبيقات. الردّ المقدَّم من "مدير إعلانات Google": ليس على الناشرين استخدام وظيفة خادم الإعلانات في "مدير إعلانات Google" للوصول إلى طلب AdX. بالإضافة إلى ذلك، لا تعتمد واجهة برمجة التطبيقات PA API على هوية مَن يبدأ المزاد، سواء في تصميمات البائع الفردي أو البائعين المتعدّدين. |
| البائع من المستوى الأعلى | يمكن للبائع من المستوى الأعلى (TLS) الوصول إلى معلومات لا يمكن لأي من بائعي المكوّنات الآخرين الوصول إليها، ما يثير المخاوف بشأن الوصول غير المتكافئ إلى المعلومات. على الرغم من أنّ أيّ كيان يمكن أن يكون TLS، إلا أنّه على الناشرين استخدام "مدير إعلانات Google" كسجّان إعلانات الناشر للوصول إلى طلب AdX. ويؤدي ذلك إلى توفير حافز لاستخدام "مدير إعلانات Google" كسجّان إعلانات الناشر، ما يمنح Google ميزة تنافسية. | ردّ Chrome: لا يحدّد تصميم واجهة برمجة التطبيقات PA API الكيان الذي يمكنه العمل كخدمة TLS. يتطلّب دور TLS تنسيق المزاد والوصول إلى معلومات المزاد ذات الصلة وفقًا لبنية واجهة برمجة التطبيقات. الردّ المقدَّم من "مدير إعلانات Google": لقد حافظنا على تركيز قوي على نزاهة المزاد لعدّة سنوات، بما في ذلك وعدنا بعدم مشاركة أي سعر من أيّ من مصادر الإعلانات غير المضمونة للناشر، بما في ذلك أسعار العناصر غير المضمونة، مع مشتري آخر قبل تقديم عروض أسعاره في المزاد، وهو ما أكدتّه لاحقًا في التزاماتنا أمام هيئة المنافسة الفرنسية. بالنسبة إلى مزادات PA API، ننوي الوفاء بوعودنا وعدم مشاركة عرض سعر أيّ مشارك في المزاد مع أيّ مشارك آخر في المزاد قبل إكمال المزاد في المزادات التي تضمّ بائعين متعدّدين. للتوضيح، لن نشارك سعر المزاد السياقي مع أي مزاد مكوّن، بما في ذلك المزاد الخاص بنا، كما أوضحنا في هذا التعديل. بالإضافة إلى ذلك، لا نستخدم معلومات عن إعدادات مزادات المكوّنات، بما في ذلك الإشارات التي يقدّمها المشترون إلى منصّات عرض الإعلانات (SSP)، كجزء من مزادنا الخاص. بالإضافة إلى ذلك، كما هو موضّح أعلاه، لا تتطلّب "إدارة الأداء من Google" من الناشرين استخدام وظيفة خادم الإعلانات من أجل الوصول إلى طلب AdX. أخيرًا، كما سبق أن ذكرنا في تقرير Google عن الربع الثاني أو الثالث من عام 2024، تشتري منصات Google في جهة الشراء، أي "إعلانات Google" (المعروفة سابقًا باسم AdWords) و"مساحة العرض 360"، مرّات الظهور من تبادلات غير تابعة لشركة Google، بما في ذلك من خلال PA API. |
| PA API و"مدير إعلانات Google"/AdX | من الصعب على الناشرين فهم تفعيل PA API على 100% من المستودع الإعلاني لأنّ تصنيف الخيار لا يوضّح الغرض. بالنسبة إلى منصّات عرض الإعلانات التي تعتمد في أغلب الأحيان على مزاد متعدد المستويات مع استخدام "مدير إعلانات Google" كنظام إدارة عروض الأسعار، لا تتوفّر طريقة لإجراء الاختبارات أو تحقيق الربح من خلال PA API بدون الخضوع لإدارة إعلانات Google. | ردّ Chrome: يحدّد معيار PA API الأدوار الفنية (مثل بروتوكول أمان طبقة النقل وبائع المكوّنات) وعملية المزاد، ما يسمح بالمرونة في تحديد المنصات التي تؤدي هذه الأدوار. تُدار الأنشطة التشغيلية، مثل الضبط والتنسيق والاتفاقيات، من قِبل الجهات المنفّذة (الناشرون وخدمات عرض الإعلانات ومزودي بروتوكول أمان طبقة النقل) لتسهيل المشاركة باستخدام إطار عمل PA API. الردّ المقدَّم من "مدير إعلانات Google": كما هو موضّح في مركز المساعدة، يقدّم "مدير إعلانات Google" للناشرين عنصر تحكّم لتفعيل الاختبار مع بائعي المكوّنات غير التابعين لشركة Google، مثل منصّات عرض الإعلانات الأخرى، على 100% من مستودع الناشر حيث تتوفّر واجهة برمجة التطبيقات لاستخدامها (مع إلغاء أيّ تحليل عينات أو تقييد قد يطبّقه "مدير إعلانات Google"). إذا فعّل الناشر عنصر التحكّم هذا، سيحاول "مدير إعلانات Google" إجراء مزاد على مستوى أعلى مع تضمين مزاد المكوّنات المقدَّم، وذلك في حال قدّم بائع مكوّنات غير تابع لشركة Google إعدادات مزاد، شرط أن يحصل الناشر على موافقة المستخدِم اللازمة لإجراء ذلك. ويوضّح "مدير إعلانات Google" للناشرين أنّ عنصر التحكّم هذا قد يؤثر في الأداء، كي يتمكّن الناشر من اتخاذ قرار مدروس. |
| المعالجة من جهة الخادم في مقابل المعالجة على الجهاز | يمكن أن تساهم الحلول من جهة الخادم، مثل عروض الأسعار والمزادات، في حلّ مشكلة تشكيل الزيارات مع الحفاظ على الخصوصية. إنّ الحلول من جهة الخادم هي المسار الوحيد القابل للتطبيق، ويجب أن تتخلّى Google عن الحلول على الجهاز. | تهدف "مبادرة حماية الخصوصية" إلى توفير حلول للعروض على كلّ من الخادم (خدمات B&A) والأجهزة، ما يقدّم خيارات لتلبية احتياجات تكنولوجيا الإعلانات وحالات الاستخدام المختلفة. |
| أمان المزاد | تؤدي الهجمات على عروض أسعار PA API إلى استبعادها بشكل أساسي من عروض الأسعار والمزادات على الجهاز، ولا يعتقد أصحاب المصلحة أنّ هذه المشكلة قد تم حلّها، ويواصلون طلب ضمانات فنية لضمان عدم التلاعب بعروض أسعار PA API، بالإضافة إلى وضع تصحيح أخطاء شامل لتوفير ميزة رصد الحوادث في الوقت الفعلي وتصحيح الأخطاء بكفاءة. | إنّ ضمان سلامة مزاد Protected Audience API، بما في ذلك الحدّ من الهجمات المحتملة، هو أحد التركيزات الرئيسية في "مبادرة حماية الخصوصية". يتضمّن تصميم واجهة برمجة التطبيقات إجراءات للحفاظ على السلامة، ونرحب بمزيد من المناقشات الفنية حول مخاوف محدّدة. قدّمنا قائمة تفصيلية بالهجمات المحتملة على PA API وناقشناها خلال اجتماع مجموعة مكافحة الاحتيال في W3C في أيار (مايو) 2024. نرحب بمزيد من المناقشات والملاحظات حول "الهجمات المحتملة على عروض أسعار PA API" التي تثير القلق. |
| الزيارات بدون ملفات تعريف الارتباط | هل ستكون هناك طريقة لتفعيل PA API فقط على الزيارات التي لا تتضمّن ملفات تعريف الارتباط لأغراض الاختبار أو لأغراض أخرى؟ | يمكن لتقنيات الإعلان تحديد ما إذا كانت ملفات تعريف الارتباط التابعة لجهات خارجية متوفّرة أم لا. يمكنك الاطّلاع على مزيد من التفاصيل هنا. |
| رقم تعريف المقعد | في ما يتعلّق باقتراح رقم تعريف المقعد، فإنّ معرفة رقم تعريف المقعد أمر أساسي لمعظم طلبات عروض الأسعار، ما يثير القلق بشأن ربط رقم تعريف المقعد بتسجيل المواد الإبداعية. بالإضافة إلى ذلك، هل سيتم تطبيقها على "الإعلان الرئيسي" فقط أم على الإعلانات المكوّنة أيضًا؟ | يعالج اقتراح BuyerAndSellerReportingId المخاوف بشأن عدم توفّر معرّف مقعد المشتري أثناء تسجيل المواد الإبداعية للإعلان الرئيسي. يهدف هذا المعرّف إلى إرسال معرّف مقعد المشتري إلى البائع. نحن بصدد تقييم مدى توفّر الإعلانات المكوّنة. |
| المراقبة وإعداد التقارير | طلب ميزة "المراقبة في الوقت الفعلي" (RTM) من أجل (1) إرسال تقارير RTM للمزادات المُلغاة بالإضافة إلى (2) مجموعات جديدة تمّ ملؤها بالمتصفّح لتوضيح نوع الإلغاء الذي حدث | يبدو أنّ RTM ليس حلّاً مناسبًا لفحص نسبة المشاركة. تم تصميم RTM، بصفتها واجهة برمجة تطبيقات لرصد الاستجابة السريعة، لرصد حالات انقطاع الخدمة المفاجئة والمهمة والمؤقتة. في المقابل، لا يتطلّب معدّل المشاركة الإبلاغ عن وقت استجابة منخفض، ولا يمثّل انقطاعًا مؤقتًا مفاجئًا ومهمًا. إنّ البائعين الذين يتعاون معهم المشترون هم الأكثر قدرة على الإجابة عن المخاوف بشأن معدّلات المشاركة، وليس المشترون الذين يبحثون عن المعلومات عبر المتصفّح. علاوةً على ذلك، بما أنّ المزادات المُلغاة شائعة جدًا، إذا كان المتصفّح سيُنشئ تقارير RTM من كل مزاد مُلغى، قد يؤدي ذلك إلى حجب تقارير RTM للأعطال الفعلية. |
| المستندات التوضيح |
الإبلاغ عن تناقض في المستندات في الشرح الخاص بواجهة برمجة التطبيقات PA API يفيد بأنّه يجب أن تكون القيمة العشوائية سلسلة UUID، ولكنّها في الواقع تعرض وعدًا. | تم اقتراح توضيح هنا. |
| السياق المجمّد |
عند العمل مع السياق المجمّد، ما هي الخيارات المتاحة لحلّ المشاكل والتحديات المتعلقة (1) بتجميع الحِزم و(2) المكتبات الخارجية و (3) أنواع البيانات غير المتوافقة؟ | لقد قدّمنا ردًا على هذا السؤال هنا. |
| المواصفات | أضافت Private Aggregation API عملية contributeToHistogramOnEvent عامة. نتيجةً لذلك، أصبح التعريف في PA API عملية مفرطة الحمل، وعمليات Web IDL "يجب ألا تكون مفرطة الحمل على مستوى الواجهة، أو الواجهة الجزئية [...]"، لذا أصبح هذا التعريف غير صالح الآن. | تشير هذه المشكلة إلى عدم اتساق مؤقت بين مواصفات Private Aggregation API وPrivate Aggregation أثناء دمج تغييرات مشابهة في كليهما. لقد دمجنا طلب دمج لحلّ هذه المشكلة. |
| المجموعات ذات الاهتمامات المشتركة | طلب إرشادات حول الطريقة المقترَحة والموفّرة للموارد لإنهاء مشاركة عروض أسعار مجموعة الاهتمامات عند إيقاف إحدى الحملات | في ما يلي بعض الاقتراحات التي يمكننا تقديمها: نعتقد أنّ أقل مدة استجابة وأقل آلية دائمة وأقل آلية لإطلاق الموارد هي استخدام إشارات عروض الأسعار في الوقت الفعلي لإعلام generateBid() بإيقاف عروض الأسعار. الخيار الثاني الذي يستخدم موارد أقل هو ضبط الأولوية السلبية لهذا IG في استجابة إشارات عروض الأسعار في الوقت الفعلي، لأنّ ذلك سيوقف generateBid() من البدء. الخيار الثالث الذي يستخدم موارد أقل هو إزالة الإعلانات من IG. لا يتمّ تفعيل generateBid() في مجموعات IG التي لا تحتوي على إعلانات. الخيار الرابع الذي يستخدم موارد أقل هو إزالة biddingLogicURL من IG. في هذه المرحلة، لا يزال بإمكانك تعديل IG أو إعادة الانضمام إليه لإعادة تفعيله. تتمحور الخيارات الإضافية حول مغادرة IG، إما من خلال leaveAdInterestGroup() أو clearOriginJoinedAdInterestGroups() أو من خلال انتهاء صلاحية IG.كما هو موضّح أعلاه، تختلف خيارات وقت الاستجابة واستهلاك الموارد. يمكن لتكنولوجيات الإعلان اختيار الخيار الذي يحقّق أفضل مفاضلة لحالات الاستخدام المحدّدة. |
| الجمهور | طلب آلية لتنفيذ عمليات منطقية على شرائح الجمهور التي تم إنشاؤها (مثل إمكانية استهداف تقاطع بين شريحة الجمهور A وB على Instagram) | باستخدام PA API، أصبح من الممكن حاليًا تنفيذ عمليات منطقية على شرائح الجمهور من الموقع الإلكتروني نفسه. لا تتوفّر حاليًا العمليات المنطقية للجماهير على مستوى مواقع إلكترونية مختلفة لأسباب تتعلّق بالخصوصية كما هو موضّح في نموذج الخصوصية. نحن نواصل إجراء الأبحاث في هذا المجال وسنشارك أيّ معلومات جديدة خلال هذه العملية. |
| طلب ميزة | اقتراح لإزالة القيود المفروضة على عروض الأسعار الإضافية التي تتطلّب معرفة TLS مسبقًا | نحن نناقش حاليًا هذا الاقتراح هنا ونرحّب بملاحظاتك الإضافية. |
| نهج معدَّل لميزة "3 أجهزة شخصية" على Chrome | هل ستظلّ واجهات برمجة تطبيقات "مبادرة حماية الخصوصية"، مثل PA API، متاحة بشكل عام لجميع مستخدمي الإصدار الثابت من Chrome، أم ستتوفّر واجهات برمجة التطبيقات (أو مجموعة فرعية منها) للمستخدمين الذين رفضوا ملفات تعريف الارتباط التابعة لجهات خارجية فقط؟ | لا ننوي أن يؤثّر قرار المستخدم برفض ملفات تعريف الارتباط التابعة لجهات خارجية في مدى توفّر واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" في الإصدار الثابت من Chrome. |
| الإشارة المحسّنة | هل هناك أي خطط لإضافة وظيفة تشير إلى ما إذا كان TLS ينوي إجراء مزاد في PA API؟ | نحن بصدد تقييم إمكانية توفير هذه الوظيفة. سنشارك المزيد من التفاصيل حول التوقيت عندما يتوفّر، ونرحّب بملاحظات إضافية حول هذا الطلب. |
| الرقم التعريفي للصفقة | القلق من أنّ متطلبات خادم KV في اقتراح معرّف الصفقة قد تكون عملية من جهة الخادم مكلفة وتستغرق وقتًا طويلاً | يسمح اقتراح معرّف الصفقة لخدمات عرض الإعلانات بالبحث في البيانات الوصفية لمعرّفات الصفقات المحدّدة من خادم المفتاح/القيمة أثناء مزادات الإعلانات الصورية، كي لا تحتاج إلى تحميل جميع البيانات الوصفية ذات الصلة بالصفقة مسبقًا على الجهاز. يتم تطوير هذا الاقتراح استجابةً لطلبات من منصّات عرض الإعلانات، ونرحّب بملاحظات إضافية حول منظومة الإعلانات المتكاملة هنا. ندرك أنّ هناك عملًا مطلوبًا لإعداد خادم "المفتاح/القيمة"، ولكنّنا نعتقد بشكل عام أنّ هذا الإجراء يشكّل فائدة صافية لشركات تكنولوجيا الإعلان. ونواصل استقبال الملاحظات والاقتراحات حول تسهيل هذه العملية. |
| تحديد عدد مرّات الظهور على مستوى Instagram | طلب تحديد عدد مرّات الظهور على مستوى Instagram من خلال PA API | إنّ تحديد عدد مرّات الظهور على مستوى Instagram له خصائص خصوصية صعبة لم نتمكّن من إيجاد حلول لها. نرحب بملاحظات إضافية من المنظومة المتكاملة إذا كانت هذه الميزة ذات أولوية عالية. |
| إعداد تقارير أرقام تعريف الصفقات وأرقام تعريف المقاعد | طلب إمكانية الحصول على أرقام تعريف الصفقة أو المقاعد في التقارير المجمّعة | إنّ وظائف معرّف تتبّع الأداء التي نعمل عليها هنا ستتيح الإبلاغ عن معرّفات الصفقات والمقاعد. يتم توفير selectedBuyerAndSellerReportingId لدالة reportResult()، لذا فإنّ أسهل طريقة للإبلاغ عن ذلك هي من خلال إعداد التقارير على مستوى الحدث (أي ترميز رقم تعريف الصفقة في عنوان URL الذي تم تمريره إلى دالة sendReportTo()). وفي حال استخدام إعداد التقارير المجمّعة، يمكن إجراء ذلك أيضًا. تتوفّر ميزة "رقم تعريف الإبلاغ" حاليًا لنسبة% 10 من عدد زيارات "القناة الثابتة" في Chrome. نحن نقيّم إمكانية توسيع نطاق الإطلاق إلى 100%. |
| المجموعات ذات الاهتمامات المشتركة | استخدِم ترتيب الأولوية نفسه في كلّ من اختيار IG وتقييمه، واستخدِم ترتيب الأولوية هذا في جميع أوضاع التقييم. | نحن نناقش حاليًا هذه المشكلة هنا ونرحّب بملاحظاتك الإضافية. |
| المجموعات ذات الاهتمامات المشتركة | اقتراح استخدام تفعيل شرائح الجمهور وتفويضها كطرق لزيادة استخدام Privacy Sandbox API | نحن على علم بهذا الطلب الذي تلقّيناه من عدة جهات معنيّة ونبحث عن حلّ له. نرحب بملاحظات إضافية من المنظومة المتكاملة. |
| المجموعات ذات الاهتمامات المشتركة | التحديات المتعلقة بإنشاء حسابات مستخدمين في PA API، خاصةً في ما يتعلّق بالتفويض والملكية عند التصرّف في عمليات شراء متعددة أو بالنيابة عن الناشرين | لقد تلقّينا طلبًا من جهات معنيّة متعددة بتوفير المزيد من عمليات تفويض IG المتقدّمة، ونرى القيمة المضافة لخدمات SSP التي تساهم في هذه العملية. نحن نُجري أبحاثًا للعثور على أفضل حلّ يسمح لجهات مختلفة بالمشاركة في عملية توسيع نطاق الجمهور. نرحب بملاحظات إضافية من المنظومة المتكاملة. |
| الأداء من جهة العميل | طلب إرشادات حول تسهيل التخزين المؤقت لـ trustedBiddingSignals من جهة العميل لتحسين تكلفة البنية الأساسية ووقت الاستجابة | نحن نناقش حاليًا هذه المشكلة هنا ونرحّب بملاحظاتك الإضافية. |
المزاد المحمي (خدمات الإعلانات والعروض)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| خدمات المفتاح/القيمة | كيف يتم تجميع الطلبات الواردة من المتصفّح إلى خادم KV الخاص بالبائع؟ كيف سيبدو الطلب الذي يُرسِله البائع من المتصفّح، هل هو طلب GET أم POST؟ بالإضافة إلى ذلك، هناك حاجة إلى بعض التوضيحات حول متطلبات "المعادلة k". | في الإصدار 1، يُرسِل Chrome طلب GET إلى خدمة KV الخاصة بالبائع من أجل جلب trustedScoringSignalsURL باستخدام الإشارات الواردة في مَعلمات طلب البحث. ستتضمّن المَعلمات hostname وrenderUrls وadComponentRenderUrls وexperimentGroupId. نختبر حاليًا بعض الإضافات لإرسال معلومات إضافية لفحص المواد الإبداعية، ولكنّ هذه الميزة لم يتم إطلاقها بعد. عند ضبط maxTrustedScoringSignalsURLLength على 0، يمكن أن يجمع Chrome جميع الإشارات في طلب واحد (ربما يتجاوز أي حد أقصى لطول عنوان URL على الخادم)، ولكن هذا ليس مضمونًا. يختار Chrome حاليًا تضمين الطلبات في الحزمة نفسها إذا كانت جاهزة للإرسال خلال 10 مللي ثانية من بعضها، ولكنّنا نبحث حاليًا عن كيفية تحسين ذلك.عند العمل مع trustedScoringSignals، من المفيد تذكُّر أنّ Chrome يحترم رؤوس التخزين المؤقت. يمكن أن تقلّل العناوين، مثل عنوان Stale-While-Revalidate "Cache-Control"، من متوسّط وقت الاستجابة من خلال السماح لمتصفّح Chrome باستخدام النسخة المخزّنة مؤقتًا (وتعديل ذاكرة التخزين المؤقت للمزاد التالي)، ما يؤدي إلى إزالة استرداد الإشارات من المسار الحرج بفعالية.أخيرًا، في ما يتعلّق بإخفاء هوية عدد معيّن من المستخدِمين، يبدو أنّ القسم المحدّد من الشرح قديم. في الأصل، كان من المفترض أن تكون عناوين URL للإشارات الموثوق بها مجهولة الهوية بدرجة k، ولكن تم إلغاء هذا الشرط. سنزيل هذه الجملة من الشرح. |
| خدمات B&A | تستغرق عملية الترقية إلى أحدث إصدار من "إعلانات Google" وقتًا طويلاً. سيكون من المفيد تقليل مُدد التصميم أو استخدام صور مُعدّة مسبقًا. | يمكن لتقنيات الإعلان إنشاء الملفات الثنائية بأنفسهم والتحقّق منها باستخدام التجزئات المقدَّمة. سننظر في إمكانية توفير عناصر تم إنشاؤها مسبقًا أو تحسين أوقات الإنشاء في المستقبل. |
| طلب ميزة واجهة برمجة التطبيقات | طلب التوافق مع نظام التشغيل macOS لبرامج نصية لبناء خدمات عروض الأسعار والمزادات (B&A) وصور الحاويات وأدوات الاستدعاء لتسهيل التطوير والاختبار على الجهاز | نوفّر حاليًا الإصدار amd64 الذي يكفي للنشر على منصات السحابة الإلكترونية المتوافقة (Google Cloud Platform وAWS). قد ننظر في إتاحة استخدام تصاميم أخرى في المستقبل. |
| AWS | هل يجب إنشاء أدوار إدارة الهوية وإمكانية الوصول لإصدارات الإصدار العلني؟ | نعم، يجب توفُّر أدوار إدارة الهوية وإمكانية الوصول للحصول على الأذونات المناسبة والتواصل مع المنسقين. تُستخدَم المفاتيح لفك تشفير نص التشفير ProtectedAudienceInput الذي يتم إنشاؤه على الجهاز كما هو موضّح هنا. بالإضافة إلى ذلك، يجب أن يكون لدى هذين الدورَين إذن اجتياز شهادة اعتماد الخادم/وحدة TEE لإصدارات الإصدار العلني مع المنسقين نفسهم. يمكنك الاطّلاع على مزيد من التفاصيل في دليل الخدمة الذاتية. |
| علامات B&A | طلب إدراج تعريفات لرموز B&A المتاحة في المستندات، لأنّ هذه التعريفات موجودة حاليًا في رمز Terraform وملفات cc وملفات proto، إلا أنّ تكنولوجيات الإعلان ستستفيد من المستندات حول هذه الرموز، وذلك للاستفادة منها كمصدر معلومات لمعرفة كيفية تخصيص عمليات النشر | نحن ننظر في إمكانية توثيق أوصاف علامات Terraform ونرحّب بملاحظاتك الإضافية هنا. |
| AWS خدمة عروض الأسعار |
أبحث عن إرشادات بشأن خدمة عروض الأسعار على AWS وسلوك التسجيل التلقائي وإعداداته. | لتصحيح أخطاء خدمات عروض الأسعار ضمن بيئة التشغيل المُعزّزة للثقة (TEE) (مثل خدمة عروض الأسعار)، ننصحك باستخدام تصحيح الأخطاء الذي تمت الموافقة عليه من خلال تقنية الإعلان. يتيح لك ذلك تفعيل التسجيل المفصّل وتسجيل بيانات الطلب/الردّ لطلبات الاختبار المحدّدة من العميل مباشرةً للمساعدة في تصحيح الأخطاء. |
| TEE K/V المستندات |
طلب توضيح بشأن بدء فرض سياسة TKV كما هو موضّح على موقع المطوّرين الإلكتروني | وسنرسل إليك إشعارًا كافيًا مسبقًا قبل طلب استخدام TEE. وحتى ذلك الحين، يمكنك مواصلة استخدام خادمك الخاص لإرسال إشارات المفاتيح/القيم في الوقت الفعلي. |
| اختبار وتحليل اختبار أ/ب | لا يزال تحليل واختبار ميزتَي "الاختبار والتحليل" ذا تكلفة عالية ولا يبدو أنّه جاهز للنشر. | نحتاج إلى مزيد من المعلومات حول تحليل التكلفة والعوامل التي تؤدي إلى تقييم مدى الجاهزية للإصدار العلني من أجل النظر في الأمر بشكل أكبر. |
| تحسين الخادم الموثوق به | اقتراح دمج المَعلمات الخاصة ببائعي المكوّنات في مَعلمة واحدة inputsPerSeller، باستخدام سلسلة JSON لقيمتها | نحن نناقش هذا الاقتراح ونرحّب بملاحظاتك الإضافية هنا. |
| الأمان | كيف يتم تقليل مخاطر الأمان الناتجة عن معالجة البيانات في الوقت الفعلي باستخدام ميزة "التوفّر والأداء"؟ | من الممكن منع المكالمات الخارجية إلى TKV. تتوفّر هذه الميزة بالكامل ويمكن ضبطها على Google Cloud Platform اليوم. بالنسبة إلى AWS، يجب تطوير دعم إضافي بسبب إيقاف AWS App Mesh نهائيًا، والذي كان يتيح ذلك في السابق. نرحّب بملاحظاتك الإضافية هنا. |
| خدمات B&A | طلب توضيح بشأن القصة/المراسلات المتعلّقة بقيمة ميزة "البث عبر بروتوكول HTTP" لتحسين تجربة المستخدمين والعملاء | تتوافق "مبادرة حماية الخصوصية" مع إمكانات البث في نقل بيانات B&A لتحسين وقت الاستجابة لتكنولوجيات الإعلان التي تختار استخدامها. ويكون تحسين الأداء اختياريًا في حال استخدام الوضع المختلط. |
| Prebid | طلب الحصول على آخر المعلومات حول المساهمة في مكتبة Prebid مفتوحة المصدر لتفعيل ميزات B&A في PA API للمنظومة المتكاملة | في آذار (مارس) 2025، أطلق Chrome ميزة التحسين المفضّلة في Prebid في الإصدار الثابت كما هو موضّح في خارطة الطريق العلنية لبرنامج B&A (راجِع آذار/مارس 2025). |
| تشكيل الزيارات | طلب آليات لتسجيل الإشارات السياقية التي تلقّاها فريق B&A لفهم وقت تفعيل عروض الأسعار على شبكة البحث بشكل أفضل وتحسين منطق "نية تقديم عروض الأسعار" في الاستجابة السياقية يتيح ذلك استخدام موارد الشبكة بشكل أفضل لتجنُّب "الزيارات غير المفيدة" (المعروفة أيضًا باسم "تشكيل الزيارات"). | نحن نناقش حاليًا اقتراحًا هنا ونرحّب بملاحظاتك الإضافية. |
| المستندات التوضيح |
مطلوب توضيح بشأن خطأ "لا يمكن الوصول إلى الخادم الوكيل للخدمة/Vsock" الذي تم رصده أثناء إعداد اختبار الدمج في B&A. | ويعود السبب في ذلك إلى الحد الأدنى لمتطلبات الذاكرة.تم تعديل شرح إعدادات AWS ليعكس هذا الشرط. |
قياس الإعلانات الرقمية
تقارير تحديد المصدر (وواجهات برمجة التطبيقات الأخرى)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| البيانات في الوقت الفعلي | ويؤثّر عدم توفّر البيانات في الوقت الفعلي في جميع العاملين في المجال. يشكّل تأخّر البيانات في الوقت الفعلي مشكلةً خطيرة للمعلِنين، إذ ينتقل المشترون إلى المنصّات التي تتضمّن "إحصاءات Google" لأنّها المكان الوحيد الذي يمكنهم فيه الحصول على دليل على الوصول إلى شرائح الجمهور. | يتم تنفيذ تأخيرات البيانات في الوقت الفعلي التي تشكّل جزءًا من Attribution Reporting API (ARA) كآليات لحماية الخصوصية من أجل الحدّ من قدرة تكنولوجيات الإعلان على استخدام التقارير على مستوى الحدث لتتبُّع المستخدِمين على جميع المواقع الإلكترونية. ومع ذلك، توفّر تقنية ARA مرونة في طريقة عرض تقارير تحديد المصدر، وذلك من خلال السماح للتقارير على مستوى الحدث بحدّ أدنى من فترة إعداد التقارير تبلغ ساعة واحدة، والسماح للتقارير المجمّعة بإمكانية إرسالها على الفور إلى تقنيات الإعلان بدون أي تأخير. |
| استخدام واجهة برمجة التطبيقات | طلب تأكيد بشأن الإعداد الصحيح لتدفّق تحديد المصدر على مستوى تطبيقات الويب المختلفة، خاصةً عند تشغيل تحديد المصدر من موقع إلكتروني إلى موقع إلكتروني وتحديد المصدر من موقع إلكتروني إلى تطبيق بشكل موازٍ | عند عرض حملات من موقع إلكتروني إلى موقع إلكتروني وحملات من موقع إلكتروني إلى تطبيق بشكل متزامن، يجب أن تختار تكنولوجيا الإعلان منصة واحدة فقط لتسجيل كل مصدر أو عامل تشغيل، وذلك لمنع الاحتساب المزدوج. ننصحك بشدة باستخدام نظام التشغيل (OS) كلما أمكن ذلك، لأنّه يمكن لنظام التشغيل تنفيذ عملية تحديد المصدر من الويب إلى الويب ومن الويب إلى التطبيق، ما دام قد تم تفويض مصادر الويب وعوامل التفعيل بشكل صحيح. ويعني ذلك الردّ باستخدام عنوان Attribution-Reporting-Register-OS-Source للمصادر وعنوان Attribution-Reporting-Register-OS-Trigger للعوامل المشغّلة. يمكن استخدام Attribution-Reporting-Support header لتحديد ما إذا كان هناك دعم على مستوى Chrome و/أو Android. يكون عنوان Attribution-Reporting-Info مفيدًا عندما لا يتوفّر عنوان Attribution-Reporting-Support في الطلب، وفي هذه الحالة سيتخذ المتصفّح قرار تسجيل المنصة استنادًا إلى مدى توفّر دعم المنصة على جهاز المستخدم. |
| مواصفات واجهة برمجة التطبيقات | طلب توضيح بشأن رأس طلب HTTP الخاص بخدمة الدعم في ميزة "تحديد المصدر وإعداد التقارير" الذي تحدّده Attribution Reporting API وما إذا كان من المقصود أن يحتوي العنوان على مفتاحَي الويب ونظام التشغيل بغض النظر عن المنصة | يخضع عنوان Attribution-Reporting-Support إلى إضافة المتصفّح لمَعلمات GREASE، لضمان استخدام الخوادم لأداة تحليل عناوين من الموقع متوافقة مع المواصفات. بالنسبة إلى هذا العنوان، يجب تفسير مفاتيح القاموس منظَّمة فقط. القيم والمَعلمات غير مستخدَمة حاليًا. يمكنك الاطّلاع على مثال هنا. |
| إعداد التقارير المستندة إلى 3PC | طلب إرشادات حول كيفية تحديد المشاكل وحلّها في الاختلافات في القياس بين ARA و3PC في الحملات الإعلانية | تتيح أداة ARA نوعَين من تقارير تصحيح الأخطاء التي يمكن استخدامها لتحديد المشاكل وحلّها وإصلاح التناقضات. يمكن استخدام تقارير تصحيح أخطاء نجاح تحديد المصدر لمقارنة نتائج ARA بسهولة مع النتائج الواردة من تقنيات القياس الأخرى، ويمكن استخدام تقارير تصحيح الأخطاء المفصّلة للحصول على مزيد من المعلومات وتحديد المشاكل المحتمَلة وحلّها في عمليات تسجيل تحديد المصدر. |
| استخدام واجهة برمجة التطبيقات | أثناء اختبار ARA، تم اكتشاف مشاكل معيّنة: عدم كفاية إعداد التقارير الدقيقة التي تؤدي إلى ظهور بيانات غير دقيقة وتحسين غير مرن للحملات، وحدود عالية تستبعد المعلِنين الأصغر حجمًا، وصعوبة مقارنة الحملات بسبب عدم اتساق مؤشرات الأداء الرئيسية. | توفّر ARA المرونة من خلال توفير مَعلمات متعدّدة يمكن لتكنولوجيات الإعلان تخصيصها لتحقيق حالات استخدام قياس محدّدة. تتيح "التقارير على مستوى الحدث" إعداد تقارير مرنة على مستوى الحدث، ما يسمح لتكنولوجيات الإعلان بتخصيص فترات إعداد التقارير وعدد التقارير التي يمكنهم تلقّيها وبيانات العوامل المشغّلة التي يريدون قياسها، ما يمكن أن يغيّر تأثير الضوضاء في بياناتهم ويسمح لهم بتحقيق حالات استخدام مختلفة. وبالمثل، تتضمّن "التقارير المجمّعة" طرقًا مختلفة يمكن للتقنيات الإعلانية من خلالها تخصيص إعداداتها، مثل عدد السمات التي تتتبّعها ومعدّل تجميعها واستخدامها لميزانية المساهمة من أجل تغيير تأثير الضوضاء وتحقيق حالات استخدام مختلفة أيضًا. |
| مواصفات واجهة برمجة التطبيقات | سؤال حول اعتماد ARA على ملفات تعريف الارتباط التابعة لجهات خارجية، وعلى وجه التحديد ما إذا كان لا يزال في مرحلة اختبار تتطلّب هذه الملفات | يتم تفعيل ARA بشكل مستقل عن ملفّات تعريف الارتباط التابعة لجهات خارجية، ولكن يجب تفعيل ملفّات تعريف الارتباط التابعة لجهات خارجية للسماح بإعداد تقارير تصحيح الأخطاء الانتقالية في ARA من أجل مقارنة نتائج ARA بنتائج تحديد المصدر المستندة إلى ملفات تعريف الارتباط. |
| استخدام واجهة برمجة التطبيقات | استفسار بشأن تسجيل مصادر تحديد المصدر من التطبيق إلى الموقع الإلكتروني على إصدارات Android القديمة (11 و12 و13) باستخدام ARA | تتوفّر ميزة ARA حاليًا على نظام التشغيل Android S والإصدارات الأحدث (12 والإصدارات الأحدث). |
| استخدام واجهة برمجة التطبيقات | طلب تعرفات الموافقة على ARA وتفاصيل التوزيع | لم يتغيّر ردّنا عن الردود التي قدّمناها في الربع سنوية السابقة: "لا ننوي مشاركة هذه المعلومات مع النظام المتّسق. نرحب بالمطوّرين بالاتصال بواجهات برمجة التطبيقات التي تم نشر الرمز البرمجي فيها اليوم لتقدير مدى توفّر واجهات برمجة التطبيقات في "مبادرة حماية الخصوصية". |
| مدى توفّر واجهة برمجة التطبيقات | عند تفعيل ARA، هل يتم تفعيل 3PC أو إيقافه؟ | عند تفعيل ARA في متصفّح المستخدمين، لا يكون له أي تأثير في إعدادات ملفات تعريف الارتباط الخاصة بالمستخدمين. من الممكن أن يكون خيار ARA مفعّلاً وأن يكون لدى المستخدم ملفات تعريف ارتباط مفعّلة أو غير مفعّلة. |
| إعداد التقارير | هل هناك قائمة محدّدة مسبقًا بالقيم التي يمكننا تلقّيها في عنوان Attribution-reporting-support؟ | وفقًا لما هو موضّح في إرشاداتنا، القيمة هي عبارة عن قاموس عناوين منظَّم، ودلالاته المحدّدة حاليًا هي فقط توفّر مفاتيح نظام التشغيل والويب أو عدم توفّرها. ويجب تجاهل جميع الأجزاء الأخرى من العنوان. بعبارة أخرى، يتطلّب التحليل استخدام أداة تحليل عناوين من الموقع، وليس مطابقة سلاسل بسيطة. |
خدمة تجميع البيانات
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| طلب ميزة | طلبات الميزات لخدمة التجميع: عمليات الدمج من خادم إلى خادم، والقياس على جميع الأجهزة، وتسهيل عملية تحديد المصدر بالاستناد إلى عدّة نقاط اتصال وإعداد تقارير المساهمة، وتحديد المصدر على جميع القنوات، وتوفير ميزات تحسين متقدّمة مستندة إلى الذكاء الاصطناعي (مثل تدريب النماذج الخاصة). |
نحن بصدد تقييم هذه الطلبات وسنشارك المزيد من التفاصيل عندما تتوفّر. نرحّب بملاحظات إضافية من المنظومة المتكاملة بشأن ما إذا كانت هذه الطلبات ذات أولوية. |
| طلب ميزة | يُرجى ضبط المَعلمة delete_on_termination في EBS على True في بيئة terraform، وذلك للتخفيف من المخاوف بشأن إعادة الضبط عند تعديل مجموعة خدمات التجميع. | نحن بصدد تقييم هذا الطلب وسنشارك المزيد من التفاصيل عندما تتوفّر. نرحب بملاحظات إضافية من المنظومة المتكاملة حول ما إذا كان هذا الطلب يُعدّ من الأولويات هنا. |
| المستندات التوضيح |
طلب إرشادات حول ما يمكن تغييره (مثل حدود المراقبة) وما يجب عدم تغييره | نحن نُقيّم نشر مستندات وإرشادات إضافية حول التخصيصات المتاحة لخدمة التجميع. |
| التفعيل | طلب توضيح بشأن تعذُّر عملية النشر الجديدة في الأمر bazel | يمكن أن يحدث تعذُّر النشر بسبب إصدار bazel المستخدَم في البيئة. سيتم تعديل المستندات لتغطية تصحيح الأخطاء في حالات تعذُّر استخدام Terraform، بالإضافة إلى الإشارة إلى إصدار bazel المطلوب. |
Private Aggregation API
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| استخدام واجهة برمجة التطبيقات | طلب إرشادات حول بعض تحديات التنفيذ، مثل فقدان البيانات المحتمَل بسبب القيود المفروضة على "مساحة التخزين المشتركة"، والصعوبات المتعلّقة بعدد القيم الفريدة للسمة الكبير الذي يتطلّب قوائم مسموح بها معقّدة لخدمة "التجميع" (يُنصح باستخدام البدل اللاتيني)، وبطء الاختبار بسبب قاعدة "عدم السماح بالنسخ المكرّرة" في خدمة "التجميع" | في ما يتعلّق بالحدود المفروضة على مساحة التخزين المشتركة، فإنّ الحد الأقصى المسموح به للمساهمات هو 20 مساهمة (يمكنك الاطّلاع على التفاصيل هنا) لكل عملية تنفيذ، وليس لكل شهر. بالإضافة إلى ذلك، يمكن لمُطلِبي واجهة برمجة التطبيقات إلغاء هذا الحدّ. تم وضع هذا الحدّ للمساعدة في إدارة تكلفة معالجة التقارير في خدمة التجميع وليس لتقييد أداة إعداد التقارير. في ما يتعلّق بطلبات البحث باستخدام البدل، نحن بصدد تقييم هذا الطلب وسنشارك المزيد من التفاصيل عند توفّرها. في ما يتعلّق بقاعدة "عدم السماح بنسخ مكرّرة"، لتفعيل الاختبار، نتيح مؤقتًا وضع تصحيح الأخطاء بغرض تجاوز هذه القاعدة. يمكنك الاطّلاع على مزيد من التفاصيل هنا . |
| فلترة الأرقام التعريفية والحِزم | هل من الممكن طلب الحزمة نفسها من خدمة التجميع مع معرّفَي فلترة مختلفَين في عمليتَي تجميع منفصلتَين، أي هل يمكن أن يعمل معرّف الفلترة كقسمة تكميلية للنطاقات؟ | نعم، هذه الميزة متاحة. عند إجراء تجميع، لن تتم معالجة سوى المساهمات التي تحتوي على معرّف فلترة يتطابق مع القائمة في مَعلمات المهمة، وسيظلّ الباقي متاحًا للمعالجة في عمليات تشغيل منفصلة. |
| تحديد المصدر بالاستناد إلى نقاط اتصال متعددة | طلبات التوضيح بشأن تنفيذ ميزة تحديد المصدر بالاستناد إلى عدّة نقاط اتصال (MTA): 1) هل هناك حدّ أقصى لعدد المساهمات إذا لم تتجاوز قيمة التجميع 2^16؟ 2) هل هناك حدّ أقصى لعدد مفاتيح التجميع الفريدة (الحزم) التي يمكن تخزينها لسياق معيّن؟ 3) كيف تعالج "خدمة تجميع البيانات" التقارير التلخيصية عندما يكون لكل وكيل مستخدم (متصفّح) مفتاح تجميع فريد، كما هو الحال على الأرجح في MTA؟ |
1) وضعنا حدودًا تلقائية للمساهمات، ولكن هناك خيارات يمكن لمُطلِب واجهة برمجة التطبيقات إلغاؤها كما هو موضّح هنا. ويهدف الحدّ الأقصى إلى مساعدة مُرسِلي طلبات البيانات من واجهة برمجة التطبيقات في إدارة تكلفة معالجة التقارير في خدمة التجميع. 2) لا يوجد حدّ أقصى لذلك، على الرغم من أنّ تكنولوجيات الإعلان يجب أن تأخذ في الاعتبار دقة مفاتيح التجميع لتحسين نسبة الإشارة إلى الضوضاء، كما هو موضّح بالتفصيل هنا. 3) يُرجى الاطّلاع على هذه الإرشادات، خاصةً إرشادات نسبة الإشارة إلى الضوضاء المذكورة أعلاه ضمن النقطة 2). |
الحد من التتبّع الخفي
تقليل معلومات وكيل المستخدم/تعديلات برنامج وكيل المستخدم
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| طلب ميزة | طلب إضافة Sec-CH-UA-Robot إلى إشارات عملاء User-Agent (UA-CH) لأنّ ذلك سيسمح للخوادم بتحديد الزيارات المبرمَجة من أجل تكييف المحتوى والأمان والإحصاءات. | هذا مثال مهم على حالات الاستخدام التي تتم مناقشتها في مجموعات المعايير الأخرى (اطّلِع على هذا الرابط لمزيد من التفاصيل)، وننصحك بالجهات المهتمة بالمشاركة من خلال تقديم ملاحظاتها. ومع ذلك، نعتقد أنّ UA-CH قد لا يكون الحلّ المناسب، نظرًا لأنّه يمكن التلاعب بسهولة برؤوس طلبات HTTP من خلال الزيارات المبرمَجة. |
حماية عنوان IP (المعروفة سابقًا باسم Gnatcatcher)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| خصوصية عناوين IP | إنّ ترك عناوين IP متاحة لشركة Google لاستخدامها يتعارض مع أهداف الخصوصية المعلَن عنها. على الرغم من أنّ Google تقول إنّها تحجب هوية المستخدمين من خلال ميزة "حماية عنوان IP"، يجب أن يكون المستخدمون مسجّلين الدخول إلى Chrome لاستخدام هذه الميزة، وبالتالي تظل Google تعرف هوياتهم. | تعود أسباب تسجيل الدخول إلى أغراض مكافحة الاحتيال وإساءة الاستخدام، ويتمثل ذلك في المقام الأول في الحد من معدّل الوصول إلى الخوادم الوكيلة. بالإضافة إلى ذلك، لحماية خصوصية المستخدمين في سياق متطلبات المصادقة، يتم توقيع رمز المرور لدينا بشكل أعمى، ما يعني أنّ رمز المرور الذي يتم إصداره أثناء تسجيل الدخول يختلف عن رمز المرور الذي يتم استخدامه أثناء التوسّط، وبالتالي لا يمكن ربط الرموز المُصدَرة بهوية المستخدم على Google لاحقًا. وهذا يعني أنّ Google لا تعرف هوية المستخدم عندما يتم توجيه زيارات هذا المستخدم من خلال خادم وكيل في وضع التصفّح المتخفي، على الرغم من متطلبات المصادقة لأسباب تتعلّق بمكافحة الاحتيال. |
| خصوصية عناوين IP | إنّ استخدام عناوين IP هو خطوة في الاتجاه الخاطئ. ولا يمكن حذفها من المتصفّح، مثل ملفات تعريف الارتباط، ولا تتوفّر للمستخدمين عناصر التحكّم في الشفافية نفسها المتوفّرة في ملفات تعريف الارتباط. في حال إيقاف ملفات تعريف الارتباط، ستنتقل الجهات العاملة في المجال إلى استخدام عناوين IP كحل بديل، مع إعطاء الأولوية للمحافظة على أنفسهم بدلاً من الخصوصية. | يهدف Chrome إلى تزويد المستخدمين بميزات تحسّن تجربة التصفّح على الويب. بالنسبة إلى مستخدمي Chrome الذين يختارون التصفّح في وضع التصفّح المتخفي، يعني ذلك توفير وسائل حماية محسّنة ضد التتبّع على مستوى المواقع الإلكترونية من خلال الحد من توفّر معلومات عنوان IP في السياقات التابعة لجهات خارجية. |
| قائمة النطاقات المخفية | ما هي معايير الاختيار في قائمة النطاقات المخفية (MDL)؟ | طوّر فريق Chrome معايير لتحديد النطاقات التي يجب أن تكون مضمّنة في قائمة MDL وبالتالي تتلقّى عناوين IP محجوبة في سياق تابع لجهة خارجية. عقدت Google شراكة مع Disconnect.me، وهي شركة رائدة في مجال الخصوصية على الإنترنت تتعاون أيضًا مع متصفّحات ويب أخرى. سيستفيد Chrome من Disconnect.me لتحديد النطاقات التي تتوافق مع المعايير التي وضعها Chrome. بالإضافة إلى ذلك، طوّر فريق Chrome منهجية لتحديد وظائف JavaScript المستخدَمة على نطاق واسع والتي توفّر نتائج متسقة من واجهات برمجة تطبيقات الويب الثابتة ذات التشويش العالي، وبالتالي يمكن استخدامها لإنشاء معرّفات احتمالية ذات تشويش عالٍ. ويتم بعد ذلك رصد هذه الدوال عند تحميلها على المواقع الإلكترونية في سياق تابع لجهة خارجية، ما يؤدي إلى إنشاء قائمة بالنطاقات التي تعرِض نصوصًا برمجية تتضمّن هذه الخصائص وتصبح جزءًا من نموذج MDL، وبالتالي يتم تمثيلها. تبحث عملية رصد إساءة استخدام واجهات برمجة التطبيقات عن أنماط إساءة الاستخدام هذه في جميع النطاقات، بما في ذلك نطاقات Google. |
| منع الاحتيال | ملاحظات حول الرموز المخصّصة للكشف عن الهوية (PRT) بأنّ وقت الظهور المقترَح الذي يبلغ 24 ساعة ومعدّلات الظهور تُعيق رصد عمليات الاحتيال في الوقت الفعلي اطلب تقليل وقت التأخير (تأخير لمدة ساعة واحدة) وزيادة الأسعار (بنسبة %10 على الأقل). تشمل الاقتراحات الإضافية تفعيل الأسعار المتفاوتة استنادًا إلى إشارات المخاطر (شبكات VPN والمتصفّحات الآلية)، والسماح بعرض مستهدف لبيانات اعتماد معيّنة. | يقدّم معظم المطوّرين الذين تواصلنا معهم تقارير كل ساعة إلى عملائهم، ويُجري العديد منهم تعديلات على قوائم حظر عناوين IP على مدار اليوم. تؤدي فترة التأخير الأقصر إلى إجراء تعديلات أكثر تكرارًا، وفي حال كانت أقل من ساعة، ستؤدي إلى إعادة تفعيل قياس IVT في الإحصاءات بالساعة، ولكن قد تزيد أيضًا من احتمالية إعادة تحديد هوية المستخدِمين. نحن منفتحون على استكشاف إمكانية تقليل فترات التأخير وتغيير معدّل الظهور استنادًا إلى دراسات المنظومة المتكاملة وملاحظات الجهات المعنية، ونرحّب بملاحظات إضافية هنا. |
| قائمة النطاقات المخفية | سؤال بشأن إدراج النطاق في قائمة MDL على الرغم من عدم توفّر حالة استخدام للإعلانات القلق من أنّ ذلك قد يؤدي إلى تفعيل ميزة "ربط عناوين IP" لإنشاء الملفات الشخصية استنادًا إلى عناوين IP | ندرك أهمية تنفيذ عملية تقديم طلبات إعادة النظر في المحتوى المدرَج في القائمة. تسمح طلبات إعادة النظر للشركات بتقديم مطالبة بأنّ نطاقاتها المُدرَجة في القائمة المسموح بها (MDL) لا تستوفي معايير الإدراج وأنّه يجب إزالتها، ما يسمح لهذا النطاق بمواصلة تلقّي عناوين IP الأصلية للمستخدمين في سياق تابع لجهة خارجية في "وضع التصفّح المتخفي". لقد أطلقنا الآن عملية تقديم طلبات إعادة النظر لمنح مالكي النطاقات وقتًا كافيًا لتقديم طلب إعادة نظر والحصول على قرار قبل إطلاق ميزة "حماية عنوان IP" في وضع التصفّح المتخفي في الإصدار الثابت من Chrome. يمكنك الاطّلاع على مزيد من التفاصيل حول عملية تقديم طلبات إعادة النظر هنا. |
| قائمة النطاقات المخفية | ملاحظات بأنّ الناشرين ينظرون في الآثار المترتبة على تضمين شركائهم في نموذج MDL وقد شعر العميل بالارتياح بعد الاطّلاع على أحكام الموقع الجغرافي لعنوان بروتوكول الإنترنت ضمن الشرح المفصّل لحماية عناوين IP. | يدرك Chrome أهمية توفير حالات استخدام مستندة إلى الموقع الجغرافي. سيحدّد الخادم الوكيل عناوين IP التي تمثّل الموقع الجغرافي التقريبي للمستخدم، بما في ذلك البلد. تتوفّر معلومات إضافية في معلومات عن تحديد الموقع الجغرافي باستخدام عنوان IP. |
| قائمة النطاقات المخفية | سؤال بشأن نموذج بيانات المنتج (MDL) بشأن ما إذا كان استهداف مستوى البلد لا يزال متاحًا أم لا | يدرك Chrome أهمية توفير حالات استخدام مستندة إلى الموقع الجغرافي. سيحدّد الخادم الوكيل عناوين IP التي تمثّل الموقع الجغرافي التقريبي للمستخدم، بما في ذلك البلد. تتوفّر معلومات إضافية في معلومات عن تحديد الموقع الجغرافي باستخدام عنوان IP. |
| رصد الاحتيال | مخاوف بشأن تأثير ميزة "حماية عنوان IP" في أنظمة رصد الاحتيال هل سيرى المستخدمون عناوين IP للخوادم الوكيلة أو عنوانًا؟ هل ستظهر منصّات عرض الإعلانات وأنظمة إدارة الطلبات عنوان IP لخادم الوكيل نفسه لاستخدام معيّن؟ يمكن أن تؤثّر التناقضات في رصد الاحتيال وOpenRTB. | إذا كان المستخدمون يتصفّحون الويب في "وضع التصفّح المتخفي" مع تفعيل ميزة "حماية عنوان IP" ويقدّمون طلبات إلى نطاقات في قائمة MDL، سيتلقّون عنوان IP وكيلاً استنادًا إلى خلاصة جغرافية محدّدة. يمكن للمؤسسات طلب تمرير سجلّات PRT كعنوان إضافي على الزيارات التي يتم توجيهها من خلال خادم وكيل، حيث يمكن الكشف عن عيّنة صغيرة من عناوين IP الأصلية بعد فترة تأخير. نعتقد أنّ العديد من منصّات عرض الإعلانات ستُرسل عنوان IP الوكيل في طلبات عروض الأسعار من جهة الخادم إلى شركاء الطلب، ولكن لا يمكن ضمان أن ترى منصّات إدارة الطلبات الفائزة عنوان IP الوكيل نفسه في وقت ظهور الإعلان. |
| رصد الاحتيال | أسئلة عن معدّل تحديث ملف الموقع الجغرافي لعنوان IP، وتوقيت التحديث للحصول على تفاصيل عن الإبلاغ عن السلوك الاحتيالي وطلبات البحث المحمية، وكيفية رصد تكنولوجيا الإعلان للأنشطة الاحتيالية | أصبح الشرح حول عناوين IP الخاصة بنقاط الاتصال في نطاقات البحث متاحًا، وكذلك القائمة بعناوين IP للخادم الوكيل والمناطق الجغرافية المرتبطة بها. ننصحك بمراجعة هذا الملف بشكل دوري للاطّلاع على التعديلات والتغييرات، لأنّ عناوين IP ستتم تبديلها بمرور الوقت. سيتم الإعلان عن عنوان البريد الإلكتروني المتاح للجميع للإبلاغ عن إساءة الاستخدام مع اقتراب موعد الإطلاق. |
| الموقع الجغرافي | طلب الحصول على قائمة عامة بعناوين IP المستخدَمة للوكلاء | يتوفّر ملف ربط عناوين IP بالمواقع الجغرافية التقريبية لحماية عنوان IP هنا. يُرجى العِلم أنّه يتم تعديل هذا الملف بشكل دوري. |
| استخدام واجهة برمجة التطبيقات | تأكيد بأنّ ميزة "حماية عنوان IP" مفعّلة تلقائيًا ولا يُتاح للمستخدمين خيار إيقافها | ستتوفّر ميزة "حماية عنوان IP" للمستخدمين في وضع التصفّح المتخفي في Chrome، على نظامَي التشغيل Android وأجهزة الكمبيوتر المكتبي. سيتمكّن المستخدمون من إيقاف ميزة "حماية عنوان IP". بالنسبة إلى إصدارات Chrome المُدارة من المؤسسات، يمكن تفعيل ميزة "حماية عنوان IP"، ولكنّها ستكون متوقفة تلقائيًا. |
| استخدام واجهة برمجة التطبيقات | طلب معلومات بشأن توفّر علامة تجربة لتفعيل ميزة "حماية عنوان IP" واختبارها في إصدارَي Chrome Canary والإصدار التجريبي | لا تتوفّر لدينا حاليًا علامة تجريبية لاختبار ميزة "حماية عنوان IP" الكاملة. لا تؤدي التجارب الوظيفية التي نُجريها إلا إلى إعادة توجيه الزيارات إلى نطاقات Google. |
| خصوصية عنوان IP | كيف تعمل إعدادات طلب موافقة المستخدم الثالث عندما ينتقل المتصفّح إلى وضع التصفّح المتخفي؟ | يتم حظر ملفات تعريف الارتباط التابعة لجهات خارجية تلقائيًا في "وضع التصفّح المتخفي". |
| وضع التصفّح المتخفي | طلب توضيح بشأن ما إذا كانت ميزة "حماية عنوان IP" تعمل في وضع التصفّح المتخفي عندما لا يكون المستخدم مسجّلاً الدخول إلى Chrome | لا تكون ميزة "حماية عنوان IP" مفعّلة إذا لم يسجّل المستخدم الدخول إلى Chrome قبل تشغيل "وضع التصفّح المتخفي". ويعود سبب ذلك إلى أغراض مكافحة الاحتيال وإساءة الاستخدام، لا سيما الحد من معدّل الوصول إلى الخوادم الوكيلة. ستستخدم ميزة "حماية عنوان IP" مصادقة العميل للحد من قدرة الجهات الفاعلة السيئة على الاستفادة من الخوادم الوكيلة لزيادة الهجمات على الخدمات في "المعيار المرجعي للمحتوى في خرائط Google". لذلك، لن تتوفّر ميزة "حماية عنوان IP" إلا للمستخدمين الذين تمّت مصادقتهم باستخدام حساب Google الذي سجّلوا الدخول إليه في متصفّح Chrome قبل فتح نافذة تصفّح متخفّي جديدة. |
| وضع التصفّح المتخفي | طلبات تقييم تأثير ميزة "حماية عنوان IP" قبل إطلاقها، بما في ذلك: (1) اقتراح استخدام علامة حالة المتصفّح أو تجميع تقارير واجهة برمجة التطبيقات لتحديد مقدار استخدام "وضع التصفّح المتخفي" (2) إرسال عنوان "حماية عنوان IP" لفترة قبل تفعيل الميزة (3) طرح الميزة على نسبة صغيرة ومعروفة من الزيارات لاحتساب النتائج. |
نحن نتفهّم اهتمام المنظومة المتكاملة بمعرفة نطاق وتأثير حماية حقوق الملكية الفكرية وقياسهما. ومع ذلك، يعمل Chrome على الحفاظ على خصوصية اختيار المستخدم للتصفّح في "وضع التصفّح المتخفي". لا يعرِض Chrome طريقة لرصد المستخدمين الذين يتصفّحون الويب في "وضع التصفّح المتخفي"، وقد اتّخذ خطوات للحدّ من الإشارات الأخرى التي قد تكشف وضع التصفّح لدى المستخدم. نحن ندرس طرقًا لتسهيل هذا الاختبار بدون التأثير في خصوصية المستخدمين الذين يتصفّحون الويب في "وضع التصفّح المتخفّي"، ونرحّب بملاحظات إضافية من المنظومة المتكاملة. |
إجراءات الحدّ من التتبّع الارتدادي
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| الامتثال | إنّ رفض Google السماح باستخدام تقنية تخفيف تتبُّع الارتدادات (BTM) المتوافقة مع التشريعات المتعلقة بحماية البيانات ليس له أساس قانوني ويجعل عملية تقديم طلبات إعادة النظر في "مبادرة وضع الحماية للخصوصية" بلا معنى. | كما أوضحنا في تقرير الملاحظات السابق، لا علاقة لحالة الامتثال بتطبيق ميزة "إدارة الأداء من خلال التسويق"، ولا تتّخذ Google أي قرارات بشأن الامتثال لتنفيذ هذه الميزة. مثل ميزات حماية الخصوصية الأخرى في Chrome، تركّز ميزة "التتبّع في Chrome" على تعزيز قدرة المستخدمين على التحكّم في إمكانية مشاركة بياناتهم وطريقة مشاركتها. إنّ عملية تقديم طلبات إعادة النظر التي يديرها طرف ثالث والمُشار إليها في تقرير الربع الثاني أو الثالث الصادر عن هيئة CMA هي خاصة بالمجالات التي تتّخذ فيها Google قرارات بشأن إدراج شركات فردية أو استبعادها من القوائم. |
| الامتثال | مناقشة حول كيفية ضمان المتصفّحات للامتثال للإجراءات التي تمت الموافقة عليها قانونيًا في سياق "اللائحة العامّة لحماية البيانات"، مع تسليط الضوء على السيناريوهات التي قد تمنع فيها المتصفّحات الإجراءات (مثل عمليات إعادة التوجيه أو ضبط ملفات تعريف الارتباط) التي وافق عليها المستخدمون صراحةً، ما يؤدي إلى حدوث تعارض بين الموافقة القانونية وإعدادات خصوصية المتصفّح | لا يمكن للمتصفّح معرفة طبيعة العلاقة بين المستخدِم والموقع الإلكتروني. بالإضافة إلى ذلك، مع السلوك الحالي لخدمة تتبُّع الزيارات الناجحة، تتوفّر حاليًا حلول بديلة للمستخدمين من أجل منح موافقة صريحة على تتبُّع عمليات الارتداد من موقع إلكتروني معيّن. يمكنك الاطّلاع على مزيد من المعلومات حول الامتثال في الأسئلة الشائعة حول الامتثال للسياسات المتعلّقة بالخصوصية. |
| المواقع الإلكترونية ذات الاستخدام المزدوج | هل يمكن الحصول على توضيح بشأن ما إذا كانت عمليات النقل من WebView أو من التطبيق إلى الويب (Chrome) ستُعتبر "مواقع إلكترونية ذات استخدام مزدوج" بموجب سياسة BTM؟ | لا يمكن للمتصفح معرفة ما إذا كانت سلسلة الارتداد قد بدأت من خلال انتقال من WebView أو التطبيق. وبالتالي، لا تمنح ميزة "إدارة الزيارات الواردة" هذه التدفقات أي معاملة خاصة. بدلاً من ذلك، يفسّر المسار على أنّه قفزة على مستوى الموقع الإلكتروني بدءًا من about:blank ويتابع السلوك العادي. |
تعزيز حدود الخصوصية على مستوى المواقع الإلكترونية
مجموعات المواقع الإلكترونية المرتبطة (المعروفة سابقًا باسم "مجموعات نطاقات الطرف الأول")
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| استخدام واجهة برمجة التطبيقات | المخاوف بشأن احتمال إساءة استخدام RWS مع ميزة "حماية عنوان IP" إنّ إتاحة عناوين IP للمؤسسات ضمن مجموعة RWS قد يشجّع المؤسسات على الانضمام إلى مجموعات RWS متعددة للوصول إلى بيانات عناوين IP القابلة للنقل لتتبُّع مستخدمي وضع التصفّح المتخفي. | إنّ متطلبات المجموعات للمواقع الإلكترونية المرتبطة ومواقع الخدمات والمجموعات ككل، والتي يتم فرضها من خلال عمليات التحقّق التلقائية، تقلّل من أي حافز محتمل لمحاولة الانضمام إلى مجموعات متعدّدة. يتطلب دمج نشاط المستخدِم على مستوى المجموعات من خلال عناوين IP تضمين نطاق MDL في مجموعة، ما يتطلّب التنسيق بين مالك المجموعة ومالك النطاق. ينطبق هذا الخطر نفسه على المواقع الإلكترونية الفردية (أي المواقع الإلكترونية التي لا تتضمّن تنسيق RWS) التي تتعاون مع نطاقات MDL. لقد أجبنا عن هذا السؤال بالتفصيل هنا. |
Fenced Frames API
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| الإعلانات المدمجة مع المحتوى | ملاحظات بأنّ "الإطارات المُحيطة"، على النحو الذي تم تصميمها به حاليًا، غير متوافقة مع نموذج النشاط التجاري للإعلانات المدمجة، والذي يتطلّب أن تتوافق الإعلانات بشكلٍ مرن مع المحتوى المحيط بها | نحن نواصل تقييم احتياجات المنظومة المتكاملة وعرض "اللقطات المُحيطة" الحالي. في جميع الأحوال، وكما ذكرنا سابقًا، سيكون استخدام "الإطارات المحدودَة" مطلوبًا قبل عام 2026. |
Shared Storage API
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| خطأ في واجهة برمجة التطبيقات | أبلِغ بأنّ Chrome يسجّل خطأ عندما تمنع آلية تحديد الميزانية في Shared Storage API من تنفيذ عملية selectURL، على الرغم من أنّ هذا السلوك متوقّع. يُرجى طلب من Chrome خفض مستوى التسجيل من خطأ إلى تحذير أو معلومات، لأنّ الخطأ لا يمكن للمستخدم اتخاذ إجراء بشأنه. | تم تنفيذ هذا التغيير وتضمينه في الإصدار M134 من Chrome، وهو متاح منذ 4 آذار (مارس) 2025. |
ملفات تعريف الارتباط في الحالة المقسَّمة المنفصلة (CHIPS)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| وثائق واجهة برمجة التطبيقات | مطلوب توضيح بشأن إجراءات الحماية الأمنية التي تقدّمها ملفات تعريف الارتباط المُقسَّمة مقارنةً بملفات تعريف الارتباط التي تتضمّن السمة SameSite=Lax/Strict. اقتراح بأن تتضمّن المستندات صراحةً أنّ ملفات تعريف الارتباط المُقسَّمة لا توفّر مستوى الحماية نفسه ضد هجمات حقن الشيفرة المصدريّة عبر موقع وسيط (XSS) وهجمات طلب المصادقة الاحتيالي (CSRF) مثل ملفات تعريف الارتباط التي تم ضبطها على SameSite=Lax/Strict | سنعدّل الشرح والمواصفات لتوضيح المعاني والإجراءات الوقائية التي تقدّمها ملفات تعريف الارتباط المقسّمة. |
FedCM
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| واجهة المستخدم والأمان | ملاحظات بأنّ واجهة مستخدم FedCM تشبه إلى حد كبير واجهة تسجيل الدخول السابقة بنقرة واحدة من Google، ومن الصعب قياس أداء FedCM بسبب عدم توفّر ميزة تتبُّع العرض السلبي، واقتراح لاستخدام لغة أكثر وضوحًا في المستندات المتعلّقة بميزة PKCE | نحن نتواصل بنشاط مع الجهات المعنية لمعالجة ملاحظاتهم. تشمل مجالات المناقشة الجارية طرق توفير مقاييس أفضل لموفّري الهوية للسماح لهم بتتبُّع أداء FedCM، والتحسينات المحتملة لمعالجة حالات الاستخدام الجديدة لواجهة برمجة التطبيقات FedCM في ما يتعلّق بحالات استخدام الاشتراكات. |
| استخدام واجهة برمجة التطبيقات | عندما يُعيد المستخدم تحميل الصفحة ويطلب navigator.credentials.get لتسجيل الدخول، تظهر نافذة منبثقة تطلب من المستخدم النقر للمتابعة، ما يؤدي إلى تأخير يؤثر في تجربة المستخدم. هل يمكن للأطراف المعتمَدة تخزين الرمز المميّز مؤقتًا الذي يعرضه navigator.credentials.get لتحسين تجربة المستخدم؟ | يمكن لموفّري خدمات الربط استخدام ملفات تعريف الارتباط الخاصة بهم لتخزين الرمز المميّز. يمكن لخدمات الربط بالحساب بعد ذلك التحقّق من ملفات تعريف الارتباط الخاصة بها لتحديد ما إذا كان المستخدم مسجّلاً الدخول قبل استدعاء navigator.credentials.get. يمكنك الاطّلاع على مزيد من التفاصيل هنا. |
| اختيار متعدّد لمزوّدي الهوية | كيف سيعرض المتصفّح خيارات تسجيل الدخول لموفّري هوية متعدّدين في FedCM؟ | تتضمّن مستندات المطوّرين معلومات حول كيفية عرض مورّدي خدمات التعريف المتعدّدين. يمكن للجهات المعنية تجربة هذه الوظيفة من خلال تفعيل العلامة fedcm-multi-idp في chrome://flags. |
| المتصفّحات وموفّري خدمات التعريف | هل يمكن لمتصفّح، مثل Chrome، أن يعمل كمسؤول عن الهوية؟ يمكن للمتصفّحات استخدام بيانات الحسابات والملفات الشخصية المخزّنة كمصدر موثوق للمصادقة. | بما أنّه يمكن تعديل المتصفّحات (مثلاً من خلال الإضافات)، لا يمكن الوثوق بأيّ ادعاءات بشأن إثبات ملكية عنوان البريد الإلكتروني يجريها المتصفّح مباشرةً بدون إجراء عملية إثبات ملكية إضافية تستند إلى الخادم. ولذلك، لا يُنصح باستخدام حلّ يعتمد على العميل فقط. لقد ناقشنا هذه المشكلة بالتفصيل هنا. |
| مواصفات واجهة برمجة التطبيقات | مناقشة حول ما إذا كان يجب أن تكون المَعلمة لخوارزمية IdentityCredential.disconnect() مطلوبة أو اختيارية | نودّ إعلامك بأنّه تمّ الآن إصلاح هذه المشكلة. ويمكن الاطّلاع على مزيد من التفاصيل هنا. |
| أمان واجهة برمجة التطبيقات | مخاوف بشأن تسرُّب الرمز المميّز في عملية تسجيل الدخول إلى FedCM إذا كان لدى مقدّم خدمات الاعتماد ثغرة XSS يمكن للمهاجم تنفيذ navigator.credentials.get في رمز برمجي ضار للحصول على الرمز المميّز. | لا تؤدي FedCM إلى إنشاء مخاطر جديدة لهجوم XSS، فهذه المخاطر متأصلة في تطبيقات الويب وبروتوكولات المصادقة الحالية. للحدّ من هذه المخاطر، على مقدّمي خدمات الربط التحقّق من مطالبة aud في الرموز المميّزة للتعريف وقبول الإثباتات الصادرة من مصدرهم فقط. كما هو موضّح هنا، هناك أفضل الممارسات الراسخة على نطاق واسع لتأمين عملية تبادل الرموز المميّزة الحالية والمتوفّرة للاستخدام مع FedCM. بالإضافة إلى ذلك، يمكن استخدام واجهة برمجة التطبيقات Storage Access API مع FedCM، ويتم منح طلبات البيانات من واجهة برمجة التطبيقات Storage Access API تلقائيًا عند إجراء طلب سابق من FedCM. من المفترض أن يؤدي ذلك إلى تفعيل مسار إعادة التوجيه المضمّن الذي تمت مناقشته في مشكلة GitHub. |
| مواصفات واجهة برمجة التطبيقات | client_metadata_endpoint هو حقل مطلوب في استجابة نقطة نهاية الإعدادات لـ FedCM. العنصر الفارغ هو استجابة صالحة، ويتجاهل Chromium استجابة 404 بدون إشعار، ما يشير إلى أنّه يتم التعامل مع نقطة النهاية على أنّها اختيارية في الممارسة العملية. | نوافق على أنّه يمكن تغيير المواصفات لتعكس ذلك وجعل client_metadata_endpoint حقلًا اختياريًا. |
| استخدام واجهة برمجة التطبيقات | المخاوف بشأن صعوبة اختبار عمليات تنفيذ FedCM بسبب واجهات المستخدم التي تتحكّم فيها المتصفّحات ولا يمكن الوصول إليها من خلال DOM | نوفّر واجهات برمجة تطبيقات لتشغيل المتصفّح من أجل اختبار الرجوع إلى الخلف، ما قد يعالج هذه المخاوف. يمكنك الاطّلاع على مستندات واجهات برمجة التطبيقات هذه هنا. |
| مواصفات واجهة برمجة التطبيقات | لم يتم توثيق المَعلمة login_url، وهي جزء مطلوب من استجابة نقطة نهاية الإعداد، في القسم 3.2 من المواصفات. | لقد أرسلنا تعديلًا على المستندات لتضمين المَعلمة login_url في القسم 3.2. |
| مواصفات واجهة برمجة التطبيقات | قلق بشأن اتجاه تتبُّع محتمل في FedCM يمكن لموفِّر الهوية إدراج المعرّفات كمَعلمات مسار في نقاط النهاية المحدّدة في استجابة نقطة نهاية الإعداد (accounts_endpoint وclient_metadata_endpoint) واستخدام هذه المعرّفات لربط طلبات البيانات الوصفية للحساب والعميل. | على الرغم من أنّه ليس لدينا دليل على أنّ موفّري خدمات تحديد الهوية يُدخلون أرقام تعريف في نقاط النهاية هذه، نحن ننظر بنشاط في تدابير التخفيف لحلّ هذه المشكلة هنا. |
مكافحة المحتوى غير المرغوب فيه والاحتيال
Private State Tokens API (وواجهات برمجة التطبيقات الأخرى)
لم يتم تلقّي أي ملاحظات هذا الربع.