تقرير ربع سنوي للربع الأول من عام 2023 يلخّص الملاحظات التي وردتنا من المنظومة المتكاملة بشأن اقتراحات "مبادرة حماية الخصوصية" وردّ Chrome عليها.
كجزء من التزاماتها بموجب "قانون معالجة المعاملات"، وافقت Google على تقديم تقارير ربع سنوية علانية عن عملية تفاعل الجهات المعنية باقتراحات "مبادرة حماية الخصوصية" (يُرجى الرجوع إلى الفقرتين 12 و17(ج)(2) من الالتزامات). يتم إنشاء تقارير الملخّصات هذه حول الملاحظات والآراء بشأن "مبادرة حماية الخصوصية" من خلال تجميع الملاحظات والآراء التي تلقّاها Chrome من المصادر المختلفة كما هو موضّح في نظرة عامة على الملاحظات والآراء، بما في ذلك على سبيل المثال لا الحصر: GitHub المشاكل، ونموذج الملاحظات والآراء المتاح على privacysandbox.com، والاجتماعات مع الجهات المعنية في المجال، ومنتديات معايير الويب. يرحّب فريق Chrome بالملاحظات التي يتم تلقّيها من المنظومة المتكاملة ويستكشف بنشاط طرق دمج الدروس المستفادة في قرارات التصميم.
يتم ترتيب مواضيع الملاحظات حسب معدّل تكرارها لكل واجهة برمجة تطبيقات. ويتم ذلك من خلال جمع ملاحظات فريق Chrome حول موضوع معيّن وتنظيمها بترتيب تنازلي حسب الكمية. تم تحديد مواضيع الملاحظات المشترَكة من خلال مراجعة مواضيع المناقشة من الاجتماعات العامة (W3C وPatCG وIETF) والملاحظات المباشرة وGitHub والأسئلة الشائعة التي تظهر من خلال الفِرق الداخلية في Google والنماذج العامة.
وعلى وجه التحديد، تمت مراجعة محاضر اجتماعات الهيئات المسؤولة عن معايير الويب، وبالنسبة إلى الملاحظات المباشرة، تمّت مراجعة سجلّات Google لاجتماعات الجهات المعنيّة وجهًا لوجه، والرسائل الإلكترونية التي تلقّاها المهندسون الفرديون، وقائمة البريد الإلكتروني لواجهات برمجة التطبيقات، ونموذج الملاحظات العلني. بعد ذلك، نسّقت Google بين الفِرق المشاركة في أنشطة التواصل المختلفة هذه لتحديد مدى رواج المواضيع التي تظهر في ما يتعلّق بكل واجهة برمجة تطبيقات.
تم تطوير تفسيرات ردود Chrome على الملاحظات من خلال عناوين الأسئلة الشائعة والمنشورة، والردود الفعلية التي تم تقديمها على المشاكل التي طرحها أصحاب المصالح، وتحديد وجهة نظر خاصة لأغراض هذا التمرين الخاص بإعداد التقارير العلنية. استنادًا إلى التركيز الحالي على التطوير والاختبار، تلقّينا أسئلة وملاحظات خاصةً بشأن واجهات برمجة التطبيقات Topics API وFLEDGE API وAttribution reporting API.
قد لا يتم النظر في الملاحظات التي يتم تلقّيها بعد انتهاء فترة إعداد التقارير الحالية.
مسرد الاختصارات
- ملفات تعريف الارتباط في الحالة المقسَّمة المنفصلة (CHIPS)
- ملفات تعريف الارتباط في الحالة المقسَّمة المنفصلة
- معالِج الإشارات الرقمية (DSP)
- وسيط عرض الطلب
- FedCM
- إدارة بيانات الاعتماد الموحّدة
- عدد اللقطات في الثانية
- مجموعات نطاقات الطرف الأول
- مكتب الإعلانات التفاعلية (IAB)
- Interactive Advertising Bureau
- IDP
- موفِّر الهوية
- مجموعة مهندسي شبكة الإنترنت (IETF)
- مجموعة مهندسي شبكة الإنترنت
- عنوان IP
- عنوان بروتوكول الإنترنت
- openRTB
- عرض الأسعار في الوقت الفعلي
- الوقت بدل الضائع
- فترة التجربة في Origin
- PatCG
- مجموعة منتدى تكنولوجيا الإعلانات الخاصة
- RP
- جهة الاعتماد
- SSP
- وسيط عرض إعلانات المورّدين
- بيئة تنفيذ موثوقة (TEE)
- بيئة التنفيذ الموثوقة
- UA
- سلسلة وكيل المستخدم
- UA-CH
- تعديلات برنامج وكيل المستخدم
- W3C
- اتحاد شبكة الويب العالمية
- WIPB
- إخفاء عناوين IP عن قصد
ملاحظات عامة، ما مِن واجهة برمجة تطبيقات/تقنية محدّدة
| موضوع الملاحظات | ملخّص | ردّ Chrome |
|---|---|---|
| الاختبار والتجربة | مدى صلة الاختبار بتقييم هيئة CMA في حال عدم اكتمال اختبارات واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" بحلول وقت بدء الاختبار | يتواصل تطوير واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" بوتيرة سريعة.
وهي متاحة حاليًا في الإصدار التجريبي من Origin للاختبار، وستكون متوفرة بشكل عام لكلّ الزيارات في هذا الصيف. بالإضافة إلى ذلك، أوضحنا المخططات الزمنية لميزات معيّنة (مثل إعداد تقارير FLEDGE على مستوى الحدث وعرض FLEDGE باستخدام إطارات iframe) التي لن تتأثر قبل عام 2026. ننصح المنظومة المتكاملة باختبار واجهات برمجة التطبيقات وتقديم ملاحظات إلى CMA استنادًا إلى ما يتوقّع المختبِرون الاعتماد عليه بعد إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا. ويمكن أن يساعد ذلك في تقييمهم للتأثير المحتمَل لإيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا. |
| عناصر تحكم المستخدم | إرشادات واضحة للمنظومة المتكاملة حول تأثير عناصر التحكّم الخاصة بالمستخدمين في واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" | لا يمكننا تقديم مشورة قانونية بشأن عناصر التحكّم التي يمكن للمنظومة المتكاملة استخدامها. في الوقت نفسه، يختبر Chrome عرض عناصر تحكّم المستخدِم في "مبادرة حماية الخصوصية" (Privacy Sandbox) المعدّلة ("الخصوصية المحسّنة للإعلانات") لمجموعة صغيرة جدًا من المستخدِمين، وذلك في إطار جهودنا المستمرة لتحسين تقنيات "مبادرة حماية الخصوصية". وتشمل التحديثات تنسيقات ولغة أكثر وضوحًا و helpful. بعد أن يُجري Chrome تقييمًا لهذه التحسينات ويقرر ما إذا كان سيتم توسيع نطاقها ليشمل عددًا أكبر من المستخدمين، يمكنه مشاركة المزيد من المعلومات مع المنظومة المتكاملة. |
| تسرُّب البيانات | خطر تسرُّب بيانات الطرف الأول إلى Google وجهات أخرى في حال اختراق المتصفّح | يوضّح الشرح المفصّل لبرنامج FLEDGE أنّه لا تتم مشاركة بيانات تقنية إعلان معيّنة إلا
مع تقنية الإعلان نفسها (إما مع وحدات العمل أو مع ملفّات تعريف الارتباط
الموثوق بها) أو عندما تتم مشاركة البيانات صراحةً من خلال تقنية الإعلان (مثل عرض مشتري
عنوان URL للإعلان الذي يريد عرضه على البائع). الاستثناء الوحيد هو أنّه يجب أن يتم التحقّق من إخفاء الهوية وفقًا لعدد k من خلال خادم مركزي عالمي، وهو مجال نواصل تخصيص موارد كبيرة له. يُرجى الاطّلاع على مقالة الشرح المتعلّقة بالخصوصية باستخدام ميزة "المعادلة الاحتمالية K" للحصول على نظرة تفصيلية على كيفية تعاملنا مع
الخصوصية. بالإضافة إلى ذلك، نحن على استعداد لتقديم المزيد من التفاصيل حول كيفية عمل تدابير الحماية لتكنولوجيا الإعلان المستخدَمة في تصميم خادم إخفاء الهوية وفقًا لعدد k. |
| منتدى إضافي للمناقشة | طلب منتدى إضافي في W3C لمشاركة ملاحظات أطراف المنظومة المتكاملة غير الفنية | نموذج ملاحظات "مبادرة حماية
الخصوصية" مناسب للتعليقات العامة والمفصّلة، سواء كانت فنية أو غير فنية. Improving Web Advertising Business Group هو منتدى للمناقشة من خلال مكالمات أسبوعية ومستودع GitHub. توضّح صفحة الملاحظات في "مبادرة حماية الخصوصية" آليات أخرى لتقديم ملاحظات والمشاركة في المناقشات. يواصل فريق Chrome أيضًا تنظيم فعاليات، مثل "ساعات العمل" العامة، لتسهيل طرح الأسئلة ومشاركته المحتوى. بالإضافة إلى ذلك، استضاف فريق Chrome أو شارك في أكثر من عشرات فعاليات المجال خلال هذا الربع من العام. |
| توضيح بشأن المخطط الزمني | توضيح بشأن التاريخ الدقيق لتوفّر الميزة للجميع في الربع الثالث من 2023 | وفقًا للمخطط الزمني المنشور على PrivacySandbox.com، من المخطّط بدء طرح الإصدار العلني في غضون فترة قصيرة مع إصدار الإصدار 115 من Chrome. |
| reCAPTCHA | تأثير واجهات برمجة تطبيقات Sandbox في حالة استخدام ميزة رصد المحتوى غير المرغوب فيه في reCATPCHA | نتلقّى ملاحظات من فريق reCAPTCHA بشكل دوري للتأكّد من أنّ اقتراحات "مبادرة حماية الخصوصية" لا تؤثّر بشكل كبير في أمان الويب أو الاحتيال. إنّهم بصدد تطوير خطتهم الخاصة للاستعداد للإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية والتعامل مع هذا التغيير، لذا من الأفضل أن يجيبوا عن هذا السؤال. |
| إضافات Chrome | هل ستسري تقنيات "مبادرة حماية الخصوصية"، مثل إجراءات مكافحة التتبّع الخفي (ACT)، على إضافات Chrome؟ | لم نُصدر أي إعلانات بشأن ما إذا كان قانون الخدمات الرقمية (ACT) قد ينطبق على إضافات Chrome. ومع ذلك، إذا كانت التكنولوجيا تجمع معلومات عن أحد المستخدمين بشكل سري، لن يكون ذلك متوافقًا مع مبادئ الخصوصية التي نتّبعها. |
عرض محتوى وإعلانات ذات صلة
المواضيع
| موضوع الملاحظات | ملخّص | ردّ Chrome |
|---|---|---|
| مراجعة التصميم وفقًا لمبادرة TAG | أصدرت TAG مراجعة التصميم المبكّرة لميزة Topics. | ما زلنا ملتزمين بميزة "المواضيع"، وقد شاركنا آخر المعلومات حول التزامنا في صفحة آخر الأخبار وفي هذه المشكلة. لقد رددنا على مراجعة TAG نقطةً نقطةً وشاركنا رؤيتنا على مستوى أعلى هنا. ستظلّ Topics API جزءًا من مجموعة واجهات برمجة التطبيقات التي يجب أن يختبرها المنظومة المتكاملة للإعلانات خلال عام 2023، ونأمل أن تكون ملاحظات الاختبار التي نتلقّاها وتجربة المطوّرين التي نكتسبها مساهمات قيّمة في الجهود المستقبلية لتطبيق المعايير على جميع المتصفّحات في هذا المجال. نحن نتطلّع إلى مواصلة التفاعل مع المنظومة المتكاملة بشأن كيفية تسهيل عملية النقل المحتملة التي يمكن أن تكون فيها Topics API قياسًا متفقًا عليه ومتوافقًا مع جميع المتصفحات. |
| طريقة التعامل مع المواضيع | التوافق مع المنهج المفتوح الذي يتّبعه Chrome لتطوير Topics API | نحن نقدّر ملاحظاتك ونتطلّع إلى مواصلة العمل مع مجموعة الصناعة لتطوير Topics API التي تضيف قيمة إلى المنظومة المتكاملة بشكل عام. |
| (تم الإبلاغ عن ذلك أيضًا في الربع الثالث من عام 2022) تصنيف المواضيع غير دقيق بما يكفي |
لا تتضمّن التصنيفات العامة للمواضيع مواضيع أكثر دقة، بما في ذلك المواضيع المتعلّقة بمنطقة معيّنة. | تعديلات الربع الأول: نحن نعمل باستمرار على تحسين التصنيف، وسنعلن في الربع الثاني عن تصنيف معدَّل لواجهة برمجة التطبيقات Topics API. لإنشاء هذا التصنيف الجديد، تعاونّا بشكل وثيق مع شركات من مختلف أنحاء المنظومة المتكاملة. نحن نبحث بنشاط عن ملاحظات حول التصنيف الأكثر فائدة للمنظومة المتكاملة. عند تقييم ما إذا كان يجب توسيع عدد المواضيع أو تضمين مواضيع أكثر دقة، هناك بعض الاعتبارات، بما في ذلك 1) الآثار المحتملة على الخصوصية (قد تؤدي المواضيع الإضافية إلى زيادة خطر وضع بصمة رقمية) و2) إمكانية استرداد المواضيع التي تم رصدها سابقًا (مثلاً، مع زيادة المواضيع، قد تكون فرصة ظهور الموضوع المحدّد في تقنية عرض الإعلانات في الماضي أقل). |
| (تم الإبلاغ عن ذلك أيضًا في الربع الرابع من عام 2022) التأثير في إشارات الطرف الأول |
قد تكون إشارة Topics ذات قيمة عالية، ما يؤدي إلى خفض قيمة إشارة الطرف الأول الأخرى المستندة إلى الاهتمامات. | نعتقد أنّ الإعلانات المستندة إلى الاهتمامات هي حالة استخدام مهمة على الويب، وقد تم تصميم ميزة "المواضيع" لدعم هذه الحالة. نُدرك أنّ بعض الناشرين الكبار قلقون من أنّ Topics قد تؤثر سلبًا في استراتيجياتهم المتعلّقة ببيانات الطرف الأول. نحن نتطلّع إلى اختبار المنظومة المتكاملة، ما سيوفّر إحصاءات عن تأثير ميزة "المواضيع" في الناشرين. |
| حالات استخدام المواضيع غير المرتبطة بالإعلانات | استخدام "المواضيع" لأغراض أخرى غير عرض إعلانات مستندة إلى الاهتمامات | تم تصميم Topics للتعامل مع حالة استخدام الإعلانات التي تستهدف الجمهور استنادًا إلى الاهتمامات، والتي نعتقد أنّها حالة استخدام مهمة للويب المجاني والمفتوح. نطلب حاليًا ملاحظات حول حالات الاستخدام الأخرى ونقيّمها. |
| حالة المشاركة التلقائية | تأثير التشريعات الإقليمية في الإعداد التلقائي للموافقة على Topics | لا نهدف إلى تقديم تعليقات بشأن الآراء القانونية. |
| (تم الإبلاغ عنها أيضًا في الربع الثالث من عام 2022) المواقع الإلكترونية المصنّفة بشكل خاطئ |
استهداف الإعلانات عند تصنيف المواضيع بشكل خاطئ لموقع إلكتروني معيّن | آخر الأخبار في الربع الأول: في الربع الثاني، سنعلن عن مصنّف معدَّل لواجهة برمجة التطبيقات Topics API ونتطلع إلى التفاعل مع المنظومة المتكاملة بشأنه. استجابةً للتعليقات الحالية، يتم تصنيف المواقع الإلكترونية من خلال مزيج من قائمة إلغاء إعدادات مُعدّة من قِبل فريقنا، والتي تحتوي على المواقع الإلكترونية الأكثر رواجًا، ونموذج تعلُّم آلي على الجهاز. يواصل Chrome تقييم خيارات المواقع الإلكترونية للمساهمة في تصنيف Topics. يجب موازنة أي تحسينات على الأداة مع مخاطر الخصوصية وإساءة الاستخدام. على سبيل المثال، تشمل بعض المخاطر ما يلي: المواقع الإلكترونية التي تستخدم التصنيف الذاتي كطريقة لترميز معاني مختلفة (قد تكون حسّاسة) في المواضيع، والمواقع الإلكترونية التي تقدّم وصفًا مضلِّلاً لمواضيعها لتحقيق مكاسب مالية، والمواقع الإلكترونية التي تهاجم المواضيع لتقليل فائدتها للآخرين (على سبيل المثال، إرسال رسائل غير مرغوب فيها إلى مواضيع المستخدمين من خلال إدخال معلومات غير مفيدة). يمكن للجميع فحص هذه المكوّنات باستخدام الأدوات المتاحة من خلال chrome://topics-internals أو هذا المشروع التعاوني. من خلال الاختبارات، نتوقّع أن يتحسن التصنيف بمرور الوقت، ونرحب بملاحظاتك حول أمثلة على المواقع الإلكترونية التي قد تكون مصنّفة بشكل خاطئ. |
| أداة تصنيف المواضيع | طلب عرض معلومات إضافية توضّح الأسباب التي تؤدي إلى عرض الرسالة "لا يوجد topics" للمتصل لأغراض تصحيح الأخطاء | ندرك ونقدّر أنّ أدوات تصحيح الأخطاء مفيدة ل المطوّرين أثناء عملهم على دمج Topics API في أنظمتهم. ومع ذلك، من خلال عرض معلومات إضافية (مثل سبب عدم عرض أي "مواضيع")، قد نشارك عن غير قصد معلومات تسمح للأطراف بالكشف عن تفاصيل إضافية (على سبيل المثال، إذا كان المستخدم في "وضع التصفّح المتخفي" أو أوقف واجهة برمجة التطبيقات وما إلى ذلك) خارج نطاق ما هو مقصود، ما قد يضرّ بخصوصية المستخدم. على الرغم من أنّنا لا نخطّط في الوقت الحالي لتوفير أدوات إضافية لتحديد الأخطاء وحلّها، نحن منفتحون على تلقّي الملاحظات حول الأدوات التي قد تكون مفيدة. |
| استرداد المعلومات الخاصة (PIR) | طلب اعتماد ميزة "استرداد المعلومات الخاصة" في Topics API | لقد أجرينا سابقًا تحقيقًا في استخدام ميزة "الاستهداف بالاستناد إلى الاهتمامات" وشاركنا المفاضلات هنا. |
| مصدر عروض الأسعار | هل سيتم تمثيل المواضيع بشكلٍ متميز عن شرائح الجمهور التي يحدّدها البائع في بث عروض الأسعار؟ | Topics API هي اقتراح من "مبادرة حماية الخصوصية" تم تطويره من خلال Chrome، وهو مختلف عن اقتراح شرائح الجمهور التي يحدّدها البائع الذي وضعه IAB Tech Lab. نتوقّع أن يتم تمثيل الاثنين بشكلٍ متميز في تدفق عروض الأسعار. تعرَّف على كيفية تمثيل المواضيع في طلبات ملفّات BID OpenRTB. |
Protected Audience API (المعروفة سابقًا باسم FLEDGE)
| موضوع الملاحظات | ملخّص | ردّ Chrome |
|---|---|---|
| مدى توفّر ميزة FLEDGE | توضيح بشأن المخططات الزمنية لاختبار ميزات FLEDGE وتنفيذها، مثل فرض إطارات الحدود وميزة "إخفاء الهوية بتقنية K" وما إلى ذلك | لقد شاركنا الحالة المتعلّقة بميزات FLEDGE المختلفة على نطاق واسع ووقت إتاحة هذه الميزات. نرحب بملاحظاتك الإضافية حول هذا الإعلان بينما نواصل تطوير FLEDGE. |
| قيود عرض المنتجات | طلب تخفيف القيود المفروضة على الإعلانات المؤلفة من عدة أجزاء في إطارات FLEDGE المحدود | كما أعلنّا في شباط (فبراير)، سيظلّ استخدام "الإطارات المُغلقة" اختياريًا حتى لعام 2026 على الأقل، وسيكون سلوك إطارات iframe متوافقًا مع urn-iframes. نرحب بمزيد من المناقشة حول هذا الموضوع. |
| مشاكل قابلية التوسّع | أداء FLEDGE مع زيادة معدّل الاستخدام | نحن نتابع بنشاط الملاحظات ونحاول فهم السياق بشكل أفضل لنتمكّن من اقتراح حلول قابلة للتنفيذ. كانت الخطوة الأولى هي تقسيم الملاحظات إلى فئتين، وقد فعلنا ذلك:
|
| (تمّ الإبلاغ عن ذلك أيضًا في الربع الثالث من عام 2022) مستوى رؤية منطق عروض الأسعار |
القلق من أنّه سيتم عرض منطق عروض الأسعار في نظام إدارة الطلبات في JavaScript | أخبار الربع الأول: لقد شاركنا اقتراحًا يهدف إلى محدودة قدرة الجهات الخارجية على طلب البيانات من السيرفر بطريقة استكشافية (التصفّح القسري)، ونرحّب بمشاركة ملاحظات جهات المنظومة المتكاملة أو دعمها للاقتراح. |
| الصعوبات في الاختبار | إتاحة الفرصة لخدمات عرض الإعلانات الأصغر حجمًا لاختبار FLEDGE بشكل صحيح، والحدّ من خطر عدم اهتمام المعلِنين بالاختبار إلا مع خدمات عرض الإعلانات الأكبر حجمًا | نحن ملتزمون بالعمل مع منصّات عرض الإعلانات الأصغر حجمًا ونشجّع بشدة على الاختبار الموسّع بين منصّات عرض الإعلانات والمعلنين بمختلف أحجامهم مع بدء طرح FLEDGE للجميع. يهمّنا معرفة كيف يمكننا مساعدتهم على أفضل وجه في اختبار FLEDGE مع الآخرين في المنظومة المتكاملة، ونرحّب بالأفكار وجهود الصناعة لتحفيز المعلِنين على إجراء الاختبار باستخدام منصّات إدارة الأداء الإعلاني الأصغر حجمًا. |
| تجديد النشاط التسويقي الديناميكي | هل سيظلّ تجديد النشاط التسويقي الديناميكي ممكنًا باستخدام FLEDGE بعد الإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية؟ | نحن ننظر في تقديم ردّ على هذا السؤال ونرحّب بمشاركة الجهات الفاعلة في المنظومة المتكاملة لإحصاءات إضافية حول كيفية استخدامهم لميزة "تجديد النشاط التسويقي الديناميكي". |
| الاحتيال/إساءة الاستخدام | كيف يمكن للمنظومة المتكاملة تقليل المخاطر ومنع الجهات الفاعلة أو المشترين السيئين من تقديم أنفسهم كشريحة جمهور مرغوب فيها؟ | ونتطلّع إلى مزيد من التفاعل مع الجهات المشاركة في المنظومة المتكاملة بشأن عمليات النصب والإساءة، ونرحّب بالمزيد من الملاحظات في هذا المجال. |
| الإعدادات المفضّلة للمستخدم | عملية حفظ الإعدادات المفضّلة للمستخدم واستخدامها في اختيار الإعلانات | بالنسبة إلى إعلانات معيّنة، تكون تكنولوجيا الإعلان ذات الصلة هي الطرف الأنسب لتوفير عناصر تحكّم في المواد الإبداعية التي يتم عرضها أو كيفية اختيارها. |
| اقتراح الاختبار الكمي | لكي يكون الاختبار الكمي عادلاً، هل يجب إجراء الاختبار على الزيارات التي لا تتضمّن ملفات تعريف الارتباط التابعة لجهات خارجية أو مع منصّات عرض الإعلانات التي تستخدِم FLEDGE فقط؟ كيف يمكن تجنُّب اختلاط الإشارات الواردة من ملفات تعريف الارتباط التابعة لجهات خارجية؟ | نحن نقدّر هذه الملاحظات ونعمل مع هيئة CMA لتصميم تجارب تقدّم صورة موثوقة عن تأثير إيقاف ملفّات تعريف الارتباط التابعة لجهات خارجية نهائيًا وطرح اقتراحات "مبادرة حماية الخصوصية" على المنظومة المتكاملة. ونشجّع على مشاركة ملاحظات إضافية حول اقتراح "الاختبار الكمي" الذي قدّمته "الهيئة البريطانية للمنافسة والأسواق" مع "الهيئة البريطانية للمنافسة والأسواق" مباشرةً. |
| مستندات أكثر وضوحًا | طلب مستندات أكثر وضوحًا حول إعدادات المزاد | نأمل مشاركة مشاركة مدوّنة تتضمّن نظرة عامة إضافية على FLEDGE و"إعداد تقارير عروض الأسعار" في الأسابيع المقبلة. |
| الموازاة | هل ستتيح خدمة عروض الأسعار والمزادات (B&A) استخدام ميزة التوازي؟ | يمكن أن تبدأ تقنية الإعلان التي تستخدم خوادم عروض الأسعار / المزادات عدة خوادم يمكنها عرض النتائج بشكل موازٍ. |
| الحدّ من إساءة الاستخدام | هل سيكون خادم FLEDGE الذي يستخدم الرموز المميّزة للحالة الخاصة والخاص بميزة "المجهولة الهوية k" مناسبًا لضمان خصوصية المستخدم؟ | لا يركز الدافع وراء استخدام تقنية "المَعلمة k" على الاستهداف الدقيق، ويركز بدلاً من ذلك على توفير بعض الإجراءات الاحتياطية خلال المرحلة المؤقتة التي تسمح فيها مبادرة FLEDGE بإعداد التقارير على مستوى الحدث. لقد شاركنا المزيد من الأفكار ونرحب بتلقّي ملاحظات إضافية. |
| تعارض وحدة ES | طلب إسقاط generateBid كدالة عامة لأنّها تتعارض مع
وحدة ES |
نحن بصدد مناقشة هذا الطلب ونرحّب بملاحظاتك الإضافية. |
| مزاد المكوّنات | طلب منح الناشرين مزيدًا من التحكّم في تصميمات المزادات | تشمل عروض الأسعار والمزادات خططًا لدعم مزاد المكوّنات، تمامًا مثل Chrome على الجهاز. |
| المخططات الزمنية لـ B&A | توضيح بشأن المخطط الزمني لتكنولوجيات الإعلان المهتمة باختبار ملفّات تعريف الارتباط للإحالات الناجحة | لقد عدّلنا للتوّ القسم التفسيري لاختبار B&A وعدّلنا قسم "المخطط الزمني" لتضمين تعريفات واضحة للمخططات الزمنية للمراحل المختلفة من اختبار B&A في Chrome، وذلك بعد مواءمة مع CMA. |
| مخطّط التحكّم في المهلة | تحسين مخطّط التحكّم في مهلة الانتظار المتاح حاليًا لبرنامج FLEDGE | هذا اقتراح مثير للاهتمام. سنضيف هذا الطلب إلى قائمة الانتظار الخاصة بالاقتراحات التي ندرس إمكانية تنفيذها، وسنُعلمك بأي تطورات. |
| مصادر عروض أسعار تصميمات الإعلانات | إمكانية مراجعة عرض السعر الفائز وفلترته استنادًا إلى تصميم الإعلان | هذا اقتراح مثير للاهتمام. سنضيف هذا الطلب إلى قائمة الانتظار الخاصة بالاقتراحات التي ندرس إمكانية تنفيذها، وسنُعلمك بأي تطورات. |
reportWin |
اقتراح لتقديم معلومات إضافية عن عرض السعر الذي يحقّق أعلى نتيجة
من مالك مجموعة اهتمامات مختلف عن الفائز في الدالة
reportWin |
هذا اقتراح مثير للاهتمام. سننظر في إضافة علامات إضافية في التقارير المجمّعة ونرحّب بملاحظات إضافية هنا. |
| أنواع الأحداث | توحيد أنواع الأحداث في واجهات برمجة التطبيقات لقياس الأداء عند دمجها مع FLEDGE | هذا اقتراح مثير للاهتمام. سنضيف هذا الطلب إلى قائمة الانتظار الخاصة بالاقتراحات التي ندرس إمكانية تنفيذها، وسنُعلمك بأي تطورات. وسيتطلّب ذلك التنسيق مع جهودنا الأوسع نطاقًا في هذا المجال، لأنّه سيؤدي إلى التأثير في واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" الأخرى غير FLEDGE. نرحب بتلقّي ملاحظات إضافية هنا. |
| حلول طويلة المدى لإعداد التقارير على مستوى الحدث | الاهتمام بالاحتفاظ ببيانات معيّنة، مثل highestScoringOtherBid
حتى بعد إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا |
كما ذكرنا في مقالتنا في مدوّنتنا في شهر شباط (فبراير)، ستبقى ميزة إعداد تقارير الفوز بالمزاد على مستوى الحدث متاحة "حتى عام 2026 على الأقل". ليس لدينا في الوقت الحالي تفاصيل إضافية لمشاركتها، ولكننا نرحب بملاحظات إضافية حول أهمية إبقاء بيانات معيّنة متاحة بعد إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا. |
| الحد الأقصى للمجموعات ذات الاهتمامات المشتركة | ما هو الحد الأقصى لعدد مجموعات الاهتمام التي يمكن لمصدر إضافة متصفّح واحد إليها؟ | يسمح متصفّح Chrome بما يصل إلى 1,000 مجموعة اهتمامات لكل مالك، وما يصل إلى 1,000 مالك مجموعة اهتمامات. فالهدف من هذه الحدود هو أن تكون خطوط حماية، وليس أن يتم انتهاكها أثناء التشغيل العادي. |
| الإشارات على مستوى الحدث | إتاحة اقتراح للحصول على إشارات على مستوى الحدث لكلّ من generateBid
وreportWin، والتي يمكن استخدامها في تدريب تعلُّم الآلة |
لقد شاركنا قرارنا بشأن الإشارات المصمّمة للمتصفّح والإشارات التي تحدّدها تكنولوجيا الإعلان هنا ونرحّب بملاحظات إضافية. |
| نصّ عروض الأسعار | أدرِج رقم تعريف المستخدِم في عنوان URL للنص البرمجي لتقديم عروض الأسعار. | لن يكون ذلك ممكنًا لأنّ FLEDGE تفرض شرطًا إضافيًا وهو أنّه يجب أن تكون مجموعة القيم الثلاثية الخاصة بمالك مجموعة الاهتمامات وعنوان URL لنص عرض الأسعار ومواد العرض المعروضة مجهولة الهوية بدرجة k لكي يتم عرض الإعلان. |
| فرض قانون K-anon | هل يتم فرض عدم الكشف عن الهوية (k-anonymity) على الزوج (componentAd, size)؟ | نعم، سيكون كذلك. يُرجى الرجوع إلى turtledove/issues/312. |
| متطلبات خدمات عروض الأسعار والمزادات | كيف توفّر خدمات B&A الدعم للمشاركين الذين يدمجون FLEDGE على الجهاز والآخرين الذين يستخدمون خدمات B&A؟ | لا نزال نُجري التعديلات النهائية على التصميم ونرحب بملاحظاتك الإضافية هنا. |
| تحديد المصدر بالاستناد إلى إجراء ما بعد المشاهدة | هل ستتوفّر إمكانية تحديد المصدر بعد المشاهدة؟ | لا يتوفّر لدينا حاليًا أيّ نوع من التعريفات العادية لقياس إمكانية المشاهدة، بل نعتمد على تصميم الإعلان نفسه لوضع علامة على حدث المشاهدة. يُرجى الرجوع إلى turtledove/issues/452. |
| استهداف الجمهور المشابه | هل يمكن أن تتيح "مبادرة حماية الخصوصية" ميزة "استهداف المستخدمين المشابهين"؟ | نحن نناقش حالة الاستخدام هنا و نرحب بملاحظاتك الإضافية. |
| واجهة برمجة التطبيقات للمراقبة في الوقت الفعلي | اقتراح لنهج مراقبة FLEDGE في الوقت الفعلي | نحن بصدد مناقشة الاقتراح ونرحب بملاحظاتك الإضافية هنا. |
| إعداد تقارير FLEDGE | يجب إجراء reportWin وreportResult بترتيب عشوائي لمنع
الإبلاغ بشكل زائد أو منخفض. |
يجب أن ينفّذ البائع أولاً reportResult() قبل أن ينفّذ المشتري
reportWin() حتى يمكن تضمين إشارات البائع من reportResult()
في reportWin(). يُرجى الاطّلاع على الشرح المفصّل للحصول على مزيد من المعلومات. |
| خوادم القيم الرئيسية المخصّصة (K/V) | هل سيتم إتاحة استخدام خوادم مخصّصة لـ K/V في المستقبل؟ | نحن نناقش السؤال هنا ونرحّب بأيّ ملاحظات إضافية. |
| المزاد على مستوى أعلى | هل يجب أن يكون أحدهم خادم إعلانات لتشغيل ميزات auction على مستوى أعلى؟ | لا تحدّد واجهة برمجة التطبيقات FLEDGE API الجهة التي يجب أن تطلبها، ولا تفرض أي متطلبات بهذا المعنى في تصميم FLEDGE. يمكن لأيّ مستخدِم تنفيذ مزاد FLEDGE (بما في ذلك مزادات البائعين المتعدّدين). كما هو موضّح في تقرير الربع الأخير من عام 2022، تسمح منصة FLEDGE لكل ناشر باختيار هيكل المزاد، بما في ذلك اختيار بائعي المكونات ومقدّمي الإعلانات على مستوى أعلى. |
| نطاق واجهة برمجة التطبيقات | هل تهدف FLEDGE إلى العمل مع بيانات الطرف الأول؟ | سننشر محتوى في الربع الثاني من عام 2023 يوضّح أنّه يمكن استخدام بيانات الطرف الأول مع FLEDGE لتنفيذ ما يلي: 1) استخدامها كمنطق لتحديد الانضمام إلى مجموعة الاهتمامات و2) إرسالها كإشارات عروض أسعار المستخدِم لاستخدامها في إنشاء منطق عروض الأسعار اللاحق. |
| المجموعات ذات الاهتمامات المشتركة على جميع النطاقات | إمكانية إنشاء مجموعات اهتمامات على مستوى النطاقات | يمكن استخدام أي معلومات متاحة في وقت إضافة متصفّح إلى مجموعة اهتمامات لإعلام هذا الجمهور بها. عند إيقاف ملفّات تعريف الارتباط التابعة لجهات خارجية نهائيًا، سيتم الحدّ من توفّر البيانات على مستوى المواقع الإلكترونية لتوجيه عملية إنشاء مجموعات الاهتمامات. |
| منطق عروض الأسعار من جهة العميل | نقل منطق عروض الأسعار الحالية من جهة الخادم إلى جهة العميل | يهمّنا معرفة المزيد عن الجوانب التي تواجه تحديات أو تنقصها حاليًا في عملية النقل، ونرحب بأي ملاحظات إضافية أو إحصاءات. |
| قيم خادم "مفتاح/قيمة" | هل يجب أن تكون قيم خادم "مفتاح/قيمة" من النوع سلسلة؟ | يجب أن تكون القيمة سلسلة، ولكن يمكنها تخزين العناصر في ملف JSON أو مخازن بروتوكول وتحويلها إلى سلسلة. |
| القائمة المحظورة للمعلِنين | ما هي الإشارات التي يمكن تقديمها للمشتري في قائمة حظر المعلنِين؟ | يمكنك العثور على المكان المناسب في auctionSignals أو في
perBuyerSignals. |
| وحدة عروض الأسعار | إتاحة وحدات عروض أسعار مختلفة، مثل تكلفة تثبيت التطبيق والتكلفة لكل ألف ظهور | نريد معرفة المزيد عن سبب الحاجة إلى ذلك في ظلّ التصميم الحالي، ونريد أيضًا معرفة ملاحظاتك إضافية. |
| منطق المزاد | هل يحدّد المتصفح أو خادم الإعلانات الفائز في المزاد؟ | يتم تنفيذ جميع عمليات اختيار الفائزين داخل مساحة المحاكاة، وتتم اتخاذ جميع القرارات من خلال رمز البائع. يقدّم المتصفّح ببساطة بيئة خاصة ومغلقة يتم فيها تشغيل رمز المشتري والبائع. |
| Permissions-Policy | هل سيستمر فرض سياسة أذونات FLEDGE الحالية بعد انتهاء مرحلة التقييم والتجربة؟ | في "تجربة المصدر"، تكون القوائم المسموح بها التلقائية الحالية لكلتا الميزتين مؤقتة وسيتم تغييرها. يهمّنا معرفة المدة التي يحتاجها خبراء التكنولوجيا الإعلانية للاستعداد للتغيير قبل أن نبدأ في تنفيذه. |
| قيد حجم الإشارة | يتم تجميع طلبات "إشارات عروض الأسعار الموثوق بها" على مستوى عدة
مجموعات اهتمامات تتضمّن trustedBiddingSignalsUrl نفسه، ويكون الحدّ الأقصى لحجم
الملفّ 2 ميغابايت. |
يسري هذا القيد على المتصلين على الجهاز لمنع استخدام موارد الجهاز بشكل مفرط. سيحصل المتصلون من خادم B&A على قيود أكثر تساهلاً. |
| إشارات إعداد التقارير | أضِف إشارة إضافية، وهي أخطاء النصوص البرمجية، للسماح باسترداد
عدد الأخطاء من جهة العميل لكل مالك مجموعة اهتمامات وكل
computeBid أو reportWin / reportResult. |
نحن نأخذ في الاعتبار المخاوف المحتملة المتعلّقة بالخصوصية في ما يتعلّق بهذا الاقتراح، ونقدّر بشدة مشاركة جهات المنظومة المتكاملة إحصاءات إضافية حول سبب الحاجة إلى ذلك. |
| حجم نافذة K-Anon | يمكنك زيادة حجم فترة K-Anon عن الحدّ الأقصى الحالي الذي يبلغ 7 أيام. | نحن ننظر في هذا الأمر وننتظر حاليًا (ونرحّب) بمعلومات إضافية من المنظومة المتكاملة. |
| أداء الجهاز | كيف يتعامل FLEDGE مع أداء الجهاز إذا كان المستخدم في عددٍ كبير من مجموعات الاهتمامات؟ | يوفّر FLEDGE العديد من خيارات المهلة وتحديد الأولوية والحدّ القصوى على مستوى منصّات عرض الإعلانات وأنظمة إدارة الطلبات التي تمنح تكنولوجيات الإعلان إمكانية التحكّم الدقيق في المواقف التي قد يكون فيها أداء الجهاز أحد أسباب الحدّ من مشاركة الجهاز في المزاد عندما يكون الجهاز في عددٍ كبير من مجموعات الاهتمامات. |
| اختبار خدمات B&A | طلب من اللاعبين في النظام البيئي استخدام الخادم الخاص بهم أثناء مرحلة الاختبار من أجل توفُّر المزيد من السجلات لإجراء تصحيح الأخطاء | تسمح ميزة B&A للمستخدمين بإطلاق الخوادم وتوسيع نطاقها من موفّري خدمات السحابة المتوفّرة المعتمَدين. للحفاظ على خصوصية المستخدم، نفرض تنفيذ العمليات داخل بيئة تنفيذ موثوقة (TEE). سنصدر قريبًا فيديو توضيحيًا عن تصحيح أخطاء IDE لتطبيقات B&A TEE، ونحن نعمل على تطوير ميزات لدعم ذلك. نسعى إلى تلقّي ملاحظات إضافية حول الموضوع. |
| المتطلبات التنظيمية | هل سيتعاون برنامج FLEDGE مع مقدّمي خدمات السحابة الإلكترونية في بلدان مختلفة ل دعم الامتثال للمتطلبات التنظيمية المحلية؟ | نحن دائمًا على استعداد لتلقّي اقتراحات بشأن مقدّمي خدمات السحابة الإلكترونية الآخرين، ولكن في الوقت الحالي، نخطّط على الأقل لاستخدام Google Cloud Platform وAWS عند فرض إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا. يُرجى الرجوع إلى هذه الشرح المفصّل للحصول على مزيد من المعلومات. |
قياس الإعلانات الرقمية
تقارير تحديد المصدر (وواجهات برمجة التطبيقات الأخرى)
| موضوع الملاحظات | ملخّص | ردّ Chrome |
|---|---|---|
| تحليل بيانات تأثير الضوضاء | إرشادات حول كيفية إجراء تحليل البيانات لتأثير "الضوضاء" | لقد شاركنا مستندات إضافية بشأن التشويش وقرارات التصميم التي يمكن
استخدامها لتغيير تأثير التشويش في بيانات تكنولوجيا الإعلان. يتوفر أيضًا دليل أكثر تفصيلاً. |
| الإبلاغ عن القيم الخالية | توضيح بشأن تنفيذ التقارير الخالية من البيانات | نعمل حاليًا على اقتراح لتنفيذ تقارير فارغة، وسيكون لدينا المزيد من التفاصيل لمشاركتها قريبًا. من خلال تنفيذ تقارير فارغة، سنتمكن من تقليل تأخّر إعداد التقارير بدون المساس بالخصوصية. |
| مستوى الضجيج | تعديل مستوى الضوضاء استنادًا إلى طول فترة الإحالة | نرحب بهذا الاقتراح وننظر في إمكانية إضافته إلى المواصفات. نرحب بتلقّي ملاحظات إضافية هنا. |
| حجم بيانات العنصر المشغِّل | لماذا يقتصر حجم بيانات العامل المشغِّل على 3 بت؟ | يقتصر الحجم على 3 بت و8 قيم مختلفة لضمان محدودية مقدار المعلومات حول المستخدِم على مستوى الموقع الإلكتروني/السياق. نرحب بجهات المنظومة المتكاملة بإرسال الملاحظات حول ما إذا كانت paramterization current لإعداد التقارير على مستوى الحدث منطقية. |
| عوامل تشغيل إعداد التقارير على مستوى الحدث | السماح بتحديد الأولوية ضمن مفتاح إزالة تكرار | نحن نستكشف حلولًا لهذه المشكلة ونرحّب بملاحظاتك الإضافية. |
| دعم تصحيح الأخطاء | توضيح بشأن تصحيح الأخطاء بعد الإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية | نريد إتاحة تصحيح الأخطاء بعد إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا، ونحن ندرس الخيارات المتاحة. نسعى إلى الحصول على ملاحظات وأفكار إضافية. |
| بدائل الإحالات الناجحة الناتجة عن النقر | طلب الحصول على مزيد من الإرشادات حول البدائل للإحالات الناجحة الناتجة عن النقر | ونشجّع المنظومة المتكاملة على استخدام Attribution Reporting API كأحد أنظمة القياس الخاصة والدائمة لحالات استخدام قياس الإحالات الناجحة السارية. تتوفّر بدائل أخرى، وعلى مزوّدي تقنية الإعلان تحديد الحلّ المناسب استنادًا إلى احتياجاتهم المرجوة من حيث الخصوصية والأداء. |
| حالات استخدام الفوترة | توضيح مدى توافق ميزة "تقارير تحديد المصدر" مع حالات استخدام الفوترة المستندة إلى الإحالات الناجحة | نحن نعمل على نشر بيان علني لتوضيح نطاق استخدام واجهة برمجة التطبيقات
Attribution Reporting API في الفوترة. لم يتم تحديد نطاق Attribution Reporting API في البداية بطريقة تتيح الفوترة المستندة إلى تكلفة الإجراء مباشرةً، بل تتيح هذه الواجهة برمجة التطبيقات الفوترة المستندة إلى النقرة والتكلفة لكل ألف ظهور، وهي بنية الفوترة التي تستخدمها أغلبية تقنيات الإعلان. قد نتيح ذلك في المستقبل إذا تلقّينا المزيد من الملاحظات بشأن المنظومة المتكاملة. |
| دعم حالات الاستخدام | مستندات حالات الاستخدام لواجهة برمجة التطبيقات Measurement API | نحن نعمل على توضيح المستندات المتعلّقة بجميع مساحات عرض تقارير "مبادرة حماية الخصوصية". |
| جودة النقرة | طلب إضافة إشارة للتمييز بين النقرات المتعمّدة وغير المتعمّدة على إعلان | نحن بصدد مناقشة الطلب ونرحّب بملاحظاتك الإضافية. |
| حلّ قياس الأداء | إتاحة حلول القياس على مستوى منصّات إدارة الأداء الإعلاني (DSP) المتعددة | يمكن لموفّري القياس استخدام Attribution Reporting API لإزالة تكرار البيانات بين منصّات إدارة الأداء الإعلاني المتعددة. بالإضافة إلى ذلك، نقترح
إتاحة قائمة بعناوين URL في attributionsrc،
ما سيسهّل على منصّات عرض الإعلانات إتاحة طلبات Attribution Reporting API لمزوّدي القياس. نرحب بأي
ملاحظات إضافية حول الاقتراح أعلاه. |
| إعداد التقارير على مستوى الحدث | طلب إتاحة عدد الأيام قبل إرسال التقرير مباشرةً | يمكن أن تحسب تكنولوجيات الإعلان هذا الطلب باستخدام المعلومات المتاحة حاليًا. لم نتلقّ أي ملاحظات أخرى بشأن هذا الطلب، ولكننا نرحّب بملاحظاتك وآرائك. |
source_registration_time |
أضِف source_registration_time في تقارير تحديد المصدر على مستوى الحدث. |
نحن ننظر في هذا الطلب ونرحّب بملاحظات إضافية بشأن ما إذا كان اللاعبون في المنظومة المتكاملة يجدون أنّ هذه الميزة مفيدة. |
| وضع التصفح المتخفي | هل ستتوفّر حلول القياس عندما يكون المستخدم في "وضع التصفّح المتخفي"؟ | لا، لن تتوفّر حلول القياس عندما يكون المستخدِم في وضع التصفّح المتخفي. تكون ملفات تعريف الارتباط التابعة لجهات خارجية غير مفعّلة تلقائيًا في "وضع التصفّح المتخفي". |
| غرف تنظيف البيانات | هل ستكون واجهات برمجة تطبيقات Measurement Protocol متوافقة مع الغرف النظيفة؟ | غرفة تنظيف البيانات هي بيئة يتم فيها تحميل بيانات ملف شخصي individual المعرِّفة من مصادر مختلفة إلى قاعدة بيانات لإجراء تحليلات استنادًا إلى دمج هذه البيانات الأساسية. إطارا القياس المُستخدَمَان في واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" هما التقارير على مستوى الحدث والتقارير الملخّصة. تحتوي التقارير على مستوى الحدث على رقم تعريف حدث يقدّمه تكنولوجيا الإعلان يمكن استخدامه في غرفة تنظيف البيانات، ولكن معلومات الإحالة الناجحة المرتبطة به ستكون محدودة ومليئة بالضوضاء. لا يمكن استخدام التقارير القابلة للتجميع المشفّرة مباشرةً في غرفة نظيفة، ولكن يمكن استخدام النتائج التلخيصية التي تقدّمها "خدمة التجميع" كإدخال للتحليلات التي تجريها أو كمعلومات تكميلية. |
خدمة تجميع البيانات
| موضوع الملاحظات | ملخّص | ردّ Chrome |
|---|---|---|
| (تم الإبلاغ عن ذلك أيضًا في الربع الرابع من العام 2022) تأخُّر إعداد التقارير |
ما هو التأخير المتوقّع في إعداد التقارير؟ | تعديل في الربع الأول من عام 2023: بناءً على ملاحظات الشركاء، شاركنا اقتراحات لتقليل مدّة المعالجة وتخفيف أثرها. وقد وافقت تكنولوجيات الإعلان على كلا الاقتراحَين أثناء مكالمات WICG. |
| قاعدة "عدم السماح بالنُسخ المكرّرة" | كيف تتعامل مع "تقرير قابل للتجميع بعد فوات الأوان" إذا سبق أن تمت معالجة التقارير القابلة للتجميع التي تحمل المعرّف المشترَك نفسه؟ | لقد شاركنا اقتراحًا بشأن إضافة تأخير إضافي في التقارير إلى المعلومات المشترَكة في التقارير التي يمكن تجميعها وتعريف رقم التعريف المشترَك لخدمة التجميع للتعامل جزئيًا مع تأثير فقدان التأخير في واجهة برمجة التطبيقات المخصّصة لتجميع التقارير. نرحب بأي ملاحظات حول الاقتراح. |
| معالجة البيانات | طلب تفعيل ميزة إجراء عدّة عمليات مرور على البيانات مع مراعاة الخصوصية التفاضلية باستخدام ميزانية الخصوصية | نحن نناقش إمكانية استخدام طريقة أكثر مرونة في استهلاك "ميزانية الخصوصية" لتفعيل حالة الاستخدام هذه ونرحّب بملاحظات إضافية. |
| (تم الإبلاغ عن ذلك أيضًا في الربع الثاني من عام 2022) سهولة استخدام طلبات البحث | فعِّل طلب البيانات المجمّعة للمفاتيح. | تعديل في الربع الأول من عام 2023: لا يزال طلبك بشأن الميزة قيد المراجعة، ولكن ليس لدينا أي اقتراحات لنشاركها في الوقت الحالي. |
| قيود "التجربة والتقييم" | توضيح نطاق "خدمة التجميع"، مثل "قاعدة عدم السماح بالمحتوى المكرّر " التي لا يتم تطبيقها حاليًا في الفترة التجريبية للمصدر | نحن ننظر في تعديل مستنداتنا لتوضيح الميزات التي ستكون متوفرة في الإصدار التجريبي الأصلي مقارنةً بالإصدار العلني. |
Private Aggregation API
| موضوع الملاحظات | ملخّص | ردّ Chrome |
|---|---|---|
| ميزانية المساهمة في التجميع الخاص | ميزانية المساهمة في المستوى 1 مقيّدة جدًا. | يُطلق على كل طلب من Private Aggregation API اسم مساهمة. بهدف
حماية خصوصية المستخدم، يكون عدد المساهمات التي يمكن جمعها
من شخص معيّن محدودًا. عند تجميع جميع القيم القابلة للتجميع في جميع مفاتيح التجميع، يجب أن يكون المجموع أقل من ميزانية المساهمة. بموجب التصميم الحالي، نضع حدًا أقصى للمساهمات التي تأتي من مصدر تقارير معيّن خلال آخر 24 ساعة تقريبًا (كإطار زمني متجدّد). هذه هي ميزانية مساهمة المستوى 1 المذكورة في الملاحظات. ننصحك بأن يحدّد المطوّرون قيمًا متناسبة مع حجم البيانات المتوقع (أي عدم استخدام القيمة 1 فقط). لذلك، قد يكون من المفيد استخدام قيمة أصغر للأحداث الأكثر شيوعًا لتجنّب استنفاد الميزانية. نسعى حاليًا إلى الحصول على بعض الملاحظات حول ميزانية المساهمة في واجهة برمجة التطبيقات الخاصة بميزة "التجميع"، وذلك في ما يتعلّق بالحدّ الرقمي والنطاق. نحن ننظر في نقل النطاق من كل مصدر إلى كل موقع إلكتروني ونقل الحدّ الحالي إلى فترة عشر دقائق مع حدّ يومي أكبر. |
الحد من التتبّع الخفي
تقليل معلومات وكيل المستخدم/تعديلات برنامج وكيل المستخدم
| موضوع الملاحظات | ملخّص | ردّ Chrome |
|---|---|---|
| استخدام Universal Analytics Reporting API | من بين أهم 10,000 موقع إلكتروني في المملكة المتحدة، لا ترسل سوى نسبة% 1 من المواقع الإلكترونية التي تستخدم الإعلانات الآلية إشارات HTTP. قد يؤثّر عدم نقل بيانات منصّات عرض الإعلانات في إمكانات مكافحة الاحتيال. | بعد إجراء تحليل على مجموعة البيانات نفسها، تبيّن لنا أنّه إذا تم احتساب استخدام Universal Analytics Channel باستخدام علامة HTML <meta> وواجهات برمجة التطبيقات JavaScript، يكون عدد المواقع الإلكترونية التي تستخدم Universal Analytics Channel أعلى بكثير من النسبة المئوية% 1 المقدَّمة في الملاحظات والآراء. استنادًا إلى ذلك، وغيرها من الحقائق، بما في ذلك الملاحظات والآراء الواردة من المنظومة المتكاملة، نشعر بالثقة في المضي قدمًا بطرح المرحلة 6 من خفض استخدام Universal Analytics تدريجيًا، بما يتوافق مع المخطط الزمني الذي تم نشره، مع إبقاء CMA على اطّلاع. يُرجى العِلم أنّه تم منح المواقع الإلكترونية فترة تحضير تبلغ عامَين تقريبًا للاستعداد لعملية النقل، ولا تزال فترة تجريبية متاحة لإيقاف الميزة نهائيًا للمواقع الإلكترونية التي تعتقد أنّها ليست جاهزة. |
| نصائح حول أشكال الأجهزة الإضافية | طلب من UA-CH لتوفير أشكال أجهزة إضافية مثل التلفزيون VR | نرحب بهذا الاقتراح وننظر في دمجه في التصميم. نرحّب بملاحظاتك الإضافية. |
| الاختبار الآلي | طلب لحلّ خطأ UA-CH في Chrome بلا واجهة مستخدم رسومية قبل إرسال مرحلة UAR 6 | تم إصلاح الخلل المعني. |
| توفّر وحدات قياس Universal Analytics (UA-CH) على أجهزة iOS | يشير موقع إلكتروني يعتمد على معلومات دقيقة من Universal Analytics لحالات استخدام الإعلانات إلى أنّ Chrome على أجهزة iOS غير متوافق. | بالنسبة إلى متصفّحات iOS غير Safari (بما في ذلك Chrome على iOS)، يجب أن يضيف مشروع WebKit ميزة التوافق مع UA-CH قبل أن يتم تفعيله (لأنّه يتحكّم في حِزمة الشبكة). |
حماية عنوان IP (المعروفة سابقًا باسم Gnatcatcher)
| موضوع الملاحظات | ملخّص | ردّ Chrome |
|---|---|---|
| (تم الإبلاغ عنها أيضًا في الربع الرابع) حالات استخدام الموقع الجغرافي | قد تمنع ميزة "حماية عنوان IP" حالات الاستخدام المشروعة للموقع الجغرافي من العمل في المستقبل، مثل تخصيص المحتوى استنادًا إلى الموقع الجغرافي. | لم يتغيّر ردّنا عن الردّ الذي قدّمناه في الربع الأخير من عام 2022: "نحن نعمل مع الجهات المعنية لضمان مواصلة Chrome إتاحة حالات الاستخدام المشروعة لعناوين IP. نحن نبحث عن ملاحظات من المنظومة المتكاملة حول دقة رصد الموقع الجغرافي لعنوان IP". |
| الالتزام بالقوانين واللوائح | إذا كان عدد سكان منطقة معيّنة أقل من مليون نسمة، سيؤدي الحدّ الأدنى الحالي الذي يبلغ مليون نسمة للحماية المتعلّقة بعنوان IP إلى منع المواقع الإلكترونية من استخدام عناوين IP للامتثال للوائح التنظيمية. | نحن نعمل مع الجهات المعنية لضمان مواصلة Chrome إتاحة حالات الاستخدام المشروعة لعناوين IP. نطلب ملاحظات من المنظومة المتكاملة بشأن الامتثال التنظيمي لحماية عنوان IP. |
| الحدّ من إساءة الاستخدام | يمكن للأطراف التحايل على ميزة "حماية عنوان IP" من خلال مشاركة عناوين IP غير المقنَّعة مع الآخرين. | ندرك أنّه قد لا يمنع اقتراح حماية عنوان IP الحالي
الأطراف من مشاركة عناوين IP
غير المقنَّعة مع الآخرين من الناحية الفنية. نحن نعمل على اتّخاذ إجراءات للحدّ من خطر إساءة الاستخدام. أثناء إجراء التعديلات على الاقتراح، نشجّعك على تقديم المزيد من الملاحظات والمناقشات. على وجه التحديد، نريد معرفة أي حالات استخدام يعتقد فيها الطرفان أنّهما بحاجة إلى مشاركة عناوين IP غير المقنَّعة مع أطراف أخرى. |
| حظر الشبكة | يمكن للأطراف التحايل على حظر الشبكة باستخدام خوادم وكيلة لحماية عنوان IP. | على الجهة التي تُجري عملية الحظر إيقاف ميزة "حماية عنوان IP" في هذا السيناريو. لقد تعاملنا مع المشكلة ونرحّب بملاحظاتك الإضافية. |
| قوائم حظر عناوين IP المتأثرة باقتراح حماية عنوان IP | تستخدِم العديد من شركات تكنولوجيا الإعلان قائمة حظر أساسية لعناوين IP، مثل قائمة عناوين IP في مركز بيانات TAG، لمنع تقديم عروض أسعار على مستودع إعلاني يُحتمَل بشدة أن يكون مخادعًا (أو على الأقل لا يمكن تحقيق الربح منه). في حال كانت تكنولوجيا الإعلان تتضمّن أيضًا خدمة تتبُّع وقد تخضع لاقتراح حماية عنوان IP، قد تفقد هذه الشركة إمكانية إجراء فحص أساسي للإعلانات قبل شراء المستودع الإعلاني. | نشجّعك على تقديم مزيد من الملاحظات ومناقشة اقتراح حماية حقوق الملكية الفكرية بشأن المشاكل والحلول المحتملة. أحد الخيارات هو تطبيق قوائم مماثلة على ميزة "حماية عنوان IP"، بحيث لا نستخدم وكيلاً للعملاء المنحدرين من عناوين IP التي تم الإبلاغ عنها سابقًا. |
تعزيز حدود الخصوصية على جميع المواقع
مجموعات نطاقات الطرف الأول
| موضوع الملاحظات | ملخّص | ردّ Chrome |
|---|---|---|
| (تم الإبلاغ عنه أيضًا في الربع الرابع) الحد الأقصى للنطاقات | طلب توسيع عدد النطاقات المرتبطة | لم يتغيّر ردّنا منذ الربع الأخير من عام 2022: "لقد أوضحنا في مكالمات WICG أنّ Chrome ملتزم بتقديم حلّ قابل للاستخدام يراعي أيضًا مصالح خصوصية المستخدمين. في هذا السياق، نشكرك على مشاركة مناقشاتك مع المنتدى حول حالات الاستخدام المحدّدة التي قد تأثرت بالحدّ الأقصى المسموح به للنطاقات، لكي يتمكّن الفريق من النظر في طرق معالجة هذه الحالات مع مواصلة حماية خصوصية المستخدمين. |
| إرسال عدد لقطات في الثانية بديل | اقتراح لطريقة بديلة لإرسال قوائم عالمية لعدد اللقطات في الثانية | في الوقت الحالي، نحن بصدد طرح مجموعات الطرف الأول (FPS) في Chrome، وقد أعددنا مستودعًا مركزيًا على GitHub لقبول عمليات إرسال المجموعات. بما أنّنا نأمل أن تملأ FPS الفجوة في حلول منصات الويب الحالية استعدادًا لإيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا، نتوقع أن نتعرّف منهم على كيفية الاستفادة من FPS من قِبل مؤلفي المواقع الإلكترونية. مع نمو قائمة المجموعات بمرور الوقت، وتكيّف المنظومة المتكاملة مع عالم ما بعد ملفات تعريف الارتباط التابعة لجهات خارجية، يمكننا أيضًا تطوير العملية إلى أن نصبح قادرين على التفكير في خطط بديلة لامركزية، مثل الخطة التي نقترحها. من خلال العملية الحالية، نتوقّع وضع مدد زمنية محدّدة، ما سيتيح لنا تطوير عملية القبول بمرور الزمن. يمكننا إعادة النظر في هذه الفكرة بعد اكتمال عملية إرسال العينة. |
| الإشراف على المراجعات | تفعيل الإشراف المجتمعي على مستودع إرسال لقطات FPS لمنع إساءة الاستخدام يمكن للمخادعين بسهولة التلاعب في العملية باستخدام مصادر مزوّدة بأرقام هواتف مؤقتة لاقتراح مجموعات، وقد يؤدي حجم الطلبات الهائل إلى التأثير في عمليات اقتراحات المجموعات الحقيقية. | نحاول أن تكون عمليات التحقّق موضوعية قدر الإمكان من خلال الاعتماد على عمليات التحقّق من الصحة الفنية. نعتقد أنّ هذا هو الأسلوب الأكثر ملاءمةً لتوسيع نطاق عملية الإرسال. وتحقيقًا لهذا الهدف، سنهدف أيضًا إلى التأكّد من أنّ العملية مقاومة للمحتوى غير المرغوب فيه أو المحتوى الذي تم إنشاؤه باستخدام أرقام هواتف مؤقتة. |
| المجموعات الفرعية المرتبطة | هل ستتمكّن مجموعات نطاقات الطرف الأول (FPS) من دعم حالات استخدام تدفق المورّدين/خدمات البرامج كخدمة (SaaS) التابعين لجهات خارجية من خلال المجموعات الفرعية المرتبطة؟ | لا تُعدّ عمليات المعالجة لدى المورّدين الخارجيين أو خدمات البرامج كخدمة (SaaS) حالة استخدام تُعتبر حاليًا ضمن نطاق "مجموعات الطرف الأول". نرحب بملاحظات إضافية حول كيفية استخدام ملفات تعريف الارتباط على جميع المواقع الإلكترونية في حالات الاستخدام هذه. |
| دمج FPS مع CHIPS | طلب دمج FPS + CHIPS لدعم حالات الاستخدام مثل اختبار A/B | نحن نناقش حالة الاستخدام هذه ونفكر أيضًا في مناقشة هذا الأمر بشكل أكبر في مكالمة WICG ونرحّب بملاحظاتك الإضافية هنا. |
| اللائحة العامة لحماية البيانات | اقتراح مجموعة فرعية جديدة من FPS يتم وضع نموذج لها استنادًا إلى مفاهيم اللائحة العامّة لحماية البيانات | لقد ناقشنا هذا الاقتراح داخليًا ووازنّاه مع غيرها من الملاحظات التي تلقّيناها بالإضافة إلى أهداف الخصوصية التي نسعى لتحقيقها. وقد قدّمنا إجابة توضّح سبب عدم اتّباع هذا الاقتراح في الوقت الحالي. |
| الذاكرة | التغيير المتوقّع في حجم ذاكرة المتصفّح عند دمج قائمة عدد اللقطات في الثانية | سبق أن تخزين المتصفّحات هذه الأنواع من القوائم بأقل تأثير ممكن في الذاكرة، مثل "قائمة الحماية من التتبّع" في ميزة "إيقاف التتبّع". على الرغم من أنّه سيتم نسخ قائمة "مجموعات الطرف الأول" إلى كل مثبّت من Chrome محليًا، سنواصل مراقبة حجم الملف ونحن confiant أنّه يمكننا تحسين مساحة الذاكرة التي يشغلها. |
Fenced Frames API
| موضوع الملاحظات | ملخّص | ردّ Chrome |
|---|---|---|
| قيود الإطارات المضمّنة المستقلة | توضيح حول القيود المفروضة من خلال "الأطر المحدود" | في شهر آذار (مارس)، عدّلنا الشرح المفصّل عن الإطارات المحدود الذي يقدّم معلومات عن إمكاناته، ونرحّب بأي ملاحظات إضافية. |
| توسيع نطاق معلومات الوصول | طلب توسيع نطاق الوصول إلى المعلومات حول اللقطات المجاورة | نسعى إلى معرفة المزيد من المعلومات عن سبب اشتراط استخدام هذه الميزة في المنظومة المتكاملة، ونرحّب بأي ملاحظات إضافية بشأنها. |
| الإطارات المضمّنة المستقلة وإطارات iframe | أسئلة حول تطابق الميزات بين "الإطارات المُحيطة" و"الإطارات المضمّنة" | ستتوفّر جميع واجهات برمجة التطبيقات والتقارير المتاحة في "مبادرة حماية الخصوصية" لإطارات div وإطارات الحدود بالطريقة نفسها. |
| إعادة تغيير حجم "الإطارات المضمّنة المستقلة" | يؤثّر حظر تغييرات حجم الإطار في حالات استخدام معيّنة. | يهمّنا معرفة المزيد عن أنواع حالات الاستخدام التي تتأثر بالقيود، ونرحّب بتلقّي ملاحظات إضافية. |
Shared Storage API
| موضوع الملاحظات | ملخّص | ردّ Chrome |
|---|---|---|
| مهام صغيرة تابعة لجهات خارجية | هل يمكن لجهات خارجية الكتابة في "مساحة التخزين المشتركة" التي تم تقسيمها حسب المصدر؟ أم هل يمكن استدعاء وحدات عمل أخرى لقياس الجهة الخارجية؟ | يحدِّد مصدر سياق التصفّح الذي يتم تنفيذ الرمز البرمجي فيه مساحة التخزين المشتركة التي يتم كتابة هذه البيانات فيها. عند إضافة رمز تابع لجهة خارجية إلى صفحة، يمكن تضمين الرمز التابع لجهة خارجية كإطار iframe مع سياق التصفّح الخاص به، ما يسمح للرمز التابع لجهة خارجية بالكتابة إلى مصدره الخاص. يمكن أيضًا تضمين الرمز البرمجي التابع لجهة خارجية كنص برمجي بدلاً من إطار iframe، ما لا يؤدي إلى تبديل سياق التصفّح، ويمكن للجهة الخارجية الكتابة في مساحة التخزين المشترَكة الخاصة بالمُضمِّن. يُرجى العِلم أنّه لا يمكن لأحد قراءة البيانات من مساحة التخزين المشتركة إلا مالكها. |
| التكرارات | لن يكون من الممكن إزالة تكرار التفاعلات خارج منظومة Chrome المتكاملة. | تهدف ميزة "مساحة التخزين المشتركة" إلى توفير نتائج فريدة لقياس مدى الوصول استنادًا إلى متصفّح Chrome داخل Chrome. نحن مهتمون بالعمل مع تقنيات الإعلان لمحاولة فهم كيفية استخدام هذه النتائج كجزء من نماذج الوصول الأوسع نطاقًا. ندرك أنّ النتائج نفسها قد تشكل فقط جزءًا من التفاعلات، ونريد العمل مع تكنولوجيات الإعلان لاستكشاف منهجيات وضع نماذج إضافية يمكن دمجها. |
| فترة معاينة الإحالة الناجحة | طلب الحصول على فترة معاينة إعلانات لمعدل الإحالات الناجحة من أجل الاطّلاع على التغييرات في الإحالات الناجحة بمرور الوقت | ويمكن تنفيذ ذلك من خلال معالجة مسارات الإحالات الناجحة المختلفة على جانب العميل باستخدام "مساحة التخزين المشتركة"، ما يوفّر مرونة إضافية للتحليلات المتقدّمة على مساحة التخزين الآمنة وغير المُقسّمة للمتصفّح. |
| فترة انتهاء صلاحية السلعة | طلب تمديد فترة انتهاء الصلاحية إلى 90 يومًا | تم تعديل سياسة الاحتفاظ بالبيانات في تشرين الثاني (نوفمبر) 2022، وتنص على محو كل مفتاح بعد ثلاثين يومًا من آخر عملية كتابة. نرحب بملاحظاتك الإضافية لتحديد ما إذا كانت السياسة الجديدة مناسبة للمنظومة المتكاملة. |
| عرض تصميمات الإعلانات بالتناوب | لا تعكس حالات استخدام ميزة "تبديل المواد الإبداعية" الإجراءات الفعلية بعد انتهاء المزاد. | يهمّنا معرفة رأي المزيد من شركات تكنولوجيا الإعلان من جهة الشراء بشأن ما إذا كانت مستندات تدوير المواد الإبداعية دقيقة أم لا. |
CHIPs
لم يتم تلقّي أي ملاحظات هذا الربع.
FedCM
| موضوع الملاحظات | ملخّص | ردّ Chrome |
|---|---|---|
| نقطة نهاية بيان الهوية | السماح صراحةً بطلبات عشوائية لنقطة نهاية ملف تعريف الهوية | لقد تعاونّا مع Mozilla في هذا طلب الطرح بهدف حصر قدرة المواقع الإلكترونية على إرسال طلبات مستندة إلى بيانات اعتماد من مصادر مختلفة بدون إزعاج المستخدمين، وسنواصل مراجعة الملاحظات الأخرى ومعالجتها أيضًا. |
| تعبئة الهوية تلقائيًا | هل يمكن استخدام FedCM لتعبئة نماذج تسجيل الدخول تلقائيًا باستخدام مقدّم هوية من قائمة FedCM؟ | تكمن المخاوف بشأن حالة الاستخدام هذه في أنّها قد تؤدي إلى تسرُّب المعلومات عندما يتمكّن موقع إلكتروني لم يتفاعل مع المستخدم من الاستعلام عن آخر مزوّد خدمة إدارة هوية اعتماد استخدمه المستخدم. نحن بصدد مناقشة هذه المشكلة ونقدّرتلقّي ملاحظات إضافية. |
| اختيار الحساب السياقي | اقتراح لإضافة إشارات سياقية في واجهة مستخدم اختيار الحساب | نحن ننظر في هذا الاقتراح ونرحّب بمناقشات إضافية. |
مكافحة المحتوى غير المرغوب فيه والاحتيال
Private State Tokens API (وواجهات برمجة التطبيقات الأخرى)
| موضوع الملاحظات | ملخّص | ردّ Chrome |
|---|---|---|
| استطلاع جمع الإمكانات | في أوائل الربع الأول من العام، انتهينا من جمع نتائج الاستطلاع التي تتطلب الحصول على ميزات لحالات استخدام مختلفة لمكافحة الاحتيال، وشاركنا هذه النتائج علنًا (دقائق، النتائج). | ونخطّط لدمج هذه الملاحظات أثناء تطوير اقتراحات جديدة و نماذج أولية لواجهات برمجة تطبيقات مخصّصة تحافظ على الخصوصية لاستخدامها في ميزات مكافحة ال fraudem. نتوقع أن نعطي الأولوية للتطوير في الحالات التي يكون فيها هناك طلب كافٍ وتكنولوجيا حالية يمكننا الاستفادة منها لطرح الميزة على الويب، مع الحفاظ على خصوصية المستخدم. على سبيل المثال، حصلت سلامة الجهاز والتشغيل على ترتيب عالٍ، وتحتوي العديد من منصّات الاختبار على واجهات برمجة تطبيقات حالية تشارك بشكل آمن تقييمًا لسلامة الجهاز، لذا فهي مرشحة جيدة لمتابعة الفحص ضمن مجموعات المنتدى. |
| ملاحظات حول ميزة "الإعلان عن نية الشحن" في توقيت المحيط الهادئ | في إطار عملية إرسال التطبيق، تلقّينا استفسارًا بشأن المتابعة، ويرجع ذلك إلى أنّنا نستخدم إصدارًا قديمًا من Privacy Pass. لقد تلقّينا أيضًا ملاحظات بأنّ المواصفة غير واضحة في بعض الأقسام، ويجب تحسينها لتسهيل ملاءمة المتصفّح. | ونخطّط لتنفيذ العديد من التغييرات المقترَحة على المواصفات قبل إرسالها إلى "إحصاءات Google"، بالإضافة إلى بعض التغييرات على واجهة برمجة التطبيقات. لقد تلقّينا الملاحظات في نهاية الربع الأول من العام، لذا نعمل على متابعة مشاكل github من خلال تقديم تفاصيل محدّدة وتعديل خطة الإطلاق (قيد التقدّم، اعتبارًا من نشر تقرير الملاحظات هذا). بالنسبة إلى التغييرات الأكبر في واجهة برمجة التطبيقات، نحن منفتحون على النظر فيها، لكنّنا نرى أنّ أفضل طريقة للمضي قدمًا هي مواصلة الإطلاق للاستخدام العام والحصول على ملاحظات عملية من المزيد من المطوّرين. نأمل مواصلة هذه المناقشة والسعي إلى توحيد المتصفحات. إذا تم وضع معيار جديد، سننظر في اعتماده وتطوير خطة للانتقال إليه بعناية. |