تقرير ربع سنوي للربع الرابع من عام 2024 يلخّص الملاحظات التي وردتنا من المنظومة المتكاملة بشأن اقتراحات "مبادرة حماية الخصوصية" وردّ Chrome عليها.
كجزء من التزاماتها تجاه هيئة CMA، وافقت Google على تقديم تقارير ربع سنوية علنية حول عملية مشاركة الجهات المعنية بعروض "مبادرة حماية الخصوصية" (راجِع الفقرتين 12 و17(ج)(2) من الالتزامات). يتم إنشاء تقارير الملخّصات هذه حول الملاحظات والآراء بشأن "مبادرة حماية الخصوصية" من خلال تجميع الملاحظات والآراء التي تلقّاها Chrome من المصادر المختلفة كما هو موضّح في نظرة عامة على الملاحظات والآراء، بما في ذلك على سبيل المثال لا الحصر: مشاكل GitHub ونموذج الملاحظات والآراء المتاح على privacysandbox.com والاجتماعات مع الجهات المعنية في المجال ومنتديات معايير الويب. يرحّب فريق Chrome بالملاحظات الواردة من المنظومة المتكاملة ويستكشف بنشاط طرق دمج الدروس المستفادة في قرارات التصميم.
يتم ترتيب مواضيع الملاحظات حسب معدّل تكرارها لكل واجهة برمجة تطبيقات. ويتم ذلك من خلال تجميع عدد الملاحظات التي تلقّاها فريق Chrome حول موضوع معيّن وتنظيمها بترتيب تنازلي حسب الكمية. تم تحديد مواضيع الملاحظات الشائعة من خلال مراجعة مواضيع المناقشة من الاجتماعات العامة (W3C وPatCG وIETF) والملاحظات المباشرة وGitHub والأسئلة الشائعة التي تظهر من خلال فِرق Google الداخلية والنماذج العامة.
وعلى وجه التحديد، تمت مراجعة محاضر اجتماعات الهيئات المسؤولة عن معايير الويب، وبالنسبة إلى الملاحظات المباشرة، تمّت مراجعة سجلّات Google لاجتماعات الجهات المعنيّة وجهًا لوجه، والرسائل الإلكترونية التي تلقّاها المهندسون الفرديون، والقائمة البريدية لواجهات برمجة التطبيقات، ونموذج الملاحظات العامة. بعد ذلك، نسّقت Google بين الفِرق المشارِكة في أنشطة التواصل المختلفة هذه لتحديد مدى انتشار المواضيع التي تظهر في ما يتعلّق بكل واجهة برمجة تطبيقات.
تم تطوير تفسيرات ردود فريق Chrome على الملاحظات من خلال الأسئلة الشائعة المنشورة والردود الفعلية التي تم تقديمها على المشاكل التي طرحها أصحاب المصالح، وتحديد موقف معيّن لأغراض هذا التمرين الخاص بإعداد التقارير العلنية. استنادًا إلى التركيز الحالي على التطوير والاختبار، تلقّينا أسئلة وملاحظات حول المواضيع وواجهة برمجة التطبيقات PA API وواجهات برمجة التطبيقات والتكنولوجيات المتعلّقة بإعداد تقارير تحديد المصدر.
قد لا يكون قد تم تقديم ردّ من فريق Chrome بشأن الملاحظات التي تم تلقّيها مؤخرًا.
مسرد الاختصارات
- 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 الإعلاني سيعمل حصريًا على تكنولوجيات "مبادرة حماية الخصوصية"، سيزداد خطر انخفاض الفائدة بشكلٍ دائم، كما سيزداد احتمال أن تتخلّى Google عن هذه التكنولوجيا. إنّ عملية البيع هذه أو الانخفاض في القيمة سيكونان تهديدًا وجوديًا لإمكانية توجيه الإعلانات التي تراعي الخصوصية على الويب المفتوح. | لا تضمن "الالتزامات" أن تعمل أنشطة Google الإعلانية حصرًا على تقنيات "مبادرة حماية الخصوصية". تنوي Google استخدام نهج مجموعة المنتجات في ما يتعلّق بإمكانية تحديد المصدر، والذي سيشمل تقنيات "مبادرة حماية الخصوصية"، بالطريقة نفسها التي يمكن للجهات الخارجية استخدامها. ندرك أنّ نهج المحفظة شائع في المنظومة المتكاملة للإعلانات. نعتقد أنّه لا يزال من المهم أن يحصل المطوّرون على أدوات وتقنيات للحفاظ على الخصوصية. سنواصل إتاحة واجهات برمجة التطبيقات في "مبادرة حماية الخصوصية" وسنستثمر فيها لتحسين الخصوصية والاستخدام بشكل أكبر. |
ميزة الإدارة | لا يتضمّن نموذج الإدارة المقترَح آليات محدّدة للمساءلة في عمليات الاستشارة الرسمية أو طلبات إعادة النظر. | هذا غير صحيح. يقدّم كلّ من (1) نظام صنع القرار والمنشورات المرتبطة به و (2) عملية تقديم طلبات إعادة النظر آليات محدّدة للمساءلة. بالإضافة إلى ذلك، سيشرف "الوصي على المراقبة" على عملها بالتفصيل. |
ميزة الإدارة | ملاحظات تفيد بأنّ النموذج لا يحتوي على أحكام لإنشاء معيار على جميع المنصات والحفاظ عليه | لا يمكن لأي نموذج إدارة إجبار الجهات الفاعلة الأخرى، في هذه الحالة المتصفّحات، على اعتماد معيار معيّن. وبالتالي، لم نقترح نموذجًا يتطلب اعتماد المعايير على جميع المنصات. ستواصل Google المشاركة في منتديات المعايير التي يُعدّ فيها تقديم الاقتراحات ومشاركة الخبرة في تنفيذها نشاطًا شائعًا في هذه العملية. |
ميزة الإدارة | ننصحك بتمديد فترة الاستشارة إلى شهرَين على الأقل. لا يقدّم نموذج الحوكمة المقترَح للمنظومة المتكاملة وقتًا كافيًا لتحليل تأثيرات التغييرات المقترَحة. | لا تشكّل فترة الأسابيع الثلاثة فترة الملاحظات الكاملة لأي تغيير معيّن، لأنّ دورات الملاحظات الحالية (التي تستمر لفترة أطول بكثير) ستستمر. بدلاً من ذلك، توفّر عملية الاستشارة نافذة جديدة ورسمية للملاحظات ضمن العملية الحالية لاتخاذ القرارات الاستراتيجية. وبناءً على ذلك، سيظل بإمكان الجهات الخارجية تقديم الملاحظات من خلال المنتديات المختلفة (بما في ذلك GitHub وW3C وجهات وضع معايير الإعلانات، مثل IAB Tech Lab) أثناء عملية تطوير الميزة. من خلال تنظيم دورات الملاحظات بهذه الطريقة، تحصل المنظومة المتكاملة على فرصة لتحليل التغيير المقترَح ومشاركة آرائها بشأنه بدون تأخير عملية التطوير بشكل كبير. |
ميزة الإدارة | طلب تفاصيل حول خطط الإدارة المستقبلية | تمّ توضيح ملخّص لنموذج الإدارة المقترَح في تقرير الربع الثاني/الثالث من العام 2024 الصادر عن هيئة CMA (الصفحات 3-5 هنا). |
طلب استثناء | طلب الحصول على استثناء للوصول إلى ملفات تعريف الارتباط التابعة لجهات خارجية للمستخدمين الذين قدّموا موافقتهم | إنّ الموافقة على الوصول إلى الجهاز والتخزين لأغراض محدّدة لمعالجة البيانات لا تشير بحدّ ذاتها إلى أنّ المستخدم يريد إلغاء إعداد "المعالجة المحدودة للبيانات" في Chrome. إنّ السماح بإلغاء إعدادات ملفات تعريف الارتباط التابعة لجهة خارجية على مستوى الموقع الإلكتروني للمستخدم سيؤدي إلى احتمالية كبيرة لإساءة الاستخدام، ولن يكون من الممكن لمتصفّح Chrome تدقيق سلوك جميع المواقع الإلكترونية التي قد تؤدي إلى طلب استثناء. |
مبادرة حماية الخصوصية | طلب معدّلات الموافقة على استخدام واجهة برمجة التطبيقات Privacy Sandbox API | ليس لدينا أي خطط لمشاركة هذه المعلومات مع المنظومة المتكاملة. نرحب بالمطوّرين باستدعاء واجهات برمجة التطبيقات التي تم نشر الرمز البرمجي فيها اليوم لتقدير مدى توفّر واجهات برمجة تطبيقات "مبادرة حماية الخصوصية". |
مرحلة التجربة والتقييم | هل هناك خطة لتمديد فترة التجربة الأصلية؟ | تم تمديد فترة التجربة والتقييم حتى 14 نيسان (أبريل) 2025. |
مبادرة حماية الخصوصية | طلب شرح موجز غير تقني عن "مبادرة حماية الخصوصية" يُبرز قيمتها التجارية ويضمن موافقة المدراء التنفيذيين | لقد أضفنا مؤخرًا قسمًا بعنوان "مراجع النشاط التجاري" إلى privacysandbox.com هنا يقدّم هذه المعلومات. |
الوضع "ب" | عندما يكون المتصفّح في "الوضع ب"، هل سيبقى ملف تعريف الارتباط الحالي (1PC أو 3PC أو مساحة التخزين المحلية) أم سيتم محوه؟ | لن يتم محو ملفّات تعريف الارتباط الحالية. وسيظل بإمكانك الوصول إلى ملفات تعريف الارتباط التابعة لجهات خارجية في سياق الطرف الأول. |
نهج معدَّل لميزة "3 أجهزة شخصية" على Chrome | هل ستتم إزالة ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا من Chrome في المستقبل؟ | نقترح نهجًا معدّلاً يعزّز خيارات المستخدم. وكما هو موضّح هنا، بدلاً من إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا، سنقدّم تجربة جديدة في Chrome تتيح للمستخدمين اتّخاذ قرار مدروس ينطبق على تصفّح الويب، وسيكون بإمكانهم تعديل هذا الخيار في أي وقت. نحن نناقش هذا المسار الجديد مع الجهات التنظيمية، وسنتواصل مع الجهات المعنية في المجال قبل طرح هذه الميزة. |
اختبار Chrome | طلب مواصلة توفّر تصنيفات "الاختبار الذي يسهِّله Chrome" | يدرك فريق "مبادرة حماية الخصوصية" أنّ الشركات تريد مواصلة استخدام تصنيفات إيقاف ملفات تعريف الارتباط نهائيًا. تشبه عملية تمديد مدى توفّر التصنيفات عملية تمديد مرحلة التجربة والتقييم. وكجزء من هذه العملية، يمكن تمديد التجربة لمرحلة رئيسية واحدة فقط من مراحل Chrome في كل مرة. على سبيل المثال، تم تمديد أحدث تجربة لميزة "الرغبة في تمديد التجربة" (I2EE) في Chrome لعلامات إيقاف ملفات تعريف الارتباط نهائيًا، وذلك من الإصدار M130 إلى M132. يتيح ذلك استخدام التصنيفات حتى الإصدار الثابت M133 في أوائل شباط (فبراير). ستخضع الإضافات الإضافية لنفس العملية، لذا ننصحك بمتابعتها في مجموعة البريد الإلكتروني blink-dev للحصول على آخر الأخبار. |
التسجيل والإقرار
لم يتم تلقّي أي ملاحظات هذا الربع.
عرض محتوى وإعلانات ذات صلة
المواضيع
موضوع الملاحظات | ملخّص | استجابة Chrome |
---|---|---|
المواصفات | هل يتم مشاركة نموذج التصنيف بين Android (حسب اسم التطبيق) وChrome (حسب اسم المضيف)؟ | لا، فهما نموذجان منفصلان لأنّهما يتضمّنان تصنيفات مختلفة. |
دقة تصنيف "المواضيع" | تكون المواضيع عامة جدًا لكي تكون مفيدة عند استخدامها مع معلومات الطرف الأول. | تسعى التصنيفات في Topics إلى تحقيق التوازن بين الفائدة والخصوصية. لقد قيّمنا الآليات المحتمَلة لجعل "المواضيع" أكثر تحديدًا، ولكننا قرّرنا في النهاية عدم إجراء ذلك بسبب اعتبارات تتعلّق بالأمان والخصوصية، بالإضافة إلى مخاوف أخرى. يمكن للتقنيات الإعلانية تحقيق أفضل النتائج من خلال دمج جميع الأدوات المتاحة، مثل تعلُّم الآلة والإشارات المصمّمة بالتوافق مع معايير الخصوصية من واجهات برمجة التطبيقات التي تحافظ على الخصوصية، بالإضافة إلى البيانات السياقية وبيانات المواد الإبداعية وبيانات الطرف الأول. يمكنك الاطّلاع على مزيد من الإرشادات حول هذا الموضوع هنا. |
استخدام واجهة برمجة التطبيقات | تغطية Topics API منخفضة. | تشمل الأسباب الشائعة لانخفاض التغطية ما يلي: - عناصر التحكّم أو إيقاف الميزة لدى المستخدم - عناصر التحكّم أو إيقاف الميزة لدى الناشر - أهلية الموقع الإلكتروني (لا تتم الموافقة على المواقع الإلكترونية التالية لمطابقتها مع المواضيع: المواقع الإلكترونية غير الآمنة وWebView وChrome على نظام التشغيل iOS ووضع التصفّح المتخفي) - قيود المستخدم (لا يمكن مراقبة مستخدمي Chrome الذين تقلّ أعمارهم عن 18 عامًا أو الذين يستخدمون وضع التصفّح المتخفي وتحديد مواضيع لهم) - متطلبات مراقبة البائع (يجب أن يكون المتصل قد شاهد المستخدم من قبل على الموقع الإلكتروني المرتبط بموضوع مؤهّل) - وقت تنفيذ الميزة مؤخرًا (يُسمح بفترة تبلغ 4 أسابيع تقريبًا لزيادة مراقبة المتصل على نطاق واسع) |
استخدام واجهة برمجة التطبيقات | طلب الحصول على معلومات عن استخدام Topics API، حيث يبدو أنّ علامة التبويب "الشبكات" تعرض أنّ هناك طلبًا تم إرساله وتلقّيه، ولكنّ chrome://topics-internals/ لا يعرض المُراقب المسجَّل. | عند استخدام آلية عنوان HTTP للتفاعل مع Topics API، يتم إرسال المواضيع في عنوان الطلب Sec-Browsing-Topics، ولكن لا يتم رصدها إلا إذا ردّ الخادم بعنوان الاستجابة Observe-Browsing-Topics: ?1. يمكنك الاطّلاع على مزيد من التفاصيل هنا. |
المشاركة في Chromium | بالنسبة إلى أجهزة الكمبيوتر المكتبي، هل سيشارك Chrome مع المتصفّحات الأخرى المستندة إلى Chromium ملاحظات وسياق الترتيب نفسه؟ بالنسبة إلى الأجهزة الجوّالة، هل سيشارك متصفّح Chrome على Android مع متصفّحات Android الأخرى المستندة إلى Chromium / Chromium داخل التطبيق ملاحظات الأداء وسياق الترتيب نفسه؟ |
لا يشارك Chrome بيانات Topics مع المتصفّحات الأخرى على الجهاز. |
المواصفات | كيف تحدّد Topics API ما إذا كان يتم اعتبار مشاهدة صفحة من قِبل مستخدم "إدخال في سجلّ المواضيع"؟ | لكي تكون الزيارة مؤهّلة لاحتساب المواضيع الأسبوعية، يجب أن تتضمّن زيارة الصفحة طلب "مراقبة" (يمكن أن يكون من أي متصل). بدون طلب "المراقبة"، لن يتم احتساب الزيارة في سجلّ المواضيع. |
الأمان | كيف تمنع Topics API أحد المتصلين من الحصول على مواضيع مراقبة المتصلين الآخرين؟ | يمكنك الاطّلاع على الشرح هنا. |
التصنيف | كيف يتم استخدام التصنيف الهرمي للبنية في Topics API في الملاحظة في كل حقبة؟ | عند احتساب أهم 5 مواضيع، لا يتمّ احتساب سوى المواضيع الأصلية التي يقدّمها المصنّف، ويتمّ تحديد الترتيبات حسب (1) معدّل تكرار زيارات الصفحة و (2) نتيجة تحديد الأولوية (راجِع المواصفات). عند احتساب المواضيع الخمسة الأكثر شيوعًا التي رصدها المتصلون، يتم تضمين المتصلين الذين رصدوا الموضوع الرئيسي أو أيًا من المواضيع الفرعية. |
المواصفات | طلب الحصول على معلومات إضافية بشأن الضوضاء العشوائية التي تبلغ نسبتها% 5 في الاستجابة | تتوفّر دائمًا 5 مواضيع رئيسية لكل حقبة. إذا لم يتضمّن سجلّ التصفّح 5 مواضيع، يتم اختيار المواضيع عشوائيًا إلى أن يصبح لديك 5 مواضيع. ونُطلق على هذه المواضيع اسم "المواضيع المُضخّمة". ولن يتلقّى المتصلون أحد هذه المواضيع المضافة عشوائيًا ما لم يلاحظوا (أي استدعاء واجهة برمجة التطبيقات) المستخدم على موقع إلكتروني يتضمّن الموضوع خلال الأسابيع القليلة الماضية. عند طلب بيانات من واجهة برمجة التطبيقات، يتم احتساب تجزئة لكل مستخدم وموقع إلكتروني وفترة زمنية. إذا كانت هذه التجزئة أقل من احتمالية عرض موضوع مشوش، يتم اختيار الموضوع العشوائي لكل مستخدم وموقع إلكتروني وحقبة. ومع ذلك، لا يتم عرض الموضوع الذي تم تشويشه إلا (على سبيل المثال، لا تتم فلترته) إذا لاحظ المُرسِل الموضوع المقابل غير المشوش لهذا المستخدِم/الموقع الإلكتروني/الفترة الزمنية (راجِع الشرح). يضمن هذا الفلتر عرض المواضيع التي تتضمّن ضوضاء بنسبة% 5 من الوقت للمتصل المحدّد، بغض النظر عن قدرته على المراقبة. |
المواصفات | كيف تعمل المواضيع المكرّرة على مستوى الأسبوع؟ هل تختار واجهة برمجة التطبيقات بشكل مستقل بين الأسابيع ثم تدمجها؟ | يتم احتساب مواضيع كل أسبوع (حقبة) بشكل مستقل. يعتمد الموضوع المحدّد الذي يتم اختياره لعرضه من كل حقبة على الموقع الإلكتروني الذي يستخدمه المتصل. لا نأخذ في الاعتبار أنّه قد يتم تكرار الموضوع على مدار الفترات الزمنية لمتصل معيّن (لذلك يجب التفكير في اختيار موضوع مختلف)، ولكننا نرحب بملاحظات إضافية حول هذه المشكلة هنا. |
Protected Audience API
موضوع الملاحظات | ملخّص | استجابة Chrome |
---|---|---|
اختبار A/B | يضيف حلّ "مساحة التخزين المشتركة" الموضّح هنا وقت استجابة طويلًا ونسبة تعذّر عالية (أي أنّ نسبة كبيرة من الزيارات تنتهي بدون معرّف قاعدة سكانية). رقم تعريف منخفض التشويش (مثل 3 بت) قد تكون كافية لإجراء اختبار A/B فعّال بدون التأثير بشكل كبير في الخصوصية. | نعتقد أنّ حلّ "مساحة التخزين المشتركة" لا يزال حلاً عمليًا، ولكنّنا ننظر في هذا الطلب ونرحب بملاحظات إضافية من المنظومة المتكاملة إذا كانت هذه الميزة ذات أولوية عالية. |
إعداد التقارير | طلب الحصول على وحدات بت إضافية في reportWin() ، خاصةً أنّه من المتوقّع أن تستخدِم تقارير النقرات والعروض الجديدة في PA API من 6 إلى 8 وحدات بت، ما سيؤدي إلى تقليل الوحدات المتبقية المتاحة لإعداد تقارير PA API الأخرى بفعالية. |
لم نعُد نفكر في زيادة عدد بتات modelingSignals إلى أكثر من 12 بتًا حاليًا بسبب مخاوف متعلقة بالخصوصية. ندعو المنظومة المتكاملة إلى تقديم ملاحظات حول اقتراحنا بشأن "تدريب النماذج الخاصة" الذي يهدف إلى تلبية احتياجات تدريب تعلُّم الآلة في بيئة آمنة بدون فرض حدود على عدد الوحدات من قِبل "مبادرة حماية الخصوصية". |
المجموعات ذات الاهتمامات المشتركة | يُرجى طلب دورات حياة مدتها 90 يومًا لمجموعات الاهتمامات (IG) لأنّ 30 يومًا ليست مدة كافية. | كما ذكرنا في مقالتنا على المدونة، نخطّط لإطالة مدة عرض المحتوى على Instagram إلى 90 يومًا، وقد أنشأنا شرحًا توضيحيًا هنا. نحن نعمل حاليًا على التنفيذ، وسنشارك مخططًا زمنيًا للإطلاق عندما يصبح متاحًا. |
المجموعات ذات الاهتمامات المشتركة | طلب تعديلات ديناميكية لتفويض IG | نحن على علم بهذا الطلب الذي تلقّيناه من عدة جهات معنيّة ونبحث عن حلّ. سنشارك آخر الأخبار على GitHub أثناء تطوير هذه الميزة، ونرحّب بملاحظات إضافية من المنظومة المتكاملة. |
على الجهاز فقط | توضيح قيمة أكبر للمنظومة المتكاملة لمواصلة الاستثمار في حلول واجهات برمجة التطبيقات لمعالجة الإعلانات على الجهاز | يواصل فريق "مبادرة حماية الخصوصية" تطوير واجهات برمجة التطبيقات المستندة إلى تكنولوجيا تعزيز الخصوصية (PET)، بما في ذلك PA API، لتقديم المزيد من خيارات الحفاظ على الخصوصية للمطوّرين في المتصفّح. تتوفّر هذه التقنيات بشكل عام على نطاق واسع في متصفّحات Chrome الآن (وليس% 1 فقط كما فهم بعض المطوّرين). سواء فعّل المستخدمون ملفات تعريف الارتباط التابعة لجهات خارجية أم لا، يمكن للمطوّرين اختيار دمج الحلول المستندة إلى تكنولوجيات معالجة البيانات في منتجاتهم، تمامًا كما تختار العديد من الشركات استخدام حلول أخرى مستندة إلى تكنولوجيات معالجة البيانات خارج المتصفّح. يستفيد العديد من المطوّرين حاليًا من الاستثمار في حلول "واجهة برمجة التطبيقات لتحديد الجمهور على الجهاز فقط" من خلال توسيع نطاق إشارة جمهور الطرف الأوّل الحاسمة لتحسين مدى الوصول إلى الجمهور على جميع المواقع الإلكترونية. ندرك أنّ بعض المطوّرين لن يختاروا استخدام واجهات برمجة التطبيقات في "مبادرة حماية الخصوصية" أو حلول أخرى مستندة إلى تكنولوجيات معالجة البيانات الشخصية إلا إذا تم إيقاف المزيد من ملفات تعريف الارتباط التابعة لجهات خارجية، وينتظر هؤلاء المطوّرون معلومات تتيح لهم توقّع عدد المتصفّحات التي ستحتفظ بملفات تعريف الارتباط التابعة لجهات خارجية. ندرك أنّ هؤلاء المطوّرين سينتظرون إلى أن يعثروا على المعلومات التي يبحثون عنها من أجل اتخاذ قرارات بشأن المنتجات. |
المجموعات ذات الاهتمامات المشتركة | السماح لخدمات عرض الإعلانات (SSP) بالمشاركة في إنشاء الإعلانات المتجاوبة على شبكة البحث والأدوار المرتبطة بها ترى منصّات SSP أنّ هذا الإجراء يشكّل جزءًا مهمًا من القيمة المضافة التي تقدّمها، وتريد أن تتمكّن من مساعدة الناشرين في بيع إعلانات IG من خلال منصّاتها. | لقد تلقّينا طلبًا من جهات معنيّة متعددة بتوفير المزيد من تفويضات IG المتقدّمة، ونرى القيمة المضافة لخدمات SSP التي تساهم في هذه العملية. نحن نبحث عن أفضل حلّ يسمح لجهات مختلفة بالمشاركة في عملية توسيع نطاق الجمهور. سنشارك آخر الأخبار على GitHub أثناء تطوير هذه الميزة ونرحّب بملاحظات إضافية من المنظومة المتكاملة. |
إعداد التقارير | الاختلافات في عدد تقارير "عروض الأسعار غير الصفرية" بين forDebuggingOnly وPrivate Aggregation API | نتوقع حدوث تناقض لسببَين: أولاً، لا يتوفّر وضع تصحيح أخطاء Private Aggregation API إلا عندما تكون ملفات تعريف الارتباط التابعة لجهة خارجية الثالثة مسموحًا بها على الجهاز، في حين تتوفّر واجهة برمجة التطبيقات forDebuggingOnly API دائمًا بدون تحليل عيّنات (سيتم تغيير هذا السلوك الأخير في نهاية المطاف على النحو الموضّح هنا). ثانيًا، تفرض Private Aggregation API حدودًا على المساهمات، في حين لا تفرض forDebuggingOnly أي حدود. تشير هذه الملاحظات إلى أنّ هناك سببًا آخر قد يؤدي إلى حدوث تناقض غير متوقّع، ونحن نعمل مع أحد الجهات المعنية الخارجية لحلّ هذه المشكلة. |
مدى سهولة النقر | كما هو موضّح في الاقتراح المعدَّل لإشارة النقرات، سيتم تسجيل المشاهدات والنقرات من خلال عرض عنوان استجابة HTTP جديد للطلبات التي تبدأها السمة "attributionsrc" والتي تكون مؤهّلة"، وسيتضمّن عنوان الاستجابة هذا قائمة بالمصادر التي يمكن استخدامها للإشارة إلى الجهات الأخرى التي يمكنها تضمين هذه المشاهدات والنقرات في الأعداد المجمّعة. هل يعني ذلك أنّ تكنولوجيا الإعلان يمكنها ضبط المصادر بشكل عشوائي؟ | يُحدَّد في شرح التفاعل أنّ تكنولوجيا الإعلان التي تساهم في حدث مشاهدة أو نقرة في عدد المشاهدات والنقرات المجمّعة ("مصدر تقديم") قد تتضمّن مَعلمة اختيارية مع عنوان الاستجابة الذي يسمح لها بتحديد "مصدر مالك حساب على Instagram واحد أو أكثر قد يتم تضمين هذا الحدث فيه في عدد المشاهدات والنقرات المحسوبة التي سيتم تقديمها لطلبات generateBid() في مزادات "الجمهور المحمي"" ("المصادر المؤهّلة").مع ذلك، لا يتم تضمين هذه المشاهدات والنقرات تلقائيًا في عدد المشاهدات والنقرات. بدلاً من ذلك، على كلّ تقنية إعلان تحديد مجموعة "المصادر المقدّمة" التي يجب تضمين أحداث المشاهدة والنقر منها في ملفّات IG الخاصة بها، ولا تساهم سوى البيانات من هذه المصادر المقدّمة في أعداد المشاهدات والنقرات المقدَّمة إلى طلبات generateBid() تقنية الإعلان هذه.تتطلّب هذه الآلية إبرام اتفاقية بين الطرفَين، كما تمنع اللاعبين الأشرار من التأثير في عدد المشاهدات والنقرات لتقنيات عرض الإعلانات الأخرى. ويعني ذلك أيضًا أنّ تكنولوجيا الإعلان "المقدّمة" التي تحدّد "المصادر المؤهّلة" بشكل عشوائي لن تؤثر في عدد المشاهدات والنقرات لهذه المصادر المؤهّلة ما لم تتضمّن هذه المصادر المؤهّلة مصدر العرض هذا بشكل صريح ومقصود في IG. |
تدريب خاص على وضع النماذج | في بعض الحالات، قد تؤدي تقنية DP-SGD (الخصوصية التفاضلية - التدرّج العشوائي للظلال) إلى إبطاء عملية التدريب بشكل كبير لأنّها تقضي على كثافة التدرجات المحسوبة أثناء الانتشار العكسي. هل هناك أيّ أساليب يتمّ النظر فيها للتعامل مع هذه المشكلة أو أيّ أفكار بشأنها؟ | ندرك بعض التقنيات للحفاظ على الكثافة في DP-SGD (مثل هذه التقنية)، ونحن نستكشف إمكانية توفير هذه الأنواع من التقنيات في البنية الأساسية لتدريب النماذج الخاصة. سنشارك آخر الأخبار بشأن هذا التطوير ونرحّب بملاحظاتك الإضافية هنا. |
الاستهداف السلبي | طلب الحصول على آخر المعلومات حول طرح ميزة الفلترة السلبية في Instagram الموضّحة هنا | كما هو موضّح في ردّنا هنا، نخطّط لإتاحة استخدام عروض الأسعار لـ IG السلبية في PA API. سنشارك مخططًا زمنيًا للإطلاق عندما يتوفّر، ونرحّب بملاحظاتك الإضافية هنا. |
عروض الأسعار | هل من الممكن دمج مجموعات IG متعددة عند تقديم عروض الأسعار؟ | لا يمكن إجراء ذلك حاليًا باستخدام PA API. تستند PA API إلى التصميم الذي يربط IG بالمعلومات التي يعرفها موقع إلكتروني واحد عن المستخدم، والتي كانت أساسية في المناقشات مع المنظومة المتكاملة بشكل عام. يتيح هذا النهج لتكنولوجيات الإعلان إنشاء مجموعة متنوعة من الحلول التي تساعد المعلِنين في توسيع شرائح جمهورهم من الطرف الأول على الويب. ندرك أنّ اقتراح Microsoft بشأن Ads Selection API يقدّم تصميمًا مختلفًا يستند فيه الجمهور إلى المعلومات على مستوى المواقع الإلكترونية. سنواصل مراقبة نهجهم، ولكن نريد أن نرى المزيد من المناقشات من المنظومة المتكاملة، بما في ذلك منتدى الخصوصية، قبل أن ننظر في إجراء تغييرات مشابهة على Chrome. |
الإعلانات المدمجة مع المحتوى | المخاوف بشأن ما إذا كان بإمكان PA API توفير الأشكال المتنوعة ومتطلبات العرض المناسبة للإعلانات المدمجة مع المحتوى وما إذا كانت PA API تسمح بالمرونة الإبداعية والتحسين اللازمَين للإعلانات المدمجة مع المحتوى الفعّالة | نحن نبحث بنشاط عن تقديم المزيد من الدعم للإعلانات المدمجة، ونرحّب بملاحظات إضافية من النظام المتكاملة. |
إعداد التقارير | طلب تحسين ثبات نصوص إعداد التقارير التي تتنافس على الموارد مع نصوص عروض الأسعار والتي قد يتم فقدانها عند التنقّل بعيدًا عن إطار المزاد الجاري | نأمل نشر ردّ على GitHub قريبًا، ولكن لا نتوقّع أن تؤثّر هذه المخاوف بشكل كبير في عملية الإبلاغ الصالحة. |
الاستبدال باستخدام وحدات الماكرو | لا تعمل عمليات استبدال العلامات البرمجية التي تم تمريرها في إعدادات المزاد مع بعض الإعدادات التابعة لجهات خارجية. | كان السبب الأساسي هو أنّ هذه الميزة لم تكن مفعّلة في بعض الزيارات المصنّفة على أنّها ضِمن "الوضع أ/ب". لقد قرّرنا مؤخرًا تفعيل هذه الميزة (وميزات أخرى في الحالة نفسها) على جميع الزيارات المصنّفة على أنّها في "وضع أ/ب". نتوقّع إجراء هذا التغيير خلال الربع الأول من عام 2025. نرحب بملاحظاتك الإضافية هنا. |
الوثائق | نطلب التوضيح لأنّه يبدو أنّ هناك تناقضًا في المستندات بشأن وحدة قياس قيمة "الحداثة" في عنصر browserSignals ضمن generateBid() . |
لقد رددنا على ذلك بالتفصيل هنا وعدّلنا مستنداتنا وفقًا لذلك. الإجابة الصحيحة هي أنّ وحدة القياس هي المللي ثانية. |
إعداد التقارير | طلب إعداد تقارير الجهات الخارجية: في حين أنّ منصّات تخطيط الحملة ومستودعات المساحات الإعلانية تتلقّى إشعارات مرّات الظهور من Chrome، لا يتلقّاها مقدّمو الخدمات الفنيون في الطبقة الوسطى تلقائيًا. | نحن نناقش حاليًا طلب هذه الميزة هنا ونرحّب بملاحظاتك الإضافية. |
المجموعات ذات الاهتمامات المشتركة | طلب إرشادات حول كيفية استبعاد "المشترين حسب مجموعات الاهتمامات" بشكل ديناميكي عند استخدام سير عمل مزادات مجموعات الاهتمامات الموازية | يمكنك الاطّلاع على الإرشادات حول هذا الموضوع هنا. |
الإعلانات المدمجة مع المحتوى | تمنع مزادات PA API المستقلة لتحميل صفحة معيّنة فلترة الإعلانات على الصفحة نفسها. | إنّ إتاحة المزيد من الإعلانات المدمجة، بما في ذلك التطبيقات المصغّرة للاقتراحات المعروفة باسم "الإعلانات المدمجة" والتي تتضمّن إعلانات متعدّدة في وحدة واحدة، هي مجال بحث نشط، وندرك أنّ التصميم الحالي قد لا يتيح فلترة الإعلانات على الصفحة نفسها، وقد تمنع أيضًا وسائل الحماية الأخرى، مثل الإطارات المحدود، ذلك. |
الإعلانات المدمجة مع المحتوى | قد تحتاج ميزات PA API الحالية، مثل فحص المواد الإبداعية وإعداد التقارير وما إلى ذلك، التي تعتمد على الإشارات المستندة إلى عناوين URL، إلى التكيف مع عناصر JSON المستخدَمة في المواد الإبداعية للإعلانات المدمجة. | إنّ إتاحة المزيد من ميزات الإعلانات المدمجة مع المحتوى هي أحد مجالات البحث النشطة، ونحن نُقيّم جدوى تكييف PA API للمساعدة في عرض الإعلانات المدمجة مع المحتوى. |
التحقّق من الإعلانات | يتأثّر أمان العلامات التجارية التابعة لجهات خارجية في PA API بسبب وقت الاستجابة والقيود المفروضة على التخزين المؤقت لـ perBuyerSignals، ما يشكّل مشكلة في المحتوى الديناميكي. | ندرك أنّ منصّات عرض الإعلانات (SSP) وأنظمة إدارة الطلبات (DSP) تحتاج إلى تحديد مهلة تخزين مؤقت مثالية لتخزين البيانات توازن بين أهداف تشكيل الزيارات والحد الأقصى لمهلة التخزين المؤقت لأمان العلامة التجارية لضمان أن تظل البيانات المخزّنة مؤقتًا ذات صلة بأمان العلامة التجارية. نحن ننظر في هذه المشكلة وسنشارك آخر المعلومات عند توفّرها. |
التحقّق من الإعلانات | يجب أن تستبدل منصّات عرض الإعلانات وحدة الماكرو FullpageURL لإجراء قياس أمان العلامة التجارية بعد تقديم عروض الأسعار. | إنّ deprecatedReplaceInURN هو الاقتراح الحالي لخدمات عرض الإعلانات (SSP) لتقديم هذه الإشارة. |
التحقّق من الإعلانات | إنّ عدم توحيد تنسيقات العلامات الكبيرة التي تستخدمها منصّات عرض الإعلانات للتحقّق من صحة عروض الأسعار بعد تقديمها قد يؤدي إلى حدوث تناقضات وأخطاء في معالجة البيانات وتحليلها. | على منصّات SSP وأدوات التحقّق من الإعلانات التعاون مباشرةً لتحديد إرشادات ومواصفات واضحة لاستخدام العلامات المصغّرة من أجل تعزيز عملية توحيد تنسيقات العلامات المصغّرة على مستوى منصّات SSP لضمان الاتّساق ومنع حدوث أخطاء في معالجة البيانات وتحليلها. وهذا النشاط هو ما تُجيده مؤسسات معايير الإعلانات، مثل IAB Tech Lab. |
التحقّق من الإعلانات | يحتاج المعلِنون ومُدقّقو الإعلانات إلى آلية لربط عمليات التحقّق من عروض الأسعار قبلها وبعدها لسياق الناشر نفسه من أجل تصحيح الأخطاء وتحديد المشاكل وحلّها. | أحد خيارات التحقّق من صحة عروض الأسعار بعد تقديمها هو من خلال الإشارات المستندة إلى المزاد والحملة والمضمّنة في إعداد التقارير على مستوى الحدث. وقد يؤدي ذلك إلى تفعيل عمليات الدمج مع سجلّات قرارات عروض الأسعار المُسبَقة. نحن نستكشف الأنماط المحتملة لتحقيق ذلك، وسنشارك آخر المعلومات عند تطويرها. |
التحقّق من الإعلانات | طلب استكشاف حلول خادم مفتاح القيمة الموثوق به (TKV) (المملوكة من منصّة عرض الإعلانات والمملوكة من أداة التحقّق من الإعلانات) لعرض الإعلانات قبل تقديم عروض الأسعار ومعالجة القيود المفروضة على عرض الإعلانات في إطارات محصورة بعد تقديم عروض الأسعار | نحن بصدد تقييم هذا الطلب ونرحّب بملاحظات إضافية من المنظومة المتكاملة هنا للعثور على حلّ يمكن أن يدعم أمان العلامة التجارية قبل تقديم عروض الأسعار، وتسهيل متطلبات التنسيق بين الأطراف. |
الإعلانات المدمجة مع المحتوى | طلب تدقيق في عرض الإعلانات المتجاوبة بعد تقديم عروض الأسعار من جهة البيع | إنّ إتاحة المزيد من الإعلانات المدمجة مع المحتوى هو مجال نشط للبحث، ونحن ننظر في إمكانية تعديل الميزات الحالية، مثل هذه الميزة، للمساعدة في عرض الإعلانات المدمجة مع المحتوى. |
المزاد المحمي (خدمات الإعلانات والحملات)
موضوع الملاحظات | ملخّص | استجابة Chrome |
---|---|---|
استغرق الرد وقتًا طويلاً | لم يتم اتخاذ تدابير كافية للحدّ من وقت الاستجابة. على الرغم من أنّ خدمات B&A قد تقلّل من هذه المشكلة على المدى الطويل، لم تلتزم Google بتوفيرها على نطاق واسع قبل إجراء تغييرات على 3PCs على Chrome. | لقد أجرينا العديد من التحسينات على وقت الاستجابة على الجهاز في الربع الأخير. نحن نعمل أيضًا على إنشاء خدمات B&A وتوسيع نطاقها حسب الحاجة. لقد عدّلنا مؤخرًا دليل أفضل الممارسات المتعلّقة بوقت الاستجابة الذي يتضمّن مزيدًا من المعلومات حول كيفية الاستفادة من هذه الميزات. ونحن نواصل أيضًا تطوير تحسينات جديدة في وقت الاستجابة، ويمكن الاطّلاع على بعض منها هنا. |
(تم الإبلاغ عنها أيضًا في الربع السابق) أمان المزادات |
طلب الحصول على مزيد من الإيضاح حول الأساليب لمنع/تخفيف محاولات التلاعب بالمزاد على الجهاز (على سبيل المثال، بما في ذلك ما إذا كانت Google تعتبر ذلك خطرًا كبيرًا) | لم يتغيّر ردّنا عن الربع السابق: "تحتفظ آليات إعداد التقارير لإعلانات PA API بالمعلومات المستخدَمة لتمييز الزيارات البشرية عن الزيارات من برامج التتبّع في الوقت الحالي. بالإضافة إلى ذلك، يمكن استخدام الأساليب الحالية المستندة إلى النطاقات لتضمين النطاقات أو استبعادها في PA API. وقد تم توضيح ذلك بمزيد من التفصيل في ردّنا على تقرير "المختبَر التقني لمكتب الإعلانات التفاعلية" (IAB Tech Lab) بشأن "مبادرة حماية الخصوصية"." |
الحلول داخل المؤسسة | المخاوف بشأن احتمال عدم اعتماد أكبر المورّدين لـ "مبادرة حماية الخصوصية" أو B&A بسبب عدم توفّر إمكانات استخدام السحابة الإلكترونية الخاصة، وطول خارطة الطريق غير الشفافة نحو توفير هذه الإمكانات | نحن ملتزمون بتوسيع البنى الأساسية التي تعمل عليها خدمات "مبادرة حماية الخصوصية". لقد أعلنّا مؤخرًا عن إتاحة استخدام خدمات "مبادرة حماية الخصوصية" مع خدمات السحابة الإلكترونية Azure، ونواصل البحث عن الحلول المحتملة لتقديم إجراءات وقاية مماثلة للخصوصية والأمان في خدمات السحابة الإلكترونية الخاصة. منذ تواصلنا معك في تشرين الأول (أكتوبر)، أحرزنا تقدمًا في إطار مواصلة البحث عن الأساليب المحتملة لتأمين خصوصية مستخدمي Chrome في بيئة تنفيذ موثوق بها (TEE) على الموقع. لقد وصلنا الآن إلى مرحلة في بحثنا نريد فيها التحقّق من الأساليب المختلفة مع الجهات المعنية في النظام البيئي، ونخطّط لبدء جمع الملاحظات في الربع الأول. ستساعد الملاحظات والآراء حول المنظومة المتكاملة والتعاون في تحسين أي حلول محتملة. |
الاختبار | هل من الممكن إنشاء بيئة آمنة للاختبار من أجل اختبار حلول إعداد التقارير في PA API (إعداد التقارير في الوقت الفعلي والتجميع الخاص)؟ | لاختبار "خدمة التجميع"، يمكن لتكنولوجيات الإعلان استخدام بيانات الاختبار وأدوات "الاختبار على الجهاز فقط" لإنشاء تقارير تلخيصية للاختبار الوظيفي. يُرجى الرجوع إلى الدرس التطبيقي حول الترميز الخاص بالاختبار على الأجهزة المحلية هنا. لاختبار التجميع في TEE، على تكنولوجيات الإعلان إكمال عملية التسجيل كما هو موضّح في المتطلّبات الأساسية لـ Codelab أعلاه. نرحب بملاحظاتك الإضافية بشأن هذا الطلب هنا. |
دمج مفتاح/قيمة الصفقة | طلب إمكانية سحب معلومات مستندة إلى الصفقة من KV لحالات استخدام النشاط التجاري | نحن بصدد تقييم طلب الميزة هذا وسنُطلعك على آخر المعلومات على GitHub. |
مقياس الصفقة بلا فوز |
طلب إشارة أو القدرة على فهم الحالات التي لم يفوز فيها نظام SSP وسبب ذلك | نحن بصدد تقييم هذا الطلب وسنُطلعك على آخر المعلومات على GitHub. |
طلب ميزة | طلب من "مبادرة حماية الخصوصية" لتوفير بنية قاموس للمساعدة في مطابقة مجموعة من الإعلانات مع المجموعة ذات الصلة من أرقام تعريف الصفقات | نحن بصدد تقييم هذا الطلب، إلى جانب طرق أخرى لتقليل حجم IG في ما يتعلق بتخزين أرقام تعريف الصفقات. سنُعلمك بآخر الأخبار على GitHub. |
الأداء | حلول لقياس الفرص المحتملة التي فاتتك في مزاد الإعلانات، ربما بسبب حجم نص عروض الأسعار | نحن بصدد تقييم هذا الطلب ونرحّب بملاحظاتك الإضافية هنا. |
المواصفات | لا يقرأ B&A حاليًا سوى حقل prevWins بدلاً من الحقل الأخير prevWinMs الذي حلّ محلّ prevWins في المواصفات. | صحيح أنّ B&A لا تُرسل المدة بالمللي ثانية في prevWins إلى generatebid() . يُرسِل Chrome المدة بالثواني لضمان تقليل الوقت المستغرَق في نقل الحمولة، ويجب أن يُجري فريق B&A عملية التحويل من الثواني إلى المللي ثانية. ستقدّم B&A كلّ من prevWins وprevWinsMs في مَعلمات browserSignals لجعل ذلك متوافقًا مع المزادات على الأجهزة.ملاحظة: حتى في مزادات الأجهزة للويب، تتطابق prevWins وprevWinsMs مع القيمة نفسها وprevWinsMs = prevWins * 1000. نحن نعطي الأولوية لحلّ هذه المشكلة. |
الوثائق | لا توضّح المستندات كيفية اختبار Seller Front End (SFE)، لذا سيكون من المفيد الحصول على إرشادات اختبار إضافية بعد إكمال عملية النشر مباشرةً، بالإضافة إلى كيفية استخدام Bazel لعمليات الإنشاء. | تم نشر هذا الدرس التطبيقي حول الترميز كدليل لتسهيل اختبار تطبيقات SFEs في المنظومة المتكاملة الأوسع نطاقًا. |
التفعيل | هل هناك خطط لتقديم ثنائيات مُعدّة مسبقًا لـ B&A؟ | نحن نفكر في توفير ملفات ثنائية مُعدّة مسبقًا لنظام التشغيل B&A، ولكن ليس لدينا مخططات زمنية محددة لذلك. وحتى ذلك الحين، يمكن لتقنيات الإعلان إنشاء الملفات الثنائية بأنفسهم والتحقّق منها باستخدام التجزئات المقدَّمة. |
التفعيل | هل يجب أن تكون جميع أنواع عمليات التنسيق (الخادم أو العميل أو المختلط) متاحة أم أنّ هناك نوعًا يجب أن تُعطى له الأولوية على غيره؟ | ليس لدينا أي اقتراحات محدّدة حول الأوضاع التي تنفّذها تكنولوجيا الإعلان. يعتمد الاختيار على عوامل مختلفة، ولكن في النهاية، يعتمد على ما يخدم مصلحة عملائك على أفضل وجه. |
الاختبار | طلب توضيح بشأن الاختبارات التي تعذّر إجراؤها أثناء إنشاء الإصدار B&A | قد يكون ذلك نتيجة اختبار غير دقيق. لقد نصحنا فريق تكنولوجيا الإعلان باستخدام العلامة --no-tests مع جميع أوامر الإنشاء build_and_test_all_in_docker لتخطّي إجراء الاختبارات. |
السجلّات | نطلب توضيحًا لسبب وضع علامة على السجلات في "مستكشف السجلّات" على Google Cloud Platform لوحدة VM التي تعمل بتطبيق SFE في وضع الاختبار، ولكن لا يتم وضع علامة على السجلات لوحدة VM في وضع الإنتاج. | من الصعب التعميم لأنّ ذلك يعتمد على ما تم رصده بالضبط، ولكن بشكل عام: - من المحتمل أن تكون السجلات من non_prod هي سجلّات stderr التي أعاد مقدّم خدمات السحابة الإلكترونية توجيهها (في هذه الحالة، Google Cloud Platform)، وقد أضافت Google Cloud Platform العلامة. - يتم بشكل عام وضع علامة على السجلات التي ينشئها الجهاز الافتراضي باستخدام مثيل الجهاز الافتراضي، في حين لا تضع Google Cloud Platform علامة على السجلات التي ينشئها الملف الثنائي. - يتم تصدير السجلات من قناة الإصدار العلني بواسطة Open Telemetry في TEE، والتي تحتوي على علامات مختلفة. في ما يلي بعض التفاصيل حول ما هو متاح في non_prod وprod. |
B&A | خطأ 403 عند عدم توفّر الأسرار عندما تكون خدمة تسجيل OTEL غير مفعّلة | تم حلّ هذه المشكلة الآن بعد تحديث الإصدار 4.1، وتم تعديل المستندات وفقًا لذلك. |
B&A | يؤدي عدم توفّر ملف outputs.tf لإعدادات terraform في Google Cloud Platform إلى حدوث خطأ. | نودّ إعلامك بأنّه تمّ الآن إصلاح هذه المشكلة. |
الاختبار | حدث خطأ أثناء جلب المفتاح الخاص في وضع الاختبار. | في هذه الحالات، يُرجى التأكّد من تشغيل الخوادم مع TEST_MODE=true. يمكنك الاطّلاع على الشرح هنا. |
خارطة الطريق | هل هناك خطط لقبول getInterestGroupAdAuctionData لأكثر من مصدر بائع واحد وعرض خريطة لمصدر البائع إلى نص مشفّر لحمولة B&A؟ | نعم، من المخطّط إضافة ميزة السماح navigator.getInterestGroupAdAuctionData() بقبول بائعين متعدّدين. |
مواصفات KV | هل يمكن عرض عنوان URL الخاص بـ KV (trustedScoringSignalsURL) كوعد؟ | يمكنك الاطّلاع على التفسير المقدَّم هنا. |
B&A | طلب إنشاء عنوان منصة جديد للإشارة إلى جانب البائع في B&A بشأن الإمكانات التي يتطلبها العميل (المتصفّح) لإجراء مزاد خاص | نحن نناقش حاليًا طلب هذه الميزة هنا ونرحّب بملاحظاتك الإضافية. |
تشكيل الزيارات | اقتراح لخفض التكاليف المتزايدة الناتجة عن استضافة خوادم B&A، خاصةً لأنظمة إدارة الطلبات | نحن نناقش حاليًا هذا الاقتراح هنا ونرحّب بملاحظاتك الإضافية. |
Bring-Your- Own-Binary |
ننصحك بتعديل الشرح للإشارة صراحةً إلى أنّ جميع الملفات الثنائية متوافقة. | تم تعديل هذه السياسة الآن، ويمكنك الاطّلاع على الشرح هنا. |
مكالمات KV | هل ينتظر generateBid() انتهاء جميع طلبات تخزين مفتاح/قيمة (KV) أو يتم تنفيذه بشكل مستقل؟ كيف يؤثّر تجميع KV في توقيته؟ |
يمكنك الاطّلاع على التفسير المقدَّم هنا. |
الأداء | طلب مستندات إضافية حول إعادة استخدام نصوص عروض الأسعار واقتراح ضبط رؤوس التحكّم في ذاكرة التخزين المؤقت على النصوص البرمجية | تمّت إضافة المستندات هنا. |
الأداء | يُرجى النظر في إمكانية تحميل الموارد (مثل نصوص عروض الأسعار) بشكل غير متزامن واستكشافها من أجل تقليل وقت استجابة المزاد على الجهاز. | نحن نناقش حاليًا طلب هذه الميزة هنا ونرحّب بملاحظاتك الإضافية. |
تسجيل الموافقة | مطلوب توضيح بشأن الخطأ الذي يظهر عند محاولة استخدام تسجيل الموافقة من خلال ضبط CONSENTED_DEBUG_TOKEN. | في هذه الحالات، تأكَّد من توفّر CONSENTED_DEBUG_TOKEN في أداة إدارة الأسرار، ومن ضبط ENABLE_OTEL_BASED_LOGGING على true وTELEMETRY_CONFIG على mode: PROD. اطّلِع على الشرح هنا الذي يشير إلى المصدر هنا. |
السجلّات | هل أحداث forDebuggingOnly متاحة من خلال B&A؟ | أصبح الخيار forDebuggingOnly لميزة "الإعلانات والحملات" متاحًا في مزادات البائع الفردي منذ نيسان (أبريل) 2024. ونخطّط لإتاحة هذه الميزة في مزادات البائعين المتعدّدين قريبًا جدًا. |
سجلّات التطبيقات المصغّرة | طلب إتاحة تسجيل "وحدات العمل" مع ChromeDriver | نحن بصدد تقييم هذا الطلب ونرحّب بملاحظاتك الإضافية هنا. |
قياس الإعلانات الرقمية
تقارير تحديد المصدر (وواجهات برمجة التطبيقات الأخرى)
موضوع الملاحظات | ملخّص | استجابة Chrome |
---|---|---|
تقارير تصحيح الأخطاء | كيف ستتوفّر تقارير تصحيح أخطاء ARA لتكنولوجيات عرض الإعلانات بعد اتّباع النهج المعدَّل لملفّات تعريف الارتباط التابعة لجهات خارجية على Chrome؟ هل يجب أن تظلّ تقنيات الإعلان قادرة على الوصول إلى تقارير تصحيح أخطاء ARA للمستخدمين الذين يحتفظون بملفّات تعريف الارتباط التابعة لجهات خارجية وفعّلوا واجهات برمجة تطبيقات "مبادرة حماية الخصوصية"؟ |
ستتمكّن تكنولوجيات الإعلان من الوصول إلى حلول تصحيح الأخطاء المستندة إلى ملفات تعريف الارتباط وتلك الخالية من ملفات تعريف الارتباط في ما يتعلّق بالمستخدمين الذين تم تفعيل ميزة "المعالجة المحدودة للبيانات" و"المعالجة المحدودة للإعلانات" لديهما. وعندما تكون ملفات تعريف الارتباط غير مفعّلة، لن يتمكّن الفريق من الوصول إلا إلى حلّ تصحيح الأخطاء المجمّع. يمكنك الاطّلاع على مزيد من التفاصيل حول حلول تصحيح الأخطاء هنا وهنا. |
ميزة "اكتشاف الأشياء" | طلب الحصول على إرشادات حول كيفية رصد الميزات في ARA من جهة الخادم | يمكن حاليًا تحديد مدى توفّر ميزة ARA استنادًا إلى استخدام إصدار Chrome المعروض في سلسلة وكيل المستخدم. نرحب بملاحظات إضافية بشأن المنظومة المتكاملة في هذا الشأن. |
طلب ميزة | طلب أن يكون وقت تسجيل المصدر source_registration_time المستخدَم في "معلومات مشترَكة" مجمّعة لتحليلات الأداء على شبكة البحث (ARA) أكثر دقة، مثلاً تقريبًا إلى ساعة واحدة أو دقيقة واحدة (بدلاً من يوم واحد)، بالإضافة إلى إمكانية ضبطه لمراعاة المنطقة الزمنية (التوقيت العالمي المنسق فقط حاليًا). | إنّ تقريب الحقل source_registration_time إلى أقرب يوم هو آلية خصوصية تُستخدَم للحدّ من قدرة تكنولوجيا الإعلان على ربط مستخدم معيّن بتسجيل مصدر معيّن. يستند عمود source_registration_time حاليًا إلى التوقيت العالمي المنسَّق، ويمكن لشركة تكنولوجيا الإعلان تعديل تقارير إعلاناتها لمراعاة ذلك. نرحّب بملاحظاتك الإضافية بشأن المنظومة المتكاملة في ما يتعلّق بهذا الطلب هنا. |
المواصفات | طلب لتوضيح مواصفات "trigger_data" و "priority"، خاصةً عند استخدامهما مع قيمة الصفيف | لا تقبل هذه الحقول قيم الصفيف. لا تمثّل الأقواس المربّعة في الشرح صفيفًا، بل تشير إلى أنّ النص ليس مثالاً على قيمة، بل هو عنصر نائب يتضمّن وصفًا. كما يشير النص في الأقواس المربّعة: - trigger_data هو int-64 - priority هو int-64 موقَّع لا يقبل أيّ من الحقلين قيم الصفيف. من الجدير أيضًا التفكير في استخدام أداة التحقّق من العناوين في ARA لتجربة قيم مختلفة والتعرّف على الأخطاء في حال كانت المستندات مربكة. |
إتاحة الإعلانات في صفحات Accelerated Mobile Pages (AMP) | هل تتوافق ميزة ARA مع إعلانات AMP؟ | يمكنك الاطّلاع على اقتراحنا بشأن كيفية إتاحة تنسيق AMP هنا، ونحن نرحب بملاحظاتك الإضافية. |
المواصفات | ما هو عنوان URL الذي سيتم اعتباره "الموقع المصدر" للإعلانات المضمّنة متعددة الطبقات في ARA؟ | عنوان URL من الموقع الإلكتروني من المستوى الأعلى |
(تم الإبلاغ عنها أيضًا في الربع سنوية السابقة) طلب ميزة |
طلب خفض الحدّ الأدنى لقيمة event_report_window من 3600 ثانية (ساعة واحدة) إلى 1800 ثانية (30 دقيقة). | يتطلّب تحديد الحدّ الأدنى لفترة إعداد التقارير موازنة بين اعتبارات الاستفادة والخصوصية. إنّ الحدّ الأدنى لإطار إعداد التقارير الذي يبلغ ساعة واحدة للتقارير على مستوى الحدث هو أمر ضروري للحفاظ على الخصوصية والحدّ من أنواع معيّنة من هجمات إعادة إنشاء السجلّ. نرحب بملاحظاتك الإضافية بشأن هذا الطلب هنا. |
الضوضاء | البحث عن فهم أعمق لكيفية تنفيذ الضوضاء في تقارير مستوى الحدث في ARA لضمان التفسير الدقيق للبيانات واستخدامها | يمكنك الاطّلاع على مزيد من التفاصيل هنا وهنا. |
إعداد التقارير | لم تعُد سمة shared_info في "التقارير المجمّعة" تحتوي على سمة source_registration_time تلقائيًا. | ويعود سبب ذلك إلى تغييرات في واجهة برمجة التطبيقات، ويمكن الاطّلاع على مزيد من التفاصيل هنا. |
إعداد التقارير | لا يظهر الرمز filtering_id في علامة التبويب "التقارير القابلة للتجميع" في واجهة مستخدم chrome://attribution-internals/. |
يظهر الرمز filtering_id حاليًا في تفاصيل علامة التبويب "عمليات تسجيل التفعيل" عند النقر على صف، ما يتيح لك تأكيد صلاحيته. ندرك مدى فائدة عرضها في علامة التبويب "التقارير القابلة للتجميع"، وقد عالجنا هذه المشكلة هنا. |
مصدر تحديد المصدر | طلب توضيح حول آلية عمل مصدر الإحالة | يمكنك الاطّلاع على شرح هنا. |
تحديد مصدر الزيارات من التطبيق إلى الموقع الإلكتروني | طلب إرشادات حول عمليات التنفيذ التي لا يتأكّد فيها ما إذا كانت المصادر ستكون نظام التشغيل أو الويب | يمكنك الاطّلاع على الإرشادات هنا. |
خدمة تجميع البيانات
موضوع الملاحظات | ملخّص | استجابة Chrome |
---|---|---|
طلب ميزة | طلب مهلة قابلة للضبط لميزة AgS و/أو مزيد من المعلومات حول حالة المهمة في عمليات التشغيل على المدى الطويل | نحن ننظر في ميزات تتيح مراقبة المهام التي تستغرق وقتًا طويلاً. نرحب بملاحظات إضافية بشأن المنظومة المتكاملة في هذا الشأن. |
Terraform | تحاول Terraform تعديل سياسة إدارة الهوية والوصول (IAM) للحساب حتى إذا لم يتم ضبط service_account_token_creator_list. | يمكن للمطوّرين إضافة الأذونات المضافة في ملف modules/adtech_setup/main.tf المحلي. |
طلب المستندات | طلب مستندات أو ورشة عمل لشرح كيفية مراقبة حالة خدمة التجميع | يمكن العثور على وصف للتنبيهات الحالية التي يمكن استخدامها لمراقبة حالة الخدمة والمهمة في ملفات Terraform ذات الصلة للمشغِّل (alarms.tf وmonitoring.tf) في مستودع coordinator-services-and-shared-libraries. سننشر مستندات وإرشادات إضافية حول كيفية مراقبة مهام خدمة التجميع. |
التحجيم | كيف يمكن مراقبة مشاكل التوسّع؟ | لقد نشرنا نسخة معدَّلة من هذه الإرشادات التي توثّق نطاق "خدمة التجميع" الأعلى. لا تتوفّر حاليًا إشارة مباشرة تشير إلى حدوث خطأ لأنّ الجهاز لا يمكنه التعامل مع حجم المهمة. تشمل الإشارات غير المباشرة ما يلي: استهلاك 90% من الذاكرة قبل حدوث خطأ، أو مهمة تؤدي إلى حدوث خطأ بشكل متكرّر. ونرحّب بملاحظات إضافية بشأن المنظومة المتكاملة في ما يتعلق بضرورة توفير هذه الإشارة. |
المواصفات | ما هو الوقت المعتاد لتشغيل دفعات تقارير AgS؟ | يُرجى الرجوع إلى الإرشادات هنا. |
Private Aggregation API
موضوع الملاحظات | ملخّص | استجابة Chrome |
---|---|---|
طلب ميزة | طلب السماح بمساهمات القيم العائمة (بما في ذلك القيم السالبة) في contributeToHistogramOnEvent بمعدّل حساسية 2^16 | نحن نناقش حاليًا هذا الاقتراح هنا ونرحّب بملاحظاتك الإضافية. |
الحد من التتبّع الخفي
تقليل معلومات وكيل المستخدم/تعديلات برنامج وكيل المستخدم
لم يتم تلقّي أي ملاحظات هذا الربع.
حماية عنوان IP (المعروفة سابقًا باسم Gnatcatcher)
موضوع الملاحظات | ملخّص | استجابة Chrome |
---|---|---|
الموقع الجغرافي | طلب ملف الموقع الجغرافي لحماية عنوان IP | يتوفّر ملف تعيين عناوين IP إلى المواقع الجغرافية التقريبية لحماية عناوين IP هنا. يُرجى العِلم أنّه يتم تعديل هذا الملف بشكل دوري. |
الحدّ من التتبّع الارتدادي
موضوع الملاحظات | ملخّص | استجابة Chrome |
---|---|---|
القائمة المسموح بها | لم يعُد الموقف المعدَّل يتناول قائمة المسموح بها أو آليات مشابهة تكون مستقلة عن عملية صنع القرار في Google. | لا تخطط Google لتوفير أي قوائم مسموح بها مرتبطة بإجراءات التخفيف من تتبُّع الارتدادات (BTM)، ويتم تطبيق إجراءات الحماية بشكلٍ موحّد على جميع النطاقات. |
الامتثال | يجب أن يكون لدى هيئة ICO سلطة بشأن الامتثال للسياسات المتعلّقة بالخصوصية. | لا ترتبط حالة الامتثال بتطبيق ميزة "إدارة الموافقة"، ولا تتّخذ Google أي قرارات بشأن الامتثال لتنفيذ هذه الميزة. |
المنافسة | يبدو أنّه قد يُسمح لشركة Google بمنع منافسي PET من استخدام ميزة "الإعلانات المتجاوبة على شبكة البحث" (أو إجراءات أخرى) ثمّ ممارسة سلطتها التقديرية في ما يتعلّق بالسماح لهم بالعودة إلى السوق. قد تؤدي عملية تقديم طلبات إعادة النظر الحالية إلى منع منافسي PET مؤقتًا من استخدام نموذج BTM أو إجراءات مماثلة. | يهدف اقتراح BTM الحالي إلى تتبُّع الارتداد كأسلوب. على الرغم من أنّ Google تهدف إلى تجنُّب إيقاف حالات استخدام معيّنة قد تتضمّن أساليب مشابهة، لا تتوفّر لدى Google خطة لتوفير إعفاءات فردية من سياسة BTM. وبالتالي، لا يطرح السؤال حول ممارسة Google لتقديرها الخاص بشأن توفّر المنافسين. |
تعزيز حدود الخصوصية على مستوى المواقع الإلكترونية
مجموعات المواقع الإلكترونية المرتبطة (المعروفة سابقًا باسم "مجموعات نطاقات الطرف الأول")
موضوع الملاحظات | ملخّص | استجابة Chrome |
---|---|---|
(تمّ الإبلاغ عنها أيضًا في الربعَين السابقَين) الحدّ الأقصى لنطاقات مجموعات المواقع الإلكترونية المرتبطة (RWS) |
إنّ الحدّ الأقصى الحالي الذي يبلغ خمسة نطاقات مرتبطة ليس مرتفعًا بما يكفي لتحقيق حالات استخدام القياس على جميع المواقع الإلكترونية. | ردّنا مشابه للردّ الذي قدّمناه في الربع سنوية السابقة: في الوقت الحالي، لا نتوقّع زيادة الحدّ الأقصى لعدد الأرقام. تم تحديد الحد الأقصى استنادًا إلى اعتبارات خصوصية المستخدمين والملاحظات الواردة من الجهات المعنية في منظومة الإيكولوجيا في W3C، بالإضافة إلى النظر في عمليات التنفيذ المشابهة في المتصفّحات الأخرى. للحصول على معلومات إضافية، يُرجى الاطّلاع على مشاركات المدونة (1 و2). ننصح بفحص حالات الاستخدام التي تتطلّب الوصول إلى ملفات تعريف الارتباط على مواقع إلكترونية مختلفة بما يتجاوز الحدّ الرقمي، والاستفادة من إرشاداتنا بشأن حالات استخدام الهوية وعمليات التضمين التي تمّت المصادقة عليها وحالات استخدام الإعلانات. نرحب بملاحظاتك الإضافية حول هذه المشكلة هنا. |
Fenced Frames API
موضوع الملاحظات | ملخّص | استجابة Chrome |
---|---|---|
الإعلانات المدمجة مع المحتوى | يشكّل عرض الإعلانات المدمجة في الإطارات المُغلقة تحديات لأنّ اكتساب تصميم الناشر يكون محدودًا بسبب القيود المفروضة على التواصل بين إطار iframe وصفحة الناشر. | إنّ إتاحة المزيد من التوافق مع الإعلانات المدمجة، بما في ذلك التوافق بعد فرض استخدام الإطارات المحدود، هو أحد المجالات النشطة التي نجري فيها الأبحاث. نرحب بملاحظاتك الإضافية حول هذه المشكلة هنا. |
Shared Storage API
موضوع الملاحظات | ملخّص | استجابة Chrome |
---|---|---|
استخدام واجهة برمجة التطبيقات | لا تتوفّر Shared Storage API على بعض الأجهزة عندما تكون واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" الأخرى قيد التشغيل. | من المتوقّع أن يظهر هذا السلوك لمجموعة فرعية صغيرة من المستخدمين (%1 تقريبًا) المشاركين في تجربة "البيانات المجمَّعة في مساحة التخزين المشتركة". يتم استخدام هذا الإعداد التجريبي لتقييم أداء واجهات برمجة التطبيقات ومدى استخدامها في سيناريوهات متنوعة. |
استخدام واجهة برمجة التطبيقات | هل تتم عمليات الكتابة في مساحة التخزين المشتركة ضمن مصدر الناشر أو مصدر نص عروض الأسعار؟ لم يُظهر الاختبار الأولي أي عمليات كتابة عندما كان مصدر الناشر يختلف عن مصدر النص البرمجي. | تم حلّ هذه المشكلة، ولا تبقى مفتوحة إلا في حال حدوث خطأ محتمل في أدوات تطوير البرامج. يمكنك الاطّلاع على مزيد من التفاصيل هنا. تُجري ميزة "مساحة التخزين المشتركة" عمليات الكتابة إلى مصدر المشتري في سياق عروض الأسعار لمكالمة generateBid . لا يكون المحتوى مرتبطًا بمصدر الناشر، حتى إذا كانت صفحة الناشر متوفّرة على نطاق مختلف. |
استخدام واجهة برمجة التطبيقات | ما هي الإجراءات الوقائية المتّبعة لمنع المستخدمين السيئين من قراءة تقارير "مساحة التخزين المشتركة"؟ | يتم تقسيم "مساحة التخزين المشتركة" من خلال طلب المصدر حتى لا يتمكّن أيّ جهة خارجية أو تكنولوجيا إعلان من قراءة بيانات "مساحة التخزين المشتركة" من تكنولوجيا إعلان أخرى. ويتم إرسال تقارير "التجميع الخاص" مباشرةً إلى المصدر نفسه عبر بروتوكول النقل الآمن للطبقة (TLS) حتى لا يتم اعتراضها. |
ملفات تعريف الارتباط في الحالة المقسَّمة المنفصلة (CHIPS)
موضوع الملاحظات | ملخّص | استجابة Chrome |
---|---|---|
ملفات تعريف الارتباط المُقسَّمة | هناك اختلاف في طريقة التعامل مع ملفات تعريف الارتباط على منافذ المضيف المحلي المختلفة في Chrome وFirefox، لا سيما عند استخدام السمة Partitioned. | يتعامل Firefox مع localhost باستخدام منافذ مختلفة كمفاتيح أقسام مختلفة. على الرغم من أنّ هذا السلوك متوافق مع مبادئ الأمان، إلا أنّه يخالف المواصفات ونهج Chrome. نتوقع مناقشة هذا الأمر مع المتصفّحات الأخرى في مناقشة حول مواصفات HTML، وسنُعلم المنظومة المتكاملة إذا أدّى ذلك إلى تغيير في مفتاح قسم CHIPS. ونرحّب بملاحظاتك الإضافية حول هذه المشكلة هنا. |
ملفات تعريف الارتباط المُقسَّمة | تسمح مسودة Clear-Site-Data بشكل غير صحيح بمحو البيانات خارج حدود الموقع الإلكتروني المُرسِل، ما يتعارض مع المناقشات السابقة المُشار إليها هنا. | هذا خطأ في مستند مواصفات المعايير، وننوي إصلاحه قريبًا. تم تحديد السلوك الصحيح في هذا القسم من الشرح، وهو متوافق مع السلوك المتوافق مع المتصفّحات الأخرى في مستودع شرح تقسيم مساحة التخزين. يعمل تطبيق Chrome بشكلٍ صحيح. |
FedCM
لم يتم تلقّي أي ملاحظات هذا الربع.
مكافحة المحتوى غير المرغوب فيه والاحتيال
Private State Tokens API (وواجهات برمجة التطبيقات الأخرى)
لم يتم تلقّي أي ملاحظات هذا الربع.