تقرير الملاحظات والآراء - الربع الثاني من عام 2025

تقرير ربع سنوي للربع الثاني من عام 2025 يلخّص الملاحظات التي تلقّيناها من المنظومة المتكاملة بشأن مقترحات "مبادرة حماية الخصوصية" وردّ Chrome عليها.

أعدّت Google هذا التقرير الربعي كجزء من التزاماتها تجاه هيئة المنافسة والأسواق (CMA) بموجب الفقرات 12 و17(ج)(2) و32(أ). يتناول هذا التقرير التقدّم الذي أحرزته Google بشأن اقتراحات "مبادرة حماية الخصوصية"، وتوقعات محدّثة بشأن التوقيت، وتفسيرات موضوعية حول كيفية أخذ Google في الاعتبار الملاحظات التي أبدتها الجهات الخارجية، وملخّصًا للتفاعلات بين Google وهيئة CMA، بما في ذلك الملاحظات التي أبدتها الهيئة وطريقة Google في معالجة هذه الملاحظات.

أطلعت Google هيئة CMA على آخر الأخبار بشأن مقترحات "مبادرة حماية الخصوصية" في "اجتماعات الحالة" المنتظمة التي تم تحديد مواعيدها وفقًا للفقرة 17(ب) من "التعهدات". بالإضافة إلى ذلك، يحتفظ الفريق بمستندات المطوّرين التي تقدّم نظرة عامة على الميزات الأساسية للإعلانات الخاصة والتغييرات في ملفات تعريف الارتباط، بالإضافة إلى معلومات حول تنفيذ واجهة برمجة التطبيقات والحالة. تتم مشاركة التعديلات الرئيسية على مدوّنة المطوّرين، بالإضافة إلى التعديلات المستهدَفة التي تتم مشاركتها مع القوائم البريدية الفردية للمطوّرين.

أخذ الملاحظات التي أبدتها الجهات الخارجية في الاعتبار

مسرد الاختصارات

ARA

Attribution Reporting API

ملفات تعريف الارتباط في الحالة المقسَّمة المنفصلة (CHIPS)

ملفات تعريف الارتباط في الحالة المقسَّمة المنفصلة

معالِج الإشارات الرقمية (DSP)

منصة عرض الطلب

FedCM

Federated Credential Management

مكتب الإعلانات التفاعلية (IAB)

مكتب الإعلانات التفاعلية (IAB)

IDP

موفِّر الهوية

مجموعة مهندسي شبكة الإنترنت (IETF)

فريق عمل هندسة الإنترنت

عنوان IP

عنوان بروتوكول الإنترنت

openRTB

عرض الأسعار في الوقت الفعلي

الوقت بدل الضائع

عملية التجربة والتقييم

PA API

Protected Audience API (المعروفة سابقًا باسم FLEDGE)

PatCG

مجموعة المنتدى الخاص لتكنولوجيات الإعلان

RP

جهة الاعتماد

RWS

مجموعة المواقع الإلكترونية المرتبطة (المعروفة سابقًا باسم "مجموعات نطاقات الطرف الأول")

SSP

منصّة عرض إعلانات المورّدين

UA

سلسلة وكيل المستخدم

UA-CH

تعديلات برنامج وكيل المستخدم

W3C

اتحاد شبكة الويب العالمية

WIPB

الجهل المتعمد بحقوق الملكية الفكرية

ملاحظات عامة، بدون واجهة برمجة تطبيقات أو تكنولوجيا محدّدة

موضوع الملاحظات	ملخّص	ردّ Chrome
مستقبل "مبادرة حماية الخصوصية"	في ضوء الإعلان عن عدم المضي قدمًا في طرح آلية لاختيار المستخدمين بشأن ملفات تعريف الارتباط التابعة لجهات خارجية، تكون بعض واجهات برمجة التطبيقات أكثر فائدة من غيرها عند توفّر ملفات تعريف الارتباط التابعة لجهات خارجية، بينما تحتاج واجهات أخرى إلى التطوّر لتكون مفيدة. هناك مجالات إضافية محتملة للاستثمار في Chrome تتجاوز واجهات Privacy Sandbox API.	نقدّر ملاحظاتك، ونواصل التواصل مع الجهات المعنية لتقييم الدور الذي يمكن أن تؤدّيه واجهات برمجة التطبيقات ضمن "مبادرة حماية الخصوصية" في المستقبل، بالإضافة إلى استكشاف مجالات جديدة للاستثمار المستقبلي، وذلك في ضوء إعلان Google في نيسان (أبريل) 2025 بأنّه سيتم الحفاظ على النهج الحالي الذي يتيح للمستخدمين اختيار ملفات تعريف الارتباط التابعة لجهات خارجية في Chrome.
مبادرة حماية الخصوصية	أعرب بعض المشاركين في النظام المتكامل عن استيائهم من الإعلان عن عدم المضي قدمًا في طرح آلية لاختيار المستخدمين لملفات تعريف الارتباط التابعة لجهات خارجية، ولكنّهم عبّروا عن فخرهم بالعمل الذي تم إنجازه، وقدّروا التحديات الفنية التي واجهتهم في "مبادرة حماية الخصوصية"، وأكّدوا على أهمية علاقة العمل التعاونية مع Chrome وعلى فائدة "منحة الاختبار في السوق".	نحن نقدّر هذه الملاحظات ونتفق على أنّ Chrome يمكنه ويجب أن يتعاون مع المطوّرين لإنشاء تقنيات تحسّن الخصوصية على الإنترنت مع الحفاظ على شبكة إنترنت تستند إلى الإعلانات.
مشاركة بيانات المتصفّح	تُعدّ مشاركة البيانات التي تتم عبر المتصفّح تكنولوجيا فعّالة لديها القدرة على معالجة أوجه القصور في السوق ومشاكل الثقة. يتمتّع المتصفّح بقيمة سياق التنفيذ التابع لجهة خارجية لأغراض التعاون.	نقدّر ملاحظاتك ونتفق معك على أنّ Chrome يمكنه ويجب أن يؤدي دورًا في مساعدة المطوّرين على إنشاء تكنولوجيات تعزّز الثقة بين المطوّرين المتعاونين والمستخدمين.
زيارات Chrome	ما هي نسبة الزيارات التي لا تستخدم ملفات تعريف الارتباط على Chrome ونسبة الزيارات في وضع التصفّح المتخفي؟	وكما أشارت هيئة CMA في "إشعار بالنية في إصدار التزامات"، لا يؤثر "وضع التصفّح المتخفي" إلا في جزء صغير جدًا من نشاط التصفّح. في كل من المملكة المتحدة والمنطقة الاقتصادية الأوروبية، يمثّل "وضع التصفّح المتخفي" في Chrome أقل من% 10 من عمليات التنقّل على الأجهزة التي تعمل بنظام التشغيل Android، وأقل من %10 من عمليات التنقّل على الأجهزة التي تعمل بنظام التشغيل Windows. تشير هذه المقاييس إلى عمليات التنقّل على متصفّح Chrome المستند إلى Chromium في المملكة المتحدة والمنطقة الاقتصادية الأوروبية فقط. لا نشارك بيانات حول المتصفّحات التي تحظر ملفات تعريف الارتباط التابعة لجهات خارجية. يمكن للمطوّرين تحديد وقت تقسيم ملفات تعريف الارتباط باستخدام عناوين الوصول إلى مساحة التخزين واستخدام إجراءات التخفيف المتاحة وفقًا لذلك.
تصنيفات Chrome Testing	ما هي خطة Chrome بشأن% 1 من الزيارات التي تم تفعيلها بدون ملفات تعريف ارتباط لأغراض الاختبار في عام 2024؟	ليس لدينا خطط لمشاركتها في الوقت الحالي، ولكنّنا ننوي مشاركتها مع الجميع فور توفّرها.
اختبار Chrome	هل يتضمّن إعداد تصنيف الاختبار الحالي معالجة للحالات التي تتوفّر فيها ملفات تعريف الارتباط التابعة لجهات خارجية وتكون واجهات برمجة التطبيقات من "مبادرة حماية الخصوصية" مفعّلة؟	يتضمّن إعداد تصنيف الاختبار الحالي معالجة لكلّ من ملفّات تعريف الارتباط التابعة لجهات خارجية وواجهات برمجة التطبيقات من "مبادرة حماية الخصوصية" في شكل "الوضع أ".
مبادرة حماية الخصوصية	يجد بعض المعلِنين أنّ واجهات Privacy Sandbox API معقّدة، ويشعرون باللامبالاة بسبب التدريبات السابقة على الاستعداد، ويتساءلون عن كيفية تحديد مزايا الاستخدام المبكر، ويبحثون عن معلومات حول تأثيرات تجديد الاستهداف، وجذب عملاء جدد، والقياس.	نحن نقدّر ملاحظاتك ونتفهّم مشاعرك بشأن تعقيد التكنولوجيا وتمارين الاستعداد. في ما يتعلّق بفهم أداء تقنيات "مبادرة حماية الخصوصية" الحالية، أشارت نتائج الاختبارات إلى أنّ مشاركة المنظومة المتكاملة عامل مهم في فهم أداء حلول "مبادرة حماية الخصوصية". ولم يكن من الممكن أن يؤدي الاختبار بكميات منخفضة إلى إعادة إنتاج ديناميكيات السوق وحوافز استخدام التكنولوجيات على نطاق واسع.

