تقرير ربع سنوي للربع الثالث من عام 2023 يلخّص الملاحظات التي تم تلقّيها بشأن المنظومة المتكاملة بخصوص اقتراحات "مبادرة حماية الخصوصية" واستجابة Chrome.
في إطار التزاماتها تجاه "مبادرة حماية الخصوصية"، وافقت Google على تقديم تقارير ربع سنوية للجميع عن عملية تفاعل الأطراف المعنية ضمن اقتراحات "مبادرة حماية الخصوصية" (يُرجى الرجوع إلى الفقرتين 12 و17(ج)(2) من الالتزامات). يتم إنشاء تقارير ملخّص ملاحظات "مبادرة حماية الخصوصية" هذه من خلال تجميع الملاحظات التي يتلقاها Chrome من مصادر مختلفة كما هو مُدرَج في نظرة عامة على الملاحظات، بما في ذلك على سبيل المثال لا الحصر: مشاكل GitHub ونموذج الملاحظات المتاح على privacysandbox.com والاجتماعات مع الجهات المعنية في المجال ومنتديات معايير الويب. يرحب Chrome بالملاحظات الواردة من المنظومة المتكاملة ويستكشف بشكل نشط طرقًا لدمج ما تعلّمته في قرارات التصميم.
يتم ترتيب مواضيع الملاحظات والآراء حسب الانتشار حسب واجهة برمجة التطبيقات. ويتم ذلك من خلال تجميع مقدار الملاحظات التي تلقّاها فريق Chrome حول موضوع معيّن والتنظيم بترتيب تنازلي للكمية. تم تحديد موضوعات الملاحظات الشائعة من خلال مراجعة موضوعات المناقشة من الاجتماعات العامة (W3C وPatCG وIETF)، والملاحظات المباشرة، وGitHub، والأسئلة الشائعة التي تظهر من خلال الفرق الداخلية والنماذج العامة في Google.
وبشكل أكثر تحديدًا، تمت مراجعة محاضر اجتماعات اجتماعات الهيئات القياسية على الويب، وللملاحظات المباشرة، تمت مراجعة سجلات Google للاجتماعات الفردية مع الأطراف المعنية ورسائل البريد الإلكتروني التي تلقاها مهندسون فرديون والقائمة البريدية لواجهة برمجة التطبيقات ونموذج الملاحظات العامة. بعد ذلك، نسقت Google بين الفرق المشاركة في أنشطة التوعية المختلفة هذه لتحديد الانتشار النسبي للموضوعات التي تظهر فيما يتعلق بكل واجهة برمجة تطبيقات.
تم تطوير تفسيرات ردود Chrome على التعليقات استنادًا إلى الأسئلة الشائعة المنشورة، والردود الفعلية التي تم تقديمها على المشاكل التي طرحتها الأطراف المعنية، وتحديد الموضع خصيصًا لأغراض تمرين إعداد التقارير العلني هذا. في إطار التركيز الحالي على التطوير والاختبار، تلقّينا أسئلة وملاحظات خاصة في ما يتعلق بالمواضيع وProtected Audience API وAttribution Reporting API.
إنّ التعليقات التي يتم تلقّيها بعد انتهاء الفترة المشمولة بالتقارير الحالية قد لا تكون قد استجابت Chrome بعين الاعتبار.
مسرد الاختصارات
- الشرائح
- ملفات تعريف الارتباط في الحالة المقسَّمة المنفصلة
- معالِج الإشارات الرقمية (DSP)
- منصّة الطلب
- FedCM
- إدارة بيانات الاعتماد الموحدة
- لقطات في الثانية
- مجموعات الطرف الأول
- مكتب الإعلانات التفاعلية (IAB)
- مكتب الإعلانات التفاعلية
- موفِّر الهوية (idP)
- موفّر الهوية
- مجموعة مهندسي شبكة الإنترنت (IETF)
- مجموعة مهندسي شبكة الإنترنت
- IP
- عنوان بروتوكول الإنترنت
- openRTB
- عروض الأسعار في الوقت الفعلي
- و إ
- تجربة المصدر
- PatCG
- مجموعة منتدى تكنولوجيا الإعلان الخاصة
- RP
- مجموعة الاعتماد
- نظام SSP
- منصة جانب المورّد
- TEE
- بيئة تنفيذ موثوقة
- UA
- سلسلة وكيل المستخدم
- UA-CH
- تلميحات إلى عميل وكيل المستخدم
- W3C
- اتحاد شبكة الويب العالمية
- قيد العمل على الإنترنت (WIPB)
- العمى النهائي لعناوين IP
ملاحظات عامة بدون واجهة برمجة تطبيقات أو تقنية محدّدة
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| جاهزية المنظومة المتكاملة | وأشار مقدّمو خدمات البريد الإلكتروني إلى مخاوف تتعلق بعدم استعداد الناشرين وعدم تنفيذهم لأعمال النشر المطلوبة. | ركّزت "مبادرة حماية الخصوصية" بشكل خاص على توعية الناشرين، وتشمل برامج تعليمية مخصَّصة على الويب واجتماعات مع كل من الناشرين ومقدِّمي الخدمات المشترِكة في خدمتَي تعزيز عمليات النشر. |
| الإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية | ازدادت المخاوف من إيقاف ملفّات تعريف الارتباط التابعة لجهات خارجية نهائيًا (3PCD) في الربع الأخير من 2023 بسبب انقطاع التكنولوجيا في المجال. | تمت مناقشة المخطّط الزمني لـ "مبادرة حماية الخصوصية" مع CMA، مع تحديد تسلسل يؤدّي إلى الاستعداد خلال النصف الثاني من العام 2024. ستنشر "مبادرة حماية الخصوصية" معلومات أكثر تفصيلاً حول تسلسل تسريع 3PCD. ضمن "الالتزامات"، تخضع 3PCD لمخاوف المنافسة التي تتم معالجتها في CMA. |
| مدير إعلانات Google | يرفض "مدير إعلانات Google" الكشف عن واجهة برمجة التطبيقات، ما يجعل الاختبار صعبًا. | الردّ الذي قدّمه "مدير إعلانات Google": للأسباب التي يوضّحها هذا الردّ من "مدير إعلانات Google"، لا تشمل خطط "مدير إعلانات Google" لدمج Protected Audience API إمكانية إتاحة خادم إعلانات الناشرين لدى Google بدون التحكّم في مزاد المستوى الأعلى. |
| مدير إعلانات Google | يفرض "مدير إعلانات Google" حدًّا أدنى سريًا للسعر الأدنى الذي لا يظهر إلا لموفّري AdX أو "عروض الأسعار المفتوحة". | توضّح المستندات العامة لـ "مدير إعلانات Google" أنّ الفائز في
المزاد السياقي يتم تمريره إلى منطق النتائج ذي المستوى الأعلى وليس
إلى أي مزاد مكوّن، بما في ذلك AdX أو "عرض الأسعار المفتوح". إضافةً إلى ذلك، يوضّح هذا المستند منطق أعلى مستوى لتسجيل النقاط: "سيقارن "مدير إعلانات Google" عرض السعر الفائز لكل مزاد مكوّن، بما في ذلك مزاد المكونات في "مدير إعلانات Google" لعروض أسعار مجموعات الاهتمامات لدى المشترين، بالإضافة إلى أفضل إعلان سياقي (الذي يتم اختياره من خلال التخصيص الديناميكي)، وسيعرض الإعلان الذي يقدم أعلى عرض سعر". |
| مدير إعلانات Google | يجب أن تخضع منتجات "إعلانات Google" للقواعد نفسها المنطبقة على منتجات الإعلانات التابعة لجهات خارجية. | تخضع منتجات "إعلانات Google" في الوقت الحالي للقواعد نفسها السارية على الأطراف الثالثة. |
| الاختبار الذي يسهّله Chrome | أضِف تصنيفات للمتصفّحات التي ليست في A أو B. | نحن لا نفكر في القيام بذلك في الوقت الحالي، حيث توصل التحقيق الذي أجريناه إلى أن إضافة تصنيفات غير تجريبية قد تؤدي إلى تعقيد مخاوف الخصوصية بشأن الزيارات في وضع التصفح المتخفي. |
| وكالة إعلانية | هل يمكن للوكالات أو الشركات التي لا تستخدم JavaScript على المواقع الإلكترونية استخدام واجهات برمجة تطبيقات "مبادرة حماية الخصوصية"؟ | يمكن لأي شخص الاتصال بواجهات برمجة تطبيقات "مبادرة حماية الخصوصية". إذا أرادت وكالة أو أي شخص آخر إنشاء تقنيات مباشرةً على واجهات برمجة التطبيقات، فيمكنها ذلك. تتطلّب واجهات برمجة التطبيقات من جهة العميل التكامل مع البرنامج، تمامًا كما تفعل ملفات تعريف الارتباط. والعديد من واجهات برمجة التطبيقات، مثل ملفات تعريف الارتباط، تشتمل أيضًا على واجهة عنوان HTTP. لقد سبق أن رأينا إطار عمل واحد في مجال الإعلانات، وهو Prebid، ينشئ عمليات دمج من جهة العميل مع واجهات برمجة التطبيقات. يمكن للمؤسسات الأخرى فعل الشيء ذاته. |
| حلول من جهة العميل | لماذا تتبنى Google حلولاً من جهة العميل لـ "مبادرة حماية الخصوصية" عندما أعرب أحد المهندسين عن قلقه سابقًا بشأن قابلية توسع هذه الحلول في عام 2012؟ | تطورت تكنولوجيا تحسين الخصوصية (PET) كمجال من مجالات الدراسة بشكل كبير منذ عام 2012 ومعها تطبيقات مُجدية من الناحية التجارية. تستند مجموعة "مبادرة حماية الخصوصية" إلى تركيبات من اختبار PET التي لم تكن ممكنة قبل أكثر من عشر سنوات. بالإضافة إلى ذلك، زادت قوة الحوسبة الشخصية، وكذلك توقعات المستهلك بشأن المتصفحات والتوقعات التنظيمية للخصوصية. |
| تعلُم الآلة | ما هو الاستخدام المخطط له من Google لاستخدام "مبادرة حماية الخصوصية" لأغراض تعلُّم الآلة؟ | إنّ جزءًا كبيرًا من المنظومة المتكاملة لتكنولوجيا الإعلان يستخدم حاليًا تكنولوجيا تعلُّم الآلة، ولا نتوقّع أن يتغيّر ذلك. لا تمنع "مبادرة حماية الخصوصية" شركات تكنولوجيا الإعلان أو أي شخص آخر من مواصلة استخدام تعلُّم الآلة. ولا تتطلب "مبادرة حماية الخصوصية" أن تستخدم الشركات التي تتكامل مع واجهات برمجة التطبيقات الخاصة بها تكنولوجيا تعلُّم الآلة. من المعقول توقع أن تستمر الشركات في إنشاء المنتجات والخدمات بطرق تلبي احتياجات عملائها، سواء كان ذلك يشمل التعلم الآلي أم لا. من الواضح أنّ أي تعلُّم الآلة تنشئه عمليات دمج "مبادرة حماية الخصوصية" معرَّف لهم، وبالتالي لن يتم حجبهم. |
| التحقق من البيانات | كيف يمكن للشركات التحقّق من دقة البيانات التي تتلقّاها من "مبادرة حماية الخصوصية" وأنّ Google مستعدّة لمراجعتها عبر كيان مثل مجلس تقييم الوسائط (MRC)؟ | تم إنشاء واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" ضمن النظام الأساسي المفتوح المصدر الذي يدعم Chrome. كما أن أجزاء واجهات برمجة التطبيقات المصممة للتشغيل في بيئات التنفيذ الموثوق بها هي أيضًا مفتوحة المصدر وقابلة للتدقيق. يمكن لأي شخص يريد فحص التعليمات البرمجية، بما في ذلك مجلس تقييم الوسائط (MRC). |
| (تم الإبلاغ أيضًا في الأرباع السابقة) دعم الإنتاج | ما هي الإجراءات المطلوبة من Chrome لدعم المشاكل الفنية وعمليات التصعيد في "مبادرة حماية الخصوصية" التي تؤثر في المنظومة المتكاملة؟ | توفّر Google مجموعة من القنوات للسماح لخبراء الإعلانات بالإبلاغ عن المشاكل الفنية وتفعيل أي عمليات تصعيد ضرورية لحلّ هذه المشاكل. بالإضافة إلى ذلك، يتوقّع Chrome إنشاء عملية وتوسيع نطاقها لحل المشاكل الفنية وعمليات التصعيد التي تؤثر في سلامة المنظومة المتكاملة. ويلتزم Chrome بضمان توفير الموارد
لهذا الجهد. يُرجى الاطّلاع على مشاركة المطوّر للحصول على مزيد من المعلومات حول المنتديات العامة والخاصة لإرسال الملاحظات والتصعيد. |
| أوضاع الاختبار التي تسهّلها Chrome | مزيد من المعلومات حول المخططات الزمنية وعمليات التنفيذ الدقيقة لأوضاع الاختبار التي يسهّلها Chrome. | لقد نشرنا مشاركة مدونة
حول أوضاع الاختبار ونعمل على مشاركة المزيد من المعلومات قريبًا. نرحّب بالاقتراحات بشأن الحجم المطلوب لتصنيفات وضع الاختبار. |
| التكامل مع المعايير الأخرى المتّبَعة في المجال | هل ستتصل واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" إما بالإصدار 2.* من إطار الشفافية والموافقة أو كليهما و"وضع الموافقة"؟ | لا نخطط لدمج واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" مباشرةً مع الإصدار الثاني من إطار الشفافية والموافقة أو وضع الموافقة. ومع ذلك، نرحب بالشركات والمجموعات التجارية المرتبطة بالمجال لتكييف منتجاتها وأُطر العمل الخاصة بها للعمل بالتوافق مع واجهات برمجة تطبيقات "مبادرة حماية الخصوصية". على سبيل المثال، في أُطر عمل مثل إطار الشفافية والموافقة، يجب على كل مشارك تحديد نهج الامتثال الخاص به استنادًا إلى إشارة إطار الشفافية والموافقة التي يتلقاها وسياسات إطار الشفافية والموافقة المرتبطة بها. نتوقع من الشركات تحديد موعد وكيفية استخدام وظائف مختلفة تقدّمها الوحدات الأساسية لـ "مبادرة حماية الخصوصية". |
التسجيل والإقرار
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| الشروط | تعني عملية التسجيل أنّ Google يمكنها تحديد الشركة التي يُسمَح لها في المنظومة المتكاملة باستخدام واجهات برمجة تطبيقات "مبادرة حماية الخصوصية". | تستلزم عملية التسجيل والمصادقة بشكل أساسي التحقّق من الكيان (على سبيل المثال، يمتلك الكيان رقم DUN، ويمكن أن يوفّر رابطًا يؤدي إلى سياسة الخصوصية، وما إلى ذلك) وتجعل المصادقة العامة شرطًا لاستدعاء واجهات برمجة التطبيقات. سيتم التحقق من صحة الكيانات التي يمكنها استيفاء متطلبات التسجيل بنجاح. بالنسبة إلى الشركات التي ليس لديها قانون DUN، نقدّم عملية تكميلية وسريعة مع شركة Dun & Bradstreet للحصول على أحد هذه الأوامر. والهدف من ذلك هو تحسين إجراءات حماية الخصوصية لواجهات برمجة التطبيقات (وفقًا للإجراءات المذكورة أعلاه)، وأيضًا إضافة المزيد من الشفافية إلى واجهات برمجة تطبيقات "مبادرة حماية الخصوصية"، ما يتيح للجهات المهتمة أن تتعرّف بشكل أفضل على مَن يستخدم واجهة برمجة التطبيقات وما هي الإقرارات التي تقدّمها. نحن مستعدون لتلقي المزيد من الملاحظات والآراء في المجال بشأن هذه المشكلة، والتي تم استخدامها بالفعل لتشكيل العملية. |
| النفقات العامة لإعادة التسجيل | تنتهي صلاحية ملف المصادقة كل 12 شهرًا ويتطلّب من المواقع الإلكترونية إعادة التسجيل. | وقد وصلتنا ملاحظات من المنظومة المتكاملة وعدّلنا نهجنا وفقًا لذلك. وهذا يعني أن الملفات لن تنتهي صلاحيتها بعد 12 شهرًا أو أي فترة زمنية محددة. إننا نحدّث دليل مطور التسجيل لدينا لإضافة سياق إضافي. |
| ملف المصادقة | كيف يتم استخدام ملف المصادقة؟ | سيُطلب من جميع الشركات التي تطلب واجهات برمجة التطبيقات لقياس الصلة ومدى الصلة بموضوع البحث
تحميل ملف المصادقة على مواقعها الإلكترونية
والاحتفاظ به للعرض العلني ما دمت تريد مواصلة
استدعاء واجهات برمجة التطبيقات. من المتوقّع أن تقدّم المواقع الإلكترونية طلبًا واحدًا تقريبًا في الساعة من "مبادرة حماية الخصوصية"، وقد تطلب بعض الكيانات المحتملة الأخرى أيضًا. وسيتم إجراء ذلك من خلال الآلية الخاصة بنظام التسجيل لطلب البحث عن خوادم الكيانات المسجَّلة والتأكّد من صلاحية ملف المصادقة. سيتم تضمين الموافقات في "تقارير الشفافية" ويمكن للجمهور الاطّلاع عليها. نتوقع من الشركات أن تتصرف وفقًا لإقراراتها المعلنة، كما هو الحال مع بقية المنظومة المتكاملة والهيئات التنظيمية ذات الصلة. |
| التسجيل | هل التسجيل لكل موقع إلكتروني أم لكل مصدر؟ | يتم التسجيل على مستوى الموقع الإلكتروني. |
عرض محتوى وإعلانات ملائمة
المواضيع
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| عروض أداء | مخاوف متعلّقة بالأداء بشأن تأثير معدّل الموافقة على Topics في المنطقة الاقتصادية الأوروبية. | ونقترح على الأطراف المعنية المعنيين التواصل مع هيئة حماية البيانات ذات الصلة بشأن هذه المشكلة. وهذه المجموعات هي الأنسب لمعالجة هذه المخاوف والتأثير في ما إذا كان يتم تحفيز تطبيقات تقنيات تعزيز الخصوصية بموجب القوانين أو يتم التعامل معها على غرار التتبُّع، ما يتطلّب اعتماد الأساليب نفسها للحصول على الموافقة. قد يؤدي الأخير إلى عدم توفّر واجهات برمجة تطبيقات مثل تلك المتوفرة في "مبادرة حماية الخصوصية" كثيرًا. |
| التسجيل | هل يحتاج مقدّمو عروض الأسعار في مرحلة مبكرة إلى التسجيل في Topics API لاستخدام إشارات Topics من مقدِّمي خدمة البيع بالتجزئة الرئيسيين | لا يحتاج مستلمو المواضيع التي تأتي بعد واجهة برمجة تطبيقات Topics API إلى أن يكونوا مسجلين، على الرغم من أنه من المحتمل أن يتم تسجيل العديد منها لاستخدام واجهات برمجة تطبيقات أخرى. سيتم توفير قائمة بالمسجّلين في "مبادرة حماية الخصوصية" بشكل آلي كجزء من جهود الشفافية التي يُجريها البرنامج، ما يتيح للمتصل المهتم بـ Topics API معرفة ما إذا كان المستلِم الذي يرسل إليه موضوعًا مسجّلاً إذا أراد المتصل ذلك. |
| فلترة المواضيع | اطلب تطبيق تصفية متصل آخر على المواضيع التي يستردها على الصفحة، من أجل مشاركة ما المشترون مؤهلون لاسترداده فقط. | ننظر في هذا الطلب ونرحب بالملاحظات الإضافية من المنظومة المتكاملة. |
| استبعاد المواقع | استبعاد المواقع الإلكترونية من المساهمة في مواضيع المستخدم | لا يتم استدعاء المواضيع افتراضيًا. يُرجى العلم أنّه لا يتم أخذ أي محتوى صفحة بعين الاعتبار عند اختيار المواضيع، ويتم تنظيم جميع المواضيع للتأكّد من أنها غير حساسة. يمكن للموقع الإلكتروني
أيضًا حظر تضمين موقعه في احتساب المواضيع من خلال
عنوان سياسة الأذونات التالي: Permissions-Policy:
browsing-topics=() |
| ملاحظة المواضيع | يمكنك السماح للناشرين بمنح أذونات لمتصفّح Chrome لتصنيف المواضيع استنادًا إلى محتوى الصفحة (على سبيل المثال، العنوان أو النص). | وسبق أن فكّرنا في توفير وظيفة تتيح تصنيف المواقع الإلكترونية إلى مواضيع استنادًا إلى محتوى الصفحة، واتخذنا قرارًا بعدم المضي قدمًا بناءً على مخاوف متعلّقة بالخصوصية والأمان. قد يخفف هذا الاقتراح من بعض هذه المخاوف، لكنه غير واضح إلى أي مدى. نظرًا لفترة تجربة CMA القادمة، لا نتوقع حدوث هذا التغيير قبل 3PCD. نرحّب بأي ملاحظات إضافية هنا. |
| ملاحظة المواضيع | توفير المزيد من سياسات الأذونات الأكثر دقة للناشرين. | سيؤدي توفير المزيد من سياسات الأذونات الدقيقة للناشرين إلى السماح للمواقع الإلكترونية للناشرين بالتأثير سلبًا في فائدة Topics API ككل، بدون أن يؤثر ذلك سلبًا في فائدة Topics API في الموقع الإلكتروني نفسه. يمكنك الرجوع إلى سياسة تحديث الأذونات لدعم الأذونات المنفصلة لاسترداد ومراقبة مشكلة GitHub للحصول على مناقشة أكثر تفصيلاً حول الموضوع. |
| المواضيع الطبية والصحية | لماذا لا يغطي تصنيف المواضيع المواضيع في الفئات الطبية أو الصحية؟ | تُعد الفئات الطبية والصحية موضوعات حساسة وبالتالي مستبعدة من تصنيف المواضيع. |
| استرجاع المواضيع | تتيح هذه الميزة طريقة أسرع يمكن لمزوِّدي خدمة البريد الإلكتروني (DSP) الحصول على Topics بدون استخدام العناوين. | تكون طرق العناوين أكثر أداءً وأقل تكلفة من إنشاء إطار iframe من مصادر متعددة وإجراء استدعاء document.browsingTopics() منه. (يجب استخدام إطار iframe متعدد المصادر للاستدعاء، لأن سياق المستوى الأعلى لمراقبة موضوع يجب أن يتطابق مع السياق الذي يتم الوصول منه إلى المواضيع). تمت مناقشة هذا الأمر بالتفصيل هنا. |
| استرجاع المواضيع | هي طلبات لدعم تمرير المواضيع من خلال العناوين في طلبات علامات النصوص البرمجية المشتركة المصدر. | من منظور أمني، هذا غير ممكن. ترتبط كل وثيقة وبيئة التنفيذ الخاصة بها بأصل واحد للوثيقة. تُعد الموارد الفرعية التابعة لجهات خارجية التي تم تحميلها وتنفيذها
في تلك البيئة نفسها مملوكة لأصل المستند. وهذا لمنع تسرُّب البيانات بدون موافقة المستخدِم من مصدر إلى آخر. يمكن استخدام السمة browsingTopics في علامات <script> بدلاً من ذلك. من المفترض أن يكون هذا خاليًا من المنظور الأمني، ولا يضيف وقت استجابة إضافيًا. يسعدنا تلقّي
ملاحظات وآراء من الجهات المهتمة. |
| الوعي | زيادة الوعي العام بـ Topics API وكيفية استخدام واجهة برمجة التطبيقات | لقد تواصلنا مع الطرف المعني الذي قدّم هذه الملاحظات
وتم حل هذه المشكلة على GitHub.
من الآن فصاعدًا، سنواصل دعم المنظومة المتكاملة لواجهة برمجة التطبيقات، ونتطلّع إلى تلقّي ملاحظات الجهات المعنيّة. في الوقت الحالي، ننصح الجهات المعنية التي تريد الاطّلاع على مزيد من المعلومات حول Topics API بالتعرّف على المستندات الواردة في دليل مطوّري برامج Chrome. |
| إشعار | إشعار لتنبيه المستخدم عندما تتم مراقبة مواضيعه من خلال موقع إلكتروني. | عالجنا هذه الملاحظات والآراء على GitHub. يمكن للمستخدمين التعرّف على مزيد من المعلومات عن عناصر التحكّم في "المواضيع" في مركز مساعدة Chrome. |
| تعلُم الآلة | كيف يمكن استخدام تقنية تعلُّم الآلة لاستنتاج مواضيع المستخدمين؟ | نعمل حاليًا على مناقشة هذه المشكلة ونرحب بملاحظات إضافية. |
| الفائدة لأنواع مختلفة من الأطراف المعنية | قد لا تتمكّن شركات تكنولوجيا الإعلان الصغيرة من الاطّلاع على المواضيع بسبب طريقة حسابها في المتصفحات. | لن يتم تحديد موضوع إلا لتكنولوجيا الإعلان التي رصدت زيارة المستخدم لصفحة حول الموضوع المعنيّ خلال الأسابيع الثلاثة الماضية. إذا لم تستدعي تقنية الإعلان واجهة برمجة التطبيقات خلال الأسابيع الثلاثة السابقة لهذا المستخدم على موقع إلكتروني حول هذا الموضوع، ستكون القيمة المعروضة فارغة. تعني هذه الميزة أنّ تقنيات الإعلان التي يستخدم عدد أكبر من مالكي المواقع الإلكترونية خدماتها، وبالتالي لديها فرص أكبر لملاحظة زيارة أي مستخدم معيّن للموقع الإلكتروني، قد تتلقّى مواضيع أكثر من تقنيات الإعلان الأخرى. تُعدّ هذه الميزة ضرورية لحماية الخصوصية في واجهة برمجة التطبيقات، لأنّها تحدّ من توفّر معلومات حول المستخدم إلا للجهات التي تكون قادرة على الاطّلاع على المعلومات الأساسية نفسها (حاليًا من خلال ملفات تعريف الارتباط التابعة لجهة خارجية). |
| طلب XHR | متى سيتم إيقاف تضمين Topics في طلبات XMLHttpRequest (XHR)؟ |
كما أعلنت Chrome
في آب (أغسطس) 2023، بدأ Chrome بالإيقاف النهائي لدعم XHR عند
الانتقال من "فترة التجربة من المصدر" إلى "مدى التوفّر للجمهور العام". مع تقدّم العمل في Topics، لم يتم تضمين دعم XHR إلا للمستخدمين الذين تم تفعيل ميزات الوقت الإضافي لهم، وتم إيقاف هذه الميزات بشكل كامل عندما تم دمج مجموعات التجارب الفردية في الوقت الإضافي. لن تتعطّل مواقعك الإلكترونية إذا كنت تستخدم Topics مع XHR. لن تتم إضافة المواضيع إلى عناوين طلبات XHR. ننصحك بالانتقال إلى fetch لطلبك، أو استخدام سمة iframe، أو استخدام واجهة برمجة تطبيقات JavaScript لاسترداد المواضيع. تتوافق ميزة "الجلب" مع كل المتصفحات الحديثة، ولكن ليس على Internet Explorer أو Opera Mini. |
| عملية تحديث التصنيف والمصنِّف | مزيد من المعلومات حول تصنيف Topics وتيرة إصدار المصنِّفات وكيف يمكن للشركات الاستعداد لمثل هذه التحديثات. | لن يطرأ أي تغيير على استجابتنا اعتبارًا من الربع الثاني: كما ذكرنا في مشاركة المدونة الأخيرة، نتوقع أن يتطور التصنيف مع مرور الوقت وأن ينتقل نظام إدارة التصنيف في نهاية المطاف إلى طرف خارجي يمثل الجهات المعنيّة من جميع أنحاء المجال. وقد شاركنا أيضًا خطة زيادة الميزة في مجموعة الإعلان عن المواضيع. |
| إساءة الاستخدام | هجوم محتمل من خلال سلسلة إعادة التوجيه. | نحن ندرس هذه المشكلة ونرحّب بتلقّي ملاحظات إضافية. |
| أنواع مستودع الناشر | ما هي أنواع المستودع الإعلاني للناشر التي ستدعمها اختبار "الجمهور المحمي" و"المواضيع"؟ | لا تنطبق أي قيود بطبيعتها على "الجمهور المحمي" أو "المواضيع" من حيث أنواع المستودع الإعلاني التي يمكن استخدامها فيها. |
| وقت الزيادة التدريجية | نقترح عليك عدم زيادة أي وقت للتصنيفات الجديدة للوصول إلى 100%. | لقد أعلنّا عن خطتنا بشأن طرح التصنيف الجديد بعد تلقّي طلب الملاحظات هذا الذي ورد من المنظومة المتكاملة ومناقشات خلال اجتماعات PATCG. |
Protected Audience API (المعروفة سابقًا باسم FLEDGE)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| مزادات من المستوى الأعلى | إمكانية استخدام خادم إعلانات الناشرين من Google بدون منح "مدير إعلانات Google" أيضًا إمكانية التحكّم في مزاد Protected Audience API الأعلى مستوى | الردّ المقدَّم من "مدير إعلانات Google": لا تشمل خطط "مدير إعلانات Google" لـ Protected Audience API إمكانية إتاحة خادم إعلانات الناشرين لدى Google بدون التحكّم في مزاد الإعلانات عالية المستوى الخاصة بالجمهور، وذلك للأسباب التالية. بهدف تقديم الخدمة لعملائنا بشكل صحيح في سوق عرض إعلانات الناشرين، يجب أن يحتفظ خادم إعلانات الناشرين في Google بالتحكّم في مزاد "الجمهور المحمي" ذي المستوى الأعلى. بصفتنا خادم إعلانات للناشرين، يتمثل دورنا في توفير توقعات للناشرين حتى يتمكنوا من التفاوض بشأن الحملات المَبيعة مباشرةً بدون الحاجة إلى إجراء حجز زائد، ولتسريع وتيرة تقديم حجوزاتهم المباشرة بشكل مثالي. يتطلب القيام بذلك إجراء المزاد النهائي لمقارنة جميع الطلب المباشر وغير المباشر المؤهل. يُعد كل من التوقعات والوتيرة من الوظائف الأساسية التي يتوقعها الناشرون من خادم الإعلانات. بدون توقّع دقيق، قد ينتهي الأمر بالناشرين إلى المبالغة في بيع مستودعهم الإعلاني، ما يعرّض سمعة أنشطتهم التجارية للخطر. وتشكّل وتيرة نشر المحتوى أهمية كبيرة أيضًا، لأنّ عدم القدرة على الوفاء بعقود الحجز مع المعلنين قد يؤدي أيضًا إلى حدوث ضرر في العلاقة المباشرة بين الناشر والمعلِن، ما قد يؤدي إلى تأثير كبير في النشاط التجاري للناشرين. باختصار، لا نشير باختصار إلى نشاط خادم إعلانات الناشر المتمثل في إجراء مزاد الإعلانات المحمية ذات المستوى الأعلى في المزاد على مستوى أعلى من الجمهور المحمي، وذلك مميزًا عن الأنشطة الأخرى لخادم إعلانات الناشر. |
directFrom |
directFromيسمح لـ "مدير إعلانات Google" بمنع الناشر من الاطّلاع على سعر المزاد السياقي. |
استجابة Chrome: من غير المعروف أنّ المعلومات التي يتم إرسالها إلى runAdAuction() واردة من البائع
إلا إذا اتصل البائع بـ runAdAuction() من إطار iframe الخاص به. في مزاد متعدد البائعين، يصبح من المستحيل أن ينشئ جميع البائعين الإطار الذي يطلب runAdAuction(). عالج "directFromSellerSignals" هذه المشكلة من خلال تحميل محتوى من حزمة موارد فرعية
تم تحميلها من مصدر البائع. ويضمن ذلك عدم إمكانية التلاعب بمصداقية وسلامة المعلومات التي يتم تمريرها إلى أي مزاد من خلال عمليات ضبط مزادات البائعين. إذا أراد الناشرون استخدام Protected Audience API لفهم أيٍّ من
المعلومات التي يحوّلها مزوّدو التكنولوجيا إلى مزادات "الجمهور المحمي"، يمكنهم طلب هذه الوظيفة من مزوّدي التكنولوجيا.ردّ "مدير إعلانات Google": لقد ركّزنا بشكل كبير على النزاهة في المزادات لسنوات، بما في ذلك وعدنا بعدم مشاركة أي سعر من أي من مصادر الإعلانات غير المضمونة للناشر، بما في ذلك أسعار تفاصيل الإعلانات غير المضمونة، مع مشترٍ آخر قبل تقديم عرض السعر في المزاد، والتي أعدنا التأكيد عليها لاحقًا في الالتزامات الفرنسية. بالنسبة إلى المزادات التي تستند إلى شرائح جمهور محمية، ننوي الوفاء بالوعد الذي قطعناه عن طريق الاستفادة من " directFromSellerSignals"، وعدم مشاركة عرض السعر لأي مشارك
في المزاد مع أي مشارك آخر في المزاد قبل اكتمال
المزاد في المزادات المتعددة البائعين. للتوضيح، لن نشارك سعر المزاد السياقي مع مزاد المكوّنات
الخاص بنا أيضًا، كما هو موضّح في تعديل المزيد من التوضيح ديناميكيات المزاد على المستوى الأعلى. |
| التعرض للمعلومات | قد يعرض المتصفح منطق العمل والتفاصيل التعاقدية الحساسة. | يمكن للشخص الذي يستخدم متصفح الويب رؤية كل ما يجري في المتصفح. عندما يحدث مزاد إعلانات داخل المتصفح، يمكن للمستخدم الذي يتم عرض مزاد الإعلانات عليه مشاهدة هذا المزاد، بما في ذلك معرفة عدد الجهات المختلفة التي تختار تقديم عروض الأسعار لها. وبما أنّ المتصفح هو وكيل المستخدم، لا نعتقد أنّه من الممكن أو المطلوب تغيير ذلك. ومع ذلك، لا يستطيع أحد رؤية هذه العمليات سوى الشخص الذي يستخدم المتصفح. لا يمكن لأي خوادم ملاحظة المزاد الذي يتم على الجهاز فقط باستخدام Protected Audience API، بما في ذلك خوادم Google. |
PerBuyerExperiment |
قد يسمح نطاق القيمة الحالي PerBuyerExperimentللمشترين بربط البيانات السياقية بطلب الخادم الموثوق به. |
لا يتوافق استخدام Protected Audience API بهذه الطريقة مع الإقرار الإلزامي من "مبادرة حماية الخصوصية" بأنّ مستخدمي واجهة برمجة التطبيقات لن يحاولوا التحايل على إجراءات حماية "مبادرة حماية الخصوصية". في المستقبل، سيوفر شرط تشغيل خوادم القيمة الأساسية في بيئات تنفيذ موثوقة (TEEs) الحماية الفنية ضد هذا الهجوم. |
| سياسة المصدر نفسه | يمكنك تخفيف قيود سياسة المصدر نفسه للسماح بالنطاقات الفرعية. | ننظر في هذا الطلب ونرحب بالملاحظات الإضافية من المنظومة المتكاملة. |
| تحديد إصدارات واجهة برمجة التطبيقات | طلب تحديد الإصدارات وملاحظات الإصدار للتغييرات في Protected Audience API | ننظر في هذا الطلب ونرحب بالملاحظات الإضافية من المنظومة المتكاملة. |
| مزادات على عدة منصات | السماح لإشارات المزاد ذات المستوى الأعلى بإجراء عمليات دمج JSON مع المكوِّن
auctionSignals |
ننظر في هذا الطلب ونرحب بالملاحظات الإضافية من المنظومة المتكاملة. |
| حد عرض السعر | عليك زيادة الحد المفروض على عدد مكوّنات الإعلان التي تدخل عرض السعر من 20 إلى 40. | ننظر في هذا الطلب ونرحب بالملاحظات الإضافية من المنظومة المتكاملة حول مدى فائدة ذلك. |
| (تم الإبلاغ أيضًا في الأرباع السابقة) أداء مزادات الجمهور المحمية |
أبلغ المختبِرون أنّ وقت الاستجابة السريع في مزادات "الجمهور المحمي" | في ما يتعلّق بوقت الاستجابة، اتّبعت Protected Audience API بشكل عام النموذج العادي الحالي لعناصر التحكّم في إنشاء العناصر التي تتيح للبائعين تحديد مقدار الوقت والموارد التي يمكن أن يستهلكها مقدّمو عروض الأسعار، وإنشاء أدوات تتيح للمشترين تحديد أفضل طريقة لاستخدام الموارد المتاحة لهم. تتوفر عناصر التحكم والأدوات هذه بشكل عام اليوم، ولكن لن يتم تحقيق الفائدة الكاملة إلا بعد اعتمادها من قبل المشترين والبائعين. إضافةً إلى ذلك، يواصل Chrome العمل على مجموعة متنوعة من تحسينات البنية الأساسية المتعلّقة بسرعة المزاد (crrev.com/1190815، crrev.com/1199839، crrev.com/1201837، crrev.com/1198339، crrev.com/1197323). ندعوك لتقديم ملاحظات وآراء بشأن نصفَي هذا الجهد في وقت الاستجابة: الأدوات الجديدة التي يجدها المشترين والبائعون مفيدة، وتقارير عن الأعطال المرصودة التي يجب على مهندسي Chrome التحقيق فيها. |
| الفلترة من جهة الشراء | إضافة دعم لفلترة جانب الشراء استنادًا إلى مجموعات الاهتمامات. | لقد اقترحنا عدة طرق يمكن من خلالها لمقدّمي الخدمات المدفوعة ومقدّمي الخدمات الرقمية تغيير تصميماتهم للتعامل مع هذا الأمر:
|
| التحكم في مجموعة اهتمامات الناشر | دعم للناشرين الذين يسعون إلى تفويض استخدام مجموعات الاهتمامات التي ينشئها الناشرون. | لقد أجرينا مناقشات مع العديد من الأطراف بشأن هذا الطلب. نرى أن جميع حالات الاستخدام هذه التي تشمل "تفويض" مجموعات المصالح التي ينشئها الناشرون يمكن استيعابها في الوقت الحالي، وبالإضافة إلى ذلك، يجب توفير دعم إضافي لكي تتدفق بعض حالات الاستخدام بسلاسة في المستقبل. |
| (تم الإبلاغ أيضًا في الربع الثاني) عن بيئات تنفيذ موثوقة | دعم بيئات التنفيذ الموثوقة (TEE) في البيئات السحابية غير العامة. | تشبه استجابتنا الأرباع السابقة: بينما نواصل استكشاف دعم لخيارات تتجاوز الحلول العامة المستندة إلى السحابة الإلكترونية، لا نخطط حاليًا لتوفير بيئة التنفيذ الموثوقة (TEE) داخل المؤسسات. في هذه المرحلة، ونظرًا لمتطلبات الأمان في "مبادرة حماية الخصوصية" والتحديات الكبيرة الناتجة عن عمليات النشر في المؤسسة، نعتقد أنّ مواصلة توسيع وتحسين عمليات النشر المستنِدة إلى السحابة الإلكترونية (على سبيل المثال، دعم Google Cloud وAWS) هو الأكثر فائدة للمنظومة المتكاملة. مع ذلك، نرحب بملاحظات إضافية حول سبب كون هذا المطلب ضروريًا وممكنًا بالنظر إلى قيود الخصوصية والأمان. |
| بيئة تنفيذ موثوقة | يمكن للمكونات في مسار عرض بيئة التنفيذ الموثوقة (TEE)، مثل جهاز موازنة الحمل، مراقبة جميع حركة المرور والحصول على معلومات عن عنوان IP لكل طلب. | يتم حاليًا تمرير عنوان IP كبيانات وصفية في عناوين الطلبات إلى خدمة إعلانات بائع غير موثوق به في حال كلٍّ من عروض الأسعار والمزاد ومزادات الجمهور المحمي على الجهاز فقط. يُرجى مراجعة إعادة توجيه البيانات الوصفية للاطّلاع على مزيد من المعلومات. نخطط على المدى الطويل لاستخدام تكنولوجيا الإعلان وتتبُّع الزيارات من خلال خادم وكيل IP، ما سيمنع المكوّنات من مراقبة جميع الزيارات في مسار العرض. |
| مدة البقاء (TTL) | هل مدة البقاء (TTL) قبل أن تطلب الخدمات تعيين مفاتيح جديدة أم أن الغرض منها أن تكون مرنة (أو ديناميكية)؟ | تكون مدة البقاء (TTL) ثابتة بشكل عام. في الوقت الحالي، تبلغ مدة البقاء (TTL) العامة 8 أيام، ويتم التناوب كل 7 أيام؛ كما أن مدة البقاء (TTL) هي نفسها للمفاتيح الخاصة في حالة خدمة التجميع. وفي حالة خدمات عروض الأسعار والمزاد، يتم استرجاع المفاتيح الخاصة والعامة كل N ساعة في المسار غير المطلوب ويتم تخزينها مؤقتًا في الذاكرة، بحيث لا يكون هناك أكثر من N ساعة بين تدوير المفاتيح والخوادم التي تحصل على هذه المفاتيح. ويكون التخزين المؤقت لمدة يوم واحد بين تدوير المفتاح وانتهاء صلاحيته هو ضمان إمكانية استمرار الخدمات في العمل حتى في حال تعذُّر إنشاء المفتاح. ونحن ندرس تمديد مدة البقاء لتكون أكثر مرونة في التعامل مع حالات انقطاع الخدمة. في حال تسرّب المفتاح، نخطط لفرض إنشاء المفاتيح يدويًا وإبطال صلاحية المفاتيح في وقت أقرب. يُرجى ملاحظة أنّه يتم تخزين المفاتيح العامة في حسابات العملاء مؤقتًا لمدة 24 ساعة حاليًا، وذلك لضمان استمرار عمل الخدمات في حال انقطاعها عن التنسيق المُستخدَم. |
| تحديد أعداد الزيارات | دعم تشكيل عدد الزيارات لخدمات عروض الأسعار والمزادات. | يمكن أن يشير "المشترون" إلى الطلب على مزادات الجمهور المحمي، وذلك استنادًا إلى بيانات الطرف الأول الخاصة بالناشر أو البيانات السياقية. يمكن للبائعين اتخاذ قرارات مماثلة أيضًا في خادم إعلانات البائع أو خادم Ad Exchange. ويمكن تدريب النماذج على بيانات الطرف الأول وأيّ تقارير مجمّعة من مزادات "الجمهور المحمي". ويمكن للبائعين استخدام هذه المعلومات لتجنُّب إرسال طلبات إلى خوادم عروض الأسعار و"المزادات" عندما لا يكون هناك طلب على مزادات "الجمهور المحمي". ونعتقد أنّ هذه الطريقة يمكن أن تكون وسيلة فعّالة لتشكيل عدد الزيارات. |
| مزاد المكونات | ما هي إشارات المزاد ذات المستوى الأعلى التي تتم مشاركتها مع بائعي المكونات؟ | يتلقى المشترون في مزاد المكونات إشارات فقط من بائع المكونات. نتطلّع إلى مشاركة مستندات حول النتيجة العامة لمزاد مدمج مع عروض أسعار العنوان ومزاد "الجمهور المحمي" قريبًا. |
| عرض الفيديو | إتاحة عرض الفيديو باستخدام Protected Audience وFenced Frames | تتيح Protected Audience API إمكانية عرض الفيديوهات باستخدام آلية تعتمد على إطارات iframe. مع ذلك، لم نصمّم بعد حلاً متوافقًا مع ميزة Fenced Frames، وهذا أحد الأسباب التي دفعتنا إلى إعادة فرض استخدام Fenced Frames في عام 2026. ويعني ذلك أنّه إذا قرّر الشريك فرض استخدام Fenced Frames الآن، سيكون دعم الفيديو غير متاح لهذا الشريك. |
| تحديد عدد مرات الظهور | (تم الإبلاغ أيضًا في الأرباع السابقة) عناصر التحكّم في عدد مرات الظهور لكل مستخدم ضمن الحملة والمجموعة الإعلانية. |
لم يطرأ أي تغيير على استجابتنا عن التقارير السابقة: ستتوفّر ميزة "جمهور محمي" إمكانية تحديد عدد مرّات الظهور للمزادات على الجهاز فقط والحملات المتعلقة بالعلامات التجارية والمحتوى. يمكن أيضًا استخدام مساحة التخزين المشتركة والحدود القصوى للموقع الإلكتروني من أجل عناصر تحكّم إضافية لتحديد عدد مرات الظهور. |
| الإعدادات المفضّلة للإعلانات | هل توفِّر ميزة Protected Audience طريقة لإيقاف المواقع الإلكترونية للمعلنِين أو حظر هذه المواقع الإلكترونية أو منعها من عرض كل مجموعات الاهتمامات مع المالك نفسه؟ | تتوفّر عدة طرق يمكن للمستخدمين من خلالها حظر الوصول إلى Protected Audience API وميزات أخرى من خلال "مبادرة حماية الخصوصية" الأخرى. |
| سياسة المصدر نفسه لعنوان URL المصدر المتعلّق بالنصوص البرمجية لعروض الأسعار والمزاد | يمكنك تخفيف المتطلبات التي تقضي بأن تكون جميع الحقول التي تحدّد عناوين URL لتحميل النصوص البرمجية أو JSON من المصدر نفسه مع المالك. | ونحن ننظر حاليًا في هذا الطلب ونرحّب بالتعليقات الإضافية من المنظومة المتكاملة. |
forDebuggingOnly |
احتمال إساءة استخدام forDebuggingOnly إذا بقيت بعد 3PCD. |
على مدار السنوات الماضية، تلقّينا ملاحظات من المنظومة المتكاملة بخصوص الثغرات في الوظائف في ميزة "الجمهور المحمي" بعد إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا، ونعمل على وضع خطة لدعمها بعد نشر 3PCD بدون التأثير على أهداف "مبادرة حماية الخصوصية". نرحّب بأي اقتراحات وملاحظات إضافية بشأن الوظائف غير المتوفّرة التي يريد المنظومة المتكاملة الاطّلاع عليها. |
| مجموعات ذات اهتمامات متعددة | استخدِم مجموعات اهتمامات متعددة في عرض السعر نفسه. | لا يمكن استخدام هذا الخيار حاليًا في Protected Audience API لأنّ ذلك سيؤدي إلى تغيير نموذج الخصوصية الأساسي. نرحّب بمزيد من النقاشات هنا. |
| المزادات على الجهاز فقط | هل سيدعم متصفّح Chrome على نظام التشغيل Android مزادات الجمهور المحمي على الجهاز؟ | نعم، ستتم إتاحة المزادات على الجهاز فقط في Chrome على نظام التشغيل Android. |
| (تم الإبلاغ في الربع الثاني من عام 2023) البيانات المرتبطة بالنقرات | أضِف بيانات ذات صلة بالنقرات إلى BrowserSignals. | نواصل تقييم طلب الميزة هذا ونرحب بملاحظات إضافية حول سبب وجوب منح الأولوية لهذه الميزة. |
| مزوِّدو "بيئة التنفيذ" الموثوق بهم | هل هناك اختلافات جوهرية في عروض "بيئة التنفيذ الموثوقة" التي يقدّمها مقدّمو خدمات السحابة الإلكترونية المختلفون؟ | لسنا على دراية بأي اختلافات كبيرة، ولكننا ننصح بمراجعة المنظومة المتكاملة لأدلة النشر المتاحة للجميع لمعرفة الحل الذي يناسب احتياجاتهم على أفضل نحو. Google Cloud: AWS. |
| (تم الإبلاغ عنها في الأرباع السابقة ) دعم الاستهداف السلبي لمجموعة الاهتمامات |
واجهة برمجة تطبيقات لدعم الاستهداف السلبي لمجموعات الاهتمامات: يتم عرض الإعلانات فقط إذا كان المستخدم لا ينتمي إلى مجموعة الاهتمامات. | نعمل حاليًا على تفعيل هذه الميزة ونناقش الطلب. |
| مخالفة محتوى | ميزات الدعم التي تتيح للمستخدمين الإبلاغ عن الإعلانات المخالِفة التي يتمّ عرضها من خلال Protected Audience API في Fenced Frames | نعتقد أنّ آلية إعداد تقارير الإعلانات ضمن الإطار الحالية تقدّم خيارات جيدة لتكنولوجيا الإعلان التي تريد تدفق إعداد تقارير "الإعلانات المخالِفة" من إنشاء المستخدمين. وهذا من شأنه أن يسمح بإعداد تقارير الإعلانات السيئة بطريقة لم تتغير بشكل أساسي عن المعيار المتّبع حاليًا في المجال. ونرحّب بطلبات الميزات الإضافية في حال بقيت أي فجوات، بما في ذلك خلال الوقت المنقضي بعد إزالة ملفات تعريف الارتباط التابعة لجهات خارجية، ولكن قبل انتشار عرض الإطار المحيط بميزة Fenced Frame على نطاق واسع. |
| إعداد تقارير حول واجهة برمجة التطبيقات الخاصة بالتجميع الخاص | كيف يمكننا حساب الوقت الذي يقضيه المستخدم في مجموعة الاهتمامات هذه؟ | في الإصدار M116 من Chrome والإصدارات الأحدث، من المفترض أن يكون بإمكانك استخدام مدى الحداثة على النحو المحدّد في pull/639. |
| خادم إخفاء هوية K | مزيد من المعلومات حول خادم K-Anonymity | شاركنا المزيد من المعلومات حول خوادم K-Anonymity هنا ونرحب بملاحظاتك الإضافية. |
| عناوين URL لتصميمات الإعلانات الديناميكية | إتاحة استخدام عناوين URL لتصميمات الإعلانات بدون إعلان مسبق مع احترام المجهولة المصدر. | نحن نناقش طلب الميزة هذا ونرحب بملاحظات إضافية حول أهمية إعطاء الأولوية لهذه الميزة. |
| شرط إخفاء هوية خوارزمية الجار الأقرب | هل ستتم إعادة طرح مطلب عدم الهوية التصنيفية في تحديثات مجموعة الاهتمامات؟ | ولا نتوقّع حدوث تغييرات في الموضع المذكور في هذه المشاركة على GitHub. كما أعلنّا في هذه المشاركة، قرّرنا إزالة شرط إخفاء الهوية k في التعديلات التي يتم إجراؤها على مجموعة اهتمامات شرائح الجمهور المحمي، وهذا ليس له أي تأثير كبير على إجراءات حماية الخصوصية الإجمالية في واجهة برمجة التطبيقات، ونخطط للنظر في إجراءات حماية أخرى محتملة ومباشرة (مثل خصوصية عنوان IP أو خادم تحديث موثوق به) في وقت لاحق عندما تكون التكنولوجيات ذات الصلة أكثر تطورًا واعتمادًا. |
| الاختبار التجريبي لخدمات عروض الأسعار والمزادات | متى سيبدأ اختبار الإصدار التجريبي من خدمات عروض الأسعار والمزادات؟ | كما هو موضّح في المخطط الزمني وخارطة الطريق، ستبدأ المرحلة الأولى من اختبار خدمات عروض الأسعار والمزادات في تشرين الثاني (نوفمبر) 2023. |
| المزامنة | طلب دعم تنسيق تصميمات الإعلانات لشبكات الإعلانات (سواء كان وسيط عرض الطلب أو وسيط عرض الطلب في الشركة أو الموقع نفسه) | يسرّنا تلقّي الملاحظات حول حالة الاستخدام هذه، ونتطلّع إلى معرفة ما إذا كان المزيد من تقنيات الإعلانات مهتمة بدعم هذه الحالة. نرحب بتلقّي الملاحظات الإضافية. |
| الإعلان المدمج مع المحتوى | إتاحة ميزة Fenced Frame للإعلانات المدمجة مع المحتوى | ننظر في إمكانية دعم حالة الاستخدام ونناقش الحلول والحلول الممكنة. |
| عدم هوية K | كيف يمكنني زيادة إعلانات مجموعة الاهتمامات التي تتوافق مع حدود k-anon؟ | وقد شاركنا بعض الإرشادات العملية حول هذا الموضوع. |
| دعم POST | دعم إرسال بيانات المزاد عبر طلبات POST. | نعمل على تقييم طلب الميزة هذا ونرحّب بعمليات الإرسال الإضافية لمشكلات GitHub بشأن سبب أهمية منح الأولوية لذلك. |
| دقة إعداد التقارير | ما مدى دقة إعداد تقارير إعلانات الإطار المحيط باستخدام الإعلانات المؤلفة من أجزاء متعددة؟ | لا يسمح التصميم الحالي بتسجيل معرّف المنتج أو موضعه لأنّ ذلك قد يعرّض خصوصية المستخدم للخطر. لا يمكن استدعاء سوى reserved.top_navigation، والذي يتم إرساله عند إجراء تفعيل من جانب المستخدم
(مثل النقرة) في الإطار المضمَّن في مكوّن الإعلان، ما يؤدي إلى
الانتقال إلى المستوى الأعلى. |
| مزاد الإعلانات | هل يمكن لـ SSP - يشارك في مزاد مكوّن - بدء مزاد مكوّن آخر بنفسه؟ | لا يمكن أن يتضمّن componentSeller أيضًا componentAuctions.ينقسم المزاد المتعدد البائعين إلى مستويَين فقط: 1. مزادات المكوّنات بالتوازي. 2- مزاد المستوى الأعلى (حيث يتنافس الإعلان الفائز من كل componentAuction). |
| مدى توفّر خدمات عروض الأسعار والمزادات | هل ستتوفّر عروض الأسعار والمزاد خلال مرحلة الاختبار التي يسهِّلها Chrome؟ | لن يكون خادم عروض الأسعار والمزاد متاحًا خلال مرحلة الاختبار التي يسهِّلها Chrome. |
| إشارات عروض الأسعار | السماح للمتصفّحات بطلب إشارات عروض الأسعار وحذفها | نعمل حاليًا على مناقشة هذا الطلب ونرحّب بملاحظات إضافية حول سبب وجوب منح الأولوية لذلك. |
generateBid() |
إمكانية تعديل userBiddingSignals لفئة الاهتمام من خلال
updateURL. |
ندرس هذا الاقتراح ونرحّب بملاحظات وآراء إضافية ومناقشة. |
| أنواع مستودع الناشر | ما هي أنواع مستودع الناشرين الذي سيكون متوافقًا مع اختبار Protected Audience API وTOPICS؟ | لا تنطبق أي قيود بطبيعتها على "الجمهور المحمي" أو "المواضيع" من حيث أنواع المستودع الإعلاني التي يمكن استخدامها فيها. |
| التكامل من خادم إلى خادم | هل التكامل المباشر بين SSP وDSP للجمهور المحمي هو مطلوب؟ | ولا يكون الدمج المباشر بين وسيط عرض الطلب (SSP) ونظام وسيط عرض الطلب (DSP) مطلوبًا إذا لم يكن هناك حاجة إلى معالجة الإشارات السياقية في خادمه الخاص لنقل تلك المعلومات التي تمت معالجتها إلى وظيفة عرض الأسعار على الجهاز فقط. |
حقل bid_currency في جلسة وجيم |
إتاحة حقل bid_currency في خدمة عروض الأسعار والمزاد |
لا تتوافق عملية "B&A" مع bid_currency بعد، ولكننا ننوي إتاحة
ذلك بحلول نهاية شهر كانون الثاني (يناير) 2024. ويمكنك الرجوع إلى المخطط الزمني هنا. |
perBuyerSignals |
هل هناك حدّ أقصى لحجم perBuyerSignals؟ |
وما من حدّ أقصى لعدد الإشارات لكل مشترٍ، ولكن قد يكون لإرسال كمية كبيرة جدًا من البيانات تأثيرات ضارة على أداء المتصفّح. |
| حالات الاستخدام على مواقع إلكترونية مختلفة | هل يمكننا استخدام مجموعات الاهتمامات في Protected Audience API على مواقع إلكترونية متعدّدة؟ | لم يتم تصميم Protected Audience لحالات الاستخدام هذه، كما هو موضّح في مقالة Turtledove/issues/282. |
| طلبات HTTP لمجموعة الاهتمامات | ضمِّن Blob لمجموعة الاهتمامات في عناوين HTTP. | ننظر في هذا الطلب ونرحّب بمزيد من الملاحظات حول هذا الطلب. |
| مراقبة جودة الإعلانات | فقدان أدوات مراقبة جودة الإعلانات المرتبطة بالمعلومات التي يتم نشرها على مواقع إلكترونية متعددة | نأخذ هذه الملاحظات في الاعتبار ونرحّب بأي ملاحظات إضافية بشأنها. |
| أدوات مطوري البرامج في Chrome | من المفترض أن تظهر طلبات شبكة الجمهور المحمية الصادرة في علامة التبويب "شبكة أدوات مطوّري برامج Chrome". | ونعمل على تفعيل هذه الوظيفة في علامة تبويب "الشبكة" ونرحب بملاحظات إضافية حول سبب وجوب منح الأولوية لذلك. |
| بيئة تنفيذ موثوقة | متى ستتم إضافة التفاصيل المتعلّقة بالمقاييس التي تؤثر على الخصوصية (ودرجاتها) إلى الشرح حول مراقبة بيئة التنفيذ الموثوق بها؟ | نحن بصدد تعديل الشرح بهذه المعلومات. سيتوفّر الشرح المحدّث بحلول تشرين الثاني (نوفمبر) 2023. |
directFrom |
لماذا لا يتم تجميع directFrom كحزمة ويب؟ |
وقد شاركنا الأسباب المنطقية لهذا القرار. |
| تفويض مرات الظهور | هل هناك أي طريقة مجدية لتفويض مرات الظهور تكون فيها نتيجة اختيار مجموعة الاهتمامات إجراء استهداف آخر؟ | لا تتوافق المزادات المتعددة المتداخلة مع أهداف الخصوصية لسببين. أولاً، عندما يتم عرض الفائز في مزاد داخل إطار Fenced Frame، تتضمّن أهداف الخصوصية المتعلقة بالجمهور المحمي عرض المواد الإبداعية الناتج بدون معرفة السياق: إنّ عنوان URL للصفحة المحيطة أو ملف تعريف الارتباط الخاص بالطرف الأول يشكّل انتهاكًا للخصوصية. وفي هذه البيئة، لا يكون بالإمكان إجراء مزاد متداخل. ثانيًا، ينص نموذج "الجمهور المحمي" على أنه يجب أن يستند الفائز في كل مزاد إلى بيانات مستمدة من موقع إلكتروني إضافي واحد فقط. وستكون المزادات المتداخلة طريقة لتجميع ذلك، ما يؤدّي إلى إمكانية اختيار الإعلانات استنادًا إلى ملف شخصي لعدة مواقع إلكترونية. |
| معيار البيانات عند عدم النشاط | اشرح بشكل أكبر معيار البيانات الساكنة في نموذج الثقة في خدمة المفتاح/القيمة. | يتم تحميل البيانات الموجودة في "خدمة القيمة الرئيسية" في الذاكرة وعرضها من هناك بدلاً من إجراء أي تخزين مؤقت للقراءة. |
| إشارة بيانات المشتري | هل هناك حد أقصى محدَّد لحجم إشارات buyer_data التي يتم تلقّيها من أنظمة عرض البيانات (DSP)؟ |
ما مِن حدود مفروضة من المتصفِّح حاليًا على إشارات buyer_data
التي يتم تلقّيها من أنظمة معالجة البيانات (DSP). |
قياس أداء الإعلانات الرقمية
Attribution Reporting (وواجهات برمجة التطبيقات الأخرى)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| باستخدام أكثر من جهاز واحد | التخطيط للحصول على الدعم على جميع الأجهزة لواجهة Attribution Reporting API | يمثل استخدام أكثر من جهاز واحد تحديات خصوصية جديدة على أجهزة 3PC، كما أنه يضيف تحديات في توزيع التكنولوجيا بالنظر إلى مجموعة الأجهزة والأنظمة الأساسية التي قد يستخدمها المستخدم. نحن نستكشف الحلول المحتملة، لكننا نركّز على حالات الاستخدام المُهمّة التي تتوافق معها حاليًا تقارير تحديد المصدر ولا نخطط لتقديم ميزة الدعم على جميع الأجهزة قبل إزالة ملفات تعريف الارتباط التابعة لجهات خارجية. |
| (تم الإبلاغ أيضًا في الأرباع السابقة) حجم بيانات المشغِّل |
لماذا يقتصر حجم بيانات المشغِّل على 3 بت؟ | يقتصر الحجم على 3 وحدات بت و8 قيم مختلفة لضمان الحدّ من مقدار المعلومات على مستوى عدة مواقع إلكترونية والسياق المتعلق بالمستخدم. نرحّب بجهات الفاعلة في المنظومة المتكاملة لإرسال الملاحظات حول ما إذا كانت المَعلمات الحالية لإعداد التقارير على مستوى الحدث كافية. |
| مسار الإحالة الناجحة | الإبلاغ عن نطاقات متعددة تم استخدامها في الإحالة الناجحة | حالة الاستخدام هذه ممكنة منذ إضافة وجهات متعددة. نرحّب بالملاحظات الإضافية. |
| النطاق نفسه في الدعم في بلد مختلف | هل تعمل ميزة "إعداد تقارير الإحالة" مع المواقع الإلكترونية التي لها نفس النطاق ولكن "نطاقات TLD" متعددة البلدان؟ | تمت مناقشة هذه المشكلة وحلها مع الطرف المعني الذي أثار السؤال. إذا احتاجت تقنية الإعلان إلى استخدام نطاقات المستوى الأعلى (TLD) في بلدان متعددة، ستحتاج إلى عمليات تسجيل متعددة، تسجيل واحد لكل نطاق مستوى أعلى في البلد. |
| تقارير محمية للجمهور وتحديد المصدر | هل يمكن لتكنولوجيا الإعلان الوصول إلى الإحالات الناجحة بعد رؤية الإعلان فقط في مزادات الجمهور المحمي، فضلاً عن الإحالات الناجحة الناتجة عن النقر في "تقارير تحديد المصدر"؟ | نعم، من المفترض أن تتيح "مبادرة حماية الخصوصية" كلاً من الإحالات الناجحة بعد رؤية الإعلان فقط (VTC) والشفافية في البطاقة ضمن Protected Audience API. |
| تأخيرات التقارير المجمَّعة | تقليل التأخيرات في تقارير التجميع بشكل أكبر. | لقد تلقّينا ملاحظات حديثة بشأن هذا الموضوع وشاركنا الأفكار هنا. ويسرّنا تلقّي ملاحظات إضافية من المنظومة المتكاملة. |
| تأخيرات التقارير المجمّعة | الحد من حالات التأخير عن طريق تقديم توسط الخادم. | ندرس هذا الاقتراح ونرحّب بأي ملاحظات إضافية . |
| حالات التأخير في التقارير على مستوى الحدث | تقليل حالات التأخير في التقارير على مستوى الحدث | إنّ الاقتراح الكامل المرن على مستوى الحدث والموضّح في عمليات الضبط المرنة على مستوى الحدث يمكن أن يقلل حالات التأخير في إعداد التقارير على مستوى الحدث إلى ساعة واحدة من خلال موازنة التشويش. |
| أصل إعداد تقارير المصادر حسب المصدر | إنّ الحدّ الأقصى لأصول إعداد التقارير للمصادر لكل موقع إلكتروني لإعداد التقارير يمنع تقنيات الإعلان من تسجيل مصادر من مصادر إعداد تقارير مختلفة لمصدر واحد لناشر واحد. | وقد تمت مناقشة ذلك مع الطرف المعني الذي طرح المشكلة، ويتم اختبار حل محتمل لاستخدام مصدر واحد لإعداد التقارير لكل موقع من مواقع إعداد التقارير قبل تجربة الحلول المحتملة الأخرى التي تتضمن عمليات إعادة توجيه. نحن مستعدون أيضًا لأيّ ملاحظات إضافية بشأن المنظومة المتكاملة بشأن هذا الحدّ. |
| الإبلاغ عن المشاكل | كيف يمكننا إبلاغ Chrome بالأخطاء أو المشاكل المتعلّقة بواجهة Attribution Reporting API؟ | في الوقت الحالي، ننصح خبراء تكنولوجيا الإعلان بالإبلاغ عن أي أخطاء في Attribution Reporting API قد تواجهها كمشكلة على GitHub. وإذا كان المستخدمون يواجهون مشكلة متعلّقة بـ Chrome، ننصحك بإنشاء خطأ في Chromium. يمكن العثور على روابط تؤدي إلى كيفية الإبلاغ عن أي مشاكل ومكان الإبلاغ عنها في قسم التفاعل ومشاركة الملاحظات. |
| التكرارات | كيف يمكننا إزالة تكرار الإحالات الناجحة عبر مسارات التعلّم والأجهزة المختلفة؟ | يُعَدّ التكرار على مستوى الأجهزة ومسارات القياس تحديًا معروفًا وحديثًا تواجهه تكنولوجيا الإعلانات اليوم أيضًا مع الشركات التابعة لجهات خارجية. باستخدام
Attribution Reporting API، يمكن لتكنولوجيا الإعلان تحديد الوقت المناسب لتسجيل
إحالات ناجحة محدّدة وإضافة بيانات وصفية محدّدة للإشارة إلى
مسارات القياس التي استخدمتها لتتبُّع الإحالات الناجحة (بعبارة أخرى،
جزء من مفتاح التجميع)، والتي يمكن مقارنتها
بمسارات القياس الأخرى. نحن مستعدون لتلقّي أي ملاحظات إضافية بشأن المنظومة المتكاملة في هذا الخصوص. |
| إزالة التكرار والأولوية | اطلب إعطاء الأولوية قبل إزالة التكرار. | ندرس هذا الطلب ونرحّب بأي ملاحظات إضافية. |
| مكافحة الاحتيال | خطر تلاعب مستخدم ضار بالبيانات على مستوى الحدث. | لا يمكن استخدام ميزة التحقّق من التقارير في إعداد التقارير على مستوى الحدث للأسباب الموضحة في المقالة لماذا لا تتوافق هذه الميزة مع التقارير على مستوى الحدث؟. |
| نوع الإحالة الناجحة | كيف يمكننا التمييز بين عرض الإعلان والتنقل في تقارير الإحالة؟ | في ما يلي خيار الفلترة المضمّن: source_type.
تتوفّر تفاصيل إضافية هنا. |
خدمة التجميع
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| استرداد الميزانية | طلبت بعض تقنيات الإعلان إمكانية إعادة معالجة التقارير في الحالات التي يحدث فيها إخفاق أو أخطاء أو عمليات حذف للتقارير. | يستكشف الفريق طرقًا لمعالجة هذا الأمر بطريقة تحافظ على الخصوصية. |
| تسجيل الموقع | طلبت تقنيات إعلانات متعددة دعمًا لمعالجة مصادر متعددة في الحساب نفسه لحالات استخدام مثل تقسيم البيانات حسب الموقع الجغرافي، المعلِن. ومن المتوقّع حدوث هذا السلوك أيضًا من خلال تكنولوجيا الإعلان نظرًا لأن عملية التسجيل في واجهة برمجة التطبيقات للعميل أصبحت الآن مستندة إلى الموقع الإلكتروني (وليس مستندة إلى المصدر). يؤدي الانتقال من نقطة الانطلاق إلى التسجيل في الموقع الإلكتروني إلى تبسيط عملية إعداد تكنولوجيا الإعلان من خلال التوافق مع عملية تسجيل العملاء. | سنُطلق قريبًا عملية نقل من التسجيل في المصدر إلى تسجيل المواقع الإلكترونية في "خدمة التجميع" ونرحب بالملاحظات من المنظومة المتكاملة. |
| خطة الإصدار والإيقاف | الجدول الزمني لإصدار وإيقاف ميزات خدمة التجميع والتصحيحات التي تم نشرها. وتهدف هذه الخطة إلى منح أدوات تكنولوجيا الإعلان معلومات حول سياسات الإصدار لديها لتمكينها من الاستعداد للإصدارات والإيقافات القادمة، وضمان تشغيل إصدارات مستقرة وآمنة من الخدمات. | لقد نشرنا مؤخرًا اقتراحًا لخطة إصدار وإيقاف خدمة التجميع ونرحب بملاحظات إضافية. |
| المنسّقون | ماذا يحدث إذا انتقل المنسقون إلى خدمة التجميع؟ | ينبغي أن يكون كلا المنسقين متاحين بالكامل حتى يعمل النظام
بشكل صحيح. تتم استيعاب عدم التوافر القصير مع عمليات إعادة المحاولة في مكتبات العملاء لدينا؛ حيث سيؤدي عدم توفر أي من المُنسقين إلى فشل مهام التجميع. يمكن إعادة تشغيل الوظائف إذا لم يتم استهلاك ميزانية الخصوصية بعد. في حال أدّى أي إخفاق في الخدمة إلى استهلاك الميزانية بدون تقرير ملخّص مكتوب في مساحة تخزين تكنولوجيا الإعلان، نقترح حاليًا استخدام تقارير تصحيح الأخطاء لاسترداد النتائج باستخدام أداة الاختبار المحلية. نعمل أيضًا على تطوير ميزات تتيح استرداد الميزانية في حال تعذُّرها، ما يتيح لتقنيات الإعلانات إعادة تشغيل وظائفها. |
واجهة برمجة التطبيقات الخاصة بالتجميع الخاص
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| عنوان URL الخاص بفقاعة البيانات | طلب إتاحة عنوان URL الخاص بكائن Blob في مساحة التخزين المشتركة. | تمت إتاحة عنوان URL لكائن Blob في الإصدار M116 من Chrome. |
الحدّ من التتبُّع السري
تقليل عدد وكيل المستخدم وتلميحات برنامج وكيل المستخدم
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| JavaScript API | مدى توفُّر واجهة برمجة تطبيقات User Agent Client Hints JavaScript API | ولا نخطط لإزالة هذه الوظيفة لأنّها تمثّل الحل الأساسي للشركاء الذين يريدون الوصول بفاعلية إلى البيانات التي تتضمّن نسبة عالية من الإنتروبيا بشكلٍ يتجاوز ما هو متاح تلقائيًا في Universal Analytics المجمّدة والمخفَّضة. |
| معلومات الجهاز وشكل الجهاز | قدرة مواقع الويب على فهم المدخلات والمخرجات والمعلومات الأخرى التي يمكن أن يدعمها الجهاز الذي يزور موقع الويب. | لقد أضفنا المساعدة بشأن هذا الطلب بالاستناد إلى الملاحظات التي تلقّيناها من المنظومة المتكاملة. |
حماية IP (المعروفة سابقًا باسم Gnatcatcher)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| الزيارات المؤهَّلة التابعة لجهات خارجية | ما الذي تشير إليه "الزيارات الواردة من جهة خارجية المؤهّلة" في الشرح؟ | نحن ندرك أهمية هذا السؤال ونعمل جاهدين على تحديد زيارات الجهات الخارجية التي ستكون مؤهَّلة وتلك التي لن تكون مؤهّلة. نرحّب بملاحظات حول هذا الموضوع. |
| عمليات تدقيق حركة بيانات الشبكة | دعم المؤسسات لإجراء عمليات تدقيق لحركة مرور بيانات الشبكة في شبكاتها. | لن تتأثّر سوى زيارات الجهات الخارجية المضمَّنة في مواقع الطرف الأول، ما من المفترض أن يحدّ من عدد الزيارات التي تتطلّب إجراء فلترة. بالإضافة إلى ذلك، ونخطط لمنح المستخدمين خيار استخدام حماية IP أم لا، وبالنسبة إلى Chrome الذي تتحكم فيه المؤسسات، ستكون هناك سياسات مؤسسة لإيقاف حماية IP. وأخيرًا، فإننا نستكشف عناصر التحكم (إن وجدت) التي سيتم توفيرها لمشغلات الشبكات لإيقاف حماية IP. نرحّب بملاحظات حول هذا الموضوع |
| التحكّم في إمكانية الوصول | وقد تؤثر حماية IP في خدمات الويب التي تستخدم عناوين IP للتحكم في الوصول. | نحن ندرك أهمية حالات الاستخدام المتعلقة بمكافحة الاحتيال والتأثير المحتمل على حالات الاستخدام هذه. إننا نسعى للحصول على ملاحظات من المنظومة المتكاملة حول كيفية توفير الدعم بشكل أفضل لحالات الاستخدام المتعلّقة بمكافحة الاحتيال التي تعتمد عادةً على عناوين IP. |
| التواصل بين الخوادم الوكيلة ثنائي الاتجاه | كيفية التأكد من عدم وجود معلومات بين الخوادم الوكيلة. | نحن بصدد تصميم تفاعلات الوكيل. وهدفنا هو تقليل فرص مشاركة هذه المعلومات عبر الوسائل التجارية والعملياتية والتقنية. |
| مصادقات غير تابعة لشركة Google | إتاحة المصادقات غير التابعة لشركة Google. | نخطط لنشر المزيد من التفاصيل حول مصادقة الحساب في المستقبل، على الرغم من أننا شاركنا بعض الاعتبارات الأولية. |
| تصنيف جهاز التتبُّع | كيف ستحدِّد ميزة "حماية IP" ما يُشكّل أداة التتبُّع وخياراتها؟ | نحن ندرك أهمية هذا السؤال ونعمل جاهدين على تحديد زيارات الجهات الخارجية التي ستكون مؤهَّلة وتلك التي لن تكون مؤهّلة. نرحّب بملاحظات حول هذا الموضوع. |
| الإحصاءات | قد تؤثر حماية بروتوكول الإنترنت (IP) في دقة خدمات التحليل. | نتطلع إلى فهم تأثير حماية الملكية الفكرية بشكل أكبر، ونرحب بالملاحظات والأمثلة الإضافية من المنظومة المتكاملة. |
| الخادم الوكيل | إذا كان المستخدم يستخدم وكيلاً أو حدد خادمًا وكيلاً يدويًا، فكيف سيعمل قناع IP في هذه الحالة؟ | نحن نتطلع إلى فهم التأثير الذي قد تحدثه حماية IP على الخوادم الوكيلة الأخرى. ليس لدينا أي خطط لمشاركتها في الوقت الحالي. نرحب بالملاحظات حول هذا الموضوع. |
| خطة مميّزة | هل ستكون "حماية IP" ميزة مدفوعة؟ | ستتوفّر ميزة "حماية IP" لمستخدمي Chrome كجزء من تجربة المتصفّح الأساسية. لن تكون ميزة مدفوعة. |
| الخادم الوكيل | هل سيتم استخدام الخوادم الوكيلة نفسها أثناء جلسات المستخدم؟ | سيستخدم اتصال HTTP/S زوجًا واحدًا من الخوادم الوكيلة وسيقدم عنوان IP واحدًا مقنعًا في المصدر. علاوة على ذلك، ليست هناك قيود صارمة على اتصالات HTTP/S المختلفة التي يتعين عليها استخدام نفس الخوادم. |
| دعم النظام الأساسي | على أي نظام أساسي سيتم دعم الحماية من بروتوكول الإنترنت (IP)؟ | ستتوفّر ميزة "حماية IP" مبدئيًا على أجهزة Chrome لأجهزة Android وأجهزة الكمبيوتر المكتبي. ونواصل تقييم كيفية توسيع نطاق الحماية ليشمل منصات أخرى. |
| إيقاف | هل سيتمكن المستخدمون من إيقاف حماية عنوان IP؟ | ونسعى إلى أن نتيح للمستخدمين خيار استخدام حماية IP أو عدمه. |
| إخفاء الهوية | ما أنواع الطلبات التي سيتم إخفاء هوية صاحبها بموجب حماية عنوان IP؟ | يتم إخفاء هوية طلبات HTTP/S ونظام أسماء النطاقات للنطاقات المؤهلة التابعة لجهات خارجية باستخدام الخوادم الوكيلة للخصوصية. سنقدّم تفاصيل إضافية في الشرح القادم حول كيفية تحديد النطاقات التي سيتم تضمينها. لن يتأثر باقي حركة البيانات (على سبيل المثال، باقي طلبات نظام أسماء النطاقات أو حركة بيانات HTTP/S الأخرى). |
| إمكانية رؤية البيانات | يمكن الوصول إلى عناوين الشبكة خلال أول خطوة في خدمة "حماية IP". | في نموذج الخادم الوكيل المكوَّن من نقطتين، لا ترى القفزة الأولى (التي تتحكم فيها Google) إلا عنوان IP للعميل المصدر وطلب الاتصال بالقفزة الثانية، في حين لا ترى القفزة الثانية (التي يتم التحكم فيها من خلال شبكة توصيل محتوى خارجي) سوى صفًا في القفزة الأولى (عنوان IP الوكيل + المنفذ) وعنوان IP الوجهة. بالنسبة إلى الردّ من المصدر، يمكن للقفزة الثانية إعادة توجيه الاستجابة إلى منفذ الخادم الوكيل +القفز الأول المرتبط بالطلب ولا تحتاج إلى معرفة أي معلومات عن عنوان IP للعميل الأصلي (وتُرجع القفزة الأولى الرد إلى العميل فقط بدون معرفة أي معلومات عن عنوان IP الوجهة). بهذه الطريقة، لن تتعرّف القفزة الأولى سوى على عنوان IP للعميل والقفزة الثانية، بينما لا تتعرّف القفزة الثانية إلا على عنوان IP الوجهة. |
| WebView | هل ستتوفّر ميزة "حماية IP" لمكوّن Android WebView في المستقبل؟ | ليس لدينا أي خطط لمشاركتها في الوقت الحالي، ولكن رؤيتنا هي توفير هذه الحماية على أوسع نطاق ممكن. |
الحدّ من التتبُّع الارتدادي
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| تتبُّع التفاعل | كيف يتم تتبع تفاعلات المستخدم؟ | تتتبّع إجراءات الحدّ من التتبّع الارتدادي نوعَين من تفاعلات
المستخدم:
ترتبط هذه التفاعلات بالموقع الإلكتروني من المستوى الأعلى في الصفحات التي تحدث فيها. على سبيل المثال، إذا نقر أحد المستخدمين في إطار iframe مضمّن، يكون التفاعل مرتبطًا بموقع المستوى الأعلى وليس بالموقع الإلكتروني المضمّن. يتم تخزين التفاعلات في قاعدة بيانات تحتوي على دالة etld+1 ووقت التفاعل. تحمي التفاعلات النطاق المرتبط من حذف حالة تتبُّع الارتداد لمدة 45 يومًا. |
| الإعفاءات المدرَجة في القائمة المسموح بها | هل يمكن استثناء النطاقات؟ | ندرس هذا الطلب ونرحب بأي ملاحظات إضافية من المنظومة المتكاملة. |
ميزانية الخصوصية
لم يتم استلام أي ملاحظات في هذا الربع من العام.
تعزيز حدود الخصوصية على مواقع إلكترونية متعددة
مجموعات المواقع الإلكترونية المرتبطة (المعروفة سابقًا باسم مجموعات نطاقات الطرف الأول)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| النهج المركزي | قلق بشأن منهج المستودع المركزي لإدارة مجموعات المواقع الإلكترونية المرتبطة. | ويُعد المستودع العام الذي يسهل الوصول إليه عاملاً أساسيًا لتصميم RWS لأنه يوفر المساءلة عن عمليات الإرسال. يتم توفير وظائف ملفات تعريف الارتباط التابعة لجهة خارجية في النهاية من خلال استخدام واجهة برمجة التطبيقات Storage Access API أو rSAFor API، حيث توفّر عضوية RWS إمكانية الوصول الممنوح تلقائيًا (على عكس الطلبات الواردة من Storage Access API). نعتقد أنّ نهجًا مثل عملية إرسال RWS هو من المتطلبات المناسبة للوصول تلقائيًا إلى ملفات تعريف الارتباط التابعة لجهات خارجية. |
| جارٍ إعادة تسمية ملف json | مع التغيير في اسم واجهة برمجة التطبيقات، هل يجب تغيير اسم ملف JSON المستضاف؟ | نعم، تم تغيير إرشادات الإرسال، ويجب أن يعرض النطاق الأساسي ملف JSON على /.well-known/related-website-set.json. ليس عليك تغيير المجموعات الحالية في قائمة RWS، ولكن في حال كانت هناك تعديلات على المجموعات الحالية، يجب تغيير ملف JSON. |
| (تم الإبلاغ أيضًا في الأرباع السابقة) حد النطاق | طلب زيادة عدد النطاقات المرتبطة | كما أعلنّا في 31 آب (أغسطس)، رفعنا حد النطاقات المرتبطة إلى خمسة نطاقات بعد الحصول على ملاحظات وآراء من المنظومة المتكاملة. قررنا زيادة حد النطاقات المرتبطة إلى خمسة نطاقات (بالإضافة إلى نطاق أساسي واحد) الذي يتطابق على أفضل نحو مع عملية التنفيذ الأكثر قابلية للمقارنة التي يوفرها متصفّح رئيسي آخر. |
| ملفات تعريف الارتباط التابعة لجهات خارجية | هل ستعمل "مجموعات المواقع الإلكترونية المرتبطة" فقط مع ملفات تعريف الارتباط التابعة للجهات الخارجية التي تم إيقافها؟ | وستعمل مجموعات المواقع الإلكترونية المرتبطة حتى إذا لم يحظر المستخدم ملفات تعريف الارتباط التابعة لجهات خارجية، ولكن لن يكون هناك أي تأثير ملحوظ لأنّ ملفات تعريف الارتباط ذات الصلة متاحة بدون الحاجة إلى "مجموعة المواقع الإلكترونية المرتبطة" وواجهة برمجة التطبيقات Storage Access API. |
| التعديلات المشروعة | كيف يمنع مستودع "مجموعات المواقع الإلكترونية المرتبطة" غير المالكين من تعديل المجموعات؟ | وفقًا لأدلة الإرسال، يمكن لأي مستخدم إرسال نسخة عامة على GitHub لتعديل ملف first_party_sets.JSON. ومع ذلك، إذا تمت الموافقة على الإصدار التجريبي (يجتاز عمليات التحقق الفنية، وهكذا)، سيتم دمجه يدويًا على دفعات إلى قائمة عدد اللقطات في الثانية الأساسية مرة واحدة في الأسبوع (أيام الثلاثاء عند الساعة 12 ظهرًا بالتوقيت الشرقي) بواسطة Google.وإذا حاولت جهة مسيئة تعديل مجموعة لا يملكها، من المفترض ألا تكون هناك مشكلة لأنّه لن يكون بإمكانها تعديل ملفات .well-known، وبالتالي لن تنجح عمليات التحقق. |
| الاستيلاء على النطاق | قد يؤدي الاستيلاء على النطاق إلى الكشف عن بيانات النطاق ذات الصلة لأطراف غير مصرّح بها. | هذا غير ممكن، كما هو موضَّح في مشكلة GitHub ضمن Protected Audience. |
واجهة برمجة تطبيقات Fenced Frames
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| مخالفة محتوى | السماح للمستخدمين بالإبلاغ عن الإعلانات المريبة. | ولا تمنع ميزة Fenced Frames إعداد تقارير الإعلانات المريبة. لا يزال بإمكان المستخدمين التفاعل مع الإعلان والإبلاغ عن الإعلانات المريبة إلى تقنية الإعلان بالطريقة المعتادة. |
| التفاعل مع المواقع المحيطة | السماح بالتفاعل مع موقع الويب المحيط أو الموقع الإلكتروني ذي المستوى الأعلى. | نتطلع إلى فهم سبب أهمية هذا الطلب ونرحب بالملاحظات الإضافية من المنظومة المتكاملة. |
| الإعلان المدمج مع المحتوى | إتاحة ميزة Fenced Frame للإعلانات المدمجة مع المحتوى | وندرس دعم حالة الاستخدام ونناقش الحلول والحلول الممكنة. |
واجهة برمجة تطبيقات مساحة التخزين المشتركة
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| على جميع النطاقات | السماح بالاتصال عبر النطاقات للتخزين المحلي. | لا تتوافق حالة الاستخدام هذه حاليًا مع بوابات الإخراج التي تحافظ على الخصوصية في مساحة التخزين المشتركة، ولكننا نرحب بسياق إضافي في إطار تطوير اقتراحات بشأن مساحة التخزين غير المقسَّمة. |
| عنوان URL الخاص بفقاعة البيانات | طلب إتاحة عنوان URL الخاص بكائن Blob في مساحة التخزين المشتركة. | تمت إتاحة عنوان URL لكائن Blob في الإصدار M116 من Chrome. |
الشرائح
لم يتم استلام أي ملاحظات في هذا الربع من العام.
FedCM
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| ملفات تعريف الارتباط التابعة لجهات خارجية | هل تم إيقاف خدمة FedCM حاليًا إذا فعّل المستخدمون "حظر ملفات تعريف الارتباط للجهات الخارجية" في إعدادات Chrome؟ | نعم، خدمة FedCM غير مفعّلة حاليًا. لإجراء الاختبار، ننصحك بتفعيل
chrome://flags/#fedcm- أيضًا.نحن نعمل على إتاحة FedCM بدون ملفات تعريف الارتباط التابعة لجهات خارجية في المستقبل. |
مكافحة المحتوى غير المرغوب فيه والاحتيال
واجهة برمجة التطبيقات للرمز المميز للحالة الخاصة (وواجهات برمجة التطبيقات الأخرى)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| انتهاء صلاحية الرمز المميّز | بعد إلغاء تثبيت Google Chrome، هل سيتم فقدان الرمز المميّز أم سيتم تخزينه مؤقتًا؟ | سيتم فقدان الرمز المميّز إذا ألغى المستخدم تثبيت Google Chrome. |
| معلومات الرمز المميّز | كيف يمكن لجهات الإصدار الحفاظ على خصوصية المعلومات التي يتم إصدارها ضمن الرمز المميز للحالة الخاصة؟ | ويتم دائمًا الحفاظ على خصوصية المعلومات في الرمز المميّز ولا يمكن تشفيرها من خلال جهات خارجية لا تملك المفاتيح. |
| خطأ في العرض التوضيحي | حدث خطأ عند محاولة تشغيل الإصدار التجريبي للرمز المميّز للحالة الخاصة. | لقد حدّثنا العرض التوضيحي ومن المفترض أن يعمل بشكل صحيح. |