تقرير ربع سنوي للربع الثالث من عام 2023 يلخّص الملاحظات التي تمّ تلقّيها بشأن منظومة الإعلانات المتكاملة حول عروض "مبادرة حماية الخصوصية" وردّ Chrome عليها.
كجزء من التزاماتها بموجب "قانون معالجة المعاملات"، وافقت Google على تقديم تقارير ربع سنوية علانية عن عملية تفاعل الجهات المعنية باقتراحات "مبادرة حماية الخصوصية" (يُرجى الرجوع إلى الفقرتين 12 و17(ج)(2) من الالتزامات). يتم إنشاء تقارير الملخّصات هذه حول الملاحظات والآراء بشأن "مبادرة حماية الخصوصية" من خلال تجميع الملاحظات والآراء التي تلقّاها Chrome من المصادر المختلفة كما هو موضّح في نظرة عامة على الملاحظات والآراء، بما في ذلك على سبيل المثال لا الحصر: GitHub المشاكل، ونموذج الملاحظات والآراء المتاح على privacysandbox.com، والاجتماعات مع الجهات المعنية في المجال، ومنتديات معايير الويب. يرحّب فريق Chrome بالملاحظات التي يتم تلقّيها من المنظومة المتكاملة ويستكشف بنشاط طرق دمج الدروس المستفادة في قرارات التصميم.
يتم ترتيب مواضيع الملاحظات حسب معدّل تكرارها لكل واجهة برمجة تطبيقات. ويتم ذلك من خلال جمع ملاحظات فريق Chrome حول موضوع معيّن وتنظيمها بترتيب تنازلي حسب الكمية. تم تحديد مواضيع الملاحظات المشترَكة من خلال مراجعة مواضيع المناقشة من الاجتماعات العامة (W3C وPatCG وIETF) والملاحظات المباشرة وGitHub والأسئلة الشائعة التي تظهر من خلال الفِرق الداخلية في Google والنماذج العامة.
وعلى وجه التحديد، تمت مراجعة محاضر اجتماعات الهيئات المسؤولة عن معايير الويب، وبالنسبة إلى الملاحظات المباشرة، تمّت مراجعة سجلّات Google لاجتماعات الجهات المعنيّة وجهًا لوجه، والرسائل الإلكترونية التي تلقّاها المهندسون الفرديون، وقائمة البريد الإلكتروني لواجهات برمجة التطبيقات، ونموذج الملاحظات العلني. بعد ذلك، نسّقت Google بين الفِرق المشاركة في أنشطة التواصل المختلفة هذه لتحديد مدى رواج المواضيع التي تظهر في ما يتعلّق بكل واجهة برمجة تطبيقات.
تم تطوير تفسيرات ردود Chrome على الملاحظات من خلال عناوين الأسئلة الشائعة والمنشورة، والردود الفعلية التي تم تقديمها على المشاكل التي طرحها أصحاب المصالح، وتحديد وجهة نظر خاصة لأغراض هذا التمرين الخاص بإعداد التقارير العلنية. استنادًا إلى التركيز الحالي على التطوير والاختبار، تلقّينا أسئلة وملاحظات خاصةً بشأن واجهات برمجة التطبيقات Topics API وProtected Audience 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 |
|---|---|---|
| مدى الجاهزية للمنظومة المتكاملة | أشارت منصّات عرض الإعلانات إلى قلقها بشأن عدم جاهزية الناشرين وعدم تنفيذهم لأعمال النشر المطلوبة. | تركّز "مبادرة حماية الخصوصية" على التواصل مع الناشرين لتعريفهم على المبادرة، ويشمل ذلك برامج تعليمية على الويب واجتماعات مخصّصة مع الناشرين وخدمات عرض الإعلانات لتعزيز عمل نشر الإصدارات. |
| الإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية | ازدياد المخاوف بشأن الإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية في الربع الرابع من العام 2023 بسبب انقطاع الخدمة في مجال التكنولوجيا | لقد ناقشنا المخطط الزمني لـ "مبادرة حماية الخصوصية" مع هيئة المنافسة والأسواق (CMA)، وسيتم تنفيذ الخطوات اللازمة للاستعداد لطرحها في النصف الثاني من عام 2024. ستنشر "مبادرة حماية الخصوصية" معلومات أكثر تفصيلاً حول تسلسل زيادة استخدام 3PCD. بموجب "الالتزامات"، يخضع "الاستئجار الثلاثي للمركبات" لمعالجة "هيئة المنافسة والأسواق" (CMA) لمشاكل المنافسة. |
| مدير إعلانات Google | يرفض "مدير إعلانات Google" عرض واجهة برمجة التطبيقات، ما يجعل الاختبار صعبًا. | الردّ المقدَّم من "مدير إعلانات Google": للسببَين الموضّحتَين في هذا الردّ المقدَّم من "مدير إعلانات Google"، لا تتضمّن خطط "مدير إعلانات Google" لدمج واجهة برمجة التطبيقات Protected Audience API إتاحة استخدام خادم إعلانات الناشر من Google بدون التحكّم في مزاد المستوى الأعلى. |
| مدير إعلانات Google | يتضمّن "مدير إعلانات Google" حدًّا أدنى سريًا للسعر لا يتم عرضه إلا في AdX أو منصّات عرض الإعلانات التي تستخدم عروض الأسعار المفتوحة. | تشير المستندات العامة لمدير إعلانات Google إلى أنّه يتمّ تمرير الفائز في المزاد السياقي
إلى منطق التقييم على مستوى أعلى وليس
إلى أيّ مزاد مكوّن، بما في ذلك AdX أو عروض الأسعار المفتوحة. بالإضافة إلى ذلك، تشير هذه المستندات إلى منطق التقييم على مستوى أعلى: "سيقارن "مدير إعلانات Google" عرض السعر الفائز لكل مزاد مكوّن، بما في ذلك مزاد المكوّن الخاص بخدمة "مدير إعلانات Google" لعروض أسعار مجموعات الاهتمامات لمشترييها، بالإضافة إلى أفضل إعلان سياقي (يتم اختياره من خلال التخصيص الديناميكي)، وسيعرض الإعلان الذي يتضمن أعلى عرض سعر". |
| مدير إعلانات Google | يجب أن تخضع منتجات "إعلانات Google" للقواعد نفسها التي تخضع لها منتجات الإعلانات التابعة لجهات خارجية. | تخضع منتجات "إعلانات Google" حاليًا للقواعد نفسها التي تخضع لها الجهات الخارجية. |
| الاختبار الذي يسهّله متصفّح Chrome | أضِف تصنيفات للمتصفّحات التي لا تندرج ضمن الفئتَين "أ" أو "ب". | لا ننوي إجراء ذلك في الوقت الحالي، لأنّ التحقيق الذي أجريناه أظهر أنّ إضافة تصنيفات غير تجريبية قد تؤدي إلى تعقيد مخاوف تتعلّق بالخصوصية بشأن الزيارات في وضع التصفّح المتخفي. |
| وكالة إعلانية | هل يمكن للوكالات أو الشركات التي لا تستخدم JavaScript على المواقع الإلكترونية استخدام واجهات برمجة تطبيقات Privacy Sandbox API؟ | يمكن لأي مستخدم استدعاء واجهات برمجة تطبيقات "مبادرة حماية الخصوصية". إذا أرادت وكالة أو أي جهة أخرى إنشاء تكنولوجيات مباشرةً على واجهات برمجة التطبيقات، يمكنها ذلك. تتطلّب واجهات برمجة التطبيقات من جهة العميل الدمج مع العميل، تمامًا كما تتطلّب ملفات تعريف الارتباط. تتضمّن العديد من واجهات برمجة التطبيقات أيضًا واجهة عنوان HTTP، مثل ملفات تعريف الارتباط. لقد رأينا إطار عمل واحدًا في مجال الإعلانات، وهو Prebid، يُنشئ عمليات دمج من جهة العميل مع واجهات برمجة التطبيقات. ويمكن للمؤسسات الأخرى اتّباع الإجراء نفسه. |
| الحلول من جهة العميل | لماذا تتّبع Google حلولًا من جهة العميل في "مبادرة حماية الخصوصية" عندما أبدى أحد المهندسين قلقه سابقًا بشأن قابلية توسيع نطاق هذه الحلول في عام 2012؟ | شهد مجال تكنولوجيا تعزيز الخصوصية (PET) تطورًا كبيرًا منذ عام 2012، وتطوّرت معه التطبيقات التي يمكن استخدامها تجاريًا. تعتمد "مبادرة حماية الخصوصية" على مجموعات من تقنيات معالجة البيانات الشخصية التي لم تكن متاحة قبل أكثر من عقد من الزمن. بالإضافة إلى ذلك، زادت قدرة أجهزة الكمبيوتر الشخصية، وكذلك توقعات المستهلكين للمتصفّحات وتوقعات الجهات التنظيمية للخصوصية. |
| تعلُم الآلة | ما هو الاستخدام المخطّط لخدمة "مبادرة حماية الخصوصية" من قِبل Google لأغراض تعلُّم الآلة؟ | تستخدِم الكثير من المنظومة المتكاملة لتكنولوجيا الإعلان حاليًا تكنولوجيا تعلُّم الآلة، ولا نتوقع أن يتغيّر ذلك. لا تمنع "مبادرة حماية الخصوصية" شركات تكنولوجيا الإعلان أو أي شخص آخر من مواصلة استخدام تعلُّم الآلة. ولا تشترط "مبادرة حماية الخصوصية" أن تستخدم الشركات التي تتكامل مع واجهات برمجة التطبيقات تعلُّم الآلة. من المنطقي توقّع أن تواصل الشركات إنشاء المنتجات والخدمات بطرق تلبي احتياجات العميل ، سواء كان ذلك يتضمّن تعلُّم الآلة أم لا. إنّ أيّ نموذج تعلُّم آلي ينشئه مُدمِجو "مبادرة حماية الخصوصية" سيكون معروفًا لهم بوضوح، وبالتالي لن يكون مخفيًا عنهم. |
| إثبات صحة البيانات | كيف يمكن للشركات التأكّد من دقة البيانات التي تتلقّاها من استخدام "مبادرة حماية الخصوصية"، وهل تقبل Google أن تخضع لمراجعة من خلال جهة مثل "مجلس تقييم الوسائط" (MRC)؟ | تم إنشاء واجهات برمجة التطبيقات في "مبادرة حماية الخصوصية" ضمن المنصة المفتوحة المصدر التي تشغّل Chrome. إنّ أجزاء واجهات برمجة التطبيقات المخصّصة للتشغيل في Trusted Execution Environments (بيئات التنفيذ الموثوق بها) هي أيضًا مفتوحة المصدر ويمكن مراجعتها. يمكن لأي شخص يريد فحص الرمز، بما في ذلك "مجلس مراجعة المحتوى"، إجراء ذلك. |
| (تم الإبلاغ عن ذلك أيضًا في الربعَين السابقَين) دعم في مرحلة الإنتاج | ما هي العملية المتّبعة في Chrome لإتاحة "مبادرة حماية الخصوصية"؟ وما هي المشاكل الفنية وعمليات التصعيد التي تؤثّر في المنظومة المتكاملة؟ | توفّر Google مجموعة من القنوات للسماح لخبراء التكنولوجيا الإعلانية بالإبلاغ عن الصعوبات الفنية وتفعيل أي تصعيدات ضرورية لحلّ هذه الصعوبات. بالإضافة إلى ذلك، يتوقّع فريق Chrome مواصلة تطوير عملية حلّ المشاكل الفنية وعمليات التصعيد التي تؤثر في أداء المنظومة المتكاملة وتوسيع نطاقها. يلتزم فريق Chrome بتوفير الموارد اللازمة
لتحقيق هذا الهدف. يُرجى الاطّلاع على المنتديات العامة والخاصة للحصول على ملاحظات وتصعيد المشاكل. |
| أوضاع الاختبار المُبسَّطة في Chrome | مزيد من المعلومات حول المخططات الزمنية وعمليات التنفيذ الدقيقة لحال وضعات الاختبار التي تسهّلها Chrome | لقد شاركنا مشاركة في مدوّنتنا
حول أوضاع الاختبار، ونعمل على مشاركة المزيد من المعلومات قريبًا. نرحب بالاقتراحات بشأن حجم تصنيفات وضع الاختبار. |
| التكامل مع المعايير الأخرى المتّبعة في المجال | هل ستتّصل واجهات برمجة التطبيقات في "مبادرة حماية الخصوصية" بإطار الشفافية والموافقة بالإصدار 2.* أو "وضع الموافقة" أو كليهما؟ | لا نخطّط لدمج واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" مباشرةً مع الإصدار 2 من "إطار الشفافية والموافقة" أو "وضع الموافقة". ومع ذلك، يُرجى العلم أنّه يمكن للشركات والمجموعات التجارية في المجال تكييف منتجاتها وأطر عملها للعمل بالتزامن مع واجهات برمجة تطبيقات "مبادرة حماية الخصوصية". على سبيل المثال، في ما يتعلّق بالإطارات المرجعية، مثل إطار الشفافية والموافقة، على كل مشارك تحديد نهج الامتثال الخاص به، استنادًا إلى إشارة إطار الشفافية والموافقة التي يتلقّاها وسياسات إطار الشفافية والموافقة المرتبطة. نتوقّع أن تحدّد الشركات حالات استخدام وظائف المختلفة التي تقدّمها عناصر "مبادرة حماية الخصوصية" وكيفية استخدامها. |
التسجيل والإقرار
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| الشروط | تعني عملية التسجيل أنّه يمكن لشركة Google تحديد الشركة التي يُسمح لها باستخدام واجهات برمجة تطبيقات Privacy Sandbox API في المنظومة المتكاملة. | تتطلّب عملية التسجيل والإقرار بشكل أساسي إثبات هوية الجهة (على سبيل المثال، يجب أن يكون لدى الجهة رقم DUNs، ويمكنها تقديم رابط يؤدي إلى سياسة الخصوصية، وما إلى ذلك)، كما تجعل الشهادة العلنية شرطًا لطلب بيانات من واجهات برمجة التطبيقات. سيتم التحقّق من صحة الكيانات التي يمكنها استيفاء متطلبات التسجيل بنجاح. بالنسبة إلى الشركات التي لا تمتلك رقم DUNS، نقدّم عملية سريعة ومجانية مع شركة Dun & Bradstreet للحصول على رقم. ويهدف الإجراء إلى تحسين إجراءات حماية الخصوصية في واجهات برمجة التطبيقات (من خلال الخطوات التي ذكرناها للتو) وإضافة طبقة من الشفافية إلى واجهات برمجة تطبيقات "مبادرة حماية الخصوصية"، حتى تتمكّن الجهات المعنيّة من فهم مَن يستخدم واجهة برمجة التطبيقات التي يستخدمها ونوع بيانات الاعتماد التي يقدّمها بشكل أفضل. نحن منفتحون علىتلقّيمزيد من الملاحظات من الخبراء في المجال بشأن هذه المشكلة، والتي سبق أن تم استخدامها لتحديد العملية. |
| الوقت المستغرَق في إعادة التسجيل | تنتهي صلاحية ملف الشهادة كل 12 شهرًا، ويتطلّب من المواقع الإلكترونية إعادة التسجيل. | لقد أخذنا ملاحظات من المنظومة المتكاملة وعدّلنا نهجنا وفقًا لذلك. وهذا يعني أنّه لن تنتهي صلاحية الملفات بعد 12 شهرًا أو أي فترة زمنية محدّدة. نعمل على تعديل دليل المطوّر الخاص بالتسجيل لإضافة سياق إضافي. |
| ملف الإقرار | كيف يتم استخدام ملف الشهادة؟ | وبحلول الموعد النهائي لتنفيذ السياسة، على جميع الشركات التي تستدعي واجهات برمجة التطبيقات لقياس الأداء ومدى الصلة بالمواضيع تحميل ملف بيان المطابقة على
موقعها الإلكتروني وإتاحته للجميع ما دامت تنوي
مواصلة استدعاء واجهات برمجة التطبيقات. من المتوقّع أن تتلقّى المواقع الإلكترونية طلبًا واحدًا تقريبًا في الساعة من Privacy Sandbox، وقد تُجري كيانات محتملة أخرى طلبات بحث أيضًا. سيتم تنفيذ ذلك من خلال آلية نظام التسجيل الخاصة لاستعلام خوادم الكيانات المسجّلة والتأكّد من صلاحية ملف الإقرار. سيتم تضمين الإقرارات في تقارير الشفافية وسيكون بإمكان عموم الجمهور الاطّلاع عليها. نتوقع من الشركات اتّخاذ الإجراءات وفقًا لبيانات الإقرار التي تقدّمها، كما سيفعل باقي عناصر المنظومة والهيئات التنظيمية ذات الصلة. |
| التسجيل | هل يتم التسجيل لكل موقع إلكتروني أو لكل مصدر؟ | يتم التسجيل على مستوى الموقع الإلكتروني. |
عرض محتوى وإعلانات ذات صلة
المواضيع
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| الأداء | مخاوف بشأن الأداء في ما يتعلّق بتأثير معدّل تفعيل ميزة "المواضيع" في المنطقة الاقتصادية الأوروبية | ننصحك بالتواصل مع هيئة حماية البيانات ذات الصلة بهذه المشكلة. إنّهم في أفضل وضع لحلّ هذه المخاوف والتأثير في ما إذا كانت القوانين تشجع على استخدام تكنولوجيات تحسين الخصوصية أو تتعامل معها بدلاً من ذلك على أنّها تتضمّن عملية تتبُّع، ما يتطلّب الاعتماد على الأساليب نفسها للحصول على الموافقة. وقد يؤدي ذلك بدوره إلى عدم توفّر واجهات برمجة التطبيقات، مثل تلك الواردة في "مبادرة حماية الخصوصية"، بقدرٍ كبير. |
| التسجيل | هل يحتاج مقدّمو عروض الأسعار في مرحلة ما بعد المعالجة إلى التسجيل في Topics API لاستخدام إشارات Topics من منصّات عرض الإعلانات في مرحلة ما قبل المعالجة؟ | لا يلزم تسجيل مستلمي المواضيع في مرحلة ما بعد المعالجة الذين يستخدمون Topics API بدون استخدام واجهة برمجة التطبيقات الأولية، على الرغم من أنّه من المحتمل أن يتم تسجيل العديد منهم لاستخدام واجهة برمجة تطبيقات أخرى. سيتمّ تقديم قائمة بالمشتركين في "مبادرة حماية الخصوصية" بشكل آلي في إطار الجهود المبذولة لتعزيز شفافية البرنامج، ما سيتيح للمتصل المهتم باستخدام Topics API التحقّق مما إذا كان المستلِم الذي يرسل إليه موضوعًا مُدرَجًا في البرنامج، إذا أراد المتصل ذلك. |
| فلترة المواضيع | يمكنك طلب تطبيق فلترة أحد المتصلين الآخرين على المواضيع التي يتم استرجاعها على الصفحة، وذلك لمشاركة ما هو مؤهّل فقط للمشترين استرجاعه. | نحن ننظر في هذا الطلب ونرحّب بتلقّي مزيد من الملاحظات من المنظومة المتكاملة. |
| استبعاد الموقع الإلكتروني | استبعاد المواقع الإلكترونية من المساهمة في "مواضيع" المستخدم | لا يتمّ استدعاء المواضيع تلقائيًا. من المهمّ ملاحظة أنّه لا يتمّ أخذ محتوى أي صفحة
بعين الاعتبار عند اختيار المواضيع، ويتمّ تنظيم كلّ
المواضيع للتأكّد من أنّها ليست حسّاسة. يمكن لأي موقع إلكتروني
أيضًا منع تضمين موقعه الإلكتروني في عملية احتساب المواضيع من خلال
عنوان سياسة الأذونات التالي: Permissions-Policy:
browsing-topics=() |
| ملاحظة المواضيع | السماح للناشرين بمنح أذونات لمتصفّح Chrome لتصنيف المواضيع استنادًا إلى محتوى الصفحة (على سبيل المثال، العنوان أو النص) | لقد فكّرنا في السابق في توفير وظيفة لتصنيف المواقع الإلكترونية إلى مواضيع استنادًا إلى محتوى الصفحة، ولكننا قرّرنا عدم المضي قدمًا في ذلك لاعتبارات تتعلّق بالخصوصية والأمان. قد يؤدي هذا الاقتراح إلى التخفيف من بعض هذه المخاوف، ولكن ليس من الواضح إلى أي مدى. بسبب فترة التجربة القادمة لقياس الأداء بالاستناد إلى التكلفة، لا نتوقّع أن يحدث هذا التغيير قبل 3PCD. نرحب بملاحظاتك الإضافية هنا. |
| ملاحظة المواضيع | توفير سياسات أذونات أكثر دقة للناشرين | من خلال توفير المزيد من خطط الأذونات الدقيقة للناشرين، يمكنهم السماح لمواقعهم الإلكترونية بالتأثير سلبًا في فائدة Topics API للمنظومة المتكاملة ككل، بدون التأثير سلبًا في فائدة Topics API للموقع الإلكتروني نفسه. يمكنك الرجوع إلى مشكلة GitHub تعديل سياسة الأذونات لتضمين أذونات منفصلة لاسترداد البيانات ومراقبتها لمناقشة الموضوع بشكل أكثر تفصيلاً. |
| المواضيع الطبية والصحية | لماذا لا تشمل تصنيفات Topics المواضيع في فئتَي "الطب" أو "الصحة"؟ | تُعدّ الفئات الطبية والصحية مواضيع حسّاسة، وبالتالي يتم استبعادها من تصنيف Topics. |
| استرداد المواضيع | طريقة أسرع لنظام إدارة الطلبات (DSP) للحصول على المواضيع بدون استرجاعها باستخدام الرؤوس | تحقّق طرق استخدام العنوان أداءً أفضل وتكلفة أقل من إنشاء ملف iframe من مصدر مختلف وإجراء مكالمة document.browsingTopics() منه. (يجب استخدام إطار iframe من مصدر مختلف للمكالمة، لأنّه يجب أن يتطابق سياق المستوى الأعلى لمراقبة موضوع مع السياق الذي يتم من خلاله الوصول إلى المواضيع). تمّت مناقشة ذلك بالتفصيل هنا. |
| استرداد المواضيع | طلبات لإتاحة تمرير Topics عبر العناوين في طلبات علامات البرامج النصية من مصادر خارجية | من منظور الأمان، هذا غير ممكن. يرتبط كل مستند و
بيئة تنفيذه بمصدر واحد، وهو
مصدر المستند. تُعتبَر الموارد الفرعية التابعة لجهات خارجية التي يتم تحميلها وتنفيذها في
هذه البيئة نفسها مملوكة لمصدر
الوثيقة. ويهدف ذلك إلى منع تسرُّب البيانات بدون موافقة من مصدر إلى آخر. يمكنك بدلاً من ذلك تقديم سمة browsingTopics في علامات <script>. يجب أن يكون هذا الإجراء آمنًا، وألا يؤدي إلى زيادة وقت الاستجابة. نحن منفتحون على
الملاحظات من الجهات المعنيّة. |
| الوعي | تحسين وعي الجمهور بواجهة برمجة التطبيقات Topics API وكيفية استخدامها | لقد تواصلنا مع صاحب المصلحة الذي قدّم هذه الملاحظات، وتم حلّ هذه المشكلة على GitHub.
من الآن فصاعدًا، سنواصل دعم المنظومة المتكاملة في فهم واجهة برمجة التطبيقات ونتطلّع إلى معرفة آراء الجهات المعنية. في الوقت الحالي، نقترح على الجهات المعنيّة التي تريد معرفة المزيد عن واجهة برمجة التطبيقات Topics API الاطّلاع على المستندات في دليل مطوّري برامج Chrome. |
| إشعار | إشعار لتنبيه المستخدم عندما يرصد أحد المواقع الإلكترونية "المواضيع" الخاصة به | لقد عالجنا هذه الملاحظات على GitHub. يمكن للمستخدمين الاطّلاع على مزيد من المعلومات عن عناصر التحكّم في Topics في مركز مساعدة Chrome. |
| تعلُم الآلة | كيف يمكن استخدام الذكاء الاصطناعي (ML) لاستنتاج مواضيع المستخدمين؟ | نحن بصدد مناقشة هذه المشكلة ونرحب بملاحظاتك الإضافية. |
| مدى الفائدة لأنواع مختلفة من الجهات المعنيّة | قد لا تتمكّن شركات تكنولوجيا الإعلان الأصغر حجمًا من مراقبة المواضيع بسبب طريقة احتسابها في المتصفّحات. | ولن تتلقّى تكنولوجيات الإعلان سوى موضوع واحد، وهو الموضوع الذي لاحظت هذه التكنولوجيا أنّ المستخدِم زار صفحة عنه في
الأسابيع الثلاثة الماضية. إذا لم تستدعي تكنولوجيا الإعلان واجهة برمجة التطبيقات في الأسابيع الثلاثة السابقة لهذا المستخدِم
على موقع إلكتروني عن هذا الموضوع، ستكون القيمة المعروضة
فارغة. تعني هذه الميزة أنّ تقنيات الإعلان التي يستخدم خدماتها عدد أكبر من أصحاب المواقع الإلكترونية، وبالتالي تتوفّر لها فرص أكبر لرصد زيارة أحد المستخدِمين إلى موقع إلكتروني معيّن، قد تتلقّى مواضيع أكثر من تقنيات الإعلان الأخرى. هذه الميزة ضرورية لحماية الخصوصية في واجهة برمجة التطبيقات، لأنّها تحدّ من توفّر معلومات عن المستخدِم لجهات خارجية محدّدة فقط يمكنها حاليًا مراقبة المعلومات الأساسية نفسها (من خلال ملفات تعريف الارتباط التابعة لجهات خارجية). |
| طلب XHR | متى سيتم إيقاف إدراج Topics في طلبات XMLHttpRequest (XHR) نهائيًا؟ |
كما أعلنّا في Chrome
في آب (أغسطس) 2023، بدأ Chrome في إيقاف استخدام طلبات XHR نهائيًا عند
الانتقال من مرحلة الإصدار التجريبي إلى الإصدار العلني. مع بدء طرح Topics، لم يتوفّر دعم XHR إلا للمستخدمين الذين تم تفعيل ميزات OT لديهم، وتم إيقافه نهائيًا عند دمج مجموعات تجارب OT الفردية. إذا كنت تستخدم Topics مع XHR، لن تتعطّل مواقعك الإلكترونية. لن تتم إضافة topics إلى عناوين طلبات XHR. ننصحك باستخدام fetch لطلبك أو استخدام سمة iframe
أو استخدام JavaScript API لاسترداد المواضيع. تتوافق ميزة "الاسترداد" مع جميع المتصفحات الحديثة، ولكن لا تتوافق مع Internet Explorer أو Opera
Mini. |
| عملية تعديل التصنيفات والمعرّفات | مزيد من المعلومات حول وتيرة طرح التصنيف والمصنّف في Topics وكيفية استعداد الشركات لهذه التعديلات | لم يتغيّر ردّنا منذ الربع الثاني: كما ذكرنا في مقالتنا الأخيرة على المدونة، نتوقّع أن تتطوّر التصنيفات بمرور الوقت، وأن يتم في نهاية المطاف نقل إدارة التصنيفات إلى جهة خارجية تمثّل الجهات المعنيّة من مختلف المجالات. شاركنا أيضًا خطة التوسّع في مجموعة topics-announce. |
| إساءة الاستخدام | هجوم محتمل عبر سلسلة إعادة التوجيه | نحن ننظر في هذه المشكلة ونرحّب بملاحظاتك الإضافية. |
| أنواع المساحات الإعلانية المتوفّرة لدى الناشر | ما هي أنواع مستودعات الناشرين التي سيتيح اختبار "شرائح الجمهور المحمية" و"المواضيع" استخدامها؟ | لا يفرض خيار "شريحة الجمهور المحمية" أو "المواضيع" قيودًا بشكلٍ أساسي من حيث أنواع المستودع الإعلاني الذي يمكن استخدامهما فيه. |
| وقت التحسين | لا يُنصح بتحديد وقت للزيادة التدريجية للوصول إلى نسبة 100% من التصنيفات الجديدة. | بعد طلب الملاحظات من المنظومة المتكاملة والمناقشات التي أجريناها خلال اجتماعات PATCG ، أعلنّا عن خطتنا لطرح التصنيف الجديد. |
Protected Audience API (المعروفة سابقًا باسم FLEDGE)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| المزادات على مستوى أعلى | إمكانية استخدام خادم إعلانات الناشر من Google بدون منح "مدير إعلانات Google" أيضًا إمكانية التحكّم في مزاد واجهة برمجة التطبيقات Protected Audience API ذات المستوى الأعلى | الردّ المقدَّم من "مدير إعلانات Google": لا تتضمّن خطط "مدير إعلانات Google" لواجهة برمجة التطبيقات Protected Audience API إتاحة استخدام خادم إعلانات الناشر من Google بدون التحكّم في مزاد Protected Audience على المستوى الأعلى، للأسباب التالية. لعرض الإعلانات بشكلٍ سليم لعملائنا في سوق عرض إعلانات الناشرين، يجب أن يحتفظ خادم إعلانات الناشرين من Google بالسيطرة على مزاد "شريحة الجمهور المحمية" على المستوى الأعلى. بصفتنا خادم إعلانات للناشرين، يكمن دورنا في تزويد الناشرين بالتوقّعات حتى يتمكّنوا من التفاوض بشأن حملات العميل المباشر بدون الحجز الزائد، وتحديد وتيرة الحجوزات المباشرة وتنفيذها على النحو الأمثل. ويتطلّب إجراء ذلك تنفيذ المزاد النهائي لمقارنة جميع الطلبات المؤهّلة المباشرة وغير المباشرة. التوقّعات ووتيرة عرض الإعلانات هما وظيفتان أساسيتان يتوقعهما الناشرون من خادم الإعلانات. في حال عدم إجراء توقّعات دقيقة، قد ينتهي الأمر بالناشرين ببيع مستودعهم الإعلاني بشكلٍ زائد، ما يعرّض سمعة نشاطهم التجاري للخطر. من المهم أيضًا تحديد وتيرة العمل، لأنّ عدم التمكّن من تنفيذ عقود الحجز مع المعلِنين قد يؤدي أيضًا إلى تعريض العلاقة المباشرة بين الناشر والمعلن للضرر، ما قد يؤدي بدوره إلى تأثير كبير في نشاط الناشر التجاري. باختصار، لا نعتبر نشاط خادم إعلانات الناشر في تشغيل مزاد "الجمهور المحمي" من المستوى الأعلى مختلفًا عن الأنشطة الأخرى لخادم إعلانات الناشر. |
directFrom |
directFromيسمح لـ "مدير إعلانات Google" بمنع الناشر من الاطّلاع على سعر المزاد السياقي. |
ردّ Chrome: لا يُعرف أنّ المعلومات التي تم تمريرها إلى runAdAuction() تأتي من العميل
ما لم يطلب العميل runAdAuction() من إطار iframe الخاص به. في
المزاد المتعدد البائعين، يصبح من المستحيل أن ينشئ جميع البائعين
الإطار الذي يشير إلى runAdAuction(). directFromSellerSignals
عالجت هذه المشكلة من خلال تحميل المحتوى من حِزمة موارد فرعية
تم تحميلها من مصدر البائع. ويضمن ذلك عدم إمكانية التلاعب بصحة
وموثوقية المعلومات التي يتم تمريرها إلى مزاد من إعدادات
مزادات البائعين. إذا أراد الناشرون استخدام Protected Audience API لفهم أيّ من المعلومات التي ينقلها مزوّدو التكنولوجيا إلى مزادات Protected
Audience، يمكنهم طلب هذه الميزة من مزوّدي التكنولوجيا.الردّ المقدَّم من "مدير إعلانات Google": لقد حافظنا على تركيز قوي على نزاهة المزاد لعدّة سنوات، بما في ذلك وعدنا بعدم مشاركة أي سعر من أي من مصادر الإعلانات غير المضمونة للناشر، بما في ذلك أسعار العناصر غير المضمونة للخط، مع مشتري آخر قبل تقديم عروض أسعاره في المزاد، وهو ما أكدتّه لاحقًا في التزاماتنا بهيئة المنافسة الفرنسية. بالنسبة إلى مزادات "الجمهور المحمي"، ننوي الوفاء بوعودنا من خلال الاستفادة من directFromSellerSignals، وعدم مشاركة عرض سعر أي مشارك في المزاد مع أي مشارك آخر في المزاد قبل إكمال
المزاد في المزادات التي تشمل بائعين متعدّدين. للتوضيح، لن نشارك
سعر المزاد السياقي مع مزاد المكوّنات
أيضًا، كما هو موضّح في تحديث مزيد من التوضيح حول ديناميات المزاد على مستوى أعلى. |
| الكشف عن المعلومات | قد يعرِض المتصفّح منطق النشاط التجاري الحسّاس وتفاصيل العقود. | يمكن للمستخدم الذي يستخدم متصفّح ويب الاطّلاع على كل ما يحدث في المتصفّح. عندما يحدث مزاد إعلاني داخل المتصفّح، من الحقيقة أنّ المستخدم الذي يستخدم المتصفّح يمكنه مشاهدة هذا المزاد أثناء حدوثه، بما في ذلك معرفة المبلغ الذي تختاره الجهات المختلفة لعرض عروض أسعارها. بما أنّ المتصفّح هو وكيل المستخدم، لا نعتقد أنّه يمكن أو من المستحسن محاولة تغيير ذلك. ومع ذلك، لا يمكن لأحد الاطّلاع على هذه العمليات إلّا المستخدم الذي يستخدم browser. إنّ المزاد الذي يتم إجراؤه على الجهاز باستخدام Protected Audience API لا يمكن لأيّ خوادم رصده، بما في ذلك خوادم Google. |
PerBuyerExperiment |
يمكن أن يسمح نطاق القيمة الحاليPerBuyerExperimentللمشترين بربط البيانات السياقية بطلب الخادم الموثوق به. |
إنّ استخدام Protected Audience API بهذه الطريقة لا يتوافق مع الشهادة الإلزامية لمبادرة حماية الخصوصية التي تفيد بأنّ مستخدمي واجهة برمجة التطبيقات لن يحاولوا التحايل على إجراءات حماية الخصوصية في مبادرة حماية الخصوصية. في المستقبل، سيوفّر شرط تشغيل خوادم أزواج المفاتيح والقِيم في بيئة تنفيذ موثوقة الحماية الفنية من هذا الإجراء. |
| سياسة المصدر نفسه | يمكنك تخفيف قيود سياسة المصدر نفسه للسماح بالنطاقات الفرعية. | نحن ننظر في هذا الطلب ونرحّب بملاحظات إضافية من المنظومة المتكاملة. |
| إصدارات واجهة برمجة التطبيقات | طلب تحديد الإصدار وملاحظات الإصدار للتغييرات في 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. |
| الفلترة من جهة الشراء | إتاحة الفلترة من جهة الشراء استنادًا إلى مجموعات الاهتمامات | لقد اقترحنا عدة طرق يمكن لخدمات SSP وDSP من خلالها تغيير
تصاميمها للتعامل مع هذه المشكلة:
|
| عنصر التحكّم في مجموعة الاهتمامات الخاصة بالناشر | دعم للناشرين الذين يريدون تفويض استخدام مجموعات الاهتمامات التي أنشأها الناشر | لقد أجرينا مناقشات مع العديد من الجهات بشأن الطلب. نعتقد أنّه يمكن الآن تلبية جميع حالات الاستخدام هذه المتعلّقة "بتفويض" المجموعات حسب الاهتمامات التي أنشأها الناشر، بالإضافة إلى أنّنا نحتاج إلى توفير دعم إضافي لتسهيل تنفيذ بعض حالات الاستخدام في المستقبل. |
| (تم الإبلاغ عنها أيضًا في الربع الثاني) بيئات التنفيذ الموثوق | إتاحة بيئة التنفيذ الموثوقة (TEE) في بيئات السحابة العلنية | لا يختلف ردّنا عن ردّنا في الربع السابق: في حين أنّنا نواصل استكشاف خيارات إضافية غير الحلول المتاحة على الصعيد العميق استنادًا إلى السحابة الإلكترونية، ليس لدينا حاليًا خطط لإتاحة استخدام ميزات TEE على الأجهزة المُدارة. في هذه المرحلة، ونظرًا لمتطلبات أمان "مبادرة حماية الخصوصية" والتحديات الكبيرة التي تطرحها عمليات النشر على الموقع، نعتقد أنّ مواصلة توسيع نطاق عمليات النشر المستندة إلى السحابة الإلكترونية وتحسينها (على سبيل المثال، إتاحة Google Cloud بالإضافة إلى AWS) هو الخيار الذي يحقق بیشترین فائدة للمنظومة المتكاملة. مع ذلك، نرحب بملاحظات إضافية حول سبب ضرورة هذا الشرط وقابليته للتنفيذ في ظل قيود الخصوصية والأمان. |
| بيئة التنفيذ الموثوقة | يمكن للمكونات في مسار عرض TEE، مثل موازن الحمولة، مراقبة جميع الزيارات والحصول على معلومات عن عنوان IP لكل طلب. | يتم حاليًا تمرير عنوان IP كبيانات وصفية في رؤوس الطلبات إلى خدمة الإعلانات الخاصة بالبائع غير الموثوق به في حال كلّ من عروض الأسعار والمزادات ومزادات "شرائح الجمهور المحمية" على الجهاز. يُرجى الاطّلاع على إعادة توجيه البيانات الوصفية للحصول على مزيد من المعلومات. على المدى الطويل، نخطّط لتوجيه طلبات تكنولوجيا الإعلان وحركة تتبُّع الإعلانات من خلال خادم وكيل لعنوان IP، ما سيمنع المكونات من مراقبة جميع الزيارات في مسار العرض. |
| مدة البقاء (TTL) | هل سيتم ضبط مدة البقاء (TTL) قبل أن تطلب الخدمات مفاتيح جديدة، أم أنّه من المفترض أن تكون مرنة (أو ديناميكية)؟ | تكون مدة البقاء ثابتة بشكل عام. في الوقت الحالي، تبلغ مدة البقاء للمفتاح العام 8 أيام، ويتم التبديل كل 7 أيام. وتبلغ مدة البقاء أيضًا المفتاح الخاص في حال استخدام "خدمة التجميع". في حال استخدام خدمات عروض الأسعار والمزادات، يتم جلب المفاتيح الخاصة والعامة كل N ساعة في مسار غير الطلب ويتم تخزينها مؤقتًا في الذاكرة، بحيث لا يكون هناك تأخير أكثر من N ساعة بين تبديل المفاتيح و استلام الخوادم لهذه المفاتيح. إنّ فترة التخزين المؤقت التي تبلغ يومًا واحدًا بين تبديل المفتاح وانتهاء صلاحيته تهدف إلى ضمان استمرار عمل الخدمات حتى في حال تعذّر إنشاء المفتاح. نحن ننظر في إمكانية تمديد مهلة "وقت الاسترجاع" ليكون أكثر قدرة على الصمود في حال انقطاع الخدمة. في حال تسرّب مفتاح، نخطّط لفرض توليد المفتاح وإلغاء صلاحية المفاتيح يدويًا في وقت أقرب. يُرجى العِلم أنّه يتم تخزين مفاتيح التشفير العلنية مؤقتًا على العملاء لمدة 24 ساعة حاليًا، وذلك مجددًا لضمان استمرار عمل الخدمات في حال انقطاع الاتصال بين المنسِّق والعملاء. |
| تشكيل الزيارات | إتاحة ميزة "تشكيل الزيارات" لخدمات عروض الأسعار والمزادات | يمكن للمشترين الإشارة إلى طلبهم لمزادات "شرائح الجمهور المحمية" استنادًا إلى بيانات الطرف الأول الخاصة بالناشر أو البيانات السياقية. يمكن للبائعين إجراء عمليات تحديد مماثلة أيضًا في خادم الإعلانات الخاص بالبائع أو خادم Ad Exchange. يمكن تدريب النماذج على بيانات الطرف الأول وأيّ تقارير مجمّعة من مزادات "شرائح الجمهور المحمية". يمكن للبائعين استخدام هذه المعلومات لتجنُّب إرسال طلبات إلى ملفّات bidding وauction الخادمة عندما لا يكون هناك طلب لمزادات "شرائح الجمهور المحمية". ونعتقد أنّه يمكن أن يكون ذلك وسيلة فعّالة لجذب الزيارات. |
| مزاد المكوّنات | ما هي إشارات auctionSignals ذات المستوى الأعلى التي تتم مشاركتها مع بائعي المكوّنات؟ | لا يتلقّى المشترون في مزاد المكوّنات إشارات إلّا من "بائع" المكوّنات. نحن نسعى إلى مشاركة مستندات حول التسلسل العام للمزاد المجمّع مع عروض الأسعار في الرؤوس ومزاد "المشاهدون المحميون" قريبًا. |
| عرض الفيديو | إتاحة عرض الفيديو باستخدام ميزة "الجمهور المحمي" وميزة "الإطارات المحدودة" | تتيح Protected Audience API عرض الفيديو باستخدام آلية تعتمد على إطارات iframe. ومع ذلك، لم نتوصّل بعد إلى حلّ متوافق مع "الإطارات المُحدودة"، وهذا هو أحد الأسباب التي دفعتنا إلى تأجيل فرض استخدام "الإطارات المُحدودة" إلى عام 2026. وهذا يعني أنّه إذا قرّر أحد الشركاء فرض استخدام "الإطارات المحدود" الآن، لن يكون بإمكانه استخدام الفيديو. |
| تحديد عدد مرات الظهور | (تمّ الإبلاغ عنها أيضًا في الربعَين السابقَين) تُستخدَم عناصر التحكّم في عدد مرّات الظهور لكلّ مستخدِم ضمن حملة ومجموعة إعلانية. |
لم يتغيّر ردّنا عن التقارير السابقة: تتيح ميزة "الجمهور المحمي" تحديد عدد مرّات الظهور للمزادات التي تعمل على الجهاز فقط والحملات السياقية والحملات المرتبطة بالعلامات التجارية أيضًا. يمكن أيضًا استخدام مساحة التخزين المشترَكة والحدود القصوى الخاصة بالموقع الإلكتروني للتحكّم في مزيد من عناصر التحكّم في تكرار الإعلانات. |
| الإعدادات المفضّلة للإعلانات | هل توفّر ميزة "شرائح الجمهور المحمية" طريقة لإيقاف الميزة أو حظر المواقع الإلكترونية للمعلنين أو طريقة لمغادرة جميع مجموعات الاهتمامات التي يملكها المالك نفسه؟ | تتوفّر للمستخدمين عدة طرق لحظر الوصول إلى Protected Audience API وميزات "مبادرة حماية الخصوصية" الأخرى. |
| سياسة المصدر نفسه لعنوان URL المصدر لنصوص عروض الأسعار والمزادات | تخفيف شرط أن تكون جميع الحقول التي تحدّد عناوين URL لتحميل النصوص البرمجية أو ملفات JSON من مصدر مماثل لملكية المالك | نحن ننظر حاليًا في هذا الطلب ونرحب بملاحظات إضافية من المنظومة المتكاملة. |
forDebuggingOnly |
احتمالية إساءة استخدام forDebuggingOnly في حال
استمرار استخدامها بعد انتهاء فترة 3PCD |
على مدار السنوات الماضية، تلقّينا ملاحظات من المنظومة المتكاملة بشأن الفجوات في الوظائف في ميزة "شرائح الجمهور المحمية" بعد إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا، ونحن نعمل على وضع خطة لإتاحة هذه الميزة بعد إيقاف ميزة "المعالجة المحدودة للبيانات" بدون المساس بأهداف "مبادرة حماية الخصوصية". نرحب بأي اقتراحات وملاحظات إضافية بشأن الوظائف غير المتوفّرة التي تريد المنظومة المتكاملة أن توفّرها. |
| مجموعات متعدّدة ذات اهتمامات مشتركة | استخدام مجموعات اهتمامات متعدّدة في عرض السعر نفسه | لا تتوفّر هذه الميزة في Protected Audience API حاليًا، لأنّ ذلك قد يؤدي إلى تغيير في نموذج الخصوصية الأساسي. نرحب بتلقّي ملاحظات إضافية هنا. |
| المزادات على الجهاز فقط | هل سيتيح Chrome على Android مزادات "شرائح الجمهور المحمية" على الجهاز؟ | نعم، ستتوفّر المزادات على الجهاز في Chrome على Android. |
| (تم الإبلاغ عنها في الربع الثاني من عام 2023) البيانات المتعلّقة بالنقرات | أضِف البيانات المتعلّقة بالنقرات إلى browserSignals. | ما زلنا نقيّم طلبك هذا ونرحّب بملاحظاتك المتعدّدة حول سبب منح الأولوية لهذا الطلب. |
| مقدّمو بيئة التنفيذ الموثوقة | هل هناك اختلافات جوهرية في عروض Trusted Execution Environment لمزوّدي خدمات السحابة الإلكترونية المختلفين؟ | لا نعلم أيّ اختلافات كبيرة، ولكننا ننصحك بأن تراجع المنظومة المتكاملة أدلة النشر العلني لمعرفة الحلّ الذي يناسب احتياجاتها بشكلٍ أفضل. Google Cloud AWS: |
| (تم الإبلاغ عنها في الربع السابق) إتاحة الاستهداف السلبي للمجموعات باهتمامات مشتركة |
واجهة برمجة تطبيقات تتيح استهداف مجموعات الاهتمامات السلبية: عرض الإعلانات فقط إذا لم يكن المستخدِم ينتمي إلى مجموعة اهتمامات | نحن ننظر في إمكانية تنفيذ هذه الميزة ونناقش الطلب. |
| مخالفة محتوى | أن تتيح الميزات للمستخدمين الإبلاغ عن الإعلانات غير الصالحة التي تعرِضها واجهة برمجة التطبيقات Protected Audience API في إطارات محصورة | نعتقد أنّ آلية الإبلاغ عن الإعلانات في الإطارات المحدود الحالية توفّر خيارات جيدة لمزوّدي تكنولوجيا الإعلان الذين يريدون عملية إعداد تقارير "الإعلانات غير الصالحة" من إنشاء المستخدمين. سيسمح ذلك بالإبلاغ عن الإعلانات المخالفة بطريقة لا تختلف بشكل أساسي عن معيار الصناعة الحالي. نرحب بطلبات الميزات الإضافية إذا بقيت هناك أي ثغرات، بما في ذلك خلال الفترة التي تلي إزالة ملفّات تعريف الارتباط التابعة لجهات خارجية، ولكن قبل أن يصبح عرض الإطارات المُغلقة رائجًا. |
| تقارير Private Aggregation API | كيف يمكننا احتساب الوقت الذي قضاه المستخدم في مجموعة الاهتمامات هذه؟ | في الإصدار M116 من Chrome والإصدارات الأحدث، من المفترض أن تتمكّن من استخدام ميزة "الحداثة" كما هو محدّد في pull/639. |
| خادم K-Anonymity | مزيد من المعلومات حول خادم K-Anonymity | لقد شاركنا المزيد من المعلومات حول خوادم K-Anonymity هنا وتلقّينا ملاحظات وآراء إضافية. |
| عناوين URL لتصميمات الإعلانات الديناميكية | إتاحة عناوين URL لتصميمات الإعلانات بدون تقديم بيان مسبق مع الحفاظ على احترام مبدأ "المجهوليّة بعامل k" | نحن نناقش طلب هذه الميزة ونرحّب بملاحظات إضافية حول سبب منح الأولوية لهذا الطلب. |
| متطلبات إخفاء الهوية وفقًا لعدد "ك" | هل سيتم إعادة فرض شرط "المعلومات المجهولة الهوية بعامل k" على تعديلات "مجموعة الاهتمامات"؟ | لا نتوقّع حدوث تغييرات على الموقف الموضّح في هذه المشاركة على GitHub. وكما أعلنّا في هذا المنشور، قرّرنا إزالة شرط إخفاء الهوية بتقنية k-anonymity في تعديلات مجموعات الاهتمامات للجمهور المحمي، لأنّه ليس له تأثير كبير في إجراءات الحماية الشاملة للخصوصية في واجهة برمجة التطبيقات، ونخطّط لمراجعة إجراءات حماية أخرى محتملة وأكثر مباشرة (مثل حماية عنوان IP أو خادم تحديث موثوق) في تاريخ لاحق عندما تكون التكنولوجيات ذات الصلة أكثر تطورًا ونشرًا واستخدامًا. |
| الإصدار التجريبي من خدمات عروض الأسعار والمزادات | متى سيبدأ الإصدار التجريبي من "خدمات عروض الأسعار والمزادات"؟ | كما هو موضّح في المخطط الزمني وخارطة الطريق، ستبدأ ال phase الأولى من اختبار خدمات عروض الأسعار والمزادات في تشرين الثاني (نوفمبر) 2023. |
| الإعلانات الحصرية | طلب إتاحة تنسيق الإعلانات لشبكات الإعلانات (يكون كلّ من منصّة SSP وDSP في الشركة أو المواقع نفسها) | نشكرك على الملاحظات بشأن حالة الاستخدام هذه ونريد معرفة ما إذا كان المزيد من تكنولوجيات الإعلان مهتمًا بتوفير هذه الميزة. نرحّب بالملاحظات الإضافية. |
| الإعلانات المدمجة مع المحتوى | إتاحة استخدام "الإطار المضمّن المستقل" للإعلانات المدمجة مع المحتوى | نحن ننظر في إمكانية توفير هذه الميزة ونناقش الحلول والحلول البديلة المحتمَلة. |
| إخفاء الهوية وفقًا لعدد "ك" | كيف يمكنني زيادة عدد إعلانات مجموعات الاهتمامات التي تستوفي حدود قياس k-anon ؟ | لقد شاركنا بعض الإرشادات التكتيكية حول هذا الموضوع. |
| دعم POST | إتاحة إرسال بيانات المزاد عبر طلبات POST | نحن بصدد تقييم طلب الميزة هذا ونرحّب بإرسال المزيد من طلبات معالجة ملفّات GitHub التي توضّح سبب منح الأولوية لهذا الميزة. |
| دقة إعداد التقارير | ما هي درجة دقة إعداد التقارير لإعلانات الإطارات المحدود مع الإعلانات التي تتألف من عدة أجزاء؟ | لا يسمح التصميم الحالي بتسجيل معرّف المنتج أو موضعه لأنّه
قد يشكّل ذلك تهديدًا لخصوصية المستخدم. لا يمكن استدعاء سوى reserved.top_navigation
، والذي سيتم إرساله عند إجراء تنشيط من قِبل المستخدِم
(مثل نقرة) على الإطار المحدود لمكوّن الإعلان، ما يؤدي إلى
التنقّل على مستوى أعلى. |
| مزاد الإعلانات | هل يمكن لمنصّة عرض الإعلانات التي تشارك في مزاد مكوّنات أن تبدأ بنفسها مزاد مكوّنات آخر؟ | لا يمكن أن يتضمّن componentSeller أيضًا componentAuctions.يتضمّن مزاد البائعين المتعدّدين مستويَين فقط: 1- مزادات المكوّنات بالتوازي 2. المزاد على مستوى القمة (حيث يتنافس الإعلان الفائز من كل componentAuction). |
| مدى توفّر خدمات عروض الأسعار والمزادات | هل ستتوفّر عروض الأسعار والمزادات خلال مرحلة الاختبار التي يوفّرها Chrome؟ | لن يكون خادم عروض الأسعار والمزاد متاحًا خلال مرحلة الاختبار المُيسَّر من Chrome. |
| إشارات عروض الأسعار | السماح للمتصفّحات بطلب إشارات عروض الأسعار وحذفها | نحن بصدد مناقشة هذا الطلب ونرحّب بملاحظات إضافية حول سبب منح الأولوية لهذا الطلب. |
generateBid() |
إمكانية تعديل userBiddingSignals في مجموعة الاهتمامات من خلال
updateURL |
نحن ننظر في هذا الاقتراح ونُرحّب بملاحظات إضافية ومناقشات. |
| أنواع المساحات الإعلانية المتوفّرة لدى الناشر | ما هي أنواع مستودع الناشر الذي سيتوافق مع اختبار "شرائح الجمهور المحمية" وTOPICS؟ | لا يفرض خيار "شريحة الجمهور المحمية" أو "المواضيع" قيودًا بشكلٍ أساسي من حيث أنواع المستودع الإعلاني الذي يمكن استخدامهما فيه. |
| الدمج من خادم إلى خادم | هل يلزم الدمج المباشر بين منصّة SSP ونظام DSP لميزة "الجمهور المحمي"؟ | لا يلزم الدمج المباشر بين منصّة SSP ونظام DSP إذا لم يكن نظام DSP يحتاج إلى معالجة الإشارات السياقية في خادمه الخاص من أجل تمرير هذه المعلومات التي تمت معالجتها إلى وظيفة عروض الأسعار على الجهاز. |
حقل bid_currency في "الإقامة والوجبات" |
إتاحة حقل bid_currency في خدمة عروض الأسعار والمزادات |
لا تتيح"الإعلانات الصورية" استخدام bid_currency بعد، ولكننا نخطّط لإتاحة استخدامها بحلول نهاية كانون الثاني (يناير) 2024. يُرجى الرجوع إلى المخطط الزمني هنا. |
perBuyerSignals |
هل هناك حدّ أقصى لحجم perBuyerSignals؟ |
ما مِن حدّ أقصى لعدد الإشارات لكلّ مشترٍ، ولكنّ إرسال بيانات كثيرة جدًا قد يكون له تأثيرات ضارّة على أداء المتصفّح. |
| حالات الاستخدام على مستوى المواقع الإلكترونية | هل يمكننا استخدام مجموعات الاهتمامات في Protected Audience API على عدة مواقع إلكترونية؟ | لم يتم تصميم شريحة الجمهور المحمية لحالات الاستخدام هذه، كما هو موضّح في turtledove/issues/282. |
| طلبات HTTP الخاصة بمجموعات الاهتمامات | يجب تضمين مجموعة بيانات المجموعة ذات الاهتمامات المشتركة في عناوين HTTP. | نحن ننظر في هذا الطلب ونريد تلقّي المزيد من الملاحظات بشأنه. |
| التحكّم في جودة الإعلانات | فقدان التحكّم في جودة الإعلانات بسبب معلومات على مستوى الموقع الإلكتروني | نحن نأخذ هذه الملاحظات في الاعتبار ونرحّب بتلقّي ملاحظات إضافية. |
| أدوات مطوري البرامج في Chrome | من المفترض أن تظهر طلبات شبكة Protected Audience Network الصادرة في علامة التبويب "الشبكة" ضمن "أدوات مطوّري برامج Chrome". | نحن نعمل على تفعيل هذه الوظيفة في علامة التبويب "الشبكة" ونرحب بملاحظات إضافية حول سبب منح الأولوية لهذه الميزة. |
| بيئة التنفيذ الموثوقة | متى ستتم إضافة تفاصيل عن المقاييس التي تؤثّر في الخصوصية (ودرجة تأثيرها) إلى الشرح عن مراقبة "بيئة التنفيذ الموثوق به"؟ | نحن بصدد تعديل الشرح لتضمين هذه المعلومات. سيتوفّر الدليل التوضيحي المعدَّل بحلول تشرين الثاني (نوفمبر) 2023. |
directFrom |
لماذا لا يتم تجميع directFrom كحزمة ويب؟ |
يمكنك الاطّلاع على السبب الذي دفعنا إلى اتّخاذ هذا القرار. |
| تفويض مرّات الظهور | هل هناك أي طريقة قابلة للتطبيق لمنح الإذن بالظهور حيث تكون نتيجة مجموعة الاهتمامات التي يتم اختيارها إجراءً آخر للاستهداف؟ | إنّ المزادات المُدمجة المتعدّدة غير متوافقة مع أهداف الخصوصية لسببَين: أولاً، عندما يتم عرض إعلان الفائز في مزاد داخل إطار محدود، تشمل أهداف الخصوصية في ميزة "الجمهور المحمي" عرض تصميم الإعلان الناتج بدون معرفة السياق: إنّ عنوان URL للصفحة المحيطة أو ملف تعريف الارتباط التابع للجهة الأولى يشكّلان انتهاكًا للخصوصية. في هذه البيئة، لا يكون المزاد المُدمَج مجدوًلاً. ثانيًا، ينصّ نموذج الجمهور المحمي على أنّه يجب أن يستند الفائز في كل مزاد إلى بيانات من موقع إلكتروني إضافي واحد فقط. ستكون المزادات المُدمجة طريقة لدمج ذلك، ما يؤدّي إلى إمكانية اختيار الإعلانات استنادًا إلى ملف تجاري يضمّ العديد من المواقع الإلكترونية. |
| معيار البيانات غير النشطة | توضيح إضافي لمعايير "البيانات في حالة الاستراحة" في نموذج ثقة خدمة "المفتاح/القيمة" | يتم تحميل البيانات في "خدمة إدارة مفاتيح التشفير" إلى الذاكرة وعرضها من هناك بدلاً من إجراء أي ذاكرة تخزين مؤقت للقراءة. |
| مؤشر بيانات المشترين | هل هناك حدّ أقصى محدّد لحجم إشارات buyer_data التي يتمّ تلقّيها
من منصّات معالجة الإشارات الرقمية؟ |
لا تفرض المتصفّحات حاليًا أيّ حدود على buyer_data الإشارات
المُستلَمة من منصّات إدارة الأداء. |
قياس الإعلانات الرقمية
تقارير تحديد المصدر (وواجهات برمجة التطبيقات الأخرى)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| باستخدام أكثر من جهاز واحد | التخطيط لإتاحة استخدام Attribution Reporting API على جميع الأجهزة | تطرح ميزة "الوصول على جميع الأجهزة" تحديات جديدة تتعلّق بالخصوصية بالإضافة إلى ميزة "الطرف الثالث"، كما تصعّب توزيع التكنولوجيا نظرًا لمجموعة الأجهزة والأنظمة الأساسية التي قد يستخدمها المستخدم. نحن نستكشف الحلول المحتملة، ولكنّنا نركّز على حالات الاستخدام المُهمّة التي تتيحها حاليًا ميزة "تقارير الإحالة الناجحة"، ولا نخطّط لإتاحة الميزة على جميع الأجهزة قبل إزالة ملفات تعريف الارتباط التابعة لجهات خارجية. |
| (تم الإبلاغ عنها أيضًا في الربع سنوية السابقة) حجم بيانات العامل المشغِّل |
لماذا يقتصر حجم بيانات العامل المشغِّل على 3 بت؟ | يقتصر الحجم على 3 بت و8 قيم مختلفة لضمان محدودية مقدار المعلومات حول المستخدِم على مستوى الموقع الإلكتروني والسياق. نرحب بجهات المنظومة المتكاملة بإرسال الملاحظات حول ما إذا كانت المَعلمات الحالية لإعداد التقارير على مستوى الحدث كافية. |
| مسار الإحالة الناجحة | الإبلاغ عن نطاقات متعددة تم استخدامها في الإحالة الناجحة | يمكن استخدام هذه الحالة منذ إضافة وجهات متعددة. نرحّب بملاحظاتك الإضافية. |
| إتاحة النطاق نفسه في بلد مختلف | هل تعمل تقارير تحديد المصدر مع المواقع الإلكترونية التي تتضمّن النطاق نفسه ولكنّها تتضمّن نطاقات مستوى أعلى متعددة للبلد؟ | تمت مناقشة هذه المشكلة وحلّها مع الجهة المعنية التي طرحت السؤال. إذا كانت تقنية عرض الإعلانات بحاجة إلى استخدام نطاقات TLD متعددة للبُلدان، يجب أن يكون لديها عمليات تسجيل متعددة، واحدة لكل نطاق TLD للبلد. |
| إعداد تقارير الجمهور المحمي وتحديد المصدر | هل يمكن لتكنولوجيات الإعلان الوصول إلى كلّ من الإحالات الناجحة بعد رؤية الإعلان فقط لمزادات الجمهور المحمي، بالإضافة إلى الإحالات الناجحة الناتجة عن النقر ل reporting تحديد المصدر؟ | نعم، من المفترض أن تتيح "مبادرة حماية الخصوصية" كلاً من ميزة "الحملات على الفيديو" وميزة "الحملات على الشبكة الإعلانية" ضمن ميزة "الجمهور المحمي". |
| تأخيرات التقارير القابلة للتجميع | تقليل تأخيرات التقارير القابلة للتجميع بشكل أكبر | لقد تلقّينا ملاحظات حديثة بشأن هذا الموضوع وشاركنا أفكارًا هنا. نرحب بملاحظات إضافية من المنظومة المتكاملة. |
| تأخيرات التقارير القابلة للتجميع | تقليل التأخيرات من خلال التوسّط بين الخادم | نحن ننظر في هذا الاقتراح ونرحّب بتلقّي ملاحظات إضافية . |
| تأخيرات التقارير على مستوى الحدث | تقليل تأخّر التقارير على مستوى الحدث | إنّ الاقتراح الكامل والمرنة على مستوى الحدث، الموضّح في الإعدادات المرنة على مستوى الحدث، يمكن أن يقلل من تأخّر إعداد التقارير على مستوى الحدث إلى ساعة واحدة مع التنازل عن الضوضاء. |
| مصدر إعداد التقارير حسب المصدر | يمنع الحدّ الأقصى لمصادر إعداد تقارير المصادر لكلّ موقع إلكتروني لإعداد تقارير المصادر تكنولوجيات الإعلان من تسجيل مصادر من مصادر إعداد تقارير مختلفة لمصدر ناشر واحد. | تمت مناقشة هذه المشكلة مع الجهة المعنية التي طرحت المشكلة، ويجري حاليًا اختبار حلّ محتمل يتمثل في استخدام مصدر واحد لإعداد التقارير لكل موقع إلكتروني يُبلغ عن مصدر قبل تجربة حلول أخرى محتملة تتضمن عمليات إعادة التوجيه. نحن منفتحون على أي ملاحظات إضافية بشأن هذا الحدّ المفروض على المنظومة المتكاملة أيضًا. |
| الإبلاغ عن المشاكل | كيف يمكننا الإبلاغ عن أخطاء أو مشاكل في واجهة برمجة التطبيقات Attribution Reporting API لتطبيق Chrome؟ | ننصحك حاليًا بأن تُبلغ تكنولوجيات الإعلان عن أي أخطاء قد تواجهها في Attribution Reporting API كمشاكل على GitHub. إذا واجهوا مشكلة متعلّقة بـ Chrome، ننصحك بإنشاء تقرير عن خلل في Chromium. يمكنك العثور على روابط للاطّلاع على كيفية الإبلاغ عن أي مشاكل ومكان الإبلاغ عنها في مقالة التفاعل مع الملاحظات ومشاركتها. |
| التكرارات | كيف يمكننا إزالة تكرار الإحالات الناجحة على مستوى مسارات الإحالات الناجحة المختلفة والأجهزة المختلفة؟ | إنّ إزالة التكرار على مستوى الأجهزة ومسارات القياس هو تحدٍّ معروف و
حالي تواجهه أيضًا تكنولوجيات الإعلان اليوم باستخدام 3PC. باستخدام واجهة برمجة التطبيقات
Attribution Reporting API، يمكن لتكنولوجيات الإعلانات تحديد وقت تسجيل
إحالات ناجحة معيّنة وإضافة بيانات وصفية معيّنة للإشارة إلى
مسارات القياس التي استخدموها لتتبُّع الإحالات الناجحة (بمعنى آخر،
جزء من مفتاح التجميع)، والتي يمكن مقارنتها بمسارات قياس أخرى. نحن منفتحون على أي ملاحظات إضافية بشأن منظومة التطبيقات المتكاملة في هذا الشأن. |
| إزالة التكرار والأولوية | يُرجى طلب الحصول على الأولوية أولاً قبل إزالة تكرار البيانات. | نحن ننظر في هذا الطلب ونُرحّب بتلقّي ملاحظات إضافية. |
| مكافحة الاحتيال | خطر تلاعب المستخدمين الضارين بالبيانات على مستوى الحدث | لا تعمل ميزة التحقّق من التقارير على مستوى الحدث للأسباب التالية: الأسباب الموضّحة في مقالة لماذا لا تتيح هذه الميزة إعداد تقارير على مستوى الحدث؟ |
| نوع الإحالة الناجحة | كيف يمكننا التفريق بين المشاهدة من خلال الانتقال إلى صفحة المنتج والانتقال إلى صفحة المنتج في تقارير تحديد المصدر؟ | لدينا خيار الفلترة المضمّن التالي: source_type.
تتوفّر تفاصيل إضافية هنا. |
خدمة تجميع البيانات
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| استرداد الميزانية | طلبت بعض التكنولوجيات الإعلانية إمكانية إعادة معالجة التقارير في الحالات التي تتعذّر فيها معالجة التقارير أو تحدث فيها أخطاء أو يتم حذفها. | يستكشف الفريق طرقًا لحلّ هذه المشكلة بطريقة تحافظ على الخصوصية. |
| تسجيل الموقع الإلكتروني | طلبت تكنولوجيات إعلانية متعدّدة الحصول على دعم لمعالجة مصادر متعدّدة في الحساب نفسه لحالات استخدام مثل تقسيم البيانات حسب الموقع الجغرافي والمعلِن. ومن المتوقّع أيضًا أن تتّبع تكنولوجيات الإعلان هذا السلوك، لأنّ تسجيل واجهة برمجة تطبيقات العميل يستند الآن إلى الموقع الإلكتروني (وليس إلى المصدر). إنّ نقل البيانات من المصدر إلى عملية تسجيل الموقع الإلكتروني يسهّل عملية إعداد تكنولوجيا الإعلان من خلال التوافق مع عملية تسجيل العميل. | سنبدأ قريبًا عملية نقل البيانات من عملية التسجيل في المصدر إلى عملية تسجيل الموقع الإلكتروني للخدمة المجمّعة، ونرحّب بتلقّي الملاحظات والآراء من المنظومة المتكاملة. |
| خطة الإصدار وإيقاف الميزة نهائيًا | جدول الإصدار والإيقاف النهائي لميزات "خدمة التجميع" والتصحيحات المنشورة والهدف من هذه الخطة هو منح خبراء التكنولوجيا الإعلانية إحصاءات عن سياسات الإصدارات لتمكينهم من الاستعداد لطرح الإصدارات القادمة وإيقاف الإصدارات القديمة نهائيًا، والتأكّد من تشغيل إصدارات الخدمات الثابتة والآمنة. | لقد نشرنا مؤخرًا اقتراحًا بشأن خطة الإصدار والإيقاف النهائي لخدمة التجميع، ونرحّب بتلقّي ملاحظات إضافية. |
| المنسّقون | ماذا يحدث في حال توقّف أدوات التنسيق عن العمل في خدمة التجميع؟ | يجب أن يكون كلا المنسقَين متاحَين بالكامل لكي يعمل النظام
بشكل صحيح. يتم التعامل مع حالات عدم التوفّر القصيرة من خلال عمليات إعادة المحاولة
في مكتبات برامج العملاء، ولكن في حال عدم توفّر أي من المنسّقين
لفترة أطول، ستتعطّل مهام التجميع. يمكن إعادة تشغيل المهام إذا لم يتم استخدام ميزانية الخصوصية بعد. فيحال أدّى أيّ عطل في الخدمة إلى إنفاق الميزانية بدون تسجيل ملف تقارير تلخيصية في مساحة تخزين تقنية الإعلان، ننصحك حاليًا باستخدام تقارير تصحيح الأخطاء لاسترداد النتائج باستخدام أداة الاختبار المحلي. نحن نعمل أيضًا على ميزات تتيح استرداد الميزانية في حال حدوث أعطال حتى تتمكّن تكنولوجيات الإعلان من إعادة تشغيل وظائفها. |
Private Aggregation API
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| عنوان URL للكتل | طلب إتاحة عنوان URL لملف Blob في مساحة التخزين المشتركة | تمت إضافة إمكانية استخدام عناوين URL لـ Blob في الإصدار M116 من Chrome. |
الحد من التتبّع الخفي
تقليل معلومات وكيل المستخدم وتعديلات برنامج وكيل المستخدم
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| JavaScript API | توفّر User Agent Client Hints JavaScript API | ما مِن خطط لإزالة هذه الوظيفة لأنّها تشكل حلولنا الأساسية للشركاء الذين يريدون الوصول بشكل نشط إلى بيانات التشفير العالي بخلاف ما هو متاح تلقائيًا في ملف utm. |
| معلومات الجهاز وشكله | قدرة المواقع الإلكترونية على فهم الإدخال والإخراج وغيرها من المعلومات التي يمكن للجهاز الذي يزور الموقع الإلكتروني التعامل معها | لقد أضفنا دعمًا لهذا الطلب بناءً على الملاحظات الواردة من المنظومة المتكاملة. |
حماية عنوان IP (المعروفة سابقًا باسم Gnatcatcher)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| الزيارات المؤهّلة من جهات خارجية | ما المقصود بعبارة "الزيارات المؤهَّلة التابعة لجهات خارجية" في الشرح؟ | نحن ندرك أهمية هذا السؤال ونعمل بنشاط على تحديد الزيارات التابعة لجهات خارجية التي ستكون مؤهّلة والتي لن تكون مؤهّلة. يسرّنا تلقّي ملاحظاتك حول هذا الموضوع. |
| عمليات تدقيق حركة بيانات الشبكة | إتاحة إمكانية إجراء تقارير تدقيق في حركة البيانات على الشبكة لمشاريع العميل | ولن تتأثّر سوى الزيارات التابعة لجهات خارجية والمضمّنة في المواقع الإلكترونية التابعة للطرف الأول، ما من شأنه الحدّ من عدد الزيارات التي تتطلّب تصفية. بالإضافة إلى ذلك، نخطّط لإتاحة خيار استخدام ميزة "حماية عنوان IP" أو عدم استخدامها للمستخدمين، وبالنسبة إلى إصدار Chrome الخاضع لإدارة المؤسسة، ستتوفّر سياسات للمؤسسات لإيقاف ميزة "حماية عنوان IP". أخيرًا، نحن بصدد استكشاف عناصر التحكّم (إن توفّرت) التي سيتم توفيرها لمشغّلي الشبكة لإيقاف ميزة "حماية عنوان IP". يسرّنا تلقّي ملاحظاتك حول هذا الموضوع. |
| التحكم في الدخول | قد تؤثر ميزة "حماية عنوان IP" في خدمات الويب التي تستخدم عناوين IP للتحكّم في الوصول. | ندرك أهمية حالات الاستخدام لمكافحة الاحتيال والتأثير المحتمل في هذه الحالات. نطلب ملاحظات من المنظومة المتكاملة حول كيفية تحسين دعم حالات استخدام مكافحة الاحتيال التي تعتمد عادةً على عناوين IP. |
| التواصل بين الخوادم الوكيلة ذات القفزةَين | كيفية التأكّد من عدم توفّر أي معلومات بين الخوادم الوكيلة | نحن بصدد تصميم التفاعلات بالنيابة. هدفنا هو تقليل فرص مشاركة هذه المعلومات من خلال النشاط التجاري والعمليات والوسائل الفنية. |
| عمليات المصادقة التي لا تتبع Google | إتاحة المصادقة غير التابعة لـ Google | نخطّط لنشر المزيد من التفاصيل حول مصادقة الحساب في المستقبل، على الرغم من أنّنا شاركنا بعض النقاط المُعتبَرة الأولية. |
| تصنيف خدمة التتبّع | كيف ستحدّد ميزة "حماية عنوان IP" ما يشكّل أداة تتبُّع و متغيراتها؟ | نحن ندرك أهمية هذا السؤال ونعمل بنشاط على تحديد الزيارات التابعة لجهات خارجية التي ستكون مؤهّلة والتي لن تكون مؤهّلة. يسرّنا تلقّي ملاحظاتك حول هذا الموضوع. |
| إحصاءات Google | قد تؤثر ميزة "حماية عنوان IP" في دقة خدمات الإحصاءات. | نسعى إلى فهم تأثير ميزة "حماية حقوق الملكية الفكرية" بشكل أكبر، ونقدّر بشدة تلقّي ملاحظات وأمثلة إضافية من المنظومة المتكاملة. |
| الخادم الوكيل | إذا كان المستخدم يستخدم خادمًا وكيلاً أو حدّد خادمًا وكيلاً يدويًا، كيف سيعمل IP Mask في هذه الحالة؟ | نسعى إلى معرفة مدى تأثير ميزة "حماية عنوان IP" في الخوادم الوكيلة الأخرى. ليس لدينا أي خطط لمشاركتها في الوقت الحالي. نرحب بتلقّي ملاحظاتك بشأن هذا الموضوع. |
| عرض Premium | هل ستكون ميزة "حماية عنوان 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" في WebView على Android في المستقبل؟ | ليس لدينا أي خطط لمشاركة هذه الميزة في الوقت الحالي، ولكنّ رؤيتنا هي توفير هذه الحماية على نطاق واسع قدر الإمكان. |
الحدّ من التتبّع الارتدادي
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| تتبُّع التفاعلات | كيف يتم تتبُّع تفاعلات المستخدِمين؟ | تتبّع إجراءات الحدّ من التتبّع الارتدادي نوعَين من تفاعلات
المستخدِمين:
ترتبط هذه التفاعلات بالموقع الإلكتروني من المستوى الأعلى على الصفحات التي تحدث فيها. على سبيل المثال، إذا نقر أحد المستخدِمين على إطار iframe مضمّن، يكون التفاعل مرتبطًا بالموقع الإلكتروني من المستوى الأعلى وليس بالموقع الإلكتروني المضمّن. يتم تخزين التفاعلات في قاعدة بيانات تحتوي على الملف الشخصي غير المخطط etld+1 ووقت التفاعل. تحمي "التفاعلات" النطاق المرتبط من تتبُّع عمليات الارتداد وحذف حالة التخفيف لمدة 45 يومًا. |
| الإعفاءات المدرَجة في القائمة المسموح بها | هل يمكن إعفاء النطاقات؟ | نحن ننظر في هذا الطلب ونرحّب بتلقّي ملاحظات إضافية من المنظومة المتكاملة. |
ميزانية الخصوصية
لم يتم تلقّي أي ملاحظات هذا الربع.
تعزيز حدود الخصوصية على جميع المواقع
مجموعات المواقع الإلكترونية المرتبطة (المعروفة سابقًا باسم "مجموعات نطاقات الطرف الأول")
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| النهج المركزي | القلق بشأن نهج المستودع المركزي لإدارة "مجموعات المواقع الإلكترونية المرتبطة" | إنّ المستودع العلني الذي يمكن الوصول إليه بسهولة هو مفتاح تصميم RWS، لأنّه يقدّم المساءلة عن العينات التي يتم إرسالها. يتم توفير وظائف ملفّات تعريف الارتباط التابعة لجهات خارجية في نهاية المطاف من خلال استخدام واجهة برمجة التطبيقات Storage Access API أو واجهة برمجة التطبيقات rSAFor API، مع توفير اشتراك RWS إذن وصول مُمنوح تلقائيًا (بدلاً من من خلال طلبات باستخدام واجهة برمجة التطبيقات Storage Access API). نعتقد أنّ نهجًا مثل عملية إرسال طلبات الحصول على موافقة المستخدِمين هو أحد المتطلّبات المناسبة للوصول إلى ملفات تعريف الارتباط التابعة لجهات خارجية الممنوح تلقائيًا. |
| إعادة تسمية ملف JSON | مع التغيير في اسم واجهة برمجة التطبيقات، هل يجب تغيير اسم ملف JSON المستضاف؟ | نعم، تم تغيير إرشادات الإرسال، ويجب أن يعرض الدومين الأساسي
ملف JSON على العنوان
/.well-known/related-website-set.json. لا يلزم تغيير المجموعات الحالية في قائمة RWS، ولكن إذا كانت هناك تعديلات تم إرسالها إلى المجموعات الحالية، يجب تعديل ملف JSON. |
| (تم الإبلاغ عنه أيضًا في الربعَين السابقَين) الحد الأقصى للنطاقات | طلب توسيع عدد النطاقات المرتبطة | كما أعلنّا في مشاركة مدونة بتاريخ 31 آب (أغسطس)، رفعنا الحد الأقصى لنطاقات التطبيقات المرتبطة إلى خمسة نطاقات استنادًا إلى الملاحظات الواردة من المنظومة المتكاملة. لقد قرّرنا زيادة الحدّ الأقصى للنطاقات المرتبطة إلى خمسة نطاقات (بالإضافة إلى نطاق أساسي واحد) بما يتوافق بشكلٍ أفضل مع التنفيذ الأكثر مقارنةً الذي يوفّره متصفّح رئيسي آخر. |
| ملفات تعريف الارتباط التابعة لجهات خارجية | هل ستتوفّر ميزة "مجموعات المواقع الإلكترونية ذات الصلة" فقط مع ملفات تعريف الارتباط التابعة لجهات خارجية متوقفة؟ | ستتمكّن مجموعات المواقع الإلكترونية ذات الصلة من العمل حتى إذا لم يحظر المستخدم ملفّات تعريف الارتباط التابعة لجهات خارجية، ولكن لن يكون هناك أي تأثير ملحوظ لأنّ ملفّات تعريف الارتباط ذات الصلة متاحة بدون أي حاجة إلى واجهتَي برمجة التطبيقات Related Website Sets وStorage Access API. |
| التعديلات المشروعة | كيف يمنع مستودع "مجموعات المواقع الإلكترونية ذات الصلة" غير المالكين من تعديل المجموعات؟ | وفقًا لمرشدات إرسال المحتوى، يمكن لأي مستخدم إرسال طلب إعادة نظر على GitHub لتعديل ملف
first_party_sets.JSON. ومع ذلك، إذا تمت الموافقة على طلب إعادة النظر (يمر بعمليات التحقّق الفنية وما إلى ذلك)، ستدمجه Google يدويًا في دفعات
إلى قائمة FPS الأساسية مرة واحدة في الأسبوع (الثلاثاء في الساعة 12 ظهرًا بالتوقيت الشرقي).إذا حاول مستخدم غير مصرّح له تعديل مجموعة لا يملكها، من المفترض ألا يؤدي ذلك إلى حدوث مشكلة لأنّه لن يتمكّن من تعديل ملفات .well-known
وبالتالي ستتعذّر عمليات التحقّق. |
| الاستيلاء على النطاق | قد يؤدي الاستيلاء على النطاق إلى تعريض بيانات النطاق ذات الصلة لجهات غير مصرّح بها. | لا يمكن إجراء ذلك، كما هو موضّح في هذه المشكلة على GitHub بشأن "الجمهور المحمي". |
Fenced Frames API
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| مخالفة محتوى | السماح للمستخدمين بالإبلاغ عن الإعلانات المريبة | لا تمنع "الأُطر المُحيطة" الإبلاغ عن الإعلانات المريبة. وسيظل بإمكان المستخدمين التفاعل مع الإعلان والإبلاغ عن الإعلانات المريبة إلى تكنولوجيا الإعلان بالطريقة المعتادة. |
| التفاعل مع المواقع المحيطة | السماح بالتفاعل مع الموقع الإلكتروني المحيط أو الموقع الإلكتروني من المستوى الأعلى | نسعى إلى معرفة سبب ضرورة هذا الطلب، ونقدّر بشدة تلقّي ملاحظات إضافية من المنظومة المتكاملة. |
| الإعلانات المدمجة مع المحتوى | إتاحة استخدام "الإطار المضمّن المستقل" للإعلانات المدمجة مع المحتوى | نحن ننظر في إمكانية توفير حالة الاستخدام هذه ونناقش الحلول والحلول البديلة المحتملة. |
Shared Storage API
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| على مستوى النطاقات | السماح بالتواصل بين النطاقات لتخزين البيانات على الجهاز | لا تتوافق حالة الاستخدام هذه حاليًا مع بوابات الإخراج التي تحافظ على الخصوصية في "مساحة التخزين المشتركة"، ولكننا نرحب بسياق إضافي أثناء تطوير الاقتراحات لمساحة التخزين غير المقسّمة. |
| عنوان URL للكتل | طلب إتاحة عنوان URL لملف Blob في مساحة التخزين المشتركة | تمت إضافة إمكانية استخدام عناوين URL لـ Blob في الإصدار M116 من Chrome. |
CHIPs
لم يتم تلقّي أي ملاحظات هذا الربع.
FedCM
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| ملفات تعريف الارتباط التابعة لجهات خارجية | هل يتم حاليًا إيقاف ميزة "إدارة الموافقة" في حال فعّل المستخدمون خيار "حظر ملفّات تعريف الارتباط التابعة لجهات خارجية " في إعدادات Chrome؟ | نعم، ميزة FedCM غير مفعَّلة حاليًا. للاختبار، ننصحك
بتفعيل
chrome://flags/#fedcm- أيضًا.نسعى إلى إتاحة استخدام ميزة "إدارة الموافقة على مستوى الموقع" بدون ملفات تعريف الارتباط التابعة لجهات خارجية في المستقبل. |
مكافحة المحتوى غير المرغوب فيه والاحتيال
Private State Tokens API (وواجهات برمجة التطبيقات الأخرى)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| انتهاء صلاحية الرمز المميّز | بعد إلغاء تثبيت Google Chrome، هل سيتم فقدان الرمز المميّز أم سيتم تخزينه مؤقتًا؟ | سيتم فقدان الرمز المميّز إذا ألغى المستخدم تثبيت Google Chrome. |
| معلومات الرمز المميّز | كيف يمكن لمُصدِري البيانات الحفاظ على خصوصية المعلومات الصادرة ضمن Private State Token؟ | يتم دائمًا الحفاظ على خصوصية المعلومات في الرمز المميّز ولا يمكن لجهات خارجية لا تملك المفاتيح إزالة التشفير منها. |
| خطأ في العرض الترويجي | حدث خطأ عند محاولة تشغيل الإصدار التجريبي من رمز حالة خاص. | لقد عدّلنا الإصدار التجريبي ومن المفترض أن يعمل بشكل صحيح الآن. |