التسجيل وإثبات صحة المعلومات

لم نتلقَّ أي ملاحظات في هذا الربع.

عرض المحتوى والإعلانات الملائمة

المواضيع

موضوع الملاحظات	ملخّص	ردّ Chrome
الأداء والفائدة من Topics API مع التحسينات	تشير الملاحظات الواردة من الجهات المعنية في جهة الشراء إلى أنّ Topics API هي إشارة قيّمة وتؤدي إلى بيانات تنافسية للتكلفة لكل ألف ظهور (CPM) مقارنةً ببيانات شرائح جمهور الطرف الثالث، وذلك بالنسبة إلى حملات المعلِنين. يرى بعض الناشرين أنّ إشارة Topics API تتمتّع بجودة أعلى من إشارات الويب المفتوح العادية. في ضوء هذه الملاحظات حول فائدة Topics API، يطلب أصحاب المصلحة إجراء تحسينات، مثل تحسين دقة التصنيف واتساقه وتوسيع نطاق عناصر التحكّم المتاحة للناشرين من أجل زيادة معدّل استخدامها.	نأخذ هذه الملاحظات في الاعتبار أثناء تقييمنا للدور الذي ستؤديه واجهات Privacy Sandbox API في المستقبل، وذلك في ضوء إعلان Google في أبريل 2025 بأنّه سيتم الحفاظ على النهج الحالي الذي يتيح للمستخدمين اختيار ملفات تعريف الارتباط التابعة لجهات خارجية في Chrome.
مدى الفائدة لمختلف أنواع الجهات المعنية	بما أنّ مصنّف المواضيع يستخدم حاليًا اسم مضيف الصفحة فقط لتحديد المواضيع ذات الصلة، تساهم المواقع الإلكترونية الكبيرة التي تتضمّن محتوًى متنوعًا في توفير مواضيع عامة، بينما تساهم المواقع الإلكترونية الصغيرة في توفير مواضيع متخصّصة ذات قيمة إعلانية أكبر.	ردّنا مشابه لردودنا في الأرباع السابقة: كما هو الحال مع ملفات تعريف الارتباط التابعة لجهات خارجية، هناك اختلاف في قيمة المعلومات التي تقدّمها المواقع الإلكترونية المختلفة. تتفاوت المواقع الإلكترونية التي تستهدف اهتمامات معيّنة في مساهمتها في القيمة: فليس كل المواقع الإلكترونية التي تستهدف اهتمامات معيّنة تتضمّن محتوًى ذا قيمة تجارية، وبالتالي تساهم بقيمة أقل. هذه هي المواقع الإلكترونية التي ستستفيد من Topics API. لقد أخذنا في الاعتبار إمكانية تصنيف الصفحات بدلاً من المواقع الإلكترونية، ولكن هناك عدد من المخاوف الكبيرة بشأن الخصوصية والأمان المرتبطة بهذا التصنيف.
تصنيف المواضيع غير دقيق بما يكفي	لا توفّر Topics API مستوى تفصيلاً كافيًا لناشري الأخبار الذين يتضمّن موقعهم الإلكتروني أقسامًا متنوعة من المحتوى ضمن نطاق واحد، ما قد يحدّ من فائدة واجهة برمجة التطبيقات لاستهداف الإعلانات.	نأخذ هذه الملاحظات في الاعتبار أثناء تقييمنا للدور الذي ستؤديه واجهات Privacy Sandbox API في المستقبل، وذلك في ضوء إعلان Google في أبريل 2025 بأنّه سيتم الحفاظ على النهج الحالي الذي يتيح للمستخدمين اختيار ملفات تعريف الارتباط التابعة لجهات خارجية في Chrome.
تحسين المصنِّف	السماح للناشرين بمنح Chrome أذونات لتصنيف المواضيع استنادًا إلى محتوى الصفحة (مثل العنوان والنص الأساسي)	نحن نأخذ هذا الطلب في الاعتبار ونرحّب بتلقّي المزيد من الملاحظات هنا.
السياسة	طلب توضيح بشأن الإرشادات المتعلقة باستخدام Topics API مع معلومات الطرف الثالث	لا توجد صعوبات في استخدام كلّ من Topics API وملفات تعريف الارتباط التابعة لجهات خارجية، لأنّ Topics API توفّر مجموعة فرعية من وظائف ملفات تعريف الارتباط التابعة لجهات خارجية.
عنوان Observe-Browse-Topics	طلب توضيح بشأن تنفيذ عنوان Observe-Browse-Topics، وتحديدًا ما إذا كان عرض العنوان بشكل متواصل سيؤدي إلى حدوث مشاكل.	لن يؤدي عرض عنوان Observe-Browse-Topics: ?1 بشكل متواصل إلى حدوث أي مشاكل فنية. يتعامل المتصفّح مع هذه الإشارة بكفاءة، حيث يكتفي بتسجيل أنّ زيارة الصفحة مؤهّلة لاحتساب المواضيع بدون التسبّب في تكرار أو أخطاء. مع أنّ هذه السمة ليست مطلوبة في كل صفحة، إلا أنّ إرسالها كعنوان عادي في جميع المستندات ذات المستوى الأعلى هو استراتيجية صالحة وبسيطة.
فئات التصنيف	طلب تعديل أحدث تصنيف للمواضيع بإضافة مواضيع جديدة	نحن بصدد دراسة هذا الطلب، ونرحّب بتلقّي المزيد من الملاحظات من المنظومة المتكاملة هنا.
القيم الخالية	طلب إرشادات حول تحسين أداء Topics API وفهم أسباب الردود الفارغة، مثل الفلترة أو الحساسية	للتوضيح، إنّ الردود null أو الردود الفارغة من Topics API هي ميزة متوقّعة متعلّقة بالخصوصية وليست خطأً. يمكن أن يكون سبب ظهور الردّ null ما يلي: • قواعد الخصوصية: فرصة عشوائية بنسبة% 5 لظهور الردّ null أو لأنّ النص البرمجي لم "يراقب" المستخدم على المواقع الإلكترونية ذات الصلة بهذا الموضوع. • حالة المستخدم: سجلّ تصفّح غير كافٍ أو استخدام "وضع التصفّح المتخفي" أو عدم موافقة المستخدم على مشاركة بياناته في إعدادات خصوصية الإعلانات في Chrome • الأخطاء الفنية: يجب أن ترسل مواقع الناشرين العنوان Observe-Browse-Topics: ?1، ويجب أن تتضمّن أي إطارات iframe تتطلّب الاتصال الإذن allow="Browse-topics". للتدقيق في ذلك، استخدِم صفحة chrome://topics-internals تصحيح الأخطاء لمعرفة المواضيع التي حسبها متصفّحك وسبب ذلك. على الرغم من أنّ ميزات الخصوصية تمنع تحقيق معدّل ملء بنسبة% 100، يمكنك تحسين الأداء من خلال: • العمل مع الناشرين: تأكَّد من أنّ شركاءك يرسلون عنوان Observe-Browse-Topics: ?1 بشكل صحيح على مواقعهم الإلكترونية. • التحقّق من الرمز: إذا كنت تستخدم إطارات iframe، تأكَّد من أنّ سياسة allow="Browse-topics" مطبَّقة.

Protected Audience API

موضوع الملاحظات	ملخّص	ردّ Chrome
تكلفة واجهة PA API وتعقيدها يعيقان استخدامها	يعطي المتبنّون أولوية أقل لعمليات دمج Protected Audience API (PA API) أو يتراجعون عنها، مشيرين إلى التكاليف التشغيلية، وعدم توفّر طلب من المعلِنين، وانخفاض حجم المستودع الإعلاني من منصات التبادل. تضمّنت بعض الملاحظات فوائد محتملة لواجهة برمجة التطبيقات PA API، مثل قدرتها على الوصول إلى شرائح جمهور ثابتة وتحقيق مدى وصول فائق بسبب معدّل المطابقة المرتفع.	نأخذ هذه الملاحظات في الاعتبار أثناء تقييمنا للدور الذي ستؤديه واجهات Privacy Sandbox API في المستقبل، وذلك في ضوء إعلان Google في أبريل 2025 بأنّه سيتم الحفاظ على النهج الحالي الذي يتيح للمستخدمين اختيار ملفات تعريف الارتباط التابعة لجهات خارجية في Chrome.
استخدام الوظائف على عدّة منصات	يجب أن تتوافق الوظائف مع عدّة منصات من خلال استخدام PA API على جميع المنصات للاستفادة من إمكانات أكبر في ما يتعلق بإعادة الاستهداف واستهداف الجمهور. على Google إتاحة الوصول إلى "مجموعات الاهتمامات" (IG) المسجّلة في Chrome عند عرض الإعلانات في البيئات الأصلية أو داخل WebView، كما يجب أن تكون مجموعات الاهتمامات المسجّلة في Android متاحة في مزادات Chrome.	نأخذ هذه الملاحظات في الاعتبار أثناء تقييمنا للدور الذي ستؤديه واجهات Privacy Sandbox API في المستقبل، وذلك في ضوء إعلان Google في أبريل 2025 بأنّه سيتم الحفاظ على النهج الحالي الذي يتيح للمستخدمين اختيار ملفات تعريف الارتباط التابعة لجهات خارجية في Chrome.
directFromSellerSignals	من خلال الحدّ من كمية المعلومات المتاحة في المزاد السياقي، يتم توجيه المشاركين في المزاد دائمًا من خلال خادم إعلانات Google. على الناشر أن يتواصل أولاً مع جميع شركاء التبادل، ثم مع "مدير إعلانات Google" (GAM) ثانيًا لتنفيذ المزاد السياقي، وأخيرًا السماح لـ "مدير إعلانات Google" بتفعيل مزادات "المصلحة المستنِدة إلى الاهتمامات". وبدون معرفة نتيجة المزاد السياقي في الوقت الفعلي، لا يمكن لأي منافس اتّخاذ قرار على أعلى مستوى بشكل عادل. قد تفتقر ميزة directFromSellerSignals ضمن PA API إلى الشفافية بشأن معلومات المزاد، ما قد يعيق إمكانية الوصول إلى البيانات الضرورية. على Google إزالة directFromSellerSignals أو تعديلها كي لا يمكن استخدامها لإخفاء سعر التسوية في مزاد خادم الإعلانات. على سبيل المثال، يمكن تمرير السعر السياقي من خلال Chrome عبر حقل شفاف وغير قابل للتغيير وموقّع يمكن لجميع المشاركين في المزاد (والناشر) الوصول إليه والتحقّق منه.	لم يتغيّر ردّنا عن الردود التي قدّمناها في الأرباع السابقة: ردّ Chrome: لا يُعرف أنّ المعلومات التي يتم تمريرها إلى runAdAuction() تأتي من البائع إلا إذا طلب البائع تنفيذ runAdAuction() من إطار iframe الخاص به. في مزاد متعدّد البائعين، يصبح من المستحيل أن ينشئ جميع البائعين إطارًا يستدعي runAdAuction(). وقد عالجت directFromSellerSignals هذه المشكلة من خلال تحميل المحتوى من حزمة موارد فرعية يتم تحميلها من مصدر البائع. ويضمن ذلك عدم التلاعب بصحة وسلامة المعلومات التي يتم إرسالها إلى المزاد من إعدادات مزادات البائعين. إذا أراد الناشرون استخدام PA API لفهم أي من المعلومات التي يمرّرها مزوّدو التكنولوجيا إلى مزادات PA، يمكنهم طلب هذه الوظيفة من مزوّدي التكنولوجيا. ردّ "إدارة إعلانات Google": لقد حافظنا على تركيز قوي على عدالة المزاد لسنوات، بما في ذلك وعدنا بعدم مشاركة أي سعر من أي مصادر إعلانية غير مضمونة للناشر، بما في ذلك أسعار تفاصيل الإعلانات غير المضمونة، مع مشترٍ آخر قبل تقديم عروض الأسعار في المزاد، وهو ما أكّدناه لاحقًا في التزاماتنا مع هيئة المنافسة الفرنسية. في مزادات Protected Audience، نلتزم بوعدنا من خلال الاستفادة من directFromSellerSignals، ولن نشارك عرض سعر أي مشارك في المزاد مع أي مشارك آخر قبل اكتمال المزاد في المزادات المتعدّدة البائعين. وللتوضيح، لن نشارك سعر المزاد السياقي مع مزاد المكوّنات الخاص بنا أيضًا، كما هو موضّح في هذا التعديل.
إعداد التقارير	طلب إضافة كيان إحصاءات/إعداد تقارير لتفعيل إعداد التقارير بشكل مركزي	نناقش هذا الطلب هنا ونرحّب بأي ملاحظات إضافية.
K-Anonymity على buyerReportingId	إمكانية تجاهل عروض الأسعار استنادًا إلى مبدأ إخفاء الهوية k لعمود "buyerReportingId" من أجل تسهيل عملية تنظيم شرائح الجمهور والوفاء بالتزامات إعداد التقارير مع مقدّمي البيانات الخارجيين	نأخذ هذه الملاحظات في الاعتبار أثناء تقييمنا للدور الذي ستؤديه واجهات Privacy Sandbox API في المستقبل، وذلك في ضوء إعلان Google في أبريل 2025 بأنّه سيتم الحفاظ على النهج الحالي الذي يتيح للمستخدمين اختيار ملفات تعريف الارتباط التابعة لجهات خارجية في Chrome.
تحسين تصحيح الأخطاء في النص البرمجي generateBid	طلب آلية لتحديد المرحلة أو "نقطة التوقف" المحدّدة بسرعة ضمن النص البرمجي generateBid الذي يتعذّر فيه إكمال العملية	نحن على دراية بالاستخدام المطلوب لميزة "القياسات في الوقت الفعلي" كآلية لتحديد نقاط توقّف مؤقت للمزادات على الأجهزة. نأخذ هذه الملاحظات في الاعتبار أثناء تقييمنا للدور الذي ستؤدّيه واجهات برمجة التطبيقات ضمن "مبادرة حماية الخصوصية" في المستقبل، وذلك في ضوء إعلان Google في نيسان (أبريل) 2025 بأنّه سيتم الحفاظ على النهج الحالي لمنح المستخدمين خيار استخدام ملفات تعريف الارتباط التابعة لجهات خارجية في Chrome.
أدوات معالجة الأحداث لمراقبة حالة runAdAuction	اقتراح بإضافة إمكانية استخدام أدوات معالجة الأحداث إلى الدالة navigator.runAdAuction في PA API لتحسين مراقبة دورة حياة مزاد الإعلانات	نحن نقيّم هذا الطلب ونرحّب بتلقّي المزيد من الملاحظات من المنظومة المتكاملة هنا.
استخدام واجهة برمجة التطبيقات	طلب توضيح كيفية دعم واجهة برمجة التطبيقات PA API وواجهة برمجة التطبيقات Attribution Reporting API (ARA) لحالات استخدام الإعلانات على الويب في حال عدم توفّر ملفات تعريف الارتباط التابعة لجهات خارجية، لا سيما للمستخدمين الذين أوقفوا ملفات تعريف الارتباط التابعة لجهات خارجية ولكن لم يوقفوا واجهات برمجة تطبيقات "مبادرة حماية الخصوصية"، وفي السيناريوهات التي تتضمّن عمليات مزامنة ملفات تعريف الارتباط غير ناجحة وWebView؟	نأخذ هذه الملاحظات في الاعتبار أثناء تقييمنا للدور الذي ستؤديه واجهات Privacy Sandbox API في المستقبل، وذلك في ضوء إعلان Google في أبريل 2025 بأنّه سيتم الحفاظ على النهج الحالي الذي يتيح للمستخدمين اختيار ملفات تعريف الارتباط التابعة لجهات خارجية في Chrome.
وقت الاستجابة	قد يؤدي وقت الاستجابة المرتبط بواجهة برمجة التطبيقات PA API إلى عرقلة اعتمادها، إذ قد يختار الناشرون إيقافها إذا كان وقت الاستجابة طويلاً جدًا.	أجرينا العديد من التحسينات على وقت الاستجابة على الجهاز خلال الأرباع السنوية القليلة الماضية. سيستمر إنشاء خدمات عروض الأسعار والمزادات وتوسيع نطاقها حسب الحاجة. تم تعديل دليل أفضل الممارسات بشأن وقت الاستجابة ليشمل المزيد من المعلومات حول كيفية الاستفادة من هذه الميزات. نعمل أيضًا على استكشاف طرق جديدة لتحسين وقت الاستجابة، ويمكنك الاطّلاع على بعضها هنا.
تسجيل السلوك في B&A (البيئة التجريبية مقابل بيئة الإنتاج)	توضيح بشأن الاختلافات في سلوك التسجيل بين وضعَي الاختبار والإنتاج لخدمات "الفوترة والاشتراك" على وجه التحديد، مدى توفّر سجلّات السحابة الإلكترونية وتأثير وضع الإنتاج في التسجيل.	أولاً، من المهم التمييز بين إصدارات الإنتاج والإصدارات غير الإنتاجية ومعلَمة TEST_MODE المنفصلة التي تتيح ببساطة مفتاح تشفير اختباري مبرمَجًا. يركّز التوضيح أدناه على أنواع الإصدارات. في الإصدارات غير الإنتاجية، تتضمّن خوادم B&A مستوى تفصيلاً قابلاً للضبط لتسجيل البيانات. تتم كتابة هذه السجلّات التفصيلية في تدفقات stdout/stderr العادية. على Google Cloud، يمكن الوصول إلى هذه السجلات من خلال واجهة التسجيل الأصلية، ويمكن العثور عليها على Amazon Web Services في سجلات وحدة التحكّم المرفقة. بالنسبة إلى إصدارات المنتج، يكون سلوك التسجيل أكثر تقييدًا. مستوى التفصيل ثابت ولا يمكن تغييره. في حين أنّ بعض السجلات غير ذات الصلة بالخصوصية، مثل رسائل بدء تشغيل الخادم ومعظم أخطاء الأعطال، لا تزال تتم طباعتها في stdout/stderr، لا تتوفّر أي سجلات خاصة بالطلبات من خلال هذه القناة. إنّ سجلّات كل طلب على حدة من إصدار إنتاج مخصّصة فقط للطلبات التي تتضمّن رمزًا مميّزًا للموافقة على تصحيح الأخطاء، ويتم تصديرها حصريًا من خلال OpenTelemetry. من المهم استخدام تصحيح الأخطاء الذي تمّت الموافقة عليه باعتدال، لأنّ الزيارات الكثيفة يمكن أن تؤدي إلى تدهور أداء الخادم وإلى حدوث أخطاء في عمليات التحقّق من السلامة. في ما يتعلق بالمقاييس، يتم تصديرها جميعًا عبر OpenTelemetry. يتم دائمًا تصدير المقاييس غير الحسّاسة للخصوصية كما هي، بدون أي "تشويش". في المقابل، يتم دائمًا "تشويش" المقاييس التي تتطلّب مراعاة الخصوصية عند تصديرها من خادم يعمل في وضع الإنتاج. يحدّد إعداد القياس عن بُعد المحدّد ما إذا كان سيتم تصدير هذه المقاييس التي تتضمّن معلومات حساسة تتعلّق بالخصوصية على شكل بيانات مشوّشة أو غير مشوّشة أو كليهما.
تضمين مسار الصفحة الكامل في إشارات عروض الأسعار الموثوقة لضمان سلامة العلامة التجارية	طلب تعديل PA API لتضمين مسار عنوان URL الكامل للصفحة ذات المستوى الأعلى، بالإضافة إلى اسم المضيف، في طلب الجلب الخاص بـ trustedBiddingSignals حالة الاستخدام الأساسية هي تفعيل عناصر تحكّم أكثر دقة في أمان العلامة التجارية. يحتاج المعلنون غالبًا إلى حظر عرض الإعلانات في أقسام معيّنة من نطاق (مثل news-site.com/politics) مع عدم وجود مشكلة لديهم في النطاق بشكل عام. وبما أنّ قوائم الحظر هذه يمكن أن تتضمّن ملايين الإدخالات، يجب تقييمها من جهة الخادم. تتضمّن المواصفات الحالية إرسال اسم المضيف فقط، ما يجعل من المستحيل على خادم trustedBiddingSignals إجراء هذا التقييم الضروري على مستوى المسار، ما يحدّ من إمكانات أمان العلامة التجارية.	نناقش حاليًا هذه المشكلة هنا، بعد مناقشات سابقة مستفيضة يمكن الاطّلاع عليها هنا، ونرحّب بتلقّي المزيد من الملاحظات. مع ذلك، نريد توضيح أنّنا لن نأخذ في الاعتبار إضافة هذه المعلومات إلا عندما يتم إرسال طلب جلب trustedBiddingSignals إلى خادم يعمل داخل بيئة تنفيذ موثوقة (TEE).

المزاد المحمي (خدمات B&A)

موضوع الملاحظات	ملخّص	ردّ Chrome
التحقّق من توفّر الاختبار	معلومات حول مدى توفّر الإصدار 2 من Key/Value (KV) للاختبار في كلّ من بيئات Chrome وB&A	يتوفّر الإصدار 2 من KV على كلّ من "بحث Google" وChrome. تتوفّر إرشادات إضافية هنا.
تنفيذ خادم KV	طلب توضيح بشأن استخدام خادم KV، وتحديدًا فيما يتعلق بربط عناوين URL لعرض تصميمات الإعلانات ببيانات الطلب، وضرورة التنسيق بين منصات عرض الإعلانات من جهة المورّد ومنصة طلب الإعلانات من جهة المعلِن لتحديد المَعلمات في عنوان URL لعرض التصميم، وتوفُّر مستندات توضّح التنسيق المطلوب وتخزين البيانات في وضع KV.	تستخدم خدمة KV السمة renderURL كمفتاح. إذا كان عنوان URL جديدًا، سيتم تخزينه. إذا كان هذا الحقل متوفّرًا، يتم عرض قيمته لاستخدامها في الدالة scoreAd. يعتمد تنسيق الإرجاع على الإعداد: يتيح خيار "استخدام الخادم الخاص بك" (BYOS) أي قيمة، بينما تتطلّب خدمة Trusted KV دالة من تعريف المستخدم. على الرغم من أنّ التنسيق مع منصّات عرض الطلب ليس مطلوبًا دائمًا، إلا أنّه ضروري للاستفادة من ميزات مثل استبدال وحدات الماكرو (مثل ${AD_WIDTH}) in the renderURL, which enables dynamic ad customization and verification. ننصحك بالبدء باختبار بسيط مع منصة طلب واحدة لتحديد مستوى التنسيق اللازم. نحن بصدد تعديل مستندات KV وسنشاركها بشكل علني فور توفّرها.
استخدام أدواتك الخاصة في "إعلانات Google" و"إعلانات Bing"	لماذا لا توفّر خدمة "التحليلات والمقاييس" وضع BYOS مشابهًا لوضع BYOS في KV؟	تتطلّب ميزة "التحليل والمقارنة" بيئة تنفيذ موثوقة (TEE)، ما يمنع استخدام نموذج "إحضار نظامك الخاص"، لأنّها تتعامل مع مجموعات بيانات حسّاسة للغاية تتطلّب فرض آليات الخصوصية، كما هو موضّح أدناه. لمنصّات عرض الطلب: تعالج منصّة "الشراء والبيع" سياق الناشر (قد يكون عنوان URL كاملاً إذا أرسله البائع بشكل صريح من خلال auctionSignals / perBuyerSignals) مع بيانات "مجموعة الاهتمامات" التفصيلية للمستخدِم. بيئة التنفيذ الموثوقة ضرورية لمعالجة هذه المجموعة بشكل آمن ولمنع إعادة تحديد هوية المستخدمين المحتملة. في KV BYOS، لا يمكن إرسال عنوان URL الكامل. بالنسبة إلى منصّات عرض الإعلانات من جهة المورّدين: يمكن أن يؤدي مجرد معرفة مجموعة "المجموعات المشابهة" المشارِكة (ومالكي منصّات الطلب الخاصة بها) في مزاد إلى إنشاء توقيع تعريفي. وهنا يأتي دور حل التمويه الذي يتطلّب استخدام بيئة تنفيذ موثوقة (TEE). لذلك، تتطلّب المعالجة الآمنة لهذه الإشارات الحسّاسة المجمّعة وتنفيذ آليات الخصوصية توفُّر بيئة خاضعة للرقابة وموثوقة في بيئة التنفيذ الموثوقة (TEE).

قياس أداء الإعلانات الرقمية

‫Attribution Reporting (وواجهات برمجة التطبيقات الأخرى)

موضوع الملاحظات	ملخّص	ردّ Chrome
سياسة الضوضاء	وقد كان تنفيذ ARA مفيدًا لبعض المشاركين في السوق، ويجب أن تواصل Google الحفاظ على إعداد التقارير على مستوى الحدث. على Google أن تخفّف من صرامة سياسة الضوضاء في الحالات التي يتوفّر فيها كلّ من "الحدّ من الضوضاء" و3PC. يستخدم المعلِنون الذين يركّزون على الأداء بشكل متزايد التنفيذ الحالي للحقل "القيمة" في حدث ARA المرن، وسيساعد وضع سياسة أقل صرامة بشأن الضوضاء في الحدّ من التأخيرات وإعداد التقارير غير الدقيقة.	تشكّل هذه الآلية جزءًا أساسيًا من تصميم ARA، وهي تهدف إلى حماية خصوصية المستخدم من خلال منع التتبُّع الفردي. نأخذ في الاعتبار الملاحظات الواردة بشأن التحديات المتعلقة بإعداد التقارير الناتجة عن الضوضاء، ونواصل تقييم الدور الذي ستؤديه واجهات برمجة التطبيقات ضمن "مبادرة حماية الخصوصية" في المستقبل، بالإضافة إلى أي تحسينات محتملة في المستقبل، وذلك في ضوء إعلان Google في نيسان (أبريل) 2025 بأنّه سيتم الحفاظ على النهج الحالي الذي يتيح للمستخدمين اختيار ملفات تعريف الارتباط التابعة لجهات خارجية في Chrome.
خريطة الطريق والدعم الطويل الأمد	طلب خارطة طريق المنتج لـ ARA، بالإضافة إلى تأكيد الاستثمار والدعم على المدى الطويل في ضوء الإعلان عن عدم المضي قدمًا في طرح آلية لاختيار المستخدمين بشأن ملفات تعريف الارتباط التابعة لجهات خارجية	يتواصل فريق "مبادرة حماية الخصوصية" مع المنظومة المتكاملة لفهم الدور الذي ستؤدّيه واجهات برمجة التطبيقات من "مبادرة حماية الخصوصية" في المستقبل وتقييم أي استثمارات مستقبلية.
القياس على جميع البيئات (من التطبيق إلى الويب)	طلب حلّ يتضمّن استخدام ميزة "القياس على جميع الأجهزة" لتسهيل القياس على مستوى بيئات متعدّدة، ما يوفّر تدفّقًا أنظف وأكثر موثوقية للبيانات، ويحسّن القدرة على ربط تفاعلات المستخدِمين على مستوى منصّات مختلفة.	تتيح ميزة "التنقّل من التطبيق إلى الويب" على الجهاز نفسه حاليًا استخدام "إعادة توجيه المستخدمين تلقائيًا". يمكنك الاطّلاع على مزيد من التفاصيل حول حلّ قياس الأداء على التطبيقات والمواقع الإلكترونية هنا وهنا.
تحديد المصدر من عدة متصفّحات	من شأن اتّباع نهج موحّد ومتوافق مع جميع المتصفّحات بشأن ميزة ARA أن يحسّن بشكل كبير القدرة على قياس عائد الاستثمار على الويب المفتوح، وأن يوفّر بديلاً مستقرًا قبل حدوث أي تغييرات تنظيمية محتملة. على فريق Chrome التعاون مع فريق Safari لإيجاد حلّ مشابه.	نستكشف حاليًا واجهة برمجة تطبيقات قابلة للتشغيل التفاعلي مع مورّدي متصفحات آخرين في مجموعتَي PATCG وPATWG ضمن W3C. مع العلم أنّ هذا العمل أولي، يمكن للأطراف المعنية الاطّلاع على مدى تقدّمنا هنا.
القياس على جميع الأجهزة/القياس بلا إنترنت	عدم إمكانية قياس الإحالات الناجحة على جميع الأجهزة ضمن "الوصول إلى الجمهور المناسب" هو قيد كبير. قياس الإحالات الناجحة من الإنترنت إلى أرض الواقع مهم أيضًا، ويمكن أن يؤدي المتصفّح دورًا في التعاون مع مورّدي خدمات القياس.	نأخذ هذه الملاحظات في الاعتبار أثناء تقييمنا للدور الذي ستؤديه واجهات Privacy Sandbox API في المستقبل، وذلك في ضوء إعلان Google في أبريل 2025 بأنّه سيتم الحفاظ على النهج الحالي الذي يتيح للمستخدمين اختيار ملفات تعريف الارتباط التابعة لجهات خارجية في Chrome.
تحديد المصدر بالاستناد إلى نقاط اتصال متعددة	طلب السماح للمعلِنين باستخدام بيانات "مبادرة حماية الخصوصية" كـ "حقيقة أساسية" غير متحيزة للتحقّق من صحة نماذج تحديد المصدر الحالية ومعايرتها. ويمكن تحقيق ذلك من خلال استخدام بيانات ARA التي يوفّرها المتصفّح كإشارة معايرة موثوقة، ما يؤدي إلى إنشاء أساس موثوق.	نأخذ هذه الملاحظات في الاعتبار أثناء تقييمنا للدور الذي ستؤديه واجهات Privacy Sandbox API في المستقبل، وذلك في ضوء إعلان Google في أبريل 2025 بأنّه سيتم الحفاظ على النهج الحالي الذي يتيح للمستخدمين اختيار ملفات تعريف الارتباط التابعة لجهات خارجية في Chrome.
قياس عدد الزيارات بدون موافقة أو بعد إيقاف التتبُّع	يمكن استخدام حلّ يحافظ على الخصوصية، مثل Interoperable Private Attribution، لإتاحة القياس للزيارات التي لا تتطلّب موافقة. سيسمح ذلك بفهم أداء الحملة بشكل أكثر شمولاً من خلال تضمين بيانات من المستخدمين الذين أوقفوا ميزة التتبّع، ما يؤدي إلى معالجة فجوة كبيرة في القياس ناتجة عن متطلبات الموافقة.	نأخذ هذه الملاحظات في الاعتبار أثناء تقييمنا للدور الذي ستؤديه واجهات Privacy Sandbox API في المستقبل، وذلك في ضوء إعلان Google في أبريل 2025 بأنّه سيتم الحفاظ على النهج الحالي الذي يتيح للمستخدمين اختيار ملفات تعريف الارتباط التابعة لجهات خارجية في Chrome.
تحديد المصدر من خادم إلى خادم	طلب السماح لتقنيات الإعلان التي تتضمّن بنية أساسية متطوّرة من جهة الخادم بالدمج مع "قياس مدى الوصول إلى الجمهور" بطريقة أكثر مرونة، ما يتيح حالات الاستخدام التي يصعب إدارتها من جهة العميل فقط، مع الحفاظ على خصوصية المستخدم.	نأخذ هذه الملاحظات في الاعتبار أثناء تقييمنا للدور الذي ستؤديه واجهات Privacy Sandbox API في المستقبل، وذلك في ضوء إعلان Google في أبريل 2025 بأنّه سيتم الحفاظ على النهج الحالي الذي يتيح للمستخدمين اختيار ملفات تعريف الارتباط التابعة لجهات خارجية في Chrome.
التسجيل في نطاقات متعدّدة	نحتاج إلى توضيح بشأن القيود والشروط عند تسجيل نطاقات متعدّدة في ARA، لا سيما ما يتعلّق بخدمة التجميع وتحديد المصدر على مستوى المواقع الإلكترونية المختلفة.	في ما يلي القيود الرئيسية عند استخدام ARA مع نطاقات متعددة: • يقتصر تحديد المصدر على مصدر واحد. لا يمكنك مطابقة نقرة من أحد نطاقاتك مع إحالة ناجحة على نطاق آخر. يتم عزل عملية تحديد المصدر في وضع الحماية ضمن المصدر نفسه لكلّ من المصدر والمشغّل. • لا تتيح "خدمة التجميع" تجميع البيانات من مصادر متعددة في حزمة واحدة. يجب تجميع التقارير من مصادر مختلفة ومعالجتها بشكل منفصل. ونحن نستكشف طرقًا لإتاحة هذه الميزة في المستقبل. باختصار، على الرغم من إمكانية تسجيل نطاقات متعددة ضمن كيان واحد، يجب حاليًا التعامل مع جميع وظائف ARA، مثل تحديد المصدر والتجميع، على أساس كل مصدر على حدة.

خدمة تجميع البيانات

لم نتلقَّ أي ملاحظات في هذا الربع.

Private Aggregation API

موضوع الملاحظات	ملخّص	ردّ Chrome
الحدود ومستويات الضوضاء	مخاوف بشأن القيود المفروضة على أحجام مفاتيح التجميع وقيم التجميع ضمن واجهة برمجة التطبيقات Private Aggregation API	تم اختيار أحجام مفتاح التجميع والقيمة لتوفير مستوى دقة عالٍ مع الحدّ من تكاليف الشبكة والتخزين. ننصحك أيضًا باستخدام التجزئة عند تعيين المفاتيح لزيادة المرونة إلى أقصى حدّ. مع أنّ هناك عوامل أخرى تحمي بيانات المستخدمين، فإنّ إضافة التشويش هي أحد الجوانب المهمة في إجراءات حماية الخصوصية التي توفّرها Private Aggregation API. نأخذ ملاحظاتك بعين الاعتبار وسنواصل تقييم الخيارات المناسبة للمعلمات، بالإضافة إلى تقييمنا للدور الذي ستؤدّيه واجهات Privacy Sandbox API في المستقبل، وذلك في ضوء إعلان Google في أبريل 2025 بأنّه سيتم الحفاظ على النهج الحالي المتمثّل في منح المستخدمين خيار استخدام ملفات تعريف الارتباط التابعة لجهات خارجية في Chrome.
الخصوصية مقابل الفائدة	قد تعطي "مبادرة حماية الخصوصية" الأولوية للخصوصية على حساب الفائدة، ما قد يعيق استخدامها. اقتراح بالسماح بمشاركة بيانات أكثر تفصيلاً بموافقة المستخدم لتحسين القياس وتخصيص الإعلانات	تم اختيار أحجام مفتاح التجميع والقيمة لتوفير مستوى دقة عالٍ مع الحدّ من تكاليف الشبكة والتخزين. ننصحك أيضًا باستخدام التجزئة عند تعيين المفاتيح لزيادة المرونة إلى أقصى حدّ. نأخذ هذه الملاحظات في الاعتبار أثناء تقييمنا للدور الذي ستؤديه واجهات برمجة التطبيقات الخاصة بـ "مبادرة حماية الخصوصية" في المستقبل، وذلك في ضوء إعلان Google في نيسان (أبريل) 2025 بأنّه سيتم الحفاظ على النهج الحالي الذي يتيح للمستخدمين اختيار ملفات تعريف الارتباط التابعة لجهات خارجية في Chrome.

فرض قيود على التتبّع الخفي

تقليل معلومات الوكيل المستخدم/حقول معلومات العميل لوكيل المستخدم

موضوع الملاحظات	ملخّص	ردّ Chrome
رصد المحتوى غير المرغوب فيه	إذا كان الطلب الأول من موقع إلكتروني يستخدم نظامًا لرصد المحتوى غير المرغوب فيه يعتمد على تلميحات العميل، قد يتعذّر على نظام التتبّع أو الرصد تحديد الطلب أو تصنيفه بشكل صحيح.	يجب أن تستخدم حالات الاستخدام التي تعتمد على إمكانية الوصول إلى "تعديلات برنامج وكيل المستخدم" (UA-CH) في الطلب الأول تعديلات برنامج وكيل المستخدم المهمة.
ملاحظات حول واجهة برمجة التطبيقات	ننصح بإيقاف الحقل Sec-CH-USA-Wow64 نهائيًا لأنّه لم يعُد مناسبًا للويب الحديث.	نحن نأخذ هذا الطلب في الاعتبار ونرحّب بتلقّي المزيد من الملاحظات هنا. تلقّينا أيضًا ملاحظات تفيد بأنّه سيكون من المفيد توسيع نطاق wow64 ليشمل أنظمة تشغيل أخرى غير Windows.

ميزة "حماية عنوان IP" (المعروفة سابقًا باسم Gnatcatcher)

موضوع الملاحظات	ملخّص	ردّ Chrome
عناصر التحكّم	طلب تبديل ميزة "حماية عنوان IP" للمواقع الإلكترونية لاستخدامها بشكل انتقائي خارج "وضع التصفّح المتخفي"	نحن نقدّر ملاحظاتك ونرحّب بتلقّي المزيد من المعلومات حول هذه المشكلة هنا.
سوء السلوك	هل ستؤدي الرموز المميزة للكشف الاحتمالي (PRT) التي تؤدي إلى قيمة NULL إلى منع تحديد هوية الجاني عندما تطلب الشرطة الإفصاح عن عنوان IP بسبب سوء السلوك على المنصة؟	إذا تم استخدام نطاق حصريًا لرصد الاحتيال وإساءة الاستخدام، من المحتمل ألا يكون مضمّنًا في "قائمة النطاقات المخفية" (MDL)، وبالتالي لن يتأثر بميزة "حماية عنوان IP". وبالتالي، لن تكون هناك حاجة إلى سجلات PRT لهذه النطاقات. إذا تم تضمين نطاق في قائمة MDL، فإنّ رموز PRT هي حاليًا الطريقة الوحيدة لمعرفة عنوان IP الأصلي لطلب تم توجيهه عبر خادم وكيل. بما أنّ تقارير الخصوصية المحسّنة مصمّمة خصيصًا لإتاحة التحليل المجمّع وليس تحديد الهوية الفردية، صحيح أنّ تقارير الخصوصية المحسّنة لن تتضمّن عنوان IP في معظم الحالات. نتوقّع أن يكون لهذا الإجراء تأثير محدود في السيناريو الموضّح، لأنّ ميزة "حماية عنوان IP" تنطبق فقط في سياق الجهات الخارجية، ما يعني أنّ الناشرين سيواصلون تلقّي عناوين IP غير مُوكّلة بالخادم الوكيل للتفاعلات مع الطرف الأول، مثل زيارة المستخدمين لموقع إلكتروني تابع لمنصة على الإنترنت.
مكافحة الممارسات الاحتيالية	ما هي تفاصيل إجراءات Google لمكافحة الاحتيال في ما يخصّ حماية الملكية الفكرية، بما في ذلك تفاصيل حول الحدّ من معدّل الوصول إلى الخوادم الوكيلة وإصدار رموز المصادقة المميزة، وما هي حالات الاستخدام المحدّدة لرموز PRT؟	نؤكّد أنّ ميزة "حماية عنوان IP" تتضمّن رموزًا مميّزة للمصادقة والحدّ من عدد الطلبات المصمّمة لمنع برامج التتبُّع من تنفيذ عمليات احتيال إعلاني من خلال الوصول المفرط إلى الخوادم الوكيلة، كما هو موضّح بالتفصيل في استراتيجية مكافحة الاحتيال ومكافحة الرسائل غير المرغوب فيها. يمكنك الاطّلاع على المزيد من حالات استخدام PRT في مستندات شرح PRT هنا.
وضع التصفّح المتخفي	هل ما زلنا نخطّط لإطلاق ميزة "حماية عنوان IP" في "وضع التصفّح المتخفي" خلال الربع الثالث من العام؟	لم يتم إجراء أي تغييرات حاليًا على الجدول الزمني للربع الثالث من العام لإطلاق ميزة "حماية عنوان IP" في وضع التصفّح المتخفي.

إجراءات الحدّ من التتبّع الارتدادي

موضوع الملاحظات	ملخّص	ردّ Chrome
ملاحظات حول واجهة برمجة التطبيقات	يجب أن يحظر Chrome الوصول إلى ملفات تعريف الارتباط أو مساحة التخزين بدلاً من تقسيمها عند تطبيق ميزة "الحدّ من تتبُّع الارتداد" (BTM)، وذلك بسبب السلوك غير المقصود والارتباك الناتج عن طريقة "التقسيم" التي يتّبعها متصفّح Safari.	نرحّب بهذا الاقتراح. في الوقت الحالي، لا تتضمّن ميزة "قياس الإحالات الناجحة المحسّن" تقسيم ملفات تعريف الارتباط أو مساحة التخزين، بل تحذفها بعد فترة سماح. إذا كانت هناك أي تصاميم لاحقة لـ BTM تتضمّن إجراءً فوريًا بشأن ملفات تعريف الارتباط، سنفضّل حظر ملفات تعريف الارتباط على تقسيمها.

تعزيز حدود الخصوصية على مستوى المواقع الإلكترونية

مجموعة المواقع الإلكترونية المرتبطة (المعروفة سابقًا باسم "مجموعات نطاقات الطرف الأول")

لم نتلقَّ أي ملاحظات في هذا الربع.

Fenced Frames API

لم نتلقَّ أي ملاحظات في هذا الربع.

Shared Storage API

موضوع الملاحظات	ملخّص	ردّ Chrome
طلب ميزة في واجهة برمجة التطبيقات	طلب لإضافة مرات مشاهدة الإعلان والنقرات عليه في "مساحة التخزين المشترَكة".	نأخذ هذه الملاحظات في الاعتبار أثناء تقييمنا للدور الذي ستؤديه واجهات Privacy Sandbox API في المستقبل، وذلك في ضوء إعلان Google في أبريل 2025 بأنّه سيتم الحفاظ على النهج الحالي الذي يتيح للمستخدمين اختيار ملفات تعريف الارتباط التابعة لجهات خارجية في Chrome.

ملفات تعريف الارتباط في الحالة المقسَّمة المنفصلة (CHIPS)

موضوع الملاحظات	ملخّص	ردّ Chrome
سؤال حول واجهة برمجة التطبيقات	طلب توضيح بشأن كيفية تفاعل عناصر التحكّم في ملفات تعريف الارتباط التابعة لجهات خارجية في Chrome مع CHIPS، وتحديدًا ما إذا كان يتم تحويل ملفات تعريف الارتباط غير المقسّمة إلى ملفات مقسّمة عند إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية، وما إذا كانت ملفات تعريف الارتباط المقسّمة تظل نشطة.	لن يتم تخزين ملفات تعريف الارتباط غير المقسّمة أو استرجاعها أو إرسالها في سياق تابع لجهة خارجية عند إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية. في المقابل، سيستمر تخزين ملفات تعريف الارتباط المجزّأة واسترجاعها وإرسالها في سياق تابع لجهة خارجية، لأنّ وظائفها لا تتأثر بإعدادات المتصفّح التي توقف ملفات تعريف الارتباط التابعة لجهات خارجية.
مشكلة تتعلّق بالخصوصية	هناك قلق من أنّ جهة خارجية مضمّنة لديها معرّف ثابت، مثل معرّف الدخول المُوحَّد، قد تتيح لكلّ من الجهة المضمّنة والجهة التي تضمّنها الحصول على معرّف رقمي عالمي، حتى مع استخدام ملفات تعريف الارتباط المقسّمة.	على الرغم من أنّ الجهة المضمَّنة قد يكون لديها معرّف ثابت، لا يمكن الوصول إلى هذا المعرّف إلا على الموقع الإلكتروني الذي تم فيه ضبط ملف تعريف الارتباط من خلال المحتوى المضمَّن، وذلك عند تخزينه في ملف تعريف ارتباط مقسَّم. سيتطلّب ربط هذا المعرّف بمواقع إلكترونية مختلفة إجراء تسجيل دخول، ما يتيح تبادل معرّف على شكل رمز مميّز للمصادقة، حتى بدون استخدام ملفات تعريف الارتباط المقسّمة.

FedCM

موضوع الملاحظات	ملخّص	ردّ Chrome
استخدام واجهة برمجة التطبيقات	تعذُّر التوسّط الصامت للمستخدمين الذين لديهم حسابات متعدّدة بدون ظهور خطأ محدّد	إنّ سلوك التوسّط بدون إذن هو ميزة مصمَّمة، لأنّها مخصّصة لحالة محدّدة جدًا يتوفّر فيها حساب واحد فقط. ننصحك بدلاً من ذلك باستخدام ميزة "التوسّط الاختياري"، التي تتيح لـ FedCM عرض أداة اختيار الحساب للمستخدم في حال تعذّر التوسّط بدون تفاعل.
استخدام واجهة برمجة التطبيقات	تعرض navigator.credentials.get أخطاء عامة، ما يمنع تسجيل أسباب الرفض المحدّدة، مثل إغلاق المستخدم للإشعار أو فترات الانتظار.	إنّ عدم قدرة المطوّرين على التمييز بين إغلاق المستخدم لمربّع حوار FedCM وبين حدوث خطأ في الشبكة وبين كون FedCM في "فترة تهدئة" بسبب إغلاق المستخدم لمربّع الحوار في السابق هو أيضًا ميزة مصمَّمة للحفاظ على خصوصية المستخدم. ويكمن القلق في أنّ هذه الإمكانية ستسمح للمواقع الإلكترونية باستنتاج حالة تسجيل الدخول للمستخدم على موفِّرات الهوية المختلفة.
تسجيل الدخول	تم رصد سلوك غير متسق في اختيار الحسابات عند تسجيل الدخول إلى حسابات متعددة.	من غير الواضح ما إذا كان تعذُّر اختيار حساب معيّن بشكل متقطّع في سيناريو تسجيل الدخول إلى عدة حسابات هو خطأ متقطّع في FedCM أو مشكلة تتعلّق بنظام الاختبار. نحن نعمل مع الشخص الذي أبلغ عن المشكلة لحلّها، وطلبنا منه تقديم المزيد من التفاصيل كي نفهمها بشكل أفضل.
استخدام واجهة برمجة التطبيقات	إذا أغلق المستخدم مربّع الحوار أثناء التفويض باستخدام FedCM، لن يتم الإبلاغ عن حالة الانتظار من خلال خطأ يمكن رصده.	نعم، هذا هو الحال، وسيؤدي ذلك إلى ظهور رمز الخطأ العام للحفاظ على خصوصية المستخدم.
استخدام واجهة برمجة التطبيقات	لماذا تدخل FedCM في فترة حظر مدتها 10 دقائق بعد إتمام عملية "إعادة المصادقة التلقائية" بنجاح؟	بما أنّ إعادة المصادقة التلقائية تتم بدون إجراء من المستخدم، إذا أراد المستخدم الرجوع إلى الموقع الإلكتروني ولكن تسجيل الدخول باستخدام حساب مختلف، سيحتاج إلى فترة زمنية لا تعيد فيها FedCM مصادقته تلقائيًا. توفّر "فترة عدم النشاط" فرصة للمستخدمين لتسجيل الدخول يدويًا باستخدام حساب مختلف. يتضمّن منشور المدونة هذا مزيدًا من التفاصيل حول "فترة الهدوء".
Lightweight FedCM	مخاوف من أنّ اقتراح Lightweight FedCM يفرض تعقيدًا إضافيًا على مقدّمي خدمات تحديد الهوية بسبب الحاجة إلى توفير طريقتَي تنفيذ غير متوافقتَين (FedCM وLightweight FedCM).	تتوافق Lightweight FedCM مع FedCM التقليدية. يمكن لموفّري خدمات تحديد الهوية اختيار طريقة التنفيذ التي يريدون استخدامها، ولن يُطلب منهم توفير الطريقتَين معًا. ‫Lightweight FedCM هي آلية إرسال لـ FedCM. إذا اختار موفِّر الهوية استخدام هذه الميزة، يمكنه إرسال معلومات الحساب إلى المتصفّح عند تسجيل دخول المستخدم، وبالتالي، عندما يستدعي الطرف المعتمَد (RP) واجهة FedCM، سيتم استرداد الحساب من المتصفّح بدلاً من نقطة نهاية الحسابات الخاصة بموفِّر الهوية.
Lightweight FedCM	مخاوف بشأن إفشاء بيانات المستخدمين الشخصية، مثل الاسم والبريد الإلكتروني وصورة الملف الشخصي، إلى الطرف المعتمد في اقتراح Lightweight FedCM	تم تعديل اقتراح Lightweight FedCM منذ تلقّي هذه الملاحظات، وذلك لإزالة الاسم والبريد الإلكتروني وصورة الملف الشخصي من ردّ الطريقة.
Lightweight FedCM	يبدو أنّ إدارة حسابات متعدّدة تم تسجيل الدخول إليها تتسم بالصرامة الشديدة في اقتراح Lightweight FedCM. لا يتيح الاقتراح حاليًا تحديد مدة بقاء الجلسة الفردية أو حالات تسجيل الدخول الدقيقة لكل حساب.	يرتبط تاريخ انتهاء الصلاحية حاليًا بموفّر الهوية (IdP) ضمن عنصر بيانات الاعتماد. لقد أخذنا علمًا بأنّ انتهاء الصلاحية لكل حساب هو سؤال مفتوح، وسنأخذ هذه الملاحظات في الاعتبار عند إجراء أي تحسينات مستقبلية.
Lightweight FedCM	إنّ التمييز بين "تم تسجيل الدخول" و "متاح للاختيار" غير محدّد بوضوح، ما قد يؤثّر في تجربة المستخدمين في ما يتعلّق باقتراح Lightweight FedCM.	لا تتوفّر حاليًا إمكانية التمييز بين الحسابات المسجّلة الدخول والخارجة من النظام في واجهة مستخدم FedCM. يجب عدم إدراج الحسابات التي تم تسجيل الخروج منها. إذا تم تسجيل الخروج من حساب وتم إدراجه، واختار المستخدم الحساب الذي لم يتم تسجيل الدخول إليه بشكل نشط، يمكن استخدام Continuation API لكي يعيد المستخدم تسجيل الدخول.
استخدام واجهة برمجة التطبيقات	عدم اتساق بين الحقل given_name في getUserInfo واستخدامه في واجهة مستخدم FedCM	تمت مناقشة هذه المشكلة بشكل أكبر مع Mozilla هنا، من أجل الاتفاق على كيفية التعامل مع given_name في getUserInfo.
استخدام واجهة برمجة التطبيقات	لا يتم توفير جميع الحقول المستخدَمة في واجهة المستخدم من IdentityProviderAccount إلى getUserInfo، وتحديدًا tel وusername، ما يشير إلى الحاجة إلى المزامنة.	تتواصل المناقشات مع Mozilla وأعضاء آخرين من مجموعة FedID Community Group بشأن تسوية الحقول التي يتم إرسالها من IdentityProviderAccount إلى getUserInfo..
Enterprise FedCM	طلب توفير دعم FedCM لحالات استخدام موفّر الهوية في المؤسسات	تتمثّل المشكلة الرئيسية في الحاجة إلى آلية موثوقة تتيح لموفّري خدمات تحديد الهوية إرسال إشارة إلى المتصفّحات تفيد بأنّ المشرفين قد وافقوا مسبقًا على السماح للمستخدم بالوصول إلى أطراف معينة لا يمكن محاكاتها و/أو إساءة استخدامها من قِبل أدوات التتبُّع على الويب. تمت مناقشة ذلك في اجتماع مجموعة FedID CG الذي عُقد في 22 أبريل (يمكنك الاطّلاع هنا على ملاحظات الاجتماع)، وتم اقتراح مجموعات من إضافات المتصفّح وسياسات المؤسسة (للأجهزة المُدارة) كحلول محتملة. نرحّب بتلقّي المزيد من الملاحظات حول هذه المشكلة هنا.

مكافحة المحتوى غير المرغوب فيه والاحتيال

Private State Token API (وواجهات برمجة التطبيقات الأخرى)

لم نتلقَّ أي ملاحظات في هذا الربع.