تقرير ربع سنوي للربع الثاني والثالث من عام 2024 يلخّص الملاحظات التي تم تلقّيها بشأن المنظومة المتكاملة بشأن مقترحات "مبادرة حماية الخصوصية" وردّ Chrome عليها.
كجزء من التزاماتها تجاه هيئة CMA، وافقت Google على تقديم تقارير ربع سنوية علانية عن عملية تفاعل الجهات المعنية باقتراحات "مبادرة حماية الخصوصية" (يُرجى الرجوع إلى الفقرتين 12 و17(ج)(2) من الالتزامات). في 22 تموز (يوليو) 2024، أعلنت Google أنّها لن تُوقِف نهائيًا ملفات تعريف الارتباط التابعة لجهات خارجية في Chrome، واقترحت بدلاً من ذلك تقديم نهج معدَّل لتعزيز خيارات المستخدم. لذلك، وبموافقة هيئة CMA، لم ترسِل Google تقريرًا علنيًا عن الربع الثاني من عام 2024 إلى هيئة CMA من أجل منح الوقت الكافي لكل من Google وهيئة CMA لأخذ تداعيات إعلان Google في الاعتبار.
يتم إنشاء تقارير الملخّصات هذه حول الملاحظات بشأن "مبادرة حماية الخصوصية" من خلال تجميع الملاحظات التي تلقّاها Chrome من المصادر المختلفة كما هو موضّح في نظرة عامة على الملاحظات، بما في ذلك على سبيل المثال لا الحصر: GitHub المشاكل، ونموذج الملاحظات المتاح على privacysandbox.com، والاجتماعات مع الجهات المعنيّة في المجال، ومنتديات معايير الويب. يرحّب فريق Chrome بالملاحظات التي يتم تلقّيها من المنظومة المتكاملة ويستكشف بنشاط طرق دمج الدروس المستفادة في قرارات التصميم.
يتم ترتيب مواضيع الملاحظات حسب مدى الانتشار وفقًا لواجهة برمجة التطبيقات. ويتم ذلك من خلال جمع ملاحظات فريق Chrome حول موضوع معيّن وتنظيمها بترتيب تنازلي حسب الكمية. تم تحديد موضوعات الملاحظات الشائعة من خلال مراجعة موضوعات المناقشة في الاجتماعات العامة (W3C وPatCG وIETF) والملاحظات المباشرة وGitHub والأسئلة الشائعة التي تظهر من خلال فرق Google الداخلية والنماذج العامة.
وبشكل أكثر تحديدًا، تمت مراجعة محاضر اجتماعات الهيئات القياسية على الويب، وللحصول على ملاحظات مباشرة، تمت مراجعة سجلات Google للاجتماعات الفردية مع الأطراف المعنية، والرسائل الإلكترونية التي يتلقّاها المهندسون الفرديين، والقائمة البريدية لواجهة برمجة التطبيقات، ونموذج الملاحظات العامة. بعد ذلك، نسّقت Google بين الفِرق المشاركة في أنشطة التواصل المختلفة هذه لتحديد مدى رواج المواضيع التي تظهر في ما يتعلّق بكل واجهة برمجة تطبيقات.
تم إعداد التفسيرات لردود Chrome على الملاحظات من الأسئلة الشائعة المنشورة والردود الفعلية المقدَّمة على المشكلات التي تطرحها الجهات المعنية، وتحديد الموضع خصيصًا لأغراض تمرين إعداد التقارير العام هذا. استنادًا إلى التركيز الحالي على التطوير والاختبار، تلقّينا أسئلة وملاحظات خاصةً بشأن واجهات برمجة التطبيقات Topics API وProtected Audience API وAttribution Reporting API.
قد لا يتم النظر في الملاحظات التي يتم تلقّيها بعد انتهاء فترة إعداد التقارير الحالية كاستجابة من فريق Chrome.
مسرد الاختصارات
- ARA
- Attribution Reporting API
- ملفات تعريف الارتباط في الحالة المقسَّمة المنفصلة (CHIPS)
- ملفات تعريف الارتباط في الحالة المقسَّمة المنفصلة
- معالِج الإشارات الرقمية (DSP)
- المنصة جانب الطلب
- FedCM
- إدارة بيانات الاعتماد الموحّدة
- عدد اللقطات في الثانية
- مجموعات منتجات الطرف الأول
- مكتب الإعلانات التفاعلية (IAB)
- Interactive Advertising Bureau
- IDP
- موفِّر الهوية
- مجموعة مهندسي شبكة الإنترنت (IETF)
- فريق فريق هندسة الإنترنت
- عنوان IP
- عنوان بروتوكول الإنترنت
- openRTB
- عروض الأسعار في الوقت الفعلي
- الوقت بدل الضائع
- فترة التجربة في Origin
- واجهة برمجة تطبيقات PAT
- Protected Audience API (المعروفة سابقًا باسم FLEDGE)
- PatCG
- مجموعة منتدى تكنولوجيا الإعلانات الخاصة
- RP
- جهة الاعتماد
- RWS
- مجموعات المواقع الإلكترونية ذات الصلة (المعروفة سابقًا باسم "مجموعات نطاقات الطرف الأول")
- SSP
- وسيط عرض إعلانات المورّدين
- بيئة تنفيذ موثوقة (TEE)
- بيئة تنفيذ موثوقة
- UA
- سلسلة وكيل المستخدم
- UA-CH
- تعديلات برنامج وكيل المستخدم
- W3C
- اتحاد شبكة الويب العالمية
- WIPB
- إخفاء عناوين IP عمدًا
ملاحظات عامة، لا يلزم تحديد واجهة برمجة تطبيقات/تقنية
| موضوع الملاحظات | ملخّص | ردّ Chrome |
|---|---|---|
| الإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية | ما هي خطط Google بشأن 3PCD، وهل تم تقييم التأثيرات على المدى الطويل في مجال الإعلان الرقمي؟ | نقترح نهجًا معدّلاً يعزّز خيارات المستخدم. وكما هو موضّح هنا، بدلاً من إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا، سنقدّم تجربة جديدة في Chrome تتيح للمستخدمين إجراء اختيار مدروس ينطبق على جميع عمليات تصفّح الويب، وسيتمكنون من تعديل هذا الخيار في أي وقت. نحن نناقش هذا المسار الجديد مع الجهات التنظيمية، وسنتواصل مع الجهات المعنية في المجال قبل طرح هذه الميزة. |
| اختيار المستخدم | لقد أثّر إعلان خيار المستخدم في اهتمام المنظومة المتكاملة باعتماد حلول "مبادرة حماية الخصوصية". هناك ملاحظات متضاربة بشأن إعلان خيار المستخدم، بما في ذلك طلبات ميزات مثل إمكانات المراقبة. | في إطار النهج المعدَّل الذي يعتمد على اختيار المستخدمين، ما زال من المهم أن يتوفّر للمطوّرين بدائل لتحسين الخصوصية لاستخدام المعرّفات على مواقع إلكترونية متعددة. على الرغم من أنّه ليس لدينا حتى الآن تفاصيل يمكننا مشاركتها حول شكل التجربة الجديدة، نتوقع زيادة كبيرة في عدد الزيارات التي لا تستخدم ملفات تعريف الارتباط في Chrome. وهذا يعني أنّ واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" تظل مهمة للأنشطة التجارية. سنواصل الاستثمار في تقنيات "مبادرة حماية الخصوصية" لتحسين الخصوصية والفائدة. |
| واجهة مستخدم "خيار المستخدم" | أسئلة حول المخطط الزمني لميزات إيقاف الميزة/الموافقة، ونوع خيار المستخدم الذي يتم النظر فيه، وكيفية تأثير واجهة المستخدم في بيئات الاختبار الآلي | ليس لدينا معلومات جديدة حول الجدول الزمني يمكننا مشاركتها في الوقت الحالي. بعد أن قرّرنا عدم مواصلة تطوير 3PCD، أردنا تقديم تعديل على المنظومة المتكاملة في أقرب وقت ممكن. سنشارك معك آخر المعلومات حول الموعد النهائي لطرح ميزة "اختيار المستخدِم" فور توفّرها. |
| اختبار Chrome | طلب مواصلة توفُّر تصنيفات الاختبار التي يوفّرها Chrome لقياس مدى اعتماد السوق والتأثير الاقتصادي لميزة "التصميم التجريبي للمنتجات في 360 درجة" بعد النصف الأول من عام 2024 | ندرك أنّ المختبِرين سيرغبون في مواصلة استخدام مجموعات المتصفّحات المصنّفة للاختبار والتنسيق حتى مع انتهاء فترة الاختبار الذي يسهِّله Chrome لعام 2024. إنّنا نقيّم الخطوات التالية للتصنيفات في ضوء الإشعار باختيار المستخدم. في الوقت الحالي، أعلن فريق Chrome عن نية توسيع نطاق الدعم لمجموعات المتصفّحات المصنّفة حتى الإصدار 132 من Chrome، والذي سيستمر حتى كانون الثاني (يناير) 2025. |
| "مبادرة حماية الخصوصية" على Android | إنّ "مبادرة حماية الخصوصية" على Android و"مبادرة حماية الخصوصية" على Chrome مرتبطتان بشكل وثيق، ولا يمكننا تقييم "مبادرة حماية الخصوصية" بشكل صحيح بدون Android. إنّ رحلة العميل المعتادة، التي تتضمّن جوانب متعددة الأجهزة ومتعددة اللمس، هي أمر مهم لكل من "مبادرة حماية الخصوصية" على Chrome و"مبادرة حماية الخصوصية" على Android. | يُرجى العِلم أنّ "مبادرة حماية الخصوصية" على Android لا تندرج ضمن نطاق التزامات Google تجاه "هيئة الأسواق الرقمية". إذا كانت الملاحظات تتعلّق بالمخططات الزمنية لطرح Android وعمليات الطرح، ليس لدينا أي معلومات جديدة يمكننا مشاركتها في الوقت الحالي، باستثناء أنّنا نواصل تطوير Android، والذي نتعامل معه كمسار عمل مستقل لتحسين الخصوصية. كما ذكرنا سابقًا، سيعتمد مدى توفّر واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" على Android أيضًا على معدّل تحديث المستخدمين لأجهزتهم، وهو معدّل لا تتحكّم فيه Google. |
| عدد الزيارات في الوضع "ب" محدود | كانت عدد الزيارات المتاحة من الوضع "ب" في مزاد الإعلانات أقل من المتوقع. | هناك عدة أسباب لحدوث انخفاض في حجم المزادات لواجهة برمجة التطبيقات Protected Audience API (PA API) عن المتوقع، على سبيل المثال: - إنّ الشركات التي نعرفها والتي دمجت واجهة برمجة التطبيقات PA API لم تُدرِج سوى أشكال إعلانات البانر. - قد لا تبدأ منصّات عرض المبيعات مزادًا في بعض الأحيان. - قد لا يتضمّن المتصفّح مجموعات الاهتمامات. - قد لا تتوفّر عروض أسعار. مع ذلك، لا نعلم بوجود أي مستخدم حاول اختبار PA API ولم يتلقّ أي زيارات. |
| ظهور انقطاع الخدمة | إمكانية الاطّلاع على حالات الانقطاع والمشاكل التي تؤثّر في واجهات برمجة التطبيقات في "مبادرة حماية الخصوصية" | تتوفَّر صفحة حالة علنية لواجهات برمجة تطبيقات "مبادرة حماية الخصوصية" التي تتضمّن خدمات خارج المتصفِّح. يولي فريق Chrome الأولوية القصوى لموثوقية منصتنا وجميع واجهات برمجة التطبيقات المُهمّة التي تستخدمها المواقع الإلكترونية والخدمات الرئيسية على الإنترنت، بما في ذلك تقنيات "مبادرة حماية الخصوصية". وحتى الآن، حدث انقطاع في الخدمة مرّة واحدة فقط. كان ذلك مرتبطًا بإعداد مؤقت للاختبار بنسبة %1. قريبًا، لن تكون الإعدادات التجريبية المعنيّة بهذا الانقطاع ضرورية، لذا نحن على ثقة من أنّ هذه المشكلة لن تحدث بعد تفعيل واجهات برمجة التطبيقات بالطريقة المعتادة في Chrome. |
| دراسة الرسم البياني لملفات تعريف الارتباط | ما هو رأي Chrome في طريقة CookieGraph الموضّحة في هذه الورقة ضمن إطار عمل "مبادرة حماية الخصوصية"؟ | تطرح الورقة بعض النقاط المثيرة للاهتمام حول رصد ملفات تعريف الارتباط التابعة للطرف الأول ومدى انتشارها، والتي يتم ضبطها من خلال نطاقات مختلفة عن النطاقات التي يزورها المستخدم. كما تشير الورقة البحثية، فإنّ ملفات تعريف الارتباط هذه مفيدة للغاية لجمع الإحصاءات والمعلومات عن كيفية تفاعل المستخدِمين مع الموقع الإلكتروني. وهذه البيانات ضرورية للمطوّرين لتقديم تجربة تصفح أفضل للمستخدمين. الوسيطة الرئيسية للورقة تحتوي على عيوب لأنها تعتبر ملفات تعريف الارتباط التابعة للطرف الأول متجهًا للتتبُّع على مواقع إلكترونية متعددة. ومع ذلك، لا ينطبق هذا الأمر إلا في ظل الافتراضات الشديدة الصرامة الموضّحة في البحث:
يُرجى العِلم أنّ هذه هي متّجهات إعادة تحديد الهوية التي يمكن استغلالها بدون استخدام ملفات تعريف الارتباط التابعة للطرف الأول (على سبيل المثال، من خلال مشاركة البيانات من جهة الخادم)، ويجب معالجتها بشكل منفصل عن جهودنا الحالية التي تركّز على آليات التتبّع المستندة إلى الحالة، مثل ملفات تعريف الارتباط التابعة لجهة خارجية. أخيرًا، نريد الإشارة إلى أنّ الورقة تساوي بين ملفات تعريف ارتباط الإحصاءات والإعلانات وملفات تعريف ارتباط التتبّع وملفات تعريف الارتباط اللازمة بدقة على أنّها ملفات تعريف ارتباط غير تتبُّعية، وهو ما قد لا يكون صحيحًا بالضرورة. في الواقع، قد تقتصر إحصاءات الطرف الأول أو خدمات المورّدين المقسّمة حسب الموقع الإلكتروني، مثل التطبيقات المصغّرة لتحديد موقع المتجر أو التطبيقات المصغّرة للمحادثة أو ملفات تعريف ارتباط موازنة التحميل، غالبًا على نطاق واحد فقط، وعلى العكس من ذلك، قد يتم تتبُّع بعض ملفات تعريف الارتباط الضرورية للغاية على مستوى المواقع الإلكترونية لأغراض مكافحة الاحتيال. |
| تغييرات تجربة المستخدم | إنّ تغييرات تجربة المستخدم في الإصدار 112 من Chrome التي تضع عناصر التحكّم في ملفات تعريف الارتباط التابعة للطرف الأول ضمن قسم "بيانات المواقع الإلكترونية على الجهاز" في إعدادات Chrome قد تصعِّب على المستخدمين حظر جميع ملفات تعريف الارتباط. | تم إجراء هذا التغيير في إطار جهودنا لفصل عناصر التحكّم في 3PC (أو مساحة التخزين غير المقسّمة) ورفع مستوى أدائها عن جميع الأنواع الأخرى من بيانات المواقع الإلكترونية. تم تصعيد عناصر التحكّم في ملفات تعريف الارتباط التابعة لجهات خارجية ضمن لوحة "الخصوصية والأمان"، في حين تم تجميع عناصر التحكّم في ملفات تعريف الارتباط التابعة للطرف الأول وجميع الأنواع الأخرى من بيانات المواقع الإلكترونية - التي تعتمد عليها عادةً وظائف الموقع الإلكتروني المهمة - ضمن "بيانات المواقع الإلكترونية على الجهاز فقط". سنواصل مراقبة الملاحظات والآراء حول هذا الموضوع، ولكننا نعتقد أنّ عملية الفصل الحالية تحقّق توازنًا جيدًا بين إمكانية العثور على عناصر التحكّم في الخصوصية المهمة والحفاظ على تجربة تصفّح فعّالة. |
| الفوترة والدفع | لا يتم اختبار الفوترة والدفعات بالكامل لأنّ المختبِرين يركّزون بشكل أكبر على اختبار مجالات أخرى من واجهات برمجة التطبيقات في "مبادرة حماية الخصوصية". | يختار المطوّرون والشركات الوقت والمحتوى الذي يريدون اختباره. تتوفّر واجهات برمجة التطبيقات بشكل عام للاختبار وبدأت منذ أيلول (سبتمبر) 2023. |
| الاختبار | لا يتم تصنيف جميع الزيارات التجريبية التي تتلقّاها منصّات إدارة الأداء من منصّات عرض الإعلانات. أبلَغ بعض مقدّمي خدمة البريد الإلكتروني أنّ نسبة مرّات الظهور غير المصنَّفة قد تختلف حسب مجموعات التجربة والتحكّم. | لا يمكن لمتصفّح Chrome التحكّم في ما إذا كانت الشركات تعيد توجيه التصنيفات في طلبات عروض الأسعار. نوفّر طريقة للحصول على تصنيف من المتصفّح. وعلى المنظومة المتكاملة إرسال التصنيفات إلى الشركاء إذا لم يتمكّن شركاؤهم من قراءة هذه التصنيفات مباشرةً. |
| 3PCD على Android WebView | طلب إرشادات حول تفعيل علامة "اختبار الإيقاف النهائي التدريجي لملفات تعريف الارتباط التابعة لجهات خارجية" في Android WebView لاختبار الإيقاف النهائي | يتم حظر ملفات تعريف الارتباط التابعة لجهات خارجية تلقائيًا في Android WebView. |
| الخصوصية التفاضلية للحدّ من المخاطر في "تدريب النماذج" | لماذا يتم استخدام أسلوب "الخصوصية التفاضلية" في تدريب النماذج؟ | إنّ الخصوصية التفاضلية، إلى جانب بيئات التنفيذ الموثوق بها (TEE)، ضرورية في تدريب النماذج لمنع تسرُّب البيانات وتأمين المعلومات الحسّاسة ضد التهديدات. يضمن هذا المنهج عدم تمكّن أوزان النماذج من الكشف عن بيانات المستخدِمين الفرديين. |
التسجيل والإقرار
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| التسجيل | طلب توضيح بشأن كيفية عمل تسجيل المصادقة بين المصدر المسجَّل وأصل تكنولوجيا الإعلان مع النطاق الفرعي الذي يتضمّن البادئة www | ما على تكنولوجيا الإعلان سوى الإعداد على https://example.com. عند تقديم المصادقة في https://example.com/.well-known/privacy-sandbox-attestations.json، تتم تغطية https://www.example.com لأنّه نطاق فرعي. |
| مواصفات واجهة برمجة التطبيقات | اقتراح إضافة مخطط JSON لملف المصادقة إلى المستودع. | نحن بصدد تقييم هذا الاقتراح ونرحّب بملاحظاتك الإضافية هنا. |
عرض محتوى وإعلانات ذات صلة
المواضيع
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| ترجيح المواضيع | إنّ أهم ما يجب فهمه في "المواضيع" هو ندرة إشارة معيّنة. من المفترض أن يتم تطوير التصميم الحالي للسماح بإضافة قيمة وزن بجانب كل موضوع تم رصده. سيكون المرجّح هو المرجّح النسبي لموضوع معيّن لمتصفّح معيّن مقارنةً بجميع المتصفّحات التي تستخدم الموضوع. | نود أن نفهم المزيد عن سبب ندرة الإشارة عن الإشارة الأكثر أهمية. نرحب بملاحظات إضافية من المنظومة المتكاملة حول فائدة حالة الاستخدام هذه هنا. |
| موثوقية المواضيع | على Google تقديم ضمانات أقوى بشأن موثوقية "المواضيع" بمرور الوقت. | سنواصل إجراء تغييرات على واجهات برمجة التطبيقات استنادًا إلى الملاحظات الواردة من المنظومة المتكاملة، وسنناقشها علنًا قبل إجرائها. سيقدّم اقتراحنا لبنية إدارة معدَّلة ضمانات إضافية. |
| المصنِّف | غالبًا ما يتم تصنيف مواقع الناشرين الإلكترونية بشكل خاطئ أو يتم إسناد مواضيع ذات مستوى عالٍ جدًا إليها لا تخدم أي أغراض مفيدة. | كما هو موضّح في الشرح المفصّل عن تصنيف المواضيع، يتم تصنيف المواقع الإلكترونية من خلال مزيج من قائمة إلغاء مصنّفة ينشئها فريقنا، وتتضمّن المواقع الإلكترونية الأكثر رواجًا، ونموذج تعلُّم آلة على الجهاز. يواصل Chrome تقييم خيارات المواقع الإلكترونية للمساهمة في تصنيف Topics. يجب موازنة أي تحسينات على الأداة مع مخاطر الخصوصية وإساءة الاستخدام. على سبيل المثال، تشمل بعض المخاطر ما يلي: - المواقع الإلكترونية التي تستخدم التصنيف الذاتي كطريقة لترميز معاني مختلفة (قد تكون حسّاسة) في المواضيع، و - المواقع الإلكترونية التي تهاجم المواضيع لتقليل فائدتها للآخرين (مثل إرسال رسائل غير مرغوب فيها إلى مواضيع المستخدمين من خلال إدخال معلومات غير ذات صلة). يمكن للمستخدمين فحص هذه المكوّنات باستخدام أدوات متاحة من خلال chrome://topics-internals أو هذا التعاون. من خلال الاختبارات، نتوقّع أن يتحسن التصنيف بمرور الوقت، ونرحّب بملاحظاتك بشأن أمثلة على المواقع الإلكترونية التي قد تكون مصنّفة بشكل خاطئ. |
| سؤال حول واجهة برمجة التطبيقات | المخاوف من أنّ Topics API تمنح مزايا دائمة ومضادة للمنافسة لخدمات عرض الإعلانات التي تحقّق الربح من المحتوى السيئ | كما هو الحال مع ملفات تعريف الارتباط التابعة لجهات خارجية، لا يهتم المتصفّح بالجهة التي يعرض لها المواضيع، ما دام هذا الكيان مسجّلاً وموثَّقًا. |
| (تم الإبلاغ عنها أيضًا في الربع سنوية السابقة) الفائدة لأنواع مختلفة من أصحاب المصلحة |
بما أنّ "تصنيف المواضيع" لا يستخدم حاليًا سوى اسم مضيف الصفحة لتحديد المواضيع ذات الصلة، تساهم المواقع الإلكترونية الكبيرة التي تتضمّن محتوى متنوّعًا في مواضيع عامة، بينما تساهم المواقع الإلكترونية الصغيرة في مواضيع محددة ذات قيمة إعلانية أكبر. | ردّنا مشابه للردّ في الربع السابق: كما هو الحال مع المواقع الإلكترونية التي تستخدم تقنية قياس الأداء من الجهات الخارجية، هناك اختلاف في قيمة المعلومات التي تساهم بها المواقع الإلكترونية المختلفة. إنّ المواقع الإلكترونية التي تتناول مواضيع محدّدة غير متّسقة في مساهمتها في القيمة: فليست كل المواقع الإلكترونية التي تتناول مواضيع محدّدة تتضمّن سياقًا ذي قيمة تجارية، وبالتالي تساهم بقيمة أقل. هذه هي المواقع الإلكترونية التي ستستفيد من Topics API. لقد فكّرنا في إمكانية إجراء التصنيفات على مستوى الصفحة بدلاً من مستوى الموقع الإلكتروني، ولكن هناك عدد من المخاوف المهمة المتعلقة بالخصوصية والأمان في ما يتعلّق بهذا التصنيف. |
| المصنِّف | غالبًا ما يتم تصنيف المواقع الإلكترونية الأصغر حجمًا بشكل غير دقيق أو لا يتم تصنيفها على الإطلاق، وبالتالي لا يمكنها المشاركة في عملية تبادل القيمة. | في ما يتعلّق بالضرر المزعوم، لا تتعرّض المواقع الإلكترونية المحدّدة التي يُحتمل أن تكون مصنّفة بشكل خاطئ لضرر أكبر من المواقع الإلكترونية الأخرى، نظرًا لأنّ المعلومات السياقية للموقع الإلكتروني ستكون متاحة دائمًا للمزادات على موقعه الإلكتروني، ما سيقدّم معلومات مشابهة للمواضيع الصحيحة، حتى في حال التصنيف الخاطئ. يتم استخدام المواضيع عادةً لجمع معلومات إعلانية قد تكون مفيدة من مواقع إلكترونية خارجية بدلاً من مواقعهم الإلكترونية. |
| إصدار التصنيف | كيف يمكننا الوصول إلى إصدار التصنيف لضمان التوافق مع الإصدارات السابقة؟ | إصدار التصنيف هو جزء من عنوان الطلب المُرسَل مع طلب جلب تم تفعيل المواضيع فيه. على سبيل المثال، إذا كان العنوان هو "(1 2);v=chrome.1:2:5, ();p=P000000000"، يكون الإصدار هو chrome.1:1:2. حيث يشير chrome.1 إلى إصدار الضبط، ويشير 2 إلى إصدار التصنيف، ويشير 5 إلى إصدار النموذج. هذه السمة مذكورة في المواصفات، وقد تمّت إضافتها أيضًا إلى الشرح. |
| بيانات المواضيع | طلب توضيح حول كيفية تعديل بيانات Topics | لم يتم تحديد تعديل التصنيف. ويمنح ذلك مورّدي المتصفّحات مرونة في التنفيذ. بعد ذلك، إليك القواعد الاستقرائية لتعديل تصنيف Chrome من الإصدار 1 إلى الإصدار 2: - يتم الاحتفاظ بشجرة تصنيف واحدة للمواضيع من الإصدارَين 1 و2. - يمثّل رقم تعريف الموضوع نفسه المعنى نفسه. - تنمو الشجرة فقط، أي أنّها تضيف مواضيع أو روابط جديدة، ولا تتقلّص أبدًا. - مع ذلك، قد تكون بعض المواضيع أو الروابط "غير نشطة" في إصدار ما، ما قد يعطي انطباعًا بأنّه حذف أو إعادة تنظيم. أمثلة: - أصبحت "الشاحنات الصغيرة" و"السيارات الرياضية المتعددة الأغراض" تستخدم الآن "الشاحنات والسيارات الرياضية المتعددة الأغراض" باعتبارها شركة رئيسية وسيطة. - أصبح "دراسة اللغة الأجنبية" الآن يحتوي على "التعليم" كعنصر رئيسي ثانٍ، ويصبح العنصر الرئيسي الأصلي "مرجع" غير نشط. تأثير المواضيع "غير النشطة": لن يتم استخدام هذه المواضيع للتصنيف الجديد. ومع ذلك، لا يزال يتم أخذها في الاعتبار عند فرض عمليات حظر المستخدمين: إذا حظر مستخدم موضوعًا في الإصدار 1، ستبقى المواضيع الفرعية محظورة في الإصدار 2 (حتى إذا كان الموضوع الفرعي يظهر ضمن موضوع رئيسي مختلف في الإصدار 2). |
| المصنِّف | نسعى إلى فهم الأسباب وأي خيارات تصحيحية متاحة بشأن التصنيفات الخاطئة. | أولاً، نريد أن نشير إلى أنّ تحديد Chrome لمواضيع الموقع الإلكتروني هو لاستخدامه فقط كمدخلات لخوارزمية Topics من أجل تحديد اهتمامات المستخدم لأغراض إعلانية. ولم يتم تطويره لأغراض تصنيف أخرى أكثر عمومية. نحن مهتمون بدقة نموذج التصنيف بشكل عام، ونحاول تحسين دقته أو تذكره كلما أمكن ذلك، ولكن على المستوى العالمي بدلاً من مستوى تصنيف الموقع الإلكتروني الفردي. ويرجع ذلك إلى أنّ التصنيف الخاطئ، في حال حدوثه، لا يضر بالموقع الإلكتروني الفردي الذي تم تصنيفه بشكل خاطئ، بل يقلل من جودة إشارة "المواضيع" عند اختيار إعلان على مواقع إلكترونية أخرى. عند اختيار الإعلانات على الموقع الإلكتروني المصنَّف بشكل خاطئ، تكون المواضيع الحقيقية للموقع الإلكتروني معروفة له، ويمكن استخدامها كمدخلات لطلبات البحث الإعلانية. نرحب بملاحظاتك الإضافية هنا. |
| اختبار واجهة برمجة التطبيقات | هل يمكن اختبار Topics وواجهات برمجة تطبيقات "مبادرة حماية الخصوصية" بشكل عام باستخدام Chromium؟ | لا يتم شحن Topics API من خلال Chromium، بل يتم شحنها مع Chrome. |
| Topics Caller | طلب تحسين القيمة المضافة لـ Topics التي تستفيد من خدمات TEE لتقنيات الإعلان لدعم تكلفة التحليل المتقدم بطرق تتوافق مع الخصوصية. | وقد ردّنا على ملاحظات مشابهة هنا. لقد أخذنا معدّل التكرار العكسي في الاعتبار، وبعد وضع نماذج له، تبيّن لنا أنّه لا يرتبط بشكل جيد بقيمة الموضوع وفقًا للقيمة التي قدّمها المشترون والبائعون. نرحب بملاحظاتك الإضافية هنا. |
| مواصفات واجهة برمجة التطبيقات | هل يمكن أن يؤدي إعداد المجموعة النموذجية للاهتمامات في المتصفّح إلى حظر Topics API؟ | لقد رددنا على هذه الملاحظات هنا. Topics API هي واجهة برمجة تطبيقات متطوّرة لـ FLoC، وتلتزم بسياسة أذونات FLoC. وفقًا لما هو موضّح في الشرح: "ملاحظة: ستحظر أيضًا العبارة القديمة Permissions-Policy: interest-cohort=() من FLoC احتساب المواضيع". |
| ترتيب المواضيع | عند الحصول على "أهم 5 مواضيع"، هل نحسب معدّل تكرار زيارات الموقع الإلكتروني استنادًا إلى كلّ متصل مؤهّل، أم نحسبه دائمًا استنادًا إلى سجلّات الزيارات الكاملة للمتصفّح؟ بالإضافة إلى ذلك، هل يتم ترتيب المواضيع بشكل إضافي لكل متصل على حدة؟ | ويستند ذلك إلى معدّل تكرار مجموعة فرعية من سجلّات التصفّح. لا يكون إدخال سجلّ التصفّح (الصفحة) مؤهّلاً للمشاركة إلا إذا كانت الصفحة تحتوي على مُرسِل طلب واحد على الأقل من Topics. يمكنك الاطّلاع على مزيد من التفاصيل حول تخزين سجلّ المواضيع هنا. كما هو موضّح في الإعلان عن التحسينات على Topics API، يعتمد الترتيب على معدّل التكرار، وكذلك على مستوى الأولوية الثنائي (اطّلِع على هذا الرابط وهذا الرابط للحصول على مزيد من التفاصيل). ومع ذلك، لا يعتمد ذلك على عدد المتصلين. يُرجى العِلم أنّ ذلك لا يعني أنّه يمكن لجميع المتصلين الحصول على أهم 5 مواضيع في الفترة التالية. وفقًا لما هو موضّح في الشرح، "يمكن فقط للمتصلين الذين لاحظوا زيارة المستخدِم لموقع إلكتروني عن الموضوع المعنيّ خلال الأسابيع الثلاثة الماضية تلقّي الموضوع". لا يحتاج المتصفّح إلى تتبُّع المتصل الذي رصد أهم 5 مواضيع (وفقًا لأهم 5 مواضيع تتضمّن نطاقات المتصل في المواصفات). نرحب بملاحظاتك الإضافية حول هذه المشكلة هنا. |
Protected Audience API (المعروفة سابقًا باسم FLEDGE)
| موضوع الملاحظات | ملخّص | ردّ Chrome |
|---|---|---|
| (تم الإبلاغ عنها أيضًا في الربع سنوية السابقة) التكاليف |
هل تشغيل وحدات TEE في السحب الإلكترونية المتاحة للجميع أكثر تكلفة مقارنةً بمراكز بيانات تكنولوجيا الإعلان داخل الشركة؟ | يستفيد نموذج الأمان الحالي لتقنية TEE من ممارسات عمليات تنفيذ السحابة العامة (اطّلِع على مزيد من التفاصيل في مستند الشرح الخاص بمتطلّبات تقنية TEE في السحابة العامة). على سبيل المثال، لا تحمي وحدات TEE الحالية المستندة إلى الأجهزة من جميع الهجمات المادية. لقد صمّم موفّرا السحابة العامة المعتمَدان حاليًا، وهما AWS وGoogle Cloud Platform، إجراءات وقائية للحدّ من مخاطر الوصول المادي، بما في ذلك من الموظفين. على الرغم من أنّ بعض تقنيات عرض الإعلانات قد ذكرت لنا أنّ تشغيل خدمات السحابة الإلكترونية أكثر تكلفة من مراكز بيانات تقنية عرض الإعلانات داخل الشركة، يتم تشغيل تقنيات عرض إعلانات أخرى على السحابة الإلكترونية العامة سواء كان ذلك بسبب التكلفة أو مزايا أخرى. نواصل تقييم خيارات توسيع نطاق توفّر تقنية TEE، بما في ذلك خارج خدمات السحابة الإلكترونية العامة. وفي إطار ذلك، نعمل على إجراء أبحاث حول مراكز البيانات على الموقع، ونتعاون مع المنظومة المتكاملة لاستكشاف الحلول المحتملة لتقديم هذا الدعم. في المرحلة الحالية من البحث، لا يمكننا ضمان أن يؤدّي ذلك إلى حلّ عملي للمنظومة المتكاملة. |
| PA API و"مدير إعلانات Google" | لا يمكن لخدمة "إدارة الأداء من Google" تحقيق نتيجة عادلة في السوق. يتعذّر على "مدير إعلانات Google" عرض الإعلانات في الوقت المناسب، وتسجيل عدد الإعلانات التي عرضها باستخدام PA API، ولا يتيح إمكانية الضبط بشأن الطريقة التي سيختارها لعرض إعلان، مثلاً عن طريق إيقاف PA API لمواضع إعلان معيّنة. | ردّ "مدير إعلانات Google": عمل فريق "مدير إعلانات Google" على تحسين وقت الاستجابة عند عرض الإعلانات من خلال PA API ولا يزال يعمل على ذلك، وذلك لكي تفوق الأرباح الإضافية التي يحقّقها الناشرون من طلب PA API أي تكاليف متكبّدة بسبب وقت الاستجابة الإضافي لمزاد PA API. تشير الاختبارات الأولية التي أجريناها إلى أنّ الناشرين يحقّقون أرباحًا صافية من PA API على الزيارات التي لا تتضمّن ملفّات تعريف الارتباط التابعة لجهة خارجية، ما يشير إلى أنّ الطلب الإضافي من PA API يفوق أي تكاليف بسبب وقت الاستجابة. ويمكن الاطّلاع على مزيد من التفاصيل حول النهج الذي نتّبعه في الأسئلة الشائعة. بالإضافة إلى ذلك، يوفّر "مدير إعلانات Google" للناشرين تقارير عن الإعلانات التي يتم عرضها من خلال PA API. ويشمل ذلك الإعلانات التي يتم عرضها عندما يكون "مدير إعلانات Google" بائعًا للمكونات، والإعلانات التي يتم عرضها من خلال بائعي مكونات آخرين عندما يكون "مدير إعلانات Google" بائعًا من المستوى الأعلى. يمكنك الاطّلاع على مزيد من التفاصيل حول الإبلاغ عن المحتوى في مركز المساعدة. أخيرًا، يسمح "مدير إعلانات Google" للناشرين بتفعيل استخدام واجهة برمجة التطبيقات PA API أو إيقافه في زياراتهم من خلال عنصر تحكّم في واجهة المستخدم (اطّلِع على مركز المساعدة لمعرفة التفاصيل). نحن منفتحون على النظر في الملاحظات بشأن المزيد من عناصر التحكّم التي قد يريدها الناشرون، وسنمنح الأولوية لأي طلبات ميزات بما يتوافق مع عملية تحديد الأولويات العادية للميزات. |
| PA API و"مدير إعلانات Google"/AdX | يبدو أنّ Google قد اتخذت موقفًا لن تشتري ببساطة أي مرات ظهور من واجهة برمجة تطبيقات PA إذا لم تتخذ "مدير إعلانات Google" قرار البيع النهائي بشأنها، تمامًا مثل "إعلانات Google" التي تشتريها من الشركة نفسها فقط. يبدو أنّ هذا الإجراء هو إساءة استخدام لمركز السوق، لأنّه يمكن أن تُرسِل "مدير إعلانات Google" أو AdX إعدادات مزاد المكوّنات إلى بائع بديل من المستوى الأعلى مثل أيّ تبادل آخر. | ردّ مدير منصة "إعلانات Google": هذا ليس موقف Google. تشتري منصّات الجهة المشترية من Google ("إعلانات Google" و"مساحة العرض والفيديو 360") مرّات الظهور من تبادلات غير تابعة لشركة Google. وينطبق ذلك على كلٍّ من مرّات الظهور من PA API ومرّات الظهور من غير PA API. |
| استجابة السوق | مخاوف Mozilla: حماية الجمهور من خلال Google Protected Audience Protect (وGoogle) أكثر من مجرد الحماية لك. | نحن نقدّر تقييم Mozilla وسنواصل التفاعل مع ملاحظات Mozilla في منتديات المعايير العامة. ويستند تقييمهم إلى أنّ التنفيذ الحالي لواجهة PA API لا يفرض بعد جميع إجراءات الحماية المخطَّط لها. لقد سعى نهجنا في طرح PA API إلى تحقيق التوازن الصحيح بين تشجيع الاستخدام وتنفيذ إجراءات حماية الخصوصية في أقرب وقت ممكن. وفي إطار ذلك، وضعنا خارطة طريق لفرض قيود الخصوصية بمرور الوقت، وذلك لتسهيل عمليات الدمج مع واجهات برمجة التطبيقات بشكل أفضل، بالإضافة إلى منحنا الوقت الكافي لجمع المزيد من الملاحظات التي يمكننا دمجها في وسائل الحماية المستقبلية (مثل ميزات VAST في "الإطارات المُغلقة"). نرحب أيضًا برسائل Mozilla الأخيرة بشأن نهجها الخاص بالخصوصية والإعلانات الرقمية: "يجب ألا تُتاح شبكة الإنترنت المجانية والمفتوحة على حساب الخصوصية" و"تحسين الإعلانات على الإنترنت من خلال المنتجات والبنية الأساسية". |
| (تمّ الإبلاغ عنها أيضًا في الأرباع السابقة) نتائج المزاد |
طلب مزاد واحد لعرض عناوين URL متعددة لعرض الإعلانات مع النتيجة المقابلة لها، ما يسهّل على الإعلانات المدمجة إزالة تكرار الإعلانات وتجنُّب مشاكل تجربة المستخدم ووقت الاستجابة | ردّنا مشابه للردّ في الربع السابق: لقد فكّرنا في مشاركة عدّة عناوين URL لعرض الإعلانات وتقييماتها المتعلّقة بها من مزاد واحد لواجهة برمجة التطبيقات PA API، ولكنّنا لم نفّذ ذلك بسبب مخاوف تتعلّق بالخصوصية. نحن نتفهّم الرغبة في تجنُّب عرض الإعلان نفسه لمرّات متعددة للمستخدم على صفحة واحدة، ونحن بصدد تقييم هذا الطلب. ونرحّب بملاحظات إضافية من المنظومة المتكاملة هنا بشأن الدعم الإضافي المطلوب في PA API لدعم حالة استخدام "الإعلانات المدمجة" على النحو الأمثل. |
| الأداء | مخاوف بشأن وقت الاستجابة الذي يؤثّر في PA API | لقد تلقّينا مخاوف بشأن وقت الاستجابة، وهذا هو أحد الأسباب التي دفعتنا إلى تطوير عدد من الميزات كجزء من PA API، ما سيتيح لخدمات عرض الإعلانات ضبط حدود على وقت استجابة وحدة معالجة الإدخال/الإخراج (DSP) بالإضافة إلى إجراء تحسينات يمكن أن تقلّل من وقت الاستجابة. لقد عدّلنا مؤخرًا دليل أفضل الممارسات المتعلّقة بوقت الاستجابة الذي يتضمّن مزيدًا من المعلومات حول كيفية الاستفادة من هذه الميزات. ونحن نواصل أيضًا تطوير تحسينات جديدة في وقت الاستجابة، ويمكن الاطّلاع على بعض منها هنا. |
| البائعون من المستوى الأعلى | على Google السماح للناشرين باختيار بائعي مزادات PA API بديلين من المستوى الأعلى. | لا تختلف واجهة برمجة تطبيقات PA API عن المستخدم الذي يبدأ مزادًا في التصاميم المخصّصة لبائع واحد والتصاميم المتعددة البائعين. تقتصر خيارات الشركات الفردية على إتاحة مزادات PA API وكيفية توفيرها. |
| (تم الإبلاغ عنها أيضًا في الربعَين السابقَين) الاستهداف السلبي |
طلب لحلّ حالة استخدام لا يريد فيها المعلِن عرض الإعلانات لشريحة جمهور معيّنة | نحن ندعم استهداف IG السلبي من خلال عروض أسعار إضافية (للمحتوى)، مما يفي بالاحتياجات التي لا يرغب المعلن في عرض إعلاناتها لجمهور معين. يمكنك الاطّلاع على التفاصيل في هذه المقالة التوضيحية وهذه المشكلة على GitHub. نحن نستكشف أيضًا حلولاً لتوفير الاستهداف السلبي لعروض الأسعار من واجهة برمجة التطبيقات المخصّصة للإعلانات، ونرحب بملاحظاتك الإضافية هنا. |
| (تم الإبلاغ عنها أيضًا في الربعَين السابقَين) الإعلانات المدمجة مع المحتوى |
طلب إتاحة استخدام "الإطار المحدود" للإعلانات المدمجة مع المحتوى | ندرس إمكانية إتاحة حالة الاستخدام هذه ونناقش الحلول والحلول الممكنة هنا. |
| WebView | نطلب توضيحًا بشأن السيناريو الذي لم يكن فيه IG المُدرَج في Chrome متاحًا للمزاد الذي تم تنفيذه على WebView. | نهدف إلى إتاحة حالات الاستخدام هذه عند توفّر بنية أساسية كافية للخصوصية. ليس لدينا أي إشعار آخر في الوقت الحالي، ولكننا نرحّب بملاحظاتك هنا. |
| العوامل السلبية | طلب تعديل معالجة عنوان URL لإتاحة استخدام عناوين IG السلبية من خلال ميزة العنوان الناشئ | نحن بصدد تقييم هذا الطلب ونرحّب بملاحظاتك الإضافية هنا. |
| فلترة التنوع | طلب الحصول على إرشادات حول كيفية تنفيذ فلترة التنوّع عند عرض الإعلانات المدمجة في PA API مع بائعين ومزادات متعددة | نناقش هذا الطلب هنا ونرحب بالتعليقات الإضافية. |
| (تم الإبلاغ عنها أيضًا في الربع سنوية السابقة) الفلاتر الحظرية |
طلب إرشادات حول كيفية فرض قواعد "حظر الناشر" (الفلاتر) عند عرض الإعلانات المدمجة في PA API مع بائعين متعدّدين | لقد شاركنا إرشادات هنا ونرحّب بملاحظات إضافية. |
| القيود | يُرجى طلب السماح بالقيود على مستوى النطاق بدلاً من مستوى النطاق الفرعي. | تلتزم القيود على مستوى النطاق الفرعي أو نقطة الانطلاق بنموذج الأمان الأساسي للويب، لذا هذا هو التصميم التلقائي. لقد ناقشنا هذا الموضوع بالتفصيل هنا وهنا. |
| عروض الأسعار الموثوق بها | طلب تعديلات برنامج وكيل المستخدم وتعديلات العميل ذات الصلة في طلبات إشارات عروض الأسعار الموثوق بها | نحن نتتبّع طلب الميزة هذا ونرحب بملاحظاتك الإضافية هنا. |
| (تم الإبلاغ عنها أيضًا في الربع سنوية السابقة) حسابات IG المتعددة |
استخدام عدّة مجموعات نموذجية للجمهور في عروض الأسعار نفسها | لا تتيح واجهة برمجة التطبيقات PA API ذلك حاليًا، لأنّ ذلك سيؤدي إلى تغيير في نموذج الخصوصية الأساسي. نرحب بمناقشة إضافية هنا. |
| (تم الإبلاغ عنها أيضًا في الربع سنوية السابقة) الأداء |
يمكن أن يؤدي نقل المزيد من المنطق إلى العميل إلى الإضرار بأداء الصفحة وتجربة المستخدم، ومن المحتمل أن يضر بنتائج تحسين محركات البحث للمواقع الإلكترونية. | نحن بصدد مناقشة هذه المشكلة ونرحّب بملاحظاتك الإضافية هنا. |
| العوامل الديناميكية للمزاد | تقلّل PA API من المعلومات حول ديناميكية المزاد (مثل المشاركين، والفائز بكل مكوّن يتم عرضه في المزاد وما إلى ذلك)، ما يحدّ من إمكانية تتبُّع الناشرين ويصعّب معرفة ما إذا كانت الصفقات يتم الالتزام بها. | اقترحنا حلاً لتتبُّع الصفقات هنا. نخطّط لتعديل بعض الحقول الحالية وإنشاء بعض الحقول الجديدة ضمن عنصر IG لتخزين DealID وSeatID والسماح بنشرهما من generateBid إلى scoreAd أو الخروج من خلال إعداد التقارير على مستوى الحدث. من المفترض أن يقدّم ذلك دعمًا كافيًا لحالة استخدام الصفقة. نرحب بملاحظاتك بشأن البيانات الوصفية الأخرى التي تعتبرها تكنولوجيات الإعلانات ضرورية لديناميكية المزاد وللحفاظ على إمكانية تتبُّع الناشرين لهذه البيانات. ونشجّع تقنيات الإعلان على تقديم أمثلة محدّدة للبيانات الوصفية التي تشير إليها والطرف الذي يجب أن تتدفق منه البيانات إلى الطرف الذي يجب أن تصل إليه. |
| مدير إعلانات Google | المخاوف بشأن شرط استخدام "مدير إعلانات Google" كسجّل إعلانات الناشر للوصول إلى طلبات AdX | الردّ المقدَّم من "مدير إعلانات Google": لا يتطلّب "مدير إعلانات Google" من الناشرين استخدام وظيفة خادم الإعلانات للوصول إلى وظيفة تبادل الإعلانات. |
| (تم الإبلاغ عنها أيضًا في الأرباع السابقة) مزاد المكوّنات |
سيكون الفائزون في مزاد مكوِّنات PA API ظاهرًا لـ "مدير إعلانات Google"، ما يثير مخاوف متعلقة بعدم المساواة في الوصول إلى المعلومات. | لم يتغيّر ردّنا عن الردود التي قدّمناها في الربع سنوية السابقة: الردّ الذي قدّمه فريق "مدير إعلانات Google": "لقد حافظنا على تركيز قوي على نزاهة المزاد لعدّة سنوات، بما في ذلك تأكيدنا على عدم مشاركة أي سعر من أيّ من مصادر الإعلانات غير المضمونة للناشر، بما في ذلك أسعار العناصر غير المضمونة، مع أيّ مشتري آخر قبل تقديم عروض أسعاره في المزاد، وهو ما أعادناه التأكيد عليه لاحقًا في التزاماتنا تجاه هيئة المنافسة الفرنسية. بالنسبة إلى مزادات PA API، ننوي الوفاء بوعودنا وعدم مشاركة عرض سعر أيّ مشارك في المزاد مع أيّ مشارك آخر في المزاد قبل إكمال المزاد في المزادات التي تضمّ بائعين متعدّدين. للتوضيح، لن نشارك سعر المزاد المستند إلى المحتوى مع أي مزاد مكوّن، بما في ذلك مزادنا الخاص، كما هو موضّح في هذا التحديث. بالإضافة إلى ذلك، لا نستخدم معلومات عن إعدادات مزادات المكوّنات، بما في ذلك الإشارات التي يقدّمها المشترون إلى منصّات عرض الإعلانات (SSP)، كجزء من مزادنا الخاص. في الواقع، نرحب بالتغييرات التي تطرأ على PA API والتي تسمح لبائعي المكوّنات بتحديد إعدادات مزادات المكوّنات بطريقة غير واضحة للبائع من المستوى الأعلى". |
| مدير إعلانات Google | هل سيطلب "مدير إعلانات Google" حصة من الأرباح مقابل عرض/إعداد تقارير عن مزادات المستوى الأعلى إذا لم يشارك "مدير إعلانات Google" في إنشاء مزاد مكوّنات واجهة برمجة التطبيقات IG أو PA؟ | الردّ المقدَّم من "مدير إعلانات Google": عندما يختار الناشرون استخدام "مدير إعلانات Google" كخادم الإعلانات الخاص بهم، ستنفّذ هذه الأداة مزادًا من المستوى الأعلى وستفرض رسومًا على عرض الإعلانات مقابل وظيفة خادم الإعلانات (وهي رسوم عرض الإعلانات نفسها التي تُطبق خارج مزادات PA API). في المقابل، إذا صدر الإعلان الفائز من بائع مكوّنات غير تابعة لـ "مدير إعلانات Google"، ما يعني أنّ "مدير إعلانات Google" لم يشارك في أي من مزاد إنشاء مزاد مكوّن IG أو PA API، يعني ذلك أنّ "مدير إعلانات Google" لا يتولّى الفوترة ولا تفرض رسومًا على وسائل الإعلام بنسبة مئوية. |
| مدى سهولة النقر | هل يخضع تسجيل أحداث النقرات للخصوصية التفاضلية نفسها؟ | لا يُخطَّط حاليًا لفرض قيود "k-anon" على هذه الميزة، لأنّ "عدد النقرات" لن يكون متاحًا إلّا كإشارة متصفّح داخل الدالة generateBid()، ولن يكون متاحًا كسمة جديدة في إعداد التقارير على مستوى الحدث. |
| الأداء | تكاليف عالية للخروج من الصفحة بسبب الردّ غير المشروط على طلبات عروض الأسعار السياقية | ولا يمكننا تقديم معلومات مباشرةً عن مزوّدي خدمات الإنترنت الذين يستخدمون أجهزة IG بسبب مخاوف تتعلّق بالخصوصية. ومع ذلك، نحن نستكشف حلولاً بديلة يمكن أن تقدّم إحصاءات مع الحفاظ على الخصوصية. |
| الإعلانات المدمجة مع المحتوى والإعلانات خارج البث | يمكنك طلب الحصول على تحديثات بشأن منظور Chrome في ما يتعلق بالإعلانات المدمجة مع المحتوى والإعلانات خارج البث. | يعتمد موضع Chrome على حالة الاستخدام المعنيّة. في ما يتعلّق بالفيديوهات، ترى Google أنّ دور Chrome هو تشجيع المنظومة المتكاملة على الوصول إلى حلول فعّالة للفيديوهات أثناء عرضها باستخدام واجهات برمجة التطبيقات. حتى الآن، فإنّ الاقتراح الوحيد الذي نعلمه هو اقتراح "شركاء المحتوى في YouTube". بالنسبة إلى الإعلانات المدمجة مع المحتوى، نعمل بنشاط على جمع الملاحظات هنا، ونخطط للتفاعل مع تقنيات الإعلانات من خلال المزيد من خطوات استكشاف المحتوى قريبًا. |
| المراقبة في الوقت الفعلي (RTM) | لا تُرسِل الزيارات المصنّفة تقارير RTM. | نحن على دراية بهذه الفجوة ونعمل على تقديم حلّ لها. سنشارك آخر المعلومات هنا عند توفّرها. |
| دعم إضافات الجمهور | طلب للحصول على معلومات جديدة حول إتاحة ميزة "توسيع شريحة الجمهور" أو شرائح الجمهور التي ينظّمها البائعون في PA API | نحن نعمل على تقديم حلّ لهذه الحالة. نحن نجمع الملاحظات من المنظومة المتكاملة بشأن الميزات التي يجب إنشاؤها وتقديم الدعم لها. سنشارك آخر الأخبار عند توفّرها ونرحّب بملاحظاتك الإضافية هنا. |
| تصحيح الأخطاء | في أداة مطوّري البرامج في Chrome، لا تتوفّر لوحة لمراقبة الأداء التفصيلي لواجهة برمجة التطبيقات PA API. على سبيل المثال، قد يتأثّر الأداء العام بعدد عروض الأسعار أو عدد المشترين. | على الرغم من أنّ هذه الملاحظات المحدّدة تتعلّق بإمكانات واجهة مستخدم "أدوات مطوّري البرامج" في Chrome للمساعدة في المراقبة، فقد طرحنا في 7 تشرين الأول (أكتوبر) إمكانية أن تهيئ تكنولوجيات الإعلان الأحداث المخصّصة التي يمكن استخدامها كأساس للمراقبة والتنبيهات. يمكنك الاطّلاع على مزيد من التفاصيل هنا ونأمل أن يعالج هذا التعديل جزءًا مهمًا من هذه الملاحظات. نرحب بأي ملاحظات أخرى حول هذه الميزة، سواء كانت متعلّقة بنقاط البيانات المتوافقة أو بتجربة المطوّر في مناقشة GitHub ذات الصلة هنا. |
| الإشارات | المخاوف بشأن ما إذا كان بإمكان منصّات إدارة الأداء (DSP) ضمان إرسال perBuyerSignals إلى منصّات عرض الإعلانات (SSP) بغض النظر عن نتائج مزاد الإعلانات السياقية | يُفترض أن يكون لمزاد المحتوى عرض سعر فائز واحد فقط من وسيط عرض إعلانات واحد، أو من الأفضل أن يكون هناك عرض سعر واحد لمحاولة التغلب عليه من خلال مزاد تالٍ من PA API. بالنسبة إلى مسار PA API، يقرّر نظام إدارة المساحة الإعلانية دعوة أيّ وجميع منصّات إدارة الطلبات التي يريد معرفة ما إذا كانت لديها طلب (في شكل ملف IG على الجهاز) لإرساله. من الممكن تمامًا ومن المرجّح جدًا أن تتم "إعادة دعوة" منصّة إدارة العروض التي خسرت مزاد الإعلانات السياقية للمشاركة في مزاد PA API. في هذه "إعادة الدعوة"، إذا قرّرت منصّة إدارة الأداء قبولها، ستعيد توجيه أي إشارات يريد "أداة التحقّق من الإعلانات" التأكّد من أنّ منصّة إدارة الأداء تأخذها في الاعتبار، إذا كانت متوفّرة لتلك الحملة. بعبارة أخرى، في مزاد واجهة برمجة التطبيقات PA API، تتوفّر دائمًا طريقة لنظام "وسيط عرض الإعلانات" لإرسال إشارات perBuyerSignals إلى "نظام عرض الإعلانات" بغض النظر عمّا حدث في المزاد السياقي. |
| الإشارات | يمكنك طلب إضافة النقرات السابقة إلى عنصر browserSignals الذي تم تمريره إلى generatedBid(). |
يمكن حلّ هذا الطلب من خلال اقتراحنا بتوفير إشارات قابلية النقر. وقد أعلنّا عن هذه الميزة في مشاركة المدوّنة الأخيرة والمفسِّر التوضيحي المقابل. نرحب بملاحظاتك الإضافية بشأن هذا الاقتراح هنا. |
| (تم الإبلاغ عنها أيضًا في الربع السابق) إشارات وضع النماذج |
طلب زيادة عدد بتات إشارات وضع النماذج من 12 بت إلى 30 بت | لقد رددنا على هذه الملاحظات باقتراح مضاد هنا. نحن نتواصل بشكل نشط مع الجهات المعنية في المجال لمعرفة آرائهم بشأن اقتراحنا، ونوازن حاليًا بين المزايا التي تعود على المجال والتأثير على مستخدمي Chrome والجهات المعنية الأخرى. |
| الوثائق | طلب إرشادات حول كيفية استخدام خوادم "المفتاح/القيمة" ووحدات TEE | تتوفّر إرشادات حول استخدام وحدات TEE في سياق نموذج الثقة لخدمة K/V في تفاصيل تصميم نموذج الثقة لخدمة K/V هنا. |
| فترة وجود IG السالبة | طلب تمديد مدة صلاحية ملفّات IG السلبية إلى 365 يومًا | تُستخدَم مجموعات IG السلبية لمنع عرض الإعلانات، ولكن لا يزال بإمكان الجهات الفاعلة السيئة استخدامها للكشف عن معلومات عن المستخدِمين، ما يؤدّي إلى مخاطر إعادة تحديد الهوية (على سبيل المثال، إحدى طرق هجوم الجهات الفاعلة السيئة هي تقديم عروض أسعار عالية تتضمّن مجموعات IG سلبية بشكل متكرّر لمعرفة ما إذا كان المستخدِم قد زار مواقع إلكترونية معيّنة أم لا). إذا احتفظنا بفترة صلاحية تبلغ 365 يومًا، سيحصل الفاعلون السيئون على بيانات أكثر بكثير عن المراجعات السلبية، ما يؤدي إلى مخاطر أكبر بكثير على الخصوصية. لذلك، لا يمكننا قبول هذا الطلب من أجل حماية خصوصية المستخدم. |
| مواصفات واجهة برمجة التطبيقات | ما الذي يمكن إدراجه كقيم يتم تمريرها كجزء من perBuyerSignals؟ هل يمكن للبائع تحديد هذه القيمة بشكل تعسّفي؟ | إنّ perBuyerSignals هو المكان الذي يمكن فيه للبائعين تقديم أي معلومات يريدون إتاحتها للمشترين داخل المزاد. يعود للمنظومة المتكاملة تحديد ما تريد إدراجه هناك، ولكننا نرحب بمناقشة إضافية هنا. |
| استبدالات ماكرو حجم الإعلان | أبحث عن إرشادات حول عدم عمل بدائل وحدة الماكرو لحجم الإعلان. | سنشارك المزيد من التفاصيل علنًا قريبًا. |
| استبدال ماكرو SSP بعد تقديم عروض الأسعار: انتحال عنوان URL من المستوى الأعلى | ما هي الآليات التي يمكن أن يقدّمها Chrome للسماح لمزوّدي خدمات إثبات الملكية بإثبات ملكية عنوان URL من المستوى الأعلى ضمن إطار عمل "مبادرة حماية الخصوصية"؟ هل هناك نقاط بيانات أو إشارات بديلة يمكن استخدامها ضمن ميزة Fenced Frames لضمان دقة عنوان URL الأعلى الذي يوفّره SSP؟ |
نحن نناقش حاليًا هذه الملاحظات الإضافية هنا. |
| طلب ميزة | طلب توفير تنسيق UACH منخفض التشويش عند جلب updateURL وعند عمليات تسجيل الإحالات الناجحة في "التقارير في الوقت الفعلي" | تتم مناقشة هذه الطلبات هنا، ونرحّب بملاحظات إضافية هنا وهنا. |
| طلب ميزة | طلب تفعيل تصميم تصحيح الأخطاء الذي وافق عليه الخادم الموثوق به عند بدء عميل معيّن لإرسال تقارير على مستوى الحدث تم تقليل عيّنتها من أجل تصحيح الأخطاء فقط من خلال forDebuggingOnly.reportAdAuctionWin() وforDebuggingOnly.reportAdAuctionLoss() |
هذا طلب نشط نتتبّعه حاليًا وسنُطلعك على آخر المعلومات المتعلّقة بالمنظومة المتكاملة عند توفّرها. نرحّب بملاحظاتك الإضافية هنا. |
| استخدام واجهة برمجة التطبيقات | طلب إرشادات حول كيفية احتساب مدى وصول المستخدِمين الفرديين ومدى وصول مرّات الظهور | نحن نناقش اقتراحًا لمعالجة كيفية قراءة رسائل IG من داخل أداة عمل تخزين مشترَكة، والتي يمكنك بعد ذلك إرسال تقارير مجمّعة خاصة بها. يمكنك الاطّلاع على مزيد من التفاصيل هنا، ونرحب بملاحظاتك حول الاقتراح ومدى فائدته للمنظومة المتكاملة. |
| استخدام واجهة برمجة التطبيقات | عدم الوضوح بشأن ما يجب أن يختبره الناشرون، وواجهات برمجة التطبيقات المهمة، وواجهة برمجة التطبيقات التي يجب تفعيلها، والميزات القادمة | نحن نبذل جهودًا لدعم الناشرين بشكل أفضل وتعزيز أدوارهم في المنظومة المتكاملة. |
| استخدام واجهة برمجة التطبيقات | هل من الممكن إضافة مستمعي الأحداث إلى أحداث Ad Auction Worklet؟ | لا يمكن إجراء ذلك من خلال الأحداث العادية، ولكن ستعالج أحداث Chrome Devtools Protocol هذه الحالة جزئيًا. يُرجى العِلم أنّه من المحتمل أن تؤثر الأحداث العادية في خصائص العزل/الخصوصية، ولكن التفاصيل متوفّرة هنا. |
| K-Anonymity | طلب توضيح بشأن متطلبات عرض الإعلان (على سبيل المثال، كان من المفترض أن يرى 50 شخصًا على الأقل الإعلان، إذا كان يُسمح بعرضه) | تقدّم مستندات المطوّرين نظرة عامة على توقعاتنا بشأن التطويرات المستقبلية. ويوضّح بشكل خاص أنّ الحدّ الأدنى الأولي للخصوصية وفقًا لنظرية k هو k=10 أشخاص. تقدّم القائمة البريدية لمطوّري البرامج blink-dev آخر الأخبار حول ما يحدث مباشرةً في Chrome. كما هو موضّح في سلسلة الرسائل الإلكترونية لقائمة البريد الإلكتروني حول الخصوصية وفقًا لمبدأ "المجهوليّة التامّة للبيانات"، نحن بصدد فرض متطلبات الخصوصية وفقًا لمبدأ "المجهوليّة التامّة للبيانات" على نحو تجريبي على حوالي% 1 من الزيارات الثابتة في Chrome، ولا نفرضها أبدًا على الشرائح التي تم تصنيفها بشكل صريح ("الوضع أ" و"الوضع ب"). |
| احتكاك | هل يمكن إزالة تشويش مفتاح/قيمة TEE مؤقتًا أو تقليل الحاجة إلى طلب جميع الأجزاء N إلى مقدار يوازن بين حماية الخصوصية والفائدة (أي هل تريد معرفة الأداء أو التكلفة لـ K/V)؟ | لا تتم معالجة هذه الأنواع من الطلبات إلا في النُسخ غير المخصّصة للنشر حيث يمكن التحكّم في التآكل. ولا يزال إلغاء هذا الاشتراك مطلوبًا في مثيلات الإنتاج. يمكننا تقييم الموقف بعد تلقّي ملاحظات من استخدام غير الإصدار العلني. |
| وجه غاضب | طلب إضافة علامة لإيقاف التشويش من ملف K/V الثنائي الخاص بوضع تصحيح الأخطاء أو غير المخصّص للإصدار العلني | تتوفّر هذه العلامة في الإصدار 1.0.0. |
| خطأ في واجهة برمجة التطبيقات | توقفت واجهة برمجة التطبيقات عن العمل بعد الترقية إلى الإصدار 126 من Chrome، على الرغم من تفعيلها في الإعدادات. | تبيّن أنّ هذه المشكلة مرتبطة بعلامة Chrome "enable-fenced-frames" التي فعّلها المستخدمون لأغراض التطوير. سيؤدي إعادة ضبط هذه العلامة على الإعداد التلقائي إلى حلّ المشكلة. |
| إعداد التقارير | طلب تفعيل إعداد التقارير في الوقت الفعلي لواجهة برمجة التطبيقات بحيث لا يعتمد المشترين على البائع. | يتم النظر في هذا الطلب هنا. تم إطلاق حلّ RTM مؤخرًا، ونرحب بملاحظات تكنولوجيات الإعلان التي سبق أن بدأت استخدام الميزة. |
| إعداد التقارير | طلب الحصول على تقارير الجهات الخارجية. على الرغم من أن أنظمة وسيط عرض الطلب (DSP) ومقدِّمي خدمة SSP تتلقى إشعارات لمرات الظهور من Chrome، في حين لا يستلمها مزوّدو الخدمات الفنيون من الطبقة المتوسطة بشكلٍ تلقائي. | نحن بصدد مناقشة هذا الطلب ونرحّب بملاحظاتك الإضافية هنا. |
خدمات المزادات المحمية
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| TEEs | إنّ متطلبات Google لإعداد الحسابات يدويًا بموجب المعايير الفنية هي قيد صارم على اختيار مقدّم خدمات السحابة الإلكترونية. يمكن اتّباع المعايير الفنية المطبّقة بدون زيارة مكتب مزوّدي خدمات السحابة الإلكترونية كما يبدو أنّ Google تنوي ذلك. إنّ تأخّر مزوّدي الحلول البديلة في عام 2025 (أقرب وقت ممكن) غير مقبول لأنّه سيؤدي إلى ظهور تأثيرات الشبكة التي تشجع على تقديم الإكراميات لحلول Google. | خدمة التجميع هي الخدمة الوحيدة المطلوبة لتشغيلها في خدمة TEE من أجل معالجة بعض حالات استخدام تكنولوجيا الإعلان. تتوافق خدمة التجميع مع كل من Amazon Web Services (AWS) وGoogle Cloud Platform (GCP). استنادًا إلى الملاحظات الواردة من تكنولوجيات عرض الإعلانات، نعتقد أنّ هذا الدعم مناسب في هذه المرحلة. في ما يتعلّق بموفّري خدمات السحابة الإلكترونية الإضافية، نشرت Google معايير تفصيلية لوحدات TEE على موفّري خدمات السحابة الإلكترونية العامة. ويهدف ذلك إلى التأكّد من أنّ حلّ TEE يستوفي أهداف الخصوصية والأمان في "مبادرة حماية الخصوصية". على وجه التحديد، تعالج خوادم "مبادرة حماية الخصوصية" (TEE) بيانات المستخدمين غير المشفّرة على مواقع إلكترونية متعددة (مثل البيانات الواردة من المواقع الإلكترونية الخاصة بالناشرين والمعلنين لخدمة التجميع). ويجب أن تكون هذه الطلبات آمنة من أجل تحقيق أهداف خصوصية المستخدمين في واجهات برمجة التطبيقات. من الضروري أيضًا توفير بيئة آمنة لضمان مواصلة واجهات برمجة التطبيقات حماية معلومات الأنشطة التجارية السرية للشركات (على سبيل المثال، منع المشاركين الآخرين في مزاد PA API من الوصول إلى بيانات النشاط التجاري الخاصة بالمشتري). حسب معلوماتنا، لا تتوفّر حاليًا تكنولوجيا "بيئة وبيئة تنفيذ موثوقة" (TEE) توفّر حماية كاملة لبيانات المستخدمين من مشغّل يُحتمَل أن يكون عدائيًا. لذلك، نضع متطلبات متعدّدة للتحقّق من موثوقية مقدّم خدمات السحابة الإلكترونية. لست متأكّدًا ممّا يشير إليه "مكتب مقدّمي خدمات السحابة الإلكترونية"، وهذا ليس جزءًا من المتطلّبات. نرحب بأي ملاحظات حول المتطلبات. ونحن نواصل أيضًا تقييم مدى توفّر الدعم لمقدّمي الخدمات الجدد، بما في ذلك بناءً على طلبات تم إرسالها باستخدام العملية المحدّدة في الشرح. حتى الآن، تلقّينا طلبًا واحدًا فقط يتضمّن إتاحة Azure، ونحن بصدد تقييمه. |
| B&A | ومن الصعب تقييم التعقيد الفني والجدوى لخدمة B&A مع استمرار تطور التصميم. | لحلّ هذه المخاوف، قدّمنا شرحًا مفصّلاً على GitHub يوضّح تصميم واجهة برمجة التطبيقات B&A، ونشرنا المخططات الزمنية لوقت توفّرها وخارطة الطريق للميزات التي تتوافق مع PA API. نحن ندعم تكنولوجيات الإعلان التي تسعى إلى نشر ميزة "الإعلانات أثناء عرض الفيديو" وجمع الملاحظات من المنظومة المتكاملة على GitHub. |
| سرير وفطور | أبحث عن إرشادات وطريقة أفضل لاحتساب تكلفة استخدام TEE في ميزة "التشفير من جهة العميل" لبدء استخدامه أو نقل بياناته من الجهاز. | لقد نشرنا مؤخرًا دليل تحديد حجم مثيل خادم "مفتاح/قيمة" الذي يتضمّن أدوات لقياس التكاليف بدقة أكبر. |
| خادم "مفتاح/قيمة" | يطلب مدقّق الإعلانات إمكانية استخدام عنوان URL الكامل للصفحة على خادم K/V لإجراء عملية إثبات صحة الإعلان. | نحن حاليًا بصدد تقييم إمكانية توفير عنوان URL الكامل للصفحة لخادم K/V الذي يعمل في بيئة آمنة للتنفيذ لأغراض إثبات صحة الإعلانات. لن يكون عنوان URL الكامل للصفحة متاحًا في ميزة "إدارة الخدمات الذاتية" لـ K/V. |
| أمان المزاد | البحث عن ميزات أمان المزاد لضمان عدم وصول الجهات المسيئة إلى البيانات الحساسة أو التصرف بانتحال الهوية - وهي ميزات تحمي المزاد من هجمات إعادة التشغيل، وكيف يمكن تطبيق تدابير الوقاية الأمنية؟ | يمكن أن يحمي نموذج الأمان الحالي في B&A سلامة المزاد. يتم تشغيل B&A في TEE تحمي سرية إشارات تقنيات الإعلان ورموزها البرمجية من الجهات الضارّة. في بنية B&A، تتدفق حمولة بيانات طلب B&A (نص مشفَّر للطلب) من العميل من خلال خادم إعلانات غير موثوق به إلى خدمة SellerFrontEnd (SFE، التي يديرها SSP في TEE). يحتوي النص المشفَّر للطلب على معرّف إنشاء يستند إلى الطابع الزمني. سيفحص SFE الطابع الزمني للطلب ويرفض أي طلبات تمت إعادة تشغيلها خلال فترة تزيد أو تقل عن n ثانية من وقت الخادم. وبالإضافة إلى ذلك، يمكن لشركة B&A إرجاع حمولة بيانات استجابة ذات حجم ثابت مضاف للاتصال من الخادم إلى الخادم. يمكن أن تساعد هذه الحلول في الحدّ من هجمات إعادة التشغيل من خلال النظام عندما يحاول مستخدم ضار إعادة تشغيل الحمولة نفسها للطلب من أجل الاطّلاع على مزيد من المعلومات حول محتواها. تعمل "البنية الأساسية والاعتماد" على توثيق نماذج الأمان وتعديلها في التفسيرات. |
| الإشارات عبر خادم K/V |
يمكنك طلب تضمين perpurchaseSignals التي تم إرسالها من خلال خدمة K/V كجزء من طلب إشارات عروض الأسعار الموثوق بها من Chrome. | نحن نُقيّم مدى جدوى تضمين معلومات من perBuyerSignals، التي يتم نقلها إلى خادم K/V الذي يعمل في بيئة آمنة للتشغيل (TEE)، بما في ذلك عنوان URL الكامل للصفحة. |
| خادم K/V | طلب مخطط زمني أكثر مراحل الاستخدام لقيود الخصوصية في مرحلة K/V وB&A. | نحن نتفهّم الرغبة في اعتماد نهج تدريجي أكثر لاستخدام مفاتيح التشفير الموحّدة (TKV) ونُقدّر طلباتك المحدّدة بشأن مفاتيح التشفير والبيانات الأساسية. وبعد تقييم دقيق، قرّرنا عدم تخفيف إجراءات حماية الخصوصية في واجهات برمجة التطبيقات هذه في الوقت الحالي. نرى أنّ هذه التدابير، مثل اتخاذ القرارات، ضرورية لحماية خصوصية المستخدم والحفاظ على الثقة في "مبادرة حماية الخصوصية". |
| خادم "مفتاح/قيمة" | أبحث عن إرشادات حول كيفية توسيع نطاق "متجر المفاتيح/القيم" من خلال إعداد متوافق. | يمكن أن يساعدك دليل تحديد حجم مثيل خادم K/V الذي تم نشره مؤخرًا في هذا الشأن. ستقدّم الأداة عدد طلبات البحث في الثانية (يُشار إليه باسم "عدد طلبات البحث في الثانية" في الشرح) في كل مجموعة من المَعلمات. |
| خادم K/V | أضِف معلومات البائع في طلب خادم K/V. | نحن نناقش هذه المشكلة ونرحّب بملاحظاتك الإضافية هنا. |
| خدمات K/V + B&A | طلب توضيح الجدول الزمني أو خارطة الطريق لإصدار K/V وB&A | بالنسبة إلى مزادات K/V وB&A، لدينا مراحل ومخططات زمنية: بالنسبة إلى خادم K/V إلى جانب مزادات PA API على الجهاز (مقابل B&A)، يتوفّر المخطط الزمني العلني هنا. بالنسبة إلى كيفية تحديد "الإصدار العلني" لـ K/V، يُرجى الاطّلاع على قسم "خارطة الطريق" الذي يحدّد مجموعة الميزات للإصدار التجريبي والإصدار العلني. بالنسبة إلى مرحلة الاختبار والإطلاق، يُرجى الاطّلاع على المخطط الزمني العلني هنا وخارطة الطريق هنا. نعرّف "الاختبار على نطاق واسع" على أنّه "اختبار كامل ومستقر على نطاق الإنتاج". يمكنك الاطّلاع هنا على مجموعة الميزات المحدّدة في هذه المرحلة. تتضمّن B&A أيضًا مرحلتَي ألفا وتجريبية، لذا سيتضمّن "الاختبار على نطاق واسع" مجموعة كبيرة من ميزات المراحل السابقة. بالنسبة إلى الدراسة K/V وB&A، يُرجى إعلامنا بما إذا كانت تعريفات المرحلة هذه تساعد في توضيح ما سيتم توفيره في الوقت المناسب. إذا كانت هناك ثغرات، يُرجى إعلامنا بها. يسرّنا أن نجعل هذه الرسائل أكثر تحديدًا للمساعدة في وضع الخطط. |
قياس الإعلانات الرقمية
تقارير تحديد المصدر (وواجهات برمجة التطبيقات الأخرى)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| استجابة السوق | إنّ اشتراط استخدام أنظمة تحديد المصدر المتنافسة لإعداد التقارير على مستوى الحدث فقط والتقارير التلخيصية/المجمّعة ضمن حدود ضيقة هو قيد تعسّفي على المنافسة. ويمنع هذا الإجراء إعادة الاستهداف والتحديد على مستوى الحدث في الوقت الفعلي حسب الجهاز، حتى في حال توفّر وسائل وقاية لضمان الامتثال لحماية البيانات (مثل إزالة التعرّف). | يستند التصميم المذكور إلى أهداف الخصوصية لواجهة برمجة التطبيقات، مثل حماية المعلومات على جميع المواقع الإلكترونية التي يتم نقلها من موقع إلكتروني إلى آخر. على سبيل المثال، تتيح ARA تحديد المصدر على مستوى الحدث من خلال تقارير الأحداث. يتم تأخير تقارير الأحداث لمدة ساعة واحدة على الأقل، وهو أمر ضروري لتسهيل ربط التقرير على مستوى الحدث بهوية المستخدِم على موقع المعلِن الإلكتروني، وذلك باستخدام هجمات قناة جانبية مستندة إلى التوقيت، كما هو موضّح هنا. بالإضافة إلى ذلك، هناك طرق أخرى لتحديد المصدر، غير ARA، مثل جمع المعلومات مباشرةً من المستخدمين الذين يقدّمون بيانات تعريفية عن قصد. نحن منفتحون على تلقّي الملاحظات والآراء حول حالات الاستخدام التي لا يمكن تحقيقها ضمن حدود الخصوصية الحالية لواجهات برمجة تطبيقات "مبادرة حماية الخصوصية". |
| أسطح متعددة | طلب تأكيد على ما إذا كانت واجهات برمجة التطبيقات ARA وShared Storage API تتيحان حالات الاستخدام على مساحات عرض متعددة أم لا، ومكان إثبات ذلك | لا تتيح ARA ومساحة التخزين المشتركة حاليًا تحديد المصدر على مستوى أجهزة متعددة (على جميع الأجهزة). تتوفّر إمكانية تحديد المصدر على مستوى التطبيقات والمواقع الإلكترونية على الجهاز نفسه (من خلال ARA). |
| (تم الإبلاغ عنها أيضًا في الربعَين السابقَين) على جميع الأجهزة |
هل تتيح ميزة ARA الإحالات الناجحة باستخدام أكثر من جهاز واحد؟ | كانت استجابتنا مماثلة لربع السنة السابق: تواجه عمليات الشراء على جميع الأجهزة تحديات جديدة تتعلّق بالخصوصية إلى جانب تحديات استخدام ملفات تعريف الارتباط التابعة لجهات خارجية، بالإضافة إلى تحديات في توزيع التكنولوجيا استنادًا إلى مجموعة الأجهزة والأنظمة الأساسية التي قد يستخدمها المستخدم. نحن نستكشف الحلول المحتملة، ولكننا نركّز على حالات الاستخدام الملحّة التي تتيحها أداة ARA حاليًا، ولا يتوفّر لدينا حاليًا مخطط زمني لدعم جميع الأجهزة. |
| التحجيم | المخاوف بشأن ما إذا كانت واجهة برمجة التطبيقات Attribution Report API (ARA) قد تم ضبطها حاليًا ويمكن نشرها وتوسيع نطاقها بشكل موثوق لخدمة جميع مستخدمي Chrome | تتوفّر ميزة ARA حاليًا لجميع مستخدمي Chrome وتعمل على النحو المتوقّع. بالإضافة إلى ذلك، نواصل اختبار موثوقية ARA وقابليتها للتوسّع ومراقبتها، مع استمرار زيادة عدد شركات تكنولوجيا الإعلان التي تختبر ARA. نرحّب بملاحظاتك الإضافية حول المنظومة المتكاملة في ما يتعلق بذلك هنا. |
| (تم إدراج هذه المعلومات أيضًا في الأرباع السابقة) إزالة التكرار |
المخاوف بشأن الطريقة التي تقترح بها ARA تقييد آلية تحديد المصدر على الأجهزة بحيث لا يتمكّن الناشرون من تنفيذ منطق ما بعد تحديد المصدر بفعالية للتقارير التلخيصية، بما في ذلك إزالة تكرار الإحالات الناجحة المتعددة من النوع نفسه للنقرة على الإعلان نفسها | لم تتغيّر استجابتنا مقارنةً بالفصول السابقة: يشكّل تكرار عمليات التكرار على جميع الأجهزة ومسارات القياس تحدّيًا معروفًا وحاليًا يواجهه اليوم أيضًا تكنولوجيات الإعلان مع الشركات التابعة لجهات خارجية. من خلال ARA، يمكن لتقنيات الإعلانات تحديد الوقت المناسب لتسجيل إحالات ناجحة معيّنة وإضافة بيانات وصفية محدّدة للإشارة إلى مسارات القياس التي استُخدِمَت لتتبُّع الإحالات الناجحة (أي جزء من مفتاح التجميع)، والتي يمكن مقارنتها بمسارات القياس الأخرى. نرحّب بملاحظاتك الإضافية حول المنظومة المتكاملة في ما يتعلق بذلك هنا. |
| تتبُّع الإحالات الناجحة | طلب إمكانية العمل مع الإحالات الناجحة من نطاقات متعددة | نحن نناقش هذا الطلب هنا ونرحّب بملاحظات إضافية حول المنظومة المتكاملة. |
| إعداد التقارير | ينتظر المتصفّح يومَين على الأقلّ و30 يومًا كحدّ أقصى لإرسال الإحالة الناجحة، ما قد يشكّل مصدر قلق نظرًا لأنّ معظم المعلِنين أصحاب المصالح هم معلِنون يستندون إلى الأداء، ويعملون في أوقات قريبة من الوقت الفعلي. | تتضمّن الإعدادات التلقائية للتقارير على مستوى الحدث الفترات التلقائية التالية لإعداد التقارير: يومَان و7 أيام و30 يومًا. من خلال إعداد التقارير المرنة على مستوى الحدث، يمكن لتكنولوجيات الإعلان تغيير عدد فترات إعداد التقارير ومدتها عن القيم التلقائية. يمكن تغيير فترات إعداد التقارير لتصبح ساعة واحدة على الأقل، ما قد يساعد في حالات استخدام المعلِنين للأداء. نرحّب بملاحظاتك الإضافية حول المنظومة المتكاملة في ما يتعلق بذلك هنا. |
| تحديد مصدر الإحالات من الإنترنت إلى المتجر | هل ستكون هناك أي خيارات تنفيذ للإعلانات من الإنترنت إلى نقاط البيع في ARA، أو هل هناك أي اقتراحات أخرى لقياس عملية تحديد المصدر من نقاط البيع إلى الإنترنت؟ | لا تتوفّر حاليًا خطط لإتاحة حالات استخدام قياس الأداء من الإنترنت إلى نقاط البيع في ARA. وهناك تحديات كبيرة تتعلق بالخصوصية والأمان يجب وضعها في الاعتبار عند تقديم هذا النوع من الدعم. نرحب بملاحظاتك الإضافية بشأن المنظومة المتكاملة في ما يتعلق بحالات الاستخدام لهذه الميزة هنا. |
| تقارير تصحيح الأخطاء | كيف يمكن تخزين معرّف AdID و/أو استرجاعه بطريقة تتيح الوصول إليه في عمليات تسجيل Chrome (المصدر/العامل المشغِّل) لتحديد المصدر من التطبيق إلى الويب؟ | لتفعيل تقارير تصحيح الأخطاء، يجب أن تثبت لنا تكنولوجيا الإعلان أنّه يمكنها الانضمام إلى المستخدم على مستوى التطبيق والويب، ويتم ذلك لضمان عدم الكشف عن أي معلومات جديدة من خلال تقارير تصحيح الأخطاء. يمكن لتكنولوجيا الإعلان إثبات عملية الربط من خلال توفير مفتاح ربط فريد لكل مستخدم. يمكن أن يكون مفتاح الانضمام هذا هو المعرّف الإعلاني أو مفتاح انضمام الطرف الأول. إذا كانت تقنية عرض الإعلانات تستخدِم المعرّف الإعلاني، لا يتيح Chrome الوصول إلى المعرّف الإعلاني من المتصفّح بشكلٍ تلقائي، وتتوقّع واجهة برمجة التطبيقات أن يكون لكل تقنية عرض إعلانات طريقة خاصة بها لنقل المعرّف الإعلاني أثناء تسجيل الويب. |
| دقة الحزمة | هل من الممكن استخدام استراتيجيات حِزم مختلفة لكلّ معلِن؟ | ننصحك بتجربة طرق مختلفة لتوسيع نطاق ميزانية المساهمات من أجل العثور على الطريقة الأنسب لحالات الاستخدام الخاصة بك. تم تصميم ARA لتكون مرنة وقابلة للتخصيص لتلبية مجموعة متنوعة من حالات استخدام تكنولوجيا الإعلان. لذلك، ننصح بتجربة استراتيجيات تجميع مختلفة لكل معلن أو لكل مجال. يمكن أن يكون استخدام استراتيجيات تجميع مختلفة مفيدًا عندما يكون لدى المعلِنين اختلافات في قيم القياس التي تهمّهم تتبُّعها وحجم قيم القياس. |
| الوثائق | طلب مستندات إضافية لتنفيذ ميزة app<>web في ARA | يمكنك الاطّلاع على مستندات حول مبادرة App<>Web لتقييم التطبيقات على ARA هنا. |
| الأداء | يمكن أن يشكّل عدد الطلبات ذات الصلة بميزة ARA عبئًا كبيرًا على خوادم الناشر مقارنةً بعدد طلبات keepalive اللازمة لتشغيل الموقع الإلكتروني المذكور. يمكن أن يساعد تجميع أحداث المصدر في طلب واحد في تقليل الضغط على الخادم. من الأفكار المحتملة السماح بصفيف من العناصر بترميز JSON. | يمكن إلى حدّ معيّن تجميع أحداث المصدر استنادًا إلى منطق معيّن باستخدام منطق JavaScript جنبًا إلى جنب مع واجهة برمجة التطبيقات. نحن نقيّم حاليًا هذا الطلب ونرحّب بملاحظات إضافية من المنظومة المتكاملة هنا. |
| طلب ميزة | اقتراح لحلّ المشكلة بسبب عدم توفّر إمكانية الدمج من خادم إلى خادم | لا نخطّط حاليًا لإتاحة دمج الخادم بالخادم في ARA. هناك العديد من تحديات الخصوصية التي يجب مراعاتها للسماح بتوفير ميزة الدمج من خادم إلى خادم. نرحب بملاحظات من المنظومة المتكاملة بشأن حالات الاستخدام الإضافية لدعم الاتصال بين الخوادم هنا. |
| الوثائق | طلب دليل "البدء السريع" الذي يوضّح الأجزاء الرئيسية من ARA/كيفية البدء والتشغيل من خلال بعض حالات الاستخدام البسيطة | يمكنك الاطّلاع على دليل البدء السريع لخدمة ARA هنا. نحن نعمل على تحسين هذه المستندات بشكل أكبر هذا العام، ونرحّب بملاحظات إضافية حول حالات استخدام أو سيناريوهات معيّنة تتطلّب مستندات إضافية هنا. |
| استخدام واجهة برمجة التطبيقات | طلب توصيات حول توسيع نطاق المساهمات للعديد من القيم الصغيرة. | ننصحك بتجربة مناهج مختلفة لتحجيم ميزانية المساهمة للعثور على الطريقة الأنسب لحالات الاستخدام لديك. بالنسبة إلى سيناريو القيم الصغيرة المتعددة، ننصحك بتجربة قيم مختلفة لدالة epsilon لتحديد نقاط الانحناء التي قد تكون فيها الضوضاء الناتجة من دالة epsilon مقبولة لحالة الاستخدام. تتوفّر مزيد من التفاصيل في ورقتنا البحثية حول تحسين التقرير التلخيصي في ARA. |
| مرنة على مستوى الحدث | متى سيتمّ تنفيذ الإعدادات المرنة على مستوى الحدث (مواصفات المشغّلات المتعدّدة)؟ | تتيح حاليًا ميزة "مستوى الحدث المرن" تخصيص جوانب إعداد التسجيل التالية: عدد التقارير التي يمكن إنشاؤها لكل مصدر، وعدد فترات إعداد التقارير ومدتها، وعدد القيم الفريدة لبيانات العامل المشغِّل. نجمع حاليًا ملاحظات إضافية حول المنظومة المتكاملة بشأن تحسينات إضافية مرنة على مستوى الحدث، ولكن لا نخطّط لتنفيذ أي منها في الوقت الحالي. نرحب بملاحظات إضافية حول حالات الاستخدام التي قد تستفيد من بعض التحسينات المرنة على مستوى الحدث والمدرَجة هنا. |
| معالجة الحِزم | طلب وضع حدّ أقصى للمساهمات المجمّعة للحِزم بالإضافة إلى قابلية التوسّع المستقبلية والتوافق مع الإصدارات القديمة | نحن بصدد مناقشة هذا الطلب ونرحّب بملاحظاتك الإضافية هنا. |
| Epsilon | ماذا يحدث لمجموعة القيم القصوى لمقياس epsilon بعد أن يصبح ARA متاحًا للجميع؟ | أصبحت ميزة ARA متاحة للجمهور العام على Chrome في الربع الثالث من عام 2023. في الوقت الحالي، ما مِن خطة لتعديل نافذة قيمة epsilon. سيقدّم اقتراحنا لبنية إدارة معدَّلة ضمانات إضافية في حال كان من المتوقّع إجراء أي تعديلات. |
| إعداد التقارير | لا تحتوي تقارير أخطاء التشغيل غير المعروفة على سمات المصدر في نص التقرير. | وفقًا لما هو موضّح في المواصفات، ليس من المطلوب أن تكون هناك حقول أخرى في نص التقرير الخاص بـ trigger-unknown-error. ندرك أنّ الجدول الذي يصف الحقول في نص التقرير كان من المحتمل أن يكون مضللاً، لأنّ الحقول المتعلقة بالمصدر قد تكون متوفّرة أو لا تكون متوفّرة استنادًا إلى السبب الأساسي للخطأ. على سبيل المثال، قد يحدث خطأ داخلي قبل حدوث منطق مطابقة المصدر، ما يعني عدم توفُّر بيانات مصدر لتعبئة تقرير تصحيح الأخطاء بها. وقد تم تعديل المستندات الآن لتوضيح ذلك. |
| استخدام واجهة برمجة التطبيقات | عند العمل مع هدفَي قياس، هما العدد والقيمة، هل يُنصح بتقسيم كلّ من ميزانية المساهمة وقيمة epsilon؟ | عند العمل مع هدفَي قياس، ننصحك بتقسيم ميزانية المساهمة بينهما. |
| إعداد التقارير | هل تتيح ميزة ARA تحديد المصدر بالاستناد إلى عدّة نقاط اتصال أو تقارير المساعدة (المعروفة أيضًا باسم تقارير المساهمة)؟ | لا تتيح ARA حاليًا تحديد المصدر بالاستناد إلى نقاط اتصال متعددة أو التقارير الداعمة. في الوقت الحالي، لا ننوي تطبيق هذا التغيير. نرحب بملاحظاتك الإضافية بشأن حالات الاستخدام وأولوياتها هنا. |
| خطأ في واجهة برمجة التطبيقات | بالنسبة إلى ARA، تشير المستندات إلى أنّه يتم استخدام XOR لدمج أجزاء مفتاح تجميع المصدر والعامل المشغِّل، ولكن في الممارسة العملية، يتم استخدام OR. يؤدي هذا التناقض إلى حدوث ارتباك وأخطاء محتملة في التنفيذ. | تم تعديل المستندات لتوضيح أنّ هذا خطأ. |
خدمة تجميع البيانات
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| وظائف التجميع | طلب السماح ببادئات متعددة في مهام التجميع | نحن نحقق في هذه الملاحظات وقد نشرنا اقتراحًا هنا. نرحب بملاحظاتك بشأن الاقتراح هنا. |
| طلب ميزة | طلب تغيير نص terraform بحيث إذا لم يتم ضبط service_account_token_creator_list (أو كانت فارغة)، يتم تخطّي تعديل سياسة إدارة الهوية وإمكانية الوصول للحساب. | نحن نحقق في هذه المشكلة هنا ونرحّب بملاحظات إضافية حول المنظومة المتكاملة. |
| استخدام واجهة برمجة التطبيقات | هناك توضيح مطلوب بشأن خطة Terraform لإظهار التغييرات دائمًا. | تم حلّ هذه المشكلة في إصدار AgS 2.8. |
| استخدام واجهة برمجة التطبيقات | أبحث عن اقتراحات لإعداد إعدادات لكل معلِن لمعدل التجميع مع فلترة مرنة للمساهمات. | يمكن حاليًا تجميع الطلبات حسب المعلِن باستخدام ARA. يمكن استخدام فلترة المساهمات المرنة للحالات الأكثر تقدّمًا التي تريد فيها تكنولوجيا الإعلان تقسيم المساهمات في التقرير بشكل أكبر حسب معدّل تكرار مختلف. يمكن لتكنولوجيات الإعلان الاطّلاع على مزيد من المعلومات حول تجميع البيانات هنا واستخدام أرقام تعريف الفلترة مع ARA هنا. نحن نعمل أيضًا على توفير المزيد من المستندات لتصفية أرقام التعريف. |
| طلب ميزة | طلب إتاحة دالة log_sum_exp في "خدمة تجميع البيانات" (AgS) | لقد تواصلنا مع هذا المعنيّ للحصول على مزيد من التفاصيل حول حالة الاستخدام. سنتواصل معك عندما تتوفّر لدينا المزيد من التفاصيل. |
| طلب ميزة | يمكنك طلب الاطّلاع على المزيد من السجلات/الإحصاءات/المقاييس الأخرى عند حدوث مشاكل في AgS والمشاكل المحتمَلة في AgS المنشور. | لقد نشرنا تعديلات على مستنداتنا لتضمين المزيد من الأخطاء والتخفيفات والأوصاف هنا. نرحب بملاحظات إضافية بشأن أي أخطاء أو مقاييس أو سجلّات أو غير ذلك غير موثّقة أو غير متوفّرة والتفاصيل التي قد تكون مفيدة هنا. |
| اختبار واجهة برمجة التطبيقات | ماذا ستكون القيمة النهائية لإبسيلون بعد فترة الاختبار؟ | في الوقت الحالي، ما مِن خطة لتعديل نافذة قيمة epsilon. ونحن نشجع المختبِرين على تجربة مَعلمات مختلفة وتقديم ملاحظاتهم. |
| إعداد التقارير | يتم إنشاء التقرير، ولكن لا يزال يظهر الخطأ PRIVACY_BUDGET_AUTHORIZATION_ERROR في رمز الإرجاع. | لقد قدّمنا إرشادات حول تحديد مصدر إعداد التقارير الصحيح والتقارير القابلة للتجميع لتجنّب حدوث هذا الخطأ. نرحب بملاحظاتك الإضافية حول المشكلة، لا سيما إذا كانت هناك أخطاء متكررة. |
| اكتشاف المفاتيح | ما الخطط المتعلقة باقتراح الاكتشاف الرئيسي؟ | ليس لدينا جدول زمني بعد لطرح اقتراح اكتشاف المفاتيح، ولكننا نطلب ملاحظات من المنظومة المتكاملة حول الاقتراح هنا. |
| التخصيص | البحث عن خيارات التخصيص المتاحة لخدمة تجميع البيانات | لا يمكن إجراء تخصيصات لخدمة التجميع داخل TEE، ولكن يمكن إجراءها لبعض المكوّنات خارج TEE. ويعود السبب في ذلك إلى معايير الخصوصية والأمان التي يجب أن نحافظ عليها في TEE. نعمل على تعديل مستنداتنا لمساعدة تكنولوجيا الإعلان على فهم البنية والمكوّنات القابلة للتخصيص. لن نتمكّن من إتاحة بعض عمليات التخصيص، لذا ننصح تقنيات الإعلان باستخدام الإعدادات العادية متى أمكن ذلك. |
| مقارنة بين النُسخ الفورية والنُسخ المتاحة عند الطلب | هل تم اختبار النظام باستخدام النُسخ غير القابلة للاستبدال مقارنةً بالنُسخ عند الطلب؟ هل هناك أي عيوب محددة لاستخدام المثيلات الافتراضية، بصرف النظر عن عدم توفرها المؤقت المحتمل؟ | لا نعطي الأولوية لإجراء الاختبارات على الأجهزة الافتراضية، لأنّنا ننصح بأن يستخدم فريق تكنولوجيا الإعلان المثيلات المتوفرة عند الطلب. يتمثل عيب استخدام النُسخ المستضافة في الوقت الحالي في أنّه يتم إيقاف المهمة أثناء إنفاق الميزانية. إذا تمّ استخدام الميزانية وانقطعت المهمة قبل أن تتلقّى تكنولوجيات عرض الإعلانات التقرير الملخّص، لن تتمكّن تكنولوجيات عرض الإعلانات من إعادة محاولة تنفيذ المهمة، بل ستحتاج إلى طلب استرداد الميزانية. لا يُنصح باسترداد الميزانية إلا في حالات الأعطال الكارثية للحفاظ على الخصوصية. نقترح أن تضبط تكنولوجيات الإعلان تغيير الحجم التلقائي للمساعدة في تقليل التكاليف. يعني اختيار 0 لميزة "توسيع النطاق التلقائي" أنّه لن تكون هناك نُسخ مثبّتة وقيد التشغيل إلى أن يتم طلب وظيفة (يُرجى العِلم أنّ هذا قد يؤدي إلى زيادة وقت الاستجابة لأنّ النُسخ سيتم تشغيلها في وقت الطلب). |
| الأخطاء المعروفة والحلول | مطلوب توضيح بشأن مهمة "خدمة تجميع البيانات" التي تعرض "خطأ في الخدمة" | تم حلّ هذه المشكلة هنا. لقد عدّلنا أيضًا بعض رسائل الخطأ لتكون أكثر وصفًا. على سبيل المثال، بدأنا طرح أخطاء أكثر تحديدًا للأذونات/المصادقة على AWS مقارنةً بالحالات السابقة التي تم فيها عرض هذه الأخطاء كأخطاء داخلية. لقد عدّلنا المستندات المتعلّقة برموز الأخطاء وخطوات التخفيف من تأثيرها هنا ونرحّب بملاحظات إضافية حول الأخطاء غير الموثّقة أو غير المتاحة والتفاصيل التي قد تكون مفيدة هنا. |
Private Aggregation API
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| تصميم المفاتيح | طلب الحصول على إرشادات حول تصميم مفتاح التجميع الخاص | على الرغم من أنّنا لا نملك دليلاً خاصًا بميزة "التجميع الخاص"، يمكن استخدام كلّ من إطار عمل اختبار التحميل لخدمة التجميع ودليل إدارة المفاتيح المتقدّمة كمرجعَين. |
| ميزانية المساهمة | على أي مستوى يتم احتساب ميزانية المساهمات وحصرها؟ | تكون ميزانية المساهمة 2^16 في فترة زمنية متجدّدة مدتها 10 دقائق و2^20 في فترة زمنية متجدّدة مدتها 24 ساعة. |
الحد من التتبُّع الخفي
تقليل معلومات وكيل المستخدم/تعديلات برنامج وكيل المستخدم
لم يتم تلقّي أي ملاحظات خلال هذا الربع من السنة.
حماية عنوان IP (المعروفة سابقًا باسم Gnatcatcher)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| Android | ما هي خطة طرح ميزة "حماية عنوان IP" على أجهزة Android؟ | نحن نستكشف إمكانية توفير ميزات مكافحة التتبّع الخفي على أجهزة Android، بما في ذلك ميزة "حماية عنوان IP"، ولكن ليس لدينا خطط رسمية لمشاركتها في الوقت الحالي. |
| استخدام واجهة برمجة التطبيقات | سؤال حول ما إذا كان هناك استثناء للحماية من الاحتيال في ميزة "حماية عنوان IP" أو سيتم توفيره | نسعى جاهدين إلى تحقيق التوازن بين حماية المستخدمين من التتبّع على الويب استنادًا إلى عناوين IP الخاصة بهم والحدّ من تعطيل العمليات العادية للخوادم، بما في ذلك استخدام عناوين IP لمكافحة إساءة الاستخدام. على الرغم من أنّه لا يمكننا تقديم المزيد من التفاصيل في الوقت الحالي، نتوقع تقديمها في المستقبل القريب ونتطلع إلى مواصلة المناقشة. |
| تحديد الجهات المسيئة | المخاوف بشأن فعالية إجراءات الأمان التقليدية في مواجهة عناوين IP الضارّة | ولن تؤدي حماية عنوان IP إلى خادم وكيل لطلبات الطرف الأول، لذا نتوقع ألا تتأثر معظم أنظمة الكشف عن التسلل. نخطّط لتوفير تفاصيل إضافية في المستقبل تتناول المخاوف المتعلّقة بمكافحة الاحتيال وتعذُّر الوصول إلى الموقع الإلكتروني لمستخدمي وضع التصفّح المتخفي. |
| إخفاء عناوين IP | إذا كان موقع الناشر الإخباري (طرف أول) يستخدم النطاق نفسه مع الموقع الإعلاني (طرف ثالث)، هل سيتم حجب عنوان IP لكلا الموقعَين؟ إذا لم يكن الأمر كذلك، كيف يمكن التمييز بين الاثنين؟ | تقترح ميزة "حماية عنوان IP" حاليًا نهجًا قائمًا على القائمة لتحديد الزيارات التابعة لجهات خارجية التي تمر عبر الخوادم الوكيلة. ومع ذلك، حتى إذا كان مصدر معيّن مدرَجًا في هذه القائمة، لن يتمّ توسيطه إذا تمّ الوصول إليه في سياق جهة أولى. نحن بصدد وضع اللمسات الأخيرة على التفاصيل المتعلقة بنطاقات الجهات الخارجية المحدّدة التي سيتم منح الأولوية لها في البداية وكيفية تحديد سياقات الجهات الأولى والجهات الخارجية بدقة لحماية عنوان IP. |
| إخفاء عنوان IP | القلق بشأن حماية عنوان IP وتأثيرها في أنظمة مكافحة الاحتيال | لا تتأثر عناوين IP الأولى بخطط حماية عناوين IP، لذا من المفترض أن تتمكن المواقع الإلكترونية، مثل المنتديات، من الوصول إلى عناوين IP لحل النزاعات. ونسعى إلى تقديم تفاصيل إضافية في المستقبل لمعالجة المخاوف المتعلقة بالاحتيال الإعلاني. |
| إخفاء عناوين IP | هل عنوان IP مخفي في عنوان النطاقات المتأثرة؟ | سيتم تعيين المستخدمين إلى منطقة جغرافية استنادًا إلى عنوان IP السابق للخادم الوكيل الذي يمثّل الموقع الجغرافي الحالي. ويمكنك الاطّلاع على المزيد من التفاصيل هنا. |
الحدّ من التتبّع الارتدادي
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| مواصفات واجهة برمجة التطبيقات | مطلوب توضيح حول سلوك Chrome في التعامل مع التنقّل الموسّع عند إغلاق علامة تبويب. | لقد حللنا هذه المشكلة هنا وعدّلنا المواصفة وفقًا لذلك. |
| تتبُّع الملاحة | مناقشة منهج للتخفيف من التتبُّع يتضمن مجموعة محدودة من الروابط لتقليل التشويش في الطلبات على مستوى المواقع الإلكترونية | نحن نواصل مناقشة هذا الموضوع مع مورّدي المتصفّحات الآخرين هنا، ونرحّب بملاحظات إضافية وأي اقتراحات محدّدة حول هذه المشكلة من المنظومة المتكاملة. |
ميزانية الخصوصية
كما هو موضّح في الشرح على GitHub وموقع المطوّرين الإلكتروني، لم تعُد ميزانية الخصوصية
تُعتبر بشكل نشط كجزء من اقتراحات "مبادرة حماية الخصوصية".
تعزيز حدود الخصوصية على مستوى المواقع الإلكترونية
ميزة Related Website Sets (المعروفة سابقًا باسم "مجموعات نطاقات الطرف الأول")
| موضوع الملاحظات | ملخّص | ردّ Chrome |
|---|---|---|
| (تم الإبلاغ عنه أيضًا في الربعَين السابقَين) الحدّ الأقصى لنطاقات مجموعات المواقع الإلكترونية ذات الصلة (RWS) | طلب زيادة حدّ النطاقات المرتبطة ضمن RWS | تشبه ردّنا فصول الأرباع السابقة: في الوقت الحالي، لا نتوقّع زيادة الحدّ الأقصى للأرقام. تم تحديد الحد الأقصى استنادًا إلى اعتبارات خصوصية المستخدمين والملاحظات الواردة من الجهات المعنية في منظومة الإيكولوجيا في W3C، بالإضافة إلى النظر في عمليات التنفيذ المشابهة في المتصفّحات الأخرى. للحصول على معلومات إضافية، يُرجى الاطّلاع على مشاركات المدونة (1 و2). ننصح بفحص حالات الاستخدام التي تتطلّب الوصول إلى ملفات تعريف الارتباط على مواقع إلكترونية مختلفة بما يتجاوز الحدّ الرقمي، والاستفادة من إرشاداتنا بشأن حالات استخدام الهوية وعمليات التضمين التي تمّت المصادقة عليها وحالات استخدام الإعلانات. إذا كانت جلسات المستخدمين مرتبطة بإجراءات تسجيل الدخول، ننصحك باستخدام واجهة برمجة التطبيقات لإدارة بيانات الاعتماد الفيدرالية (FedCM) للحفاظ على الوظائف. نرحّب بملاحظاتك بشأن حالات الاستخدام الأخرى التي قد تكون مطلوبة هنا. |
| التعامل مع ملفات تعريف الارتباط على مستوى المواقع الإلكترونية | لا يتم تمرير ملفات تعريف الارتباط على مستوى المواقع الإلكترونية التي تم ضبطها من خلال نطاق فرعي في الطلبات اللاحقة من النطاق الأساسي. تستمر المشكلة حتى مع ضبط إعدادات CORS والبيانات المُعتمَدة بشكلٍ صحيح. | لقد قدّمنا إرشادات هنا بشأن الاستخدام الصحيح لواجهة برمجة التطبيقات requestStorageAccessFor التي تتطلّب تحديد المصدر الكامل (أي تضمين النطاقات الفرعية) من أجل إرسال ملفات تعريف الارتباط على مستوى المواقع الإلكترونية في طلبات الجلب اللاحقة. |
| اختيار المستخدم | طلب الحصول على مزيد من المعلومات حول requestStorageAccessFor المستخدَمة من قِبل RWS بعد طرح ميزة "خيار المستخدم"، لا سيما كيفية عمل إيماءة المستخدم الضمنية أو الصريحة التي تسمح حاليًا بالوصول إلى 3 أجهزة كمبيوتر في النظام الجديد | نتوقع أن يكون سلوك ميزة "المعالجة المحدودة للبيانات" في أيّ من وضعَي اختيار المستخدم (أي بغض النظر عمّا إذا اختار المستخدمون الاحتفاظ بملفات تعريف الارتباط التابعة لجهات خارجية أو حصرها) متسقًا مع السلوك الحالي/المتاح في Chrome مع السماح بملفات تعريف الارتباط التابعة لجهات خارجية مقابل حظر ملفات تعريف الارتباط التابعة لجهات خارجية مع تفعيل ميزة "المعالجة المحدودة للبيانات" (إعداد "السماح للمواقع الإلكترونية ذات الصلة بالاطّلاع على نشاطك في المجموعة"). ننصحك باستدعاء hasStorageAccess أولاً للتأكّد مما إذا كان بإمكان المحتوى المضمّن الوصول إلى ملفات تعريف الارتباط غير المقسَّمة على مواقع إلكترونية متعددة، وذلك قبل استدعاء requestStorageAccess. ستُعرِض طريقة hasStorageAccess القيمة true إذا اختار المستخدم السماح بتطبيقات الجهات الخارجية التي تملك إذن الوصول إلى مساحة التخزين. لا تتطلّب طريقة requestStorageAccessFor حاليًا إيماءة من المستخدم إذا كان الإذن بتطبيقات الجهات الخارجية مسموحًا به. لقد فتحنا مشكلة جديدة في GitHub لمناقشة السلوك الصحيح في هذه الحالة وتحديد السلوك الصحيح، ونرحّب بالملاحظات الإضافية الواردة من المنظومة المتكاملة. |
| استخدام واجهة برمجة التطبيقات | المخاوف بشأن عدم الوضوح بشأن استخدام RWS لأغراض "تجارية"، ما يعرقل عملية اعتمادها أشار صاحب المصلحة إلى اهتمامه بتجميع الإصدارات للإعلانات المستهدفة. | ويتمثل الاستخدام المقصود في RWS في دعم وظائف الموقع الإلكتروني الأساسية وتجارب المستخدم الأساسية. وننصحك باستخدام واجهات برمجة التطبيقات الإعلانية المصمّمة لهذا الغرض في حالات الاستخدام ذات الصلة بالإعلانات المستهدفة. |
| استخدام واجهة برمجة التطبيقات | الإبلاغ عن مشكلة في requestStorageAccess حيث يمكن ضبط بيانات localStorage ولكن ليس ملفات تعريف الارتباط | حدثت المشكلة بسبب خطأ إملائي في سمة SameSite. تأكَّد من التهجئة الصحيحة واضبطها صراحةً على "بدون" لأجهزة 3PC. |
| مواصفات واجهة برمجة التطبيقات | الاختلافات في مخطّطات JSON في المستودع، مثل وضع الحقل contact بشكل غير صحيح واقتراحات للتحسينات، بما في ذلك استخدام الكلمة الرئيسية oneOf لضمان الاتساق | نحن نتقصى هذه الملاحظات وسندرس إجراء هذه التحسينات على المخطط في المستقبل القريب. نرحب بملاحظاتك الإضافية هنا. |
| وصول الجهات الخارجية إلى RWS | بعد الحصول على موافقة المستخدم، يجب السماح للمنفذ بتحديد النطاقات التابعة لجهات خارجية التي ستحصل أيضًا على إذن بالوصول إلى بيانات واجهة برمجة التطبيقات RWS API. | إنّ السماح للجهات الخارجية بدمج بياناتها غير المقسّمة مع بيانات المواقع الإلكترونية في إطار "الاستجابة للطلبات بدون تخزين" سيؤدي إلى تقويض إجراءات حماية التتبّع على المواقع الإلكترونية في "مبادرة حماية الخصوصية". مع ذلك، ندرس إمكانية السماح للأطراف الثالثة بالاحتفاظ بالبيانات المقسَّمة إلى RWS، ونسعى للحصول على ملاحظات بشأن تصميم هذا الحل هنا. |
Fenced Frames API
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| سؤال حول واجهة برمجة التطبيقات | مخاوف بشأن كيفية تأثير "الإطارات المُغلقة" التي لا يمكنها الوصول إلى الشبكة في أمان العلامة التجارية وحماية المعلِنين من الاحتيال | ونحن نتّبع هذه المشكلة في سياق خطتنا لتطبيق ميزة Fenced Frames. سنبدأ قريبًا بالبحث عن حلول متوافقة مع فرض استخدام "الإطارات المحدود"، وسنشاركها فور توفّر اقتراحات كافية. |
| سؤال حول واجهة برمجة التطبيقات | هل ما زالت واجهة برمجة التطبيقات Fenced Frames API مجدولة في العام 2026؟ | وفقًا لما هو منصوص عليه في الإعلان العلني، لن تكون إطارات الالتفاف مطلوبة قبل عام 2026. |
| خطأ في واجهة برمجة التطبيقات | عندما يُرسِل reportEvent() بيانات النقرات بنجاح من إطار فرعي من مصدر مختلف، لا يُلغي reportEvent() بيانات الإطار العلوي.setReportEventDataForAutomaticBeacons() |
نحن بصدد مناقشة هذه المشكلة ونرحّب بملاحظاتك الإضافية هنا. |
Shared Storage API
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| الإعلان عن التطبيقات | لا تتوفّر واجهة برمجة تطبيقات مكافئة لواجهة Shared Storage API في "مبادرة حماية الخصوصية" على Android. | نحن نقيّم الحلول على Android استنادًا إلى احتياجات حالات الاستخدام والقيود المفروضة على المنصة. ليس لدينا أي خطط لمشاركتها في الوقت الحالي، ولكننا نرحب بملاحظات إضافية من المنظومة المتكاملة بشأن هذه المشكلة. |
| استخدام واجهة برمجة التطبيقات | هناك التباس بشأن الحاجة إلى أداة عمل إضافية لتطبيق JavaScript من أجل تنفيذ Shared Storage API. |
نحن ننظر في هذه الملاحظات ونبحث في إمكانية تعديل مستنداتنا لشرح الحاجة إلى نصوص برمجية إضافية لتطبيقات "مهام صغيرة" لواجهة برمجة التطبيقات Share Storage API. |
| عدم الموثوقية | يمكن أن تتغيّر واجهة برمجة التطبيقات المشتركة في مساحة التخزين بشكل كبير أو قد يتم تجاهلها بناءً على الانتقادات المتعلّقة بالخصوصية، ما يجعلها قاعدة غير موثوقة للبناء عليها. | لا نخطط لتغيير البنية الأساسية لميزة "مساحة التخزين المشتركة" أو إيقافها نهائيًا. إنّ التغييرات الرئيسية التي تم الإعلان عنها هي في بوابة الإخراج لعنوان URL المحدّد، حيث ستكون الإطارات المُحدودة مطلوبة وسيتم إيقاف إعداد التقارير على مستوى الحدث نهائيًا. ولن تسري هذه التغييرات إلا في العام 2026 على الأقل. |
ملفات تعريف الارتباط في الحالة المقسَّمة المنفصلة (CHIPS)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| ملفات تعريف الارتباط المُقسَّمة | لا يفرّق Chrome بين مفاتيح التقسيم بناءً على الكيانات الأصلية للإطارات، على عكس Firefox، ما يؤدي إلى عدم الاتساق. | اعتمد Chrome "وحدة بت سلسلة الأصل" لحل المخاوف الأمنية والتناقضات مع سلوك Firefox. يمكنك الاطّلاع على مزيد من التفاصيل هنا. |
| ملفات تعريف الارتباط المُقسَّمة | تشارك إطارات iframe المضمّنة التي لها مستويات وصول مختلفة إلى مساحة التخزين ملف تعريف الارتباط المقسَّم نفسه وتُعيد كتابته، ما يؤدي إلى حدوث تناقضات في حالات المصادقة. | بالنسبة إلى هذا الإعداد المحدّد، ننصحك باستخدام ملفات تعريف ارتباط غير مقسّمة مع طلب واجهة برمجة التطبيقات Storage Access API. لقد ناقشنا هذا الموضوع بمزيد من التفصيل هنا. |
| ملفات تعريف الارتباط المُقسَّمة | هل سيتم محو ملفّات تعريف الارتباط المُقسَّمة عند إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية؟ هل هناك طريقة لاختبار هذا السلوك؟ | ليس لدينا أي خطط لمشاركة هذه المعلومات في الوقت الحالي. ومع ذلك، يمكن للمطوّرين اختبار هذه الوظيفة من خلال حذف ملفات تعريف الارتباط المقسّمة يدويًا من خلال لوحة "تطبيق أدوات مطوّري البرامج في Chrome>ملفات تعريف الارتباط". |
FedCM
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| نطاق تسجيل موفِّر الهوية (IdP) وأداة اختيار المؤسسة |
سؤال حول توسيع نطاق تسجيل موفِّر الهوية من السياسة الحالية المشتركة المصدر إلى سياسة الموقع الإلكتروني نفسه سيسمح هذا التغيير بإدارة الهوية على نطاق أوسع وأكثر مرونة، مثل السماح لصفحة الترحيب في إحدى الجامعات بتسجيل عدة مقدّمي هوية مستندين إلى النطاق الفرعي بدون الحاجة إلى عمليات تسجيل منفصلة خاصة بالمصدر. ملاحظات حول تحسين إمكانية تصحيح الأخطاء، ومعالجة العملاء الموافَق عليهم للتوسّط الصامت، وتوضيح سلوك ملفات تعريف الارتباط، والسماح بتخصيص نص النافذة المنبثقة، ومعالجة مشاكل المهلة |
نحن ندرك هذه الملاحظات وننظر في كيفية دمج أداة اختيار المؤسسات في FedCM. ونرحّب بملاحظات وآراء إضافية من المنظومة المتكاملة هنا بينما نواصل تحسين هذا النهج. |
| ملفات تعريف ارتباط موفِّر الهوية | مناقشة حول تأثير تنفيذ ملفات تعريف ارتباط الجلسات قصيرة العمر كجزء من اقتراح "بيانات اعتماد الجلسة المرتبطة بالجهاز" (DBSC) تمّ التعبير عن مخاوف بشأن تجربة المستخدِم في FedCM، حيث تتطلّب ملفات تعريف الارتباط لموفِّر الهوية المنتهية الصلاحية وضعًا مشروطًا يظهر للمستخدِم من أجل التجديد. | يجب أن تسمح سياسة DBSC المقترَحة بتجديد ملفات تعريف الارتباط بدون تفاعل المستخدم، ما يضمن استمرارية تجربة المستخدم. لقد ناقشنا هذه المشكلة بالتفصيل هنا. |
| مواصفات واجهة برمجة التطبيقات | سؤال حول مدى ملاءمة استخدام "NetworkError" في مواصفات واجهة برمجة التطبيقات FedCM API عندما لا يساوي حجم مصفوفة "providers" 1 | نتّفق على أنّ الخطأ "TypeError" سيكون أكثر ملاءمة لهذا الموقف، لأنه يعكس خطأ في الترميز بدلاً من مشكلة في الشبكة. سننظر في هذا التغيير ونستكشف إمكانية إزالة هذا التقييد في التحديثات المستقبلية أثناء تقدّمنا في إتاحة استخدام موفِّري هوية متعددين. نرحب بملاحظاتك الإضافية هنا. |
مكافحة المحتوى غير المرغوب فيه والاحتيال
Private State Tokens API (وواجهات برمجة التطبيقات الأخرى)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| فترة تجريبية لإيقاف الميزة نهائيًا والوضع "ب" | المخاوف بشأن فترة إيقاف الميزة نهائيًا والاختبار في الوضع "ب" وإمكانية إيقاف استخدام "الرموز المميّزة للحالة الخاصة" (PST) وإمكانية توفّر واجهة برمجة تطبيقات جديدة تناسب حالة الاستخدام المتعلّقة بمكافحة الاحتيال بشكلٍ أفضل | لن تتغيّر فترة الاختبار لعملية الإيقاف النهائي واختبار الوضع "ب". سنُعلمك بأي تعديلات من خلال مدوّنة المطوّرين. لا ننوي إيقاف إتاحة علامة التبويب "الإعلانات المتجاوبة على شبكة البحث"، ونحن نناقش حاليًا تطوير الميزات والتعديلات المستمرة على GitHub. لم نعلن عن أي واجهات برمجة تطبيقات جديدة، ولكننا نرحّب بملاحظاتك حول كيفية معالجة ملفات PST لحالات الاستخدام لمكافحة الاحتيال بشكل أفضل. |
| ملاحظات بشأن واجهة برمجة التطبيقات | طلب إمكانية إبطال الرموز المميّزة لمعالجة حالة استخدام لمكافحة الاحتيال | يمكن لجهة الإصدار إبطال جميع الرموز المميّزة من خلال تغيير المفاتيح التي تستخدمها، لكنّ عمليات إبطال الرموز المميّزة الفردية غير قابلة للتنفيذ مع واجهة برمجة التطبيقات، لأنّ ذلك قد يتطلّب السماح لجهة الإصدار بربط إصدار الرموز المميّزة وتحصيل قيمتها، ما يؤدي إلى إيقاف نموذج خصوصية PST لمنع التتبُّع بين الحدثَين. |