تقرير ربع سنوي للربع الثاني من العام 2023 يلخّص الملاحظات التي تم تلقّيها بشأن المنظومة المتكاملة حول اقتراحات "مبادرة حماية الخصوصية" واستجابة Chrome.
في إطار التزاماتها تجاه "مبادرة حماية الخصوصية"، وافقت Google على تقديم تقارير ربع سنوية للجميع عن عملية تفاعل الأطراف المعنية ضمن اقتراحات "مبادرة حماية الخصوصية" (يُرجى الرجوع إلى الفقرتين 12 و17(ج)(2) من الالتزامات). يتم إنشاء تقارير ملخّص ملاحظات "مبادرة حماية الخصوصية" هذه من خلال تجميع الملاحظات التي يتلقاها Chrome من مصادر مختلفة كما هو مُدرَج في نظرة عامة على الملاحظات، بما في ذلك على سبيل المثال لا الحصر: مشاكل GitHub ونموذج الملاحظات المتاح على privacysandbox.com والاجتماعات مع الجهات المعنية في المجال ومنتديات معايير الويب. يرحب Chrome بالملاحظات الواردة من المنظومة المتكاملة ويستكشف بشكل نشط طرقًا لدمج ما تعلّمته في قرارات التصميم.
يتم ترتيب مواضيع الملاحظات والآراء حسب الانتشار حسب واجهة برمجة التطبيقات. ويتم ذلك من خلال تجميع مقدار الملاحظات التي تلقّاها فريق Chrome حول موضوع معيّن والتنظيم بترتيب تنازلي للكمية. تم تحديد موضوعات الملاحظات الشائعة من خلال مراجعة موضوعات المناقشة من الاجتماعات العامة (W3C وPatCG وIETF)، والملاحظات المباشرة، وGitHub، والأسئلة الشائعة التي تظهر من خلال الفرق الداخلية والنماذج العامة في Google.
وبشكل أكثر تحديدًا، تمت مراجعة محاضر اجتماعات اجتماعات الهيئات القياسية على الويب، وللملاحظات المباشرة، تمت مراجعة سجلات Google للاجتماعات الفردية مع الأطراف المعنية ورسائل البريد الإلكتروني التي تلقاها مهندسون فرديون والقائمة البريدية لواجهة برمجة التطبيقات ونموذج الملاحظات العامة. بعد ذلك، نسقت Google بين الفرق المشاركة في أنشطة التوعية المختلفة هذه لتحديد الانتشار النسبي للموضوعات التي تظهر فيما يتعلق بكل واجهة برمجة تطبيقات.
تم تطوير تفسيرات ردود Chrome على التعليقات استنادًا إلى الأسئلة الشائعة المنشورة، والردود الفعلية التي تم تقديمها على المشاكل التي طرحتها الأطراف المعنية، وتحديد الموضع خصيصًا لأغراض تمرين إعداد التقارير العلني هذا. في إطار التركيز الحالي على التطوير والاختبار، تلقّينا أسئلة وملاحظات خاصة في ما يتعلق بالمواضيع وProtected Audience API وAttribution Reporting API.
إنّ التعليقات التي يتم تلقّيها بعد انتهاء الفترة المشمولة بالتقارير الحالية قد لا تكون قد استجابت Chrome بعين الاعتبار.
مسرد الاختصارات
- الشرائح
- ملفات تعريف الارتباط في الحالة المقسَّمة المنفصلة
- معالِج الإشارات الرقمية (DSP)
- منصّة الطلب
- FedCM
- إدارة بيانات الاعتماد الموحدة
- لقطات في الثانية
- مجموعات الطرف الأول
- مكتب الإعلانات التفاعلية (IAB)
- مكتب الإعلانات التفاعلية
- موفِّر الهوية (idP)
- موفّر الهوية
- مجموعة مهندسي شبكة الإنترنت (IETF)
- مجموعة مهندسي شبكة الإنترنت
- IP
- عنوان بروتوكول الإنترنت
- openRTB
- عروض الأسعار في الوقت الفعلي
- و إ
- تجربة المصدر
- PatCG
- مجموعة منتدى تكنولوجيا الإعلان الخاصة
- RP
- مجموعة الاعتماد
- نظام SSP
- منصة جانب المورّد
- TEE
- بيئة تنفيذ موثوقة
- UA
- سلسلة وكيل المستخدم
- UA-CH
- تلميحات إلى عميل وكيل المستخدم
- W3C
- اتحاد شبكة الويب العالمية
- قيد العمل على الإنترنت (WIPB)
- العمى النهائي لعناوين IP
ملاحظات عامة بدون تحديد واجهة برمجة التطبيقات أو التكنولوجيا
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| حوكمة البيانات والامتثال التنظيمي | إرشادات المنظومة المتكاملة حول استخدام "مبادرة حماية الخصوصية" بما يتوافق مع المتطلبات التنظيمية | كما هو الحال مع أي تقنية جديدة، تكون كل شركة مسؤولة عن ضمان امتثال استخدامها لـ "مبادرة حماية الخصوصية" للقانون، ولا يمكن لشركة Google تقديم المشورة القانونية للآخرين. ومع ذلك، ندرك أن هذا هو مجال اهتمام رئيسي للمنظومة المتكاملة. لقد نشرنا مستندات تقنية شاملة لكل واجهة من واجهات برمجة التطبيقات، والتي من المفترض أن توفّر الأساس لإجراء التقييمات القانونية اللازمة، ونعمل على توفير مواد إضافية لدعم جهود الشركات للالتزام بالمتطلبات التنظيمية. |
| اقتراح الاختبار الكمّي من CMA | مزيد من المعلومات عن اقتراح الاختبار الكمّي CMA | نحن نعمل مع CMA لتصميم تجارب توضّح تأثير إيقاف ملفّات تعريف الارتباط التابعة لجهات خارجية في عملية إيقاف ملفّات تعريف الارتباط التابعة لجهات خارجية، فضلاً عن تقديم اقتراحات "مبادرة حماية الخصوصية" في المنظومة المتكاملة. في نيسان (أبريل)، نشرت "هيئة الأسواق المحلية" إرشادات عالية المستوى حول ما يمكن توقّعه خلال فترة الاختبار وفترة الفترة التجريبية يليها إرشادات تفصيلية في حزيران (يونيو). ونحن نشجّع على مشاركة الأسئلة أو الملاحظات بشأن اقتراحات "الاختبار الكمّي" المقدَّمة من "هيئة السوق الرئيسية" (CMA) مباشرةً مع "الهيئة المعنية بالتسويق". |
| أوضاع الاختبار التي تسهّلها Chrome | مزيد من المعلومات والتوضيحات بشأن جداول الاختبارات | نشرنا مشاركة مدوّنة في 18 أيار (مايو) تتضمّن مزيدًا من المعلومات حول وضعَي الاختبار الذي يسهّله Chrome. هذه التفاصيل ليست نهائية، وسننشر المزيد من الإرشادات التنفيذية أثناء تقدُّمنا في الربع الثالث من 2023. |
| مساحة تخزين مقسَّمة | هل سيتم استخدام مساحة التخزين المُقسَّمة أثناء الاختبار الذي يسهّله Chrome؟ | سيتم شحن ميزة تقسيم مساحة التخزين إلى جميع المستخدمين قبل تجربة إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا. وبالتالي، سيتم تفعيله لكل مجموعات التجربة. سيتوفّر للمواقع الإلكترونية خيار تفعيل الفترة التجريبية للإيقاف النهائي لاستعادة مساحة التخزين غير المقسَّمة خلال هذه الفترة الزمنية. |
| دعم في مجال الإنتاج | ما هي الإجراءات المطلوبة من Chrome لدعم المشاكل الفنية وعمليات التصعيد في "مبادرة حماية الخصوصية" التي تؤثر في المنظومة المتكاملة؟ | توفّر Google مجموعة من القنوات للسماح لتكنولوجيا الإعلان بالإبلاغ عن المشاكل وتفعيل أي عمليات تصعيد ضرورية. يُرجى الاطّلاع على مشاركة المطوّر للحصول على مزيد من المعلومات حول المنتديات العامة والخاصة للحصول على ملاحظات وتصعيد. |
| المخطط الزمني للتسجيل | الإطار الزمني الحالي للتسجيل قصير جدًا | ما زلنا نقيّم الموعد النهائي للتنفيذ ونودّ الحصول على معلومات من المنظومة المتكاملة حول الجدول الزمني الأنسب لك. |
| رقم D-U-N-S | مزيد من المعلومات حول متطلبات رقم نظام ترقيم البيانات العالمي (DUNS) للتسجيل والتصديق | ويمكن للمشاركين الاطّلاع على متطلبات الحصول على رقم D-U-N-S على الموقع الإلكتروني لشركة Dun & Bradstreet. تختلف المتطلبات حسب السوق، لذلك يجب أن يتأكد المشاركون من فحص الموقع الإلكتروني للسوق المحددة التي يهتمون بها. ومع ذلك، يجب على المشاركين بشكل عام تقديم معلومات أساسية حول نشاطهم التجاري، مثل اسم النشاط التجاري والعنوان ومعلومات الاتصال لمالك النشاط التجاري أو مديره. قد يُطلب من المشاركين أيضًا تقديم معلومات مالية، مثل الإيرادات السنوية للنشاط التجاري. بعد اكتمال الطلب، ستراجعه شركة D&B وتصدر رقم D-U-N-S إذا تمت الموافقة على الطلب. |
| الانتقال من مرحلة التجربة والتقييم إلى مدى التوفّر للجمهور العام | هل سيؤثّر الانتقال من تجربة المصدر إلى مدى التوفّر للجمهور العام في مختبِري الإصدار التجريبي من Origin Trial؟ | اعتبارًا من شهر تموز (يوليو)، سيتمكّن المختبِرون من الوصول إلى واجهات برمجة التطبيقات ذات الصلة والقياس على النطاق العام. سيؤدي ذلك إلى حدوث تداخل بين مدى توفّر الإصدار التجريبي المصدر ومدى التوفّر للجمهور العام. |
| دراسة AdExchanger | مزيد من المعلومات حول منهجية الاستطلاع | طلب الاستطلاع من المشاركين تقدير معدلات المزامنة والأرباح لأنشطتهم التجارية. وكان الأمر متروكًا لمنهجية المستجيبين في الإجابة عن أسئلتهم الفردية. |
| قيم المعلّمات | كيف يتم تحديد قيم المَعلمات، مثل مستوى التشويش وحدود إخفاء الهوية وميزانية الخصوصية؟ | يوضّح هذا الشرح التوضيحي GitHub المبادئ الأكثر عمومية وراء واجهات برمجة تطبيقات "مبادرة حماية الخصوصية". لا تزال العديد من القيم نهائية ونرحب بالتعليقات حول هذا الموضوع. |
عرض محتوى وإعلانات ملائمة
المواضيع
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| الحفاظ على الخصوصية | بحث تقييم Topics API بشأن الحفاظ على الخصوصية | نحن نشارك بشكل نشط مع المجتمع البحثي، ونقدم أبحاثنا حول خصائص الخصوصية لواجهة Topics API في الأوراق والتقارير وعروض ورش العمل. يسعدنا رؤية المزيد من الأعضاء الخارجيين من مجتمع البحث يتفاعلون مع هذا المجال. تحمي Topics API المستخدمين من التتبُّع العام على الويب، إذ تصعِّب تتبُّع المستخدمين على نطاق واسع. وتشير هذه الأبحاث إلى أنّنا ننجح في تحقيق ذلك باستخدام Topics API. وهي أكثر خصوصية من ملفات تعريف الارتباط التابعة لجهات خارجية، كما تحمي المستخدمين في الوقت نفسه الذي تدعم فيه المواقع الإلكترونية التي يستمتعون بزيارتها. |
| تصنيف المواضيع ليس دقيقًا بما فيه الكفاية | لا يتضمن تصنيف المواضيع الواسعة المواضيع الأكثر دقة، بما في ذلك المواضيع الخاصة بالمنطقة. | استجابةً للملاحظات السابقة التي وردتنا من المنظومة المتكاملة، نشرنا مشاركة مدونة في 15 حزيران (يونيو) توضّح بالتفصيل تصنيفًا معدَّلاً جديدًا يتضمّن العديد من التحسينات بعد الملاحظات الواردة من المنظومة المتكاملة. وكجزء من عملنا على التصنيف المعدَّل، تفاعَلنا مع شركات عديدة على مستوى المنظومة المتكاملة، مثل Raptive (المعروفة سابقًا باسم CafeMedia) وCriteo. يزيل التصنيف المحدّث الفئات التي لاحظناها أقل فائدة، لصالح الفئات التي تتطابق بشكل أفضل مع اهتمامات المعلنين، مع الحفاظ على التزامنا باستبعاد الموضوعات التي يحتمل أن تكون حساسة. نشجّع المنظومة المتكاملة على مراجعة أحدث تصنيف وتقديم ملاحظات عن التغييرات. |
| عملية تحديث التصنيف والمصنِّف | مزيد من المعلومات حول تصنيف المواضيع وتواتر إصدار المصنِّفات وكيفية الاستعداد للشركات لمثل هذه التعديلات | كما ورد في مشاركة المدونة الأخيرة، نتوقع أن يتطور التصنيف مع مرور الوقت، وأن تحكُم التصنيف في النهاية إلى طرف خارجي يمثل أطرافًا معنية من مختلف أنحاء المجال. وقد شاركنا أيضًا خطة زيادة الميزة في مجموعة الإعلان عن المواضيع. |
| التأثير في إشارات الطرف الأول | قد تكون الزيادة في عدد المواضيع في التحديث الأخير للتصنيف ذا قيمة عالية، ما يؤدي إلى خفض قيمة الإشارات الأخرى المستندة إلى اهتمامات الطرف الأول. | في تقرير الربع الأول من عام 2023، علّقت هيئة CMA قائلاً: "نتفهّم أنّ Google كانت تناقش التصنيف الجديد المقترَح مع العديد من المشاركين في السوق على مستوى سلسلة إمداد تكنولوجيا الإعلان. في حين أشار عدد قليل من الناشرين الكبار إلى أنّ الفائدة الأكبر للمواضيع ستؤدي إلى زيادة الضغط التنافسي على الحلول المستندة إلى بيانات الطرف الأول، فإنّ وجهة نظرنا الأولية هي أنّ الفائدة الأكبر هي الأفضل للمنافسة بشكل عام، لا سيما قدرة الناشرين الأصغر حجمًا على مواصلة تحقيق الربح من مستودعهم الإعلاني بعد إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية". ويتماشى عرضنا مع هذا التعليق الذي أجرته مؤسسة CMA. |
| الفائدة لأنواع مختلفة من الأطراف المعنية | إنّ تقنيات الإعلان التي تعمل كجهات وسيط عرض الإعلان (SSP) ومقدّمي خدمة العرض (DSP) قد تكون لها مزايا كبيرة على الجهات الفاعلة الأخرى في المنظومة المتكاملة. | لم يطرأ أي تغيير على ردّنا عن الأرباع السابقة: " التزمت Google مع CMA بتصميم وتنفيذ اقتراحات "مبادرة حماية الخصوصية" بطريقة لا تشوّه المنافسة من خلال الاختيار الذاتي للأنشطة التجارية الخاصة بشركة Google، ولمراعاة التأثير على المنافسة في الإعلان الرقمي وعلى الناشرين والمعلنين، بغض النظر عن الحجم. نواصل العمل عن كثب مع CMA لضمان امتثال عملنا لهذه الالتزامات. مع تقدّم عملية اختبار "مبادرة حماية الخصوصية"، أحد الأسئلة الرئيسية التي سنقيّمها هو مستوى أداء التكنولوجيات الجديدة لأنواع مختلفة من الجهات المعنيّة. الملاحظات مهمة في هذا الصدد، خاصة الملاحظات المحددة والقابلة للتنفيذ التي يمكن أن تساعدنا في تحسين التصميمات الفنية. لقد عملنا مع مؤسسة CMA لتطوير نهجنا في ما يتعلق بالاختبار الكمي، ونؤيد نشر ملاحظة حول تصميم التجربة من أجل توفير مزيد من المعلومات للمشاركين في السوق وفرصة للتعليق على الأساليب المقترحة". |
| المواضيع الفرعية | بما أن معايير اختيار المواضيع تتمثل في معدل تكرار زيارات المتصفح، هل سيؤدي تقسيم الشرائح إلى عدم ظهور المواضيع الفرعية في القمة؟ | يقيّم Chrome حاليًا منهجيات أخرى لترتيب المحتوى ويستكشف مؤشرات أخرى قد تؤدي إلى تحسين الترتيب. وسنعلن عن خططنا المعدّلة إلى المنظومة المتكاملة في الوقت المناسب. |
| الحساسية | يجب أن يكون هدف Topics API هو ضمان أن تكون معلومات المستخدمين التي يتم الحصول عليها أو المستمدة من Topics API أقل حساسية شخصية مما يمكن استخلاصه باستخدام أساليب التتبُّع الحالية. | نعتقد أنّ Topics API تتميّز بدرجة أكبر من الخصوصية بكثير من التكنولوجيات الحالية، وتحدّ بشكل كبير من إعادة تحديد هوية المستخدمين، ومصمّمة لاستبعاد مواضيع حسّاسة. وندرك أنّ المواضيع قد تكون مرتبطة ببيانات الطرف الأول أو يمكن دمجها لإنشاء فئات حساسة، ولكن نعتقد أنّ Topics API هي خطوة نحو تعزيز خصوصية المستخدمين ونلتزم بمواصلة تحسين واجهة برمجة التطبيقات. |
| هيكل التصنيف | إضافة المعرّف وتحديد الإصدارات والبيانات الوصفية الأخرى إلى تصنيف المواضيع | حاليًا، نُدرِج معرِّف التصنيف في استجابة واجهة برمجة التطبيقات. في إطار سعينا إلى الحوكمة على المدى الطويل، من المنطقي مراجعة عنصر Topics وتضمين بيانات وصفية إضافية بشأن تحديد الإصدارات إذا لزم الأمر. |
| تحكم الناشر | يجب أن يكون للناشرين رأيهم في المواضيع التي تصنف مواقعهم الإلكترونية ضمنها. | إنّ التصنيف الخاطئ للمواقع الإلكترونية قد يجعل إشارة "المواضيع" أقل فائدة بعض الشيء كإشارة عامة بعض الشيء، ولكن المواقع الإلكترونية المحدّدة التي يتم تصنيفها بشكل خاطئ قد تكون أقل عرضة للضرر مقارنةً بأي مواقع أخرى. ويرجع ذلك إلى أنّ المعلومات السياقية الخاصة بالموقع الإلكتروني ستكون متاحة دائمًا للمزادات على هذا الموقع، ما قد يؤدي إلى تقديم معلومات مماثلة للموضوع الصحيح، حتى في حالة حدوث خطأ في التصنيف. نرحّب بالملاحظات حول هذا الموضوع. إنّ السماح للناشرين بالتحكّم في تصنيفهم ينطوي على بعض المخاطر. قد تصنّف المواقع الإلكترونية مواقعها عن طريق الخطأ عن قصد، ما يقلّل من فائدة هذه المواقع للجميع، أو قد تشفّر المعاني الحساسة لمواضيع أقل شيوعًا، ما يضرّ بخصوصية المستخدمين. |
| إضافات Chrome | السماح لإضافات Chrome بإدارة المواضيع وفلترتها، على غرار إضافات إدارة ملفات تعريف الارتباط الحالية | من المفترض أن يكون هذا ممكنًا كما هو موضَّح على GitHub، لكننا نرحب بملاحظات إضافية من المنظومة المتكاملة. |
| الانتقال إلى مرحلة التوفّر للجمهور العام | هل سيكون هناك أيّ تأثير في Topics API عند الانتقال من مرحلة التجربة والتقييم إلى مدى التوفّر العام؟ | ولن يتم فقدان أي بيانات للمستخدمين الذين ينتقلون من مرحلة التجربة والتقييم إلى مدى التوفّر للجمهور العام. |
| الخصوصية | قد تحتوي أسماء المضيفين على معلومات خاصة قد تكشفها Topics API. | لدينا عدد من إجراءات التخفيف لضمان الخصوصية، كما هو موضح هنا. |
| الاحتيال وإساءة الاستخدام | كيفية منع التلاعب بالمواضيع من خلال الزيارات الاحتيالية | يمكنك الاطّلاع هنا على إجراءات الحدّ من التتبُّع. |
| مصنِّف المواضيع | هل يمكن للمواقع الإلكترونية طلب تغيير تصنيف المواضيع؟ | يهمّنا الاطّلاع على آراء المنظومة المتكاملة حول هذا الموضوع، ونرحّب بالملاحظات والآراء هنا. |
| المواقع الإلكترونية لمزوّدي المواضيع | تعيين بعض المواقع الإلكترونية التي تستضيف محتوى للعديد من المواضيع بصفتها "مواقع مقدِّمة خاصة بمواضيع خاصة" وتدريب المصنِّفات استنادًا إلى العلامات المتوفرة في صفحات الويب. | نعمل حاليًا على مناقشة الاقتراح هنا، ونرحب بملاحظات إضافية. |
Protected Audience API (المعروفة سابقًا باسم FLEDGE)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| تحديد أعداد الزيارات | تأثير التصفية المستندة إلى SSP في الأداء لتحسين حِمل الطلبات في الثانية (QPS) | لقد قضينا وقتًا طويلاً في التفكير في تشكيل عدد الزيارات، وننصحك بأن يستفيد مزوّدو خدمات البيع بالتجزئة من التخزين المؤقت. |
| مستوى صوت الاختبار | يواجه المستخدمون صعوبات في اختبار ميزة "الجمهور المحمي"، لأنّ مزوِّدي خدمة البريد الإلكتروني (SSP) ومقدّمي خدمة النظام الأساسي (DSP) يواجهون صعوبة في جذب أعداد كبيرة من الزيارات. | نحن نعمل باستمرار على تشجيع شركاء SSP وDSP على استخدام ميزة "الجماهير المحمية" واختبارها. لقد بدأنا توفّر الخدمة للجمهور العام ونحن على ثقة من أنّ النسبة المئوية للزيارات التي فعّلَت الإعلانات المخصّصة لها ستجعل تجربة التسوّق أكثر جذبًا للشركاء. |
| مستوى التعقيد | يتطلّب تنفيذ حلول الجماهير المحمية جهدًا كبيرًا وتكاليف كبيرة. | نحن ندرك أنّه من الصعب استخدام التكنولوجيات الجديدة، بما في ذلك "مبادرة حماية الخصوصية". يعمل فريق "مبادرة حماية الخصوصية" عن كثب مع مجموعة كبيرة من الجهات المعنيّة لتوعية جهودهم ودعمها، كما يقيّم باستمرار برامج المسرّعات الأخرى لدعم اعتماد المنظومة المتكاملة. |
| بيئات تنفيذ موثوقة | دعم بيئات التنفيذ الموثوقة (TEE) في البيئات السحابية غير العامة | وبينما نستكشف خيارات دعم محتملة بخلاف الحلول المستنِدة إلى السحابة الإلكترونية، لا يمكن في الوقت الحالي إتاحة بيئة التنفيذ الموثوقة (TEE) داخل المؤسسة نظرًا لقيود الأمان داخل المؤسسة والتي قد تتطلّب إجراء تقييم يستغرق وقتًا طويلاً في ما يتعلّق بـ "مبادرة حماية الخصوصية". نظرًا لمتطلبات الأمان في "مبادرة حماية الخصوصية" والتحديات الكبيرة الناتجة عن عمليات النشر داخل المؤسسة، نعتقد أنّ مواصلة توسيع نطاق عمليات النشر المستنِدة إلى السحابة الإلكترونية وتحسينها (مثل دعم Google Cloud Platform (GCP) بالإضافة إلى خدمات AWS) هي الأكثر إفادة للمنظومة المتكاملة. مع ذلك، نرحّب بملاحظات إضافية حول سبب أهمية هذا الشرط. |
| هيكل التكلفة | سيؤدي اقتراح خدمات عروض الأسعار والمزادات إلى زيادة التكلفة والتعقيد لتكنولوجيا الإعلان مقارنةً بالنماذج من جهة العميل. | نعمل حاليًا على تطوير دليل لتقدير تكاليف دعم عروض الأسعار وسير عمل المزادات في خادم عروض الأسعار والمزاد، والذي يرتبط باستخدام تكنولوجيا الإعلان، لتحقيق أحد أهداف تصميماتنا. |
| المخططات الزمنية لكيانون | متى سيتم فرض قيود إخفاء الهوية التصنيفية k على "renderUrl"؟ | نعمل حاليًا على توضيح المخطط الزمني لعملية التنفيذ الذي سنصدره قريبًا. |
| القيود المفروضة على مزاد الإعلانات | هل يمكن لمتصفّح Chrome فرض قيود على اسم "runAdAuction" بحيث لا يمكن الاتصال به إلا من أعلى الصفحة؟ |
على الرغم من أنّ تصميمنا يتوافق بالكامل مع runAdAuction لكي يكون قابلاً للاتصال من الصفحة العلوية، إلا أننا نعتقد أنّ قصره على إتاحة الاتصال من النطاق العلوي قد يكون أكثر ضررًا بالنسبة إلى الناشرين.لقد أبلغنا المنظومة المتكاملة على وجه التحديد أنّ "مبادرة حماية الخصوصية" تحتاج إلى تخفيف العبء الواقع على الناشرين والمعلِنين. تتوافق هذه الملاحظات مع المبدأ العام لتطوير الويب الذي ينص على أنه يمكن لمالكي المواقع الإلكترونية استخدام أدوات من جهات خارجية في إدارة مواقعهم. كان هدف "مبادرة حماية الخصوصية" هو تشجيع منظومة متكاملة سليمة بدون الحاجة إلى وصف آلية عمل الناشرين وتقنيات الإعلانات. من خلال السماح للناشر باختيار طريقة الاتصال بـ runAdAuction على موقعه الإلكتروني والأشخاص الذين يتصلون به على موقعه الإلكتروني، نعتقد أنّنا نوفّر المرونة للناشرين للعثور على أفضل مسار لتلبية متطلباتهم. |
| دعم التنفيذ | هل بإمكان Chrome إنشاء أو المساهمة في تنفيذ مصدر مفتوح لمزاد متعدد البائعين؟ | تهدف "مبادرة حماية الخصوصية" إلى تطوير تقنيات الحفاظ على الخصوصية التي لا تعتمد على ملفات تعريف الارتباط التابعة لجهات خارجية أو معرّفات أخرى على مواقع إلكترونية متعددة. نحن نريد تشجيع إنشاء منظومة متكاملة سليمة بدون الحاجة إلى توضيح آلية عمل تكنولوجيا الإعلان. لقد نشرنا إرشادات حول آلية عمل واجهات برمجة التطبيقات في مستودع GitHub ونحن مستعدون لاستكشاف الحلول في المجال. لا نخطط لتنفيذ أي عملية تنفيذ محدّدة، لأنّ هدفنا الأساسي هو إنشاء تكنولوجيات الأنظمة الأساسية، وليس فرض استراتيجيات لاستخدام هذه التكنولوجيات. ستساعد تكنولوجياتنا في تمكين شركات تكنولوجيا الإعلان من تقديم أفضل خدمة ممكنة لعملائها من خلال توفير تدابير حماية الخصوصية المناسبة للمستهلكين. |
| مزادات متعددة البائعين | هل سيفرض Chrome مشاركة فائز "سياقي" مع مزادات المكوّنات؟ | تم تصميم Protected Audience API بهدف منح الجهات التي تبدأ المزاد المتعدد البائعين إمكانية تمرير معلومات إلى مزاد المكوّنات (ملاحظة: قبل بدء المزاد فقط). ومع ذلك، لا نرى طريقة تتيح للمتصفّح تمييز ما إذا كانت معلومة معيّنة مفيدة للسياق أم لا، لذا لا يمكننا فرض الحظر أو طلب معلومات معيّنة. |
| الإعداد المفضّل للمستخدم لتتبُّع الموافقة | Adtech يسأل مدير الإعلانات عن كيفية تنفيذ تتبُّع موافقة المستخدم بشكل صحيح | تتضمّن استجابتنا ما قلناه في الربع الأول: "بالنسبة إلى إعلانات معيّنة، تكون تكنولوجيا الإعلان الملائمة هي أفضل ما يكون في وضع يسمح لها بتقديم عناصر تحكّم في تصميمات الإعلانات التي يتم عرضها أو كيفية اختيارها". لقد ناقشنا عددًا من السيناريوهات المتعلقة بهذه المشكلة خلال اجتماع WICG Protected Audience Meet في أيار (مايو)، ونرحّب بمزيد من الملاحظات والمناقشات حول هذه المشكلة. |
| الجمهور المخصّص | هل ستتوافق واجهة Protected Audience API مع حالات الاستخدام المتعلّقة بـ SSP؟ | تسمح Protected Audience API لمزوِّدي خدمات تكنولوجيا الإعلان وغيرهم من مزوّدي تقنية الإعلان بامتلاك شرائح الجمهور المخصّصة وإدارتها. يتم حاليًا تطوير المزيد من الإرشادات حول كيفية دمج SSP مع واجهة برمجة تطبيقات PA API، وسيتم توفير هذه الإرشادات لمقدّمي الخدمات التجارية على الإنترنت ومزوّدي تقنية الإعلان الآخرين لدعم جهود الدمج. |
| التنسيقات | هل الفيديو متوافق مع Protected Audience API؟ | يتم عرض إعلانات الفيديو بإحدى الطريقتين التاليتين: بتنسيق VAST بتنسيق XML أو HTML (إعلان خارج البث يمكن أن يحمّل VAST XML في مشغّل فيديو أيضًا). ويمكن للمشترين عرض أيٍّ من التنسيقَين من خلال RenderURL. تم تعديل مواصفات نموذج عرض إعلانات الفيديو مؤخرًا لإتاحة Attribution Reporting API. ستحتاج المواقع الإلكترونية التي تعرض إعلانات الفيديو إلى الاستعداد لطريقة عرض الإعلانات عبر Protected Audience API. وهذا يعني التأكّد من أنّ علامات مواضع الإعلانات يمكن أن تمرِّر عنوان URL من إطار iframe لـ Protected Audience إلى مشغّل فيديو. بالنسبة إلى ميزة Fenced Frames، سنعمل على تلبية متطلبات الفيديو قبل الحاجة إلى استخدام Fenced Frames، التي لا تبدأ قبل عام 2026. |
| مستوى التقدم | كيف تعمل حالة الاستخدام الخاصة بميزة "تتبُّع وتيرة الإنفاق" مع Protected Audience API؟ | نحن نقدّر الملاحظات التي نتلّقاها. يهمّنا الاطّلاع على المزيد من حالات هذا الطلب مع تفاصيل إضافية واردة من المزيد من شركاء SSP لأنّ هذه المشكلة كانت غالبًا مصدر قلق بشأن نظام DSP حتى الآن. |
| فترة تكرار التحديث | قد لا يكون تكرار المكالمات من dailyUpdate (ما يصل إلى مكالمة واحدة لكل مجموعة اهتمام في اليوم) كافيًا لحالات استخدام معيّنة، مثل تعديل معلومات المنتج. |
نحن نقدّر الملاحظات التي نتلّقاها. تتوفّر حلول أخرى للسماح لتكنولوجيا الإعلان باستخدام الإشارات التي يتم تعديلها بوتيرة مختلفة، مثل عمليات البحث عن خوارزمية K/V. |
| مراقبة جودة الإعلان | كيف ينفّذ الناشرون مراقبة جودة الإعلانات؟ | في الوقت الحالي، توفّر Protected Audience API وظائف للناشرين لإعلام مزوّدي خدمة البريد الإلكتروني بعناصر تحكّم معيّنة يمكنهم إنشاؤها كجزء من عملية ضبط المزاد، وتحديد عروض الأسعار المُسبَقة (أي القوائم المرفوضة استنادًا إلى التصنيفات المرتبطة بالإعلانات). ونرحّب بملاحظاتك بشأن أي وظائف إضافية قد تتطلّبها هذه المنظومة المتكاملة. |
| تصحيح الأخطاء | متى ستتم إزالة وظيفة "forDebuggingOnly"؟ |
نخطّط لإيقاف forDebuggingOnly بسبب إيقاف تشغيل ملفّات تعريف الارتباط التابعة لجهات خارجية في ما يتعلّق بأحداث الخسارة. نخطّط لإيقاف "forDebuggingOnly" في ما يتعلّق بالأحداث التي تحقق الربح في عام 2026 في أقرب وقت ممكن. |
| مجموعات الاهتمامات على جميع الأجهزة | اقتراح لتفعيل مجموعات الاهتمامات على جميع الأجهزة لوكلاء المستخدم الذين تمت مصادقتهم | نحن نقيّم هذا الاقتراح، ولكن الدقة العالية للاستهداف على جميع الأجهزة تشكّل مخاوف كبيرة بشأن الخصوصية، كما هو موضَّح في هذه مشكلة GitHub. |
| (تم الإبلاغ أيضًا في الربع الأول) | هل سيظل تجديد النشاط التسويقي الديناميكي متاحًا مع Protected Audience API بعد إيقاف ملفّات تعريف الارتباط التابعة لجهات خارجية؟ | ونعتقد أنّ حالة الاستخدام هذه ممكنة باستخدام ميزة "الجمهور المحمي"، كما هو موضّح هنا. |
| البيانات ذات الصلة بالنقر | إضافة بيانات ذات صلة بالنقرات إلى browserSignals. |
نطلب حاليًا توضيحًا بشأن وقت حدوث النقرة لإعطاء موقف أولي. |
| (تم أيضًا الإبلاغ عنها في الربع الرابع من عام 2022) الوظائف المحدّدة من جانب المستخدم في Protected Audience (الجمهور المحمي) | كيف سيتم توفير الدوال التي يحدّدها المستخدم في Protected Audience API؟ هذه هي وظائف يمكن برمجتها من قِبل المستخدمين النهائيين لتوسيع وظائف واجهة برمجة التطبيقات. | ذكرت أيضًا تكنولوجيا الإعلان التي طرحت هذه المشكلة أنّها لا تزال تعمل على تقييم ما يمكن فعله باستخدام أداة UDF، لذلك ليس هناك أي ملاحظات يمكن اتخاذ إجراء بشأنها حتى الآن، أو إلى حين توفّر الميزة للجمهور العام على الأقل. |
| العملة | يجب عدم تمثيل مبالغ العملة باستخدام النقاط العائمة. | وقد عالجنا هذه المشكلة بالتفصيل هنا. |
| إمكانات اختيار الإعلانات التي لا تندرج ضمن نظام وسيط عرض الطلب (DSP) | ما الدور الذي تؤديه خوادم الإعلانات في مزادات Protect Audience API؟ | نحن على دراية بطلبات خوادم الإعلانات لمواصلة تقديم خدمات اختيار الإعلانات بعد تقديم عروض الأسعار / تحسين تصميمات الإعلانات الديناميكية. نقيّم حاليًا التحليل التفصيلي للفجوات بين Protected Audience API الحالية وهذه الطلبات. |
| GenerateBid | دعم اقتراح "إعلانات Google" بعرض أكثر من إعلان مرشّح واحد لكل مجموعة اهتمامات إعلانية من generateBid والحصول على درجات هؤلاء المرشحين في "scoreAd". |
يتم حاليًا تقييم هذه المشكلة. نرحّب بالملاحظات الإضافية هنا. |
| طلب المزاد | هل يجب أن تكون مزادات Protected Audience API هي الأخيرة التي يتم عرضها كي تتمكّن من الاستفادة من نتائج جميع المزادات الأخرى؟ | ما مِن متطلبات فنية لتشغيل Protected Audience API في النهاية. |
| التنقل الذي لا يبدأه المستخدم | إظهار التنقل الذي لا يبدأه المستخدم | نعمل حاليًا على مراجعة هذا الطلب ومناقشته هنا ونرحب بملاحظات إضافية. |
| التخزين المؤقت | لا ينبغي أن ينشئ SSP وسيط عرض الطلب (DSP) لكل مشتريSignals من ذاكرة التخزين المؤقت إذا تغيرت حالة المستخدم. | وندرك أنّ التخزين المؤقت لا يناسب كل حالة استخدام خاصة بإشارات لكل مشتري، ونحن نقيّم الخيارات الإضافية. نرحّب بأي ملاحظات إضافية من المنظومة المتكاملة حول ما إذا كان التخزين المؤقت مناسبًا لحالات الاستخدام لديهم. |
| إعداد تقارير الإحالة والجمهور المحمي | كيف يمكن أن تعمل Attribution Reporting API مع Protected Audience API؟ | تتوفّر عمليات الدمج حاليًا في Protected Audience API لكلٍّ من وضعَي Attribution Reporting API (التقارير على مستوى الحدث والتقارير التلخيصية). في 1 حزيران (يونيو)، شاركنا المزيد من المعلومات حول الدمج المحسَّن بين Protected Audience API وAttribution Reporting API. يمكنك القراءة عنها هنا. |
| نقطة نهاية الخادم | هل ستكون نقطة نهاية الخادم هي خادم التجميع الموثوق به في التصميم النهائي؟ | نقطة نهاية الخادم هي نقطة نهاية تتم صيانتها من خلال تكنولوجيا الإعلان، وتكون مستقلة عن خوادم التجميع الموثوق به وتُستخدم لمعالجة التقارير التي تم جمعها وتحويلها. ليس لدينا أي تغييرات مخططة لنقطة نهاية إعداد التقارير في الوقت الحالي. يهدف التصميم الحالي إلى التأكّد من أنّ التقارير المجمّعة نفسها (باستخدام حمولات بيانات مشفّرة) لا تسرّب البيانات من مواقع إلكترونية متعددة، لذلك ليس من الضروري الاستعانة بنقطة نهاية موثوق بها. تُكبّد المشكلة أيضًا أنّه من المحتمل أن يكون لتقنيات الإعلانات المختلفة استراتيجيات تجميع مطلوبة مختلفة. نرحّب بالملاحظات الإضافية هنا. |
| WebIDL | مواصفات Protected Audience API الحالية غير متوافقة مع مواصفات WebIDL. | نعمل على تقييم هذه الملاحظات ومناقشة المشكلة هنا. |
| إدارة الموافقة | كيف سيتم التعامل مع تمرير إشارة الموافقة في Protected Audience API؟ | لا تندرج المعلومات السياقية ضمن نطاق Protected Audience API. نعمل حاليًا على مناقشة هذه المشكلة ونرحب بملاحظات إضافية. |
| التسويق المستند إلى الحساب | هل من الممكن حالات استخدام التسويق المستند إلى الحساب؟ | تتيح Protected Audience API مجموعة متنوّعة من حالات الاستخدام للتسويق المستند إلى الجمهور. ما زلنا نفهم كيف يمكن لواجهة Protected Audience API تقديم الدعم الأفضل لحالة الاستخدام الخاصة هذه، ونرحّب بملاحظات إضافية حول هذه المشكلة من المنظومة المتكاملة. |
| مزاد المكوّنات | ما النتيجة التي يحصل عليها المشاركون في مزاد المكوّنات؟ | لا تسجِّل مزادات المكوّنات نتائج مجموعات الاهتمامات مباشرةً، بل تسجّل الإعلانات وعروض الأسعار التي يرسلها وسيط عرض الطلب من دالة generateBid. يتم تشغيل الدالة generateBid() لكل مجموعة اهتمام، ويعرض نظام معالجة البيانات (DSP) ما يلي عند تنفيذ generateBid:
return {
'ad': adObject,
'adCost': optionalAdCost,
'bid': bidValue,
'render': renderUrl,
'adComponents':
[adComponent1, adComponent2, ...],
'allowComponentAuction': false,
'modelingSignals': 123};
}
|
| المساهمات الخارجية | طلب دعم المساهمات الخارجية على قاعدة رموز GitHub لخادم القيمة/المفتاح. | نتطلّع إلى تعديل العمليات ذات الصلة لدعم المساهمات الخارجية في رمز GitHub. |
| حجم مجموعة الاهتمامات | ما هو الحد الأقصى المسموح به لعدد المفاتيح التي يمكن أن يتوافق معها تطبيق IG؟ | الحد الحالي هو 50 كيلوبايت لحجم رسالة IG واحدة ويتم احتساب المفاتيح كجزء من ذلك. نرحّب بمزيد من المناقشة حول الحدّ الأقصى للحجم. |
| التجميع | كيف يمكن تقليل عدد اتصالات خادم K/V؟ | يمكنك استخدام عناوين التحكم في ذاكرة التخزين المؤقت عبر HTTP لتقليل عدد طلبات K/V. على سبيل المثال، يمكن تخزينها مؤقتًا في مزادات المكوّنات، وأيضًا في جميع الخانات الإعلانية على صفحة واحدة. |
| التحكم في الإصدارات | التوافق مع إصدارات متعددة من رمز تكنولوجيا الإعلان | ستتيح خدمات عروض الأسعار والمزادات إمكانية استخدام إصدارات متعددة من رمز تكنولوجيا الإعلان. في واجهة برمجة تطبيقات عروض الأسعار والمزاد، يمكن أن يحدّد الطلب SelectAd إصدار الرمز المستخدَم في طلب المزاد (أي عروض الأسعار / المزاد وكذلك إعداد التقارير). |
| مساحة التخزين المشتركة | دعم الكتابة في مساحة التخزين المشتركة في خدمة عروض الأسعار والمزادات. | في الوقت الحالي، لا تدعم خدمات عروض الأسعار والمزادات مساحة التخزين المشتركة، ولكننا نرحب بملاحظات إضافية حول سبب أهمية حالات الاستخدام هذه للمنظومة المتكاملة. |
| الانتقال من الويب إلى التطبيق | إتاحة المشاركة من موقع إلكتروني إلى التطبيق لمجموعات الاهتمامات | إنّ "Web-to-app" غير مدرَج حاليًا في عملية نشر Protected Audience API في Chrome وAndroid، لكنّنا مهتمون بالاطّلاع على المنظومة المتكاملة حول أهمية حالة الاستخدام هذه. |
| عدم هوية K | كيفية التعامل مع العناصر الاحتياطية K-Anonymity | نعمل حاليًا على مناقشة المشكلة ونرحب بملاحظات إضافية. |
قياس الإعلانات الرقمية
Attribution Reporting (وواجهات برمجة التطبيقات الأخرى)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| الإعدادات البديلة للتقرير على مستوى حدث الإحالة الناجحة بعد رؤية الإعلان فقط | ملاحظات بشأن إعدادات التقرير البديل على مستوى حدث الإحالة الناجحة بعد رؤية الإعلان فقط | لقد وصلتنا بعض الملاحظات التي تفيد بأنّ الإعدادات الحالية على مستوى الحدث ليست مثالية، لذا نطلب منك تقديم الملاحظات حول عمليات الضبط العامة المثلى. نحن مستعدون لتلقّي ملاحظات إضافية بشأن هذا الموضوع ونعتقد أنّ الشرح المرن على مستوى الأحداث يساعد في حلّ هذه المشكلة أيضًا. |
| عمليات الضبط المرنة على مستوى الحدث | ما هي حالة ميزة الإعدادات المرنة على مستوى الحدث؟ | وقد شاركنا المستندات حول الإعداد المرن على مستوى الحدث. الميزة لا تزال في مرحلة الاقتراح ونتطلّع إلى تلقّي المزيد من الملاحظات حول ما إذا كانت الميزة ذات قيمة للمنظومة المتكاملة أم لا. |
| عمليات الضبط المرنة على مستوى الحدث | كيف يمكن تسوية التقارير المتضاربة من أطراف مختلفة؟ | تتم معالجة معظم سيناريوهات إعداد التقارير من خلال استخدام التقارير المجمّعة، في حين أنّ اقتراح الضبط المرن على مستوى الحدث مخصّص تحديدًا لتوفير مزيد من المرونة للتقارير على مستوى الحدث، والتي غالبًا ما تُستخدم في حالات استخدام التحسين. نحن نرحب بأي تعليقات أو ملاحظات إضافية بشأن المنظومة المتكاملة بخصوص هذا السيناريو. |
| تسجيل المصدر | ماذا لو حدث تسجيل المصدر بعد تسجيل العامل المشغِّل؟ | في الوقت الحالي، إذا حدث تسجيل المصدر بعد تسجيل العامل المشغِّل، لن يمكن إسناد المصدر وعامل التشغيل إلى بعضهما بعضًا. يبدو أن هذا سيناريو حالة هامشية. نرحّب بأي ملاحظات إضافية بشأن هذه المشكلة وسنعالجها إذا كان هناك سيناريو يواجهه العديد من تقنيات الإعلان. |
| التعامل مع وكالات إعلانية متعددة | كيف يمكن لمزوِّدي خدمة العرض (DSP) استخدام Attribution Reporting API عندما يعمل أحد المعلنين مع عدة وكالات إعلانية؟ | تتيح واجهة برمجة التطبيقات إمكانية إعادة التوجيه، وبالتالي يمكن استخدامها حتى في حال عمل المعلِن مع عدة وكالات إعلانية. بالإضافة إلى ذلك، هناك بعض القيود المفروضة في ما يتعلق بعمليات إعادة التوجيه لضمان تحسين واجهة برمجة التطبيقات للخصوصية. لقد حدَّدنا أيضًا حلاً بديلاً محتملاً يستخدم واجهة برمجة التطبيقات الخاصة بمساحة التخزين المشتركة للسيناريو المحدَّد الذي طرحته تقنية الإعلان. نحن نرحب بأي تعليقات إضافية بشأن هذا السيناريو، وسنستمر في التكرار التحسيني بناءً على هذه التعليقات. |
| الحدود القصوى المسموح بها للوجهة | قد تتأثر حالة استخدام الإعلانات التي تتم إعادة تحميلها تلقائيًا بوضع حدود للوجهة. | لقد ناقشنا هذه المشكلة في اجتماع WICG في 1 أيار (مايو) ونتطلّع إلى تلقّي ملاحظات بشأن الحدّ المعقول المسموح به. أضفنا إلى شرح إعداد تقارير الإحالة مع تقارير الإحالة على مستوى الحدث الذي ينص على أنّ المتصفّح يمكنه الحدّ من عدد نطاقات المستوى الأعلى (eTLD) 1+ الخاصة بالوجهة التي تمثلها المواقع الإلكترونية المصدر. (راجِع طلب السحب). |
| إعداد تقارير الإحالة والجمهور المحمي | كيف يمكن أن تعمل Attribution Reporting API مع Protected Audience API؟ | تتوفّر عمليات الدمج حاليًا في Protected Audience API لكلٍّ من وضعَي Attribution Reporting API (التقارير على مستوى الحدث والتقارير التلخيصية). في 1 حزيران (يونيو)، شاركنا المزيد من المعلومات حول الدمج المحسَّن بين Protected Audience API وAttribution Reporting API. يمكنك القراءة عنها هنا. |
| عمليات الضبط المرنة على مستوى الحدث | شارِك الآن أفضل الممارسات المتعلّقة بمحاكاة الضوضاء بعد أن أصبحت المَعلمات قابلة للضبط. | لدينا رمز مشترك على GitHub يمكن لأي مستخدم استخدامه لتقييم تحصيل المعلومات وتأثير التشويش في أي إعدادات مرنة على مستوى الحدث يريد اختبارها. نريد التواصل مع أي مستخدم يختار الاختبار باستخدام الرمز ويرغب في مشاركة ملاحظاته. |
| قياس الإحالة على المواقع الإلكترونية والتطبيقات | متى ستتوفّر ميزة قياس الإحالة على المواقع الإلكترونية والتطبيقات؟ | أعلنّا في 9 أيار (مايو) عن تجربة قياس الإحالة على جميع التطبيقات والويب عبر Attribution Reporting API. على الرغم من التخطيط لمدى التوفّر للجمهور العام لواجهات برمجة التطبيقات ذات الصلة والقياس في Chrome 115، لا يتم حاليًا التخطيط للوصول إلى مدى التوفّر للجمهور العام في Chrome 115. |
| إزالة تكرار الإحالات الناجحة | كيف يمكن التوفيق بين حلول القياس المستقلة وتقنية ARA؟ | كما هو الحال مع الممارسات العادية الحالية، سيعمل المعلِنون مع مزوِّد خدمة قياس مستقل تابع لجهة خارجية لإزالة تكرار تقارير الإحالات الناجحة. لقد وفّرنا موارد عن كيفية إزالة تكرار الإحالات الناجحة لإعداد التقارير على مستوى الحدث. |
| فقدان البيانات أثناء تحديثات قاعدة بيانات "تقارير تحديد المصدر" | هل سيحدث أي فقدان للبيانات عندما يعدّل Chrome قاعدة بيانات Attribution Reporting كما تم الإعلان عنه؟ | بدءًا من الإصدار 115 من إصدار Chrome الثابت، سنبدأ بتفعيل واجهات برمجة التطبيقات الملائمة والقياس لجزء من مستخدمي Chrome تلقائيًا. وسيزيد توفّر هذه الميزة للجمهور العام بينما نرصد أي مشاكل محتملة. سيتمثل الهدف في الوصول إلى نسبة توفّر% 100 على مدى أسابيع، بحلول الربع الثالث من عام 2023. وسيتزامن هذا مع نهاية مرحلة التجربة والتقييم المتعلّقة بمدى الصلة بالموضوع والقياس. اعتبارًا من تموز (يوليو)، سيتمكّن المختبِرون من التسجيل للوصول إلى واجهات برمجة التطبيقات هذه للجمهور العام. سيؤدي ذلك إلى حدوث تداخل بين مدى توفّر مرحلة التجربة والتوفّر للجمهور العام من خلال التسجيل. سيكون الرمز المميّز لمرحلة التجربة والتقييم صالحًا حتى 19 أيلول (سبتمبر)، ولكن ننصحك بالتسجيل في واجهات برمجة التطبيقات قبل انتهاء الصلاحية للانتقال بسلاسة من مرحلة التجربة والتقييم بدون إيقاف أي اختبارات جارية. كما ورد في هذا الإشعار، لن يتم نقل البيانات المسجَّلة من الإصدارات الأقدم (M113 والإصدارات الأقدم) بعد التحديث، وبالتالي قد تفقد البيانات. لن تظهر حالة فقدان البيانات هذه في تقارير تصحيح الأخطاء، وسنحاول تجنُّب فقدان البيانات من 114 إلى 115. |
| الإذن بالوصول إلى الفوترة | استخدام إعداد تقارير الإحالة لفوترة تكلفة الإحالة الناجحة | كما هو موضّح في هذه المقالة، قد لا تكون Attribution Reporting API مناسبة لمتطلّبات فوترة تكلفة الإحالة الناجحة، بسبب تشويش الإضافة إلى التقارير على مستوى الحدث والتقارير التلخيصية. نشجّع الجهات الفاعلة في المنظومة المتكاملة على مشاركة ملاحظاتها وآرائها حول تأثيرها على نماذج الفوترة المختلفة من خلال Attribution Reporting API على GitHub. |
خدمة التجميع
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| تغيير في تأخير التقرير القابل للتجميع | ردود الفعل الإيجابية على الاقتراح لتغيير تأخير التقرير التجميعي ليكون من [10-60 دقيقة] إلى [0-10 دقائق] بعد الحصول على الملاحظات الواردة من المنظومة المتكاملة | يسعدنا أن نرى رد فعل إيجابي على التغيير المقترح، ونشجّع المنظومة المتكاملة على مواصلة تقديم الملاحظات بشأن اقتراحاتنا. |
| حل داخل المؤسسة | هل يمكن نشر خدمة التجميع في مراكز البيانات داخل الشركة؟ | وبينما نستكشف خيارات دعم محتملة بخلاف الحلول المستنِدة إلى السحابة الإلكترونية، لا يمكن في الوقت الحالي إتاحة بيئة التنفيذ الموثوقة (TEE) داخل المؤسسة نظرًا لقيود الأمان داخل المؤسسة والتي قد تتطلّب إجراء تقييم يستغرق وقتًا طويلاً في ما يتعلّق بـ "مبادرة حماية الخصوصية". نظرًا لمتطلبات الأمان في "مبادرة حماية الخصوصية" والتحديات الكبيرة الناتجة عن عمليات النشر داخل المؤسسة، نعتقد أنّ مواصلة توسيع نطاق عمليات النشر المستنِدة إلى السحابة الإلكترونية وتحسينها (مثل دعم Google Cloud Platform (GCP) بالإضافة إلى خدمات AWS) هي الأكثر إفادة للمنظومة المتكاملة. مع ذلك، نرحّب بملاحظات إضافية حول سبب أهمية هذا الشرط. |
| إعادة معالجة التقارير لفترات زمنية مختلفة | إمكانية إعادة معالجة التقارير لفترات زمنية مختلفة | لقد وصلتنا طلبات مشابهة نتمكّن من تقسيم الدفعات لنطاقات زمنية مختلفة. ويتمثّل أحد الاقتراحات في السماح بإمكانية توسيع المعرّف المشترك بتصنيف تحدّده تكنولوجيا الإعلان، بحيث يمكن تقسيم التقارير إلى دفعات مختلفة. ما زلنا في مرحلة مبكرة لتقييم هذه العملية، وسنُطلعك على آخر المعلومات حول المنظومة المتكاملة مع تطوّر هذا الاقتراح. |
| الآثار المترتبة على الخصوصية في بيئة التنفيذ الموثوقة | الشعور الإيجابي تجاه الآثار المترتبة على الخصوصية في بيئات التنفيذ الموثوقة | وتسرّنا معرفة ردود الفعل الإيجابية من المنظومة المتكاملة بخصوص الاقتراحات التي نقدّمها، ونرحب بملاحظات إضافية بينما نواصل تكرار جهودنا وتطويرها. |
| بنود الخدمة | ما هو الموعد النهائي لقبول بنود خدمة التجميع؟ | على الرغم من أنّنا لم نحدّد بعد موعدًا نهائيًا لقبول الأحكام والشروط، ننصح شركات المنظومة المتكاملة على قبول الأحكام والشروط في أقرب وقت ممكن لتجنّب حدوث تأخير في عملية التسجيل. نشجّع الشركات على التواصل معنا إذا كانت لديك أي أسئلة. |
| استكشاف المفاتيح | وستتيح ميزة الاكتشاف الرئيسية للمختبِرين إمكانية طلب البحث عن التقارير المجمّعة بدون الحاجة إلى قائمة صريحة بالمجموعات الرئيسية المحتملة من أجل معالجة تقارير تلخيصية لتحديد المصدر على جميع الشبكات لتحسين الأداء والدقة. | ونعمل حاليًا على استكشاف الحلول والحلول الممكنة، ونرحب بملاحظات إضافية من المنظومة المتكاملة. |
واجهة برمجة التطبيقات الخاصة بالتجميع الخاص
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| مصدر إعداد التقارير | كيف يتم تحديد مصدر إعداد التقارير؟ | دائمًا ما يكون أصل إعداد التقارير هو أصل النص البرمجي لمتصل "التجميع الخاص". |
| مسافة مفتاح 128 بت | وضوح بشأن تحديد مساحة مفتاح 128 بت | سنجعل تحديد مساحة المفاتيح هذه أكثر وضوحًا ونحل حالات عدم الاتساق عبر الصفحات. ننصحك باستخدام استراتيجيات التجزئة للبقاء ضمن مساحة المفاتيح هذه. |
| الحد الأقصى للمساهمة لكل تقرير | الحدّ الأقصى الحالي، وهو 20 مساهمة في كل تقرير، منخفض جدًا. | وبدلاً من زيادة الحد الأقصى لعدد المساهمات، نحن منفتحون على النظر في تقسيم التقارير بدلاً من اقتطاعها عند بلوغ هذا الحد. وسنفعّل المنظومة المتكاملة مع تطوّر هذا الاقتراح. |
| إعداد تقارير مدى الوصول إلى الجمهور | طلب إعداد تقارير حول مدى الوصول من عدّة منصات/أجهزة. يُعد مدى الوصول إلى الجمهور مقياسًا أساسيًا لإعلانات العلامة التجارية. يعتمد المعلِنون على التقديرات من عدّة منصات أو على جميع الأجهزة لإعداد تقارير مدى الوصول وعدد مرات الظهور لتحليل حملاتهم وتخصيص الإنفاق. تستخدِم نماذج مدى الوصول ملفات تعريف الارتباط التابعة لجهات خارجية كإشارة لقياس الإعلانات التي تظهر في بيئات الجهات الخارجية، ولذلك طلبت تقنيات الإعلان حلاً بديلاً بعد إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا. |
يعمل فريق "مبادرة حماية الخصوصية" على استكشاف ميزات لدعم منهجيات الوصول في جميع النطاقات بعد إيقاف ملفّات تعريف الارتباط التابعة لجهات خارجية نهائيًا. نرحّب بتلقّي ملاحظات إضافية من المنظومة المتكاملة. |
الحدّ من التتبُّع السري
تقليل عدد وكيل المستخدم/تلميحات برنامج وكيل المستخدم
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| (تم أيضًا الإبلاغ أيضًا في الربع الأول من عام 2023) ملاحظات حول أشكال الأجهزة الإضافية | طلب "تلميحات برامج وكيل المستخدم" (UA-CH) لتوفير أشكال إضافية من الأجهزة، مثل التلفزيون والواقع الافتراضي | ما زلنا نعمل على اتخاذ بعض قرارات التصميم الرئيسية (سواء من أجل تقديم قيمة واحدة مثل "التلفزيون" أو قائمة من إمكانيات أشكال الأجهزة)، ولكن مع ذلك، سنظل مهتمًا بوضع نماذج أولية لهذه الفكرة. |
| ميزانية الخصوصية | قد تؤدي قيود الميزانية على الخصوصية إلى أن تصبح طلبات UA-CH غير محدّدة عند إرسال عدد كبير جدًا من الطلبات. | ما مِن تعديلات جديدة في الوقت الحالي بشأن اقتراح ميزانية الخصوصية، ولكنّنا التزمنا بعدم فرض قيود على طلبات تلميحات عملاء Universal Analytics قبل إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا. |
| توافق الموقع | تستخدم المواقع الإلكترونية علامة UA-CH التجارية لحظر متصفِّحات معيّنة من الوصول إلى المواقع الإلكترونية. | هناك حالات استخدام صالحة لإنشاء قائمة للعلامات التجارية، وإحدى هذه الحالات هي التوافق الدقيق. تكون Universal Analytics مجانية لأنّ هناك علامات تجارية متعدّدة لحلّ هذه المشاكل. |
حماية IP (المعروفة سابقًا باسم Gnatcatcher)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| الاحتيال وإساءة الاستخدام | كيف يمكن للشركات وضع تدابير لمكافحة الاحتيال في حماية حقوق الملكية الفكرية؟ | نحن ندرك أهمية حالات الاستخدام المتعلقة بمكافحة الاحتيال والتأثير المحتمل على حالات الاستخدام هذه. نخطط لنشر المزيد من التفاصيل حول دعم مكافحة عمليات الاحتيال في وقت لاحق من هذا الصيف. إننا نسعى إلى الحصول على ملاحظات من المنظومة المتكاملة حول كيفية دعم حالات الاستخدام المتعلّقة بمكافحة الاحتيال بشكل أفضل. |
| GeoIP | مزيد من المعلومات حول المخطط الزمني للاختبار والنشر في GeoIP | نشر Chrome مؤخرًا معلومات جديدة توضح بالتفصيل خطط GeoIP لدينا. ونخطط لنشر المزيد من المعلومات حول المخططات الزمنية للنشر في الربع الثالث. نتوقّع إطلاق "حماية IP" كميزة موافقة للمستخدم على نسبة صغيرة من الزيارات في البداية. ويرجع السبب في ذلك إلى أنّنا ندرك أنّ هذا الاقتراح قد يتضمّن بعض التغييرات المهمة للشركات، ونودّ إعطاء المنظومة المتكاملة وقتًا للتعديل وتقديم ملاحظاتها قبل طرح الميزة على نطاق أوسع. |
| مصادقة الحساب | كيف ستعمل مصادقة الحساب مع الخادم الوكيل بالضبط؟ | نخطط لنشر المزيد من التفاصيل حول مصادقة الحساب في وقت لاحق من هذا الصيف، على الرغم من أننا شاركنا بعض الاعتبارات الأولية بالفعل. |
الحدّ من التتبُّع الارتدادي
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| إرشادات الاختبار | معلومات عن كيفية اختبار الحدّ من التتبُّع الارتدادي | لقد نشرنا مشاركة مدونة في أيار (مايو) تتضمّن معلومات إضافية عن كيفية اختبار ميزة "الحدّ من التتبُّع الارتدادي". |
| الوثائق | وضوح اقتراح تتبُّع الارتداد | لا يزال الاقتراح الحالي قيد التنفيذ ويواصل Chrome تعديل الاقتراح لتوفير الوضوح والمعلومات للمنظومة المتكاملة. نعمل على تقديم المزيد من التفاصيل ونرحب بأي تعليقات إضافية. |
| حذف ملفات تعريف الارتباط | هل ستحذف ميزة "الحدّ من التتبّع الارتدادي" جميع ملفات تعريف الارتباط في النطاق؟ | سيؤدي الحدّ من التتبُّع الارتدادي (BTM) إلى محو كل مساحة التخزين وكل ذاكرة التخزين المؤقت، كما هو موضَّح هنا. |
| التحايل على الحدّ من التتبُّع الارتدادي | يمكن تجاوز تصنيف أداة تتبُّع الارتداد عن طريق إجراء عمليات إعادة توجيه تتضمّن نوافذ منبثقة أو علامات تبويب جديدة. | لا تزال مواصفات "الحدّ من التتبّع الارتدادي" قيد التطوير. لقد ركزنا في المقام الأول على عمليات إعادة التوجيه من علامة التبويب نفسها حتى الآن، ولكننا نخطط للعمل على تدفقات النوافذ المنبثقة في المستقبل. نرحّب بالملاحظات الإضافية هنا. |
ميزانية الخصوصية
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| الاستهداف القريب | قد تؤثر "ميزانية الخصوصية" في حالات استخدام الاستهداف القريب. | لقد تلقّينا ملاحظات حول هذه المشكلة ونريد تلقّي مزيد من المعلومات حول التأثيرات المحتمَلة للمنظومة المتكاملة. |
تعزيز حدود الخصوصية على مواقع إلكترونية متعددة
مجموعات نطاقات الطرف الأول
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| (تم الإبلاغ أيضًا في الأرباع السابقة) حد النطاق | طلب زيادة عدد النطاقات المرتبطة | يقيّم Chrome الحدّ الرقمي المناسب للمجموعة الفرعية المرتبطة التي ستعمل على تحقيق التوازن بين الخصوصية والفائدة لحالات الاستخدام التي تم تحديدها. بدءًا من النهاية، أشار Chrome إلى أنه لم يتم الانتهاء بعد من العدد الدقيق للمجموعة الفرعية المرتبطة. |
| حالة الاستخدام المضمّنة | دعم حالات الاستخدام المضمّنة التي تتطلب "مجموعات نطاقات الطرف الأول" و"الشرائح" و"مساحة التخزين المشتركة" | تلقّى متصفّح Chrome الملاحظات بشأن حالة الاستخدام هذه، ويُحقّق الفريق في هذه الحالة الملاحظات الإضافية ويرحب بها. |
| إدارة المستودعات | معلومات حول سياسات إزالة مجموعات نطاقات الطرف الأول من مستودع GitHub في حال حدوث تناقضات أو إهمال | تلقّى متصفِّح Chrome الملاحظات بشأن حالة الاستخدام هذه. يُحقّق الفريق حاليًا في هذه المسألة ويرحب بالملاحظات الإضافية. |
| تعليم المستخدم | يجب أن يعمل Chrome على زيادة وعي المستخدم بمجموعات نطاقات الطرف الأول وفهمها لزيادة معدّل الاستخدام. | ويلتزم Chrome بتعريف المستخدمين على مجموعات نطاقات الطرف الأول، وقد نشر مقالة في مركز المساعدة (رابطها من واجهة مستخدم Chrome) لهذا الغرض. يسعى Chrome أيضًا إلى مواصلة التعرُّف على أفضل طريقة لتثقيف المستخدمين في السياقات المناسبة. |
| مشاركة 3PCD | ستظل ملفات تعريف الارتباط التابعة لجهات خارجية متوفّرة ضمن إحدى مجموعات نطاقات الطرف الأول بعد إيقاف ملفّات تعريف الارتباط التابعة لجهات خارجية نهائيًا. | وعلى الرغم من أنّ requestStorageAccess وrequestStorageAccessFor يتيحان مرة أخرى استخدام ملفات تعريف الارتباط التابعة لجهات خارجية في حالات استخدام محدّدة وواضحة، إلا أنّهما يتطلبان الآن استدعاءً نشطًا من قِبل الموقع الإلكتروني، بدلاً من توفيرهما تلقائيًا كما هو الحال مع الحالة الحالية لملفات تعريف الارتباط التابعة لجهات خارجية (في Chrome).على الرغم من أنّ عملية الاستدعاء هذه ضمن مجموعة واحدة لن تتطلب موافقة المستخدم، يمكن للمستخدمين منع ذلك من خلال إيقاف هذا السلوك في "الإعدادات". يتوفّر مزيد من المعلومات للمستخدمين في مقالة مركز المساعدة (الرابط من خلال واجهة مستخدم Chrome). ونخطّط لتوسيع نطاق تطبيق دليل المطوِّر الحالي لزيادة عدد اللقطات في الثانية بنسبة تصل إلى %100. |
| إرسال مجموعات نطاقات الطرف الأول | أعِد تسمية دالة .well-known/first-party-set المطلوبة لتضمين إضافة .json. |
وقد أجرينا هذا التغيير لضمان إتاحة بعض خطط استضافة الويب. |
| تسجيل IANA | يجب أن يكون first_party_sets.JSON مسجّلاً لدى IANA. |
ندرس الاقتراح ونرحب بالملاحظات الإضافية هنا. |
واجهة برمجة تطبيقات Fenced Frames
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| حظر الإعلانات | قد تسهّل "الإطارات المضمّنة" على أدوات حظر الإعلانات حظر الإعلانات. | يمكن أن تتفاعل الإضافات مع الإطارات الموجودة ضمن جدار حماية بشكل مشابه للطريقة التي ستتفاعل بها مع إطارات iframe. سيكون أيضًا عنوان URL الفعلي الذي يوشك الانتقال إليه ضمن الإطار المحيط مرئيًا على الإضافات، وبالتالي يمكنها تطبيق أي قواعد مطابقة لعناوين URL لحظرها كما يحدث في إطارات iframe. قد يؤدي حظر جميع الإطارات المضمّنة في حدود فارغة بدون أي شروط إلى تعطّل حالات الاستخدام غير الإعلاني للإطارات المضمّنة في أذونات الوصول. |
واجهة برمجة تطبيقات مساحة التخزين المشتركة
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| اعتماد على نطاق أوسع | يجب أن تكون مساحة التخزين المشتركة معيارًا على مستوى المجال ومتاحة عبر المتصفحات. | نحن نرحّب بهذه الملاحظات ونقدّرها. يواصل Chrome المشاركة بنشاط في منتدى W3C لدعم الاقتراحات وطلب الملاحظات والآراء والحث على الاستخدام. |
| بوابات الإخراج | بوابات إخراج مساحة التخزين المشتركة محدودة جدًا. | نأخذ في الاعتبار هذه الملاحظات ونرحّب بملاحظات إضافية حول المنظومة المتكاملة حول سبب محدودية بوابات الإخراج. |
| الالتزام باللوائح التنظيمية | كيف ستتعامل مساحة التخزين المشتركة مع الامتثال التنظيمي مثل سياسات الاحتفاظ بالبيانات؟ | توفّر مساحة التخزين المشتركة مرونة في تنفيذ وتخصيص المنطق للتحكّم في فترة صلاحية أي بيانات مخزَّنة وانتهاء صلاحيتها. يمكن لتقنيات الإعلانات تعديل بيانات "مساحة التخزين المشتركة" أو محوها بناءً على كتابة الطوابع الزمنية. |
| اختبار أ/ب | كيف يمكن إجراء اختبار A/B لكلٍّ من مساحة التخزين المشتركة وProtected Audience API؟ | ونحن نعمل على نشر إرشادات إضافية في هذا الشأن ونأمل أن نشارك المزيد من التفاصيل في المستقبل. |
| حد مساحة التخزين المشتركة | ماذا سيحدث عند بلوغ الحد الأقصى المسموح به لمساحة التخزين المشتركة؟ | وفي حال بلوغ هذا الحدّ، لن يتم تخزين أي إدخالات أخرى. |
| الوصول المتعدد عند تحميل الصفحة نفسها | ماذا يحدث عند الدخول إلى مساحة التخزين المشتركة عدة مرات في تحميل الصفحة نفسه؟ | وأفضل طريقة للتعامل مع هذا الأمر هي استخدام الدالة window.sharedStorage.append(key, value). بدلاً من تعديل القيمة لكل إعلان، يمكن أن يؤدي ذلك إلى حدوث تضاربات إذا تم عرض إعلانات متعددة. ستضيف دالة الإلحاق القيمة الجديدة في نهاية القيمة الموجودة من قبل. |
| وظيفة iframe | هل ستتوافق مساحة التخزين المشتركة مع وظائف iframe معيّنة بعد إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا؟ | بعد إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا، سيتم تقسيم مساحة التخزين على الجهاز في إطارات iframe حسب الموقع الإلكتروني ذي المستوى الأعلى، ولكن لن يتم حظر إطارات iframe نفسها. لا يمكن نسخ البيانات في مساحة التخزين المحلية لإطار iframe عبر العديد من المواقع ذات المستوى الأعلى، ولكن لا يزال من الممكن استخدام مساحة التخزين المحلية داخل iframe. |
الشرائح
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| حد الأقسام | لا تزال المساحة التي تبلغ 10 كيبيبايت لكل موقع إلكتروني مقسّم مهمة، ونودّ أن يتم تخفيضها. | سبق أن أشارت منصّة Firefox إلى موضع إيجابي في ميزة CHIPS. للحصول على دعم Webkit، ننصح المطوّرين بتزويد شركة Apple مباشرةً بملاحظاتهم بشأن هذه المشكلة في GitHub بخصوص حالات الاستخدام التي يتم فيها تفضيل ملفات تعريف الارتباط المقسّمة على مساحة التخزين المقسّمة. |
| التضمينات التي تمت مصادقتها | قد تؤثر الشرائح في تدفق تسجيل الدخول المُوحَّد (SSO) الحالي بسبب اختلاف التقسيم الذي يؤثر على التضمينات التي تمت مصادقتها. | ننوي الاستفادة من واجهة برمجة التطبيقات Storage Access API (مع طلبات المستخدِمين) لدعم حالة استخدام التضمينات التي تمّت مصادقتها، وقد أرسلنا مؤخرًا intent-to-type (نموذج أولي لغرض معيّن). |
| سياسات الفترة منذ الإنشاء | هل ستسري سياسات القيمة الدائمة المحتملة على ملفات تعريف الارتباط الخاصة بالطرف الأول؟ | لا ننوي حاليًا فرض حدود دائمة على ملفات تعريف الارتباط للطرف الأول. |
FedCM
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| دعم تفويض OAuth | المواءمة بشأن تفويض نطاقات Oauth التي لا تتضمن الملف الشخصي | نحن نسعى جاهدين إلى الحصول على ملاحظات من منتدى "هوية الويب" من خلال W3C FedID CG حول أفضل الطرق لدعم التفويض بخلاف المصادقة الأساسية بعد إيقاف ملفات تعريف الارتباط التابعة لجهة خارجية. |
| دعم SAML | المواءمة مع متطلبات دعم SAML | يسعى الفريق جاهدًا للحصول على مدخلات من منتديات الأبحاث والتعليم حول احتياجات دعم SAML (بالإضافة إلى دعم OpenID-connect) بعد إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية. |
مكافحة المحتوى غير المرغوب فيه والاحتيال
واجهة برمجة التطبيقات للرمز المميز للحالة الخاصة (وواجهات برمجة التطبيقات الأخرى)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| استكشاف الإشارات الجديدة | أعرب العديد من الشركاء عن شعورهم الإيجابي باستكشاف الإشارات التي يسهِّلها المتصفِّح بخصوص سلامة الجهاز أو ثقة المستخدم. بشكلٍ عام، يتوخون الحذر أيضًا بشأن الإشارات الجديدة المصمّمة لغرض محدّد التي تكفي للاحتفاظ بالمستويات الحالية من رصد عمليات الاحتيال. | نحن متحمسون لاستكشاف اقتراحات جديدة معًا في منتدى مكافحة الاحتيال وأمان الويب، والإقرار أيضًا بمخاوفهم ومشاركتها. لهذا السبب أصبحت "مكافحة المحتوى غير المرغوب فيه والاحتيال" إحدى مراحل العمل الأساسية ضمن "مبادرة حماية الخصوصية"، ولا نزال نولي الأولوية للاستثمار في الحفاظ على أمان الويب في إطار جهودنا لتحسين خصوصية المستخدمين. |
| ملاحظات إيجابية حول توقيت المحيط الهادئ | وقد أبدى العديد من الشركاء اهتمامًا باختبار ملفات PST أو استخدامها في العديد من حالات استخدام أمان الويب أو مكافحة الاحتيال. | يسعدنا تلقّي الدعم والاهتمام باستكشاف الحلول الجديدة التي تستخدم PST. نوفّر موارد ونماذج رموز برمجية متاحة من خلال الموقع الإلكتروني لمطوّري Chrome، ويسعدنا تلقّي ملاحظات إضافية. |
| الاحتيال وإساءة الاستخدام | إرشادات لمنع الاحتيال للإعلانات / الرصد أثناء القياس بعد إيقاف ملفّات تعريف الارتباط التابعة لجهات خارجية عند عدم توفّر المعرّفات. | لقد طرحنا أدوات مثل "الرموز المميّزة للحالة الخاصة"، والتي تساعد في استرداد بعض الإشارات المفقودة من خلال ملفات تعريف الارتباط التابعة لجهات خارجية لأغراض مكافحة الاحتيال، ولكن مع تطبيق عناصر تحكّم جديدة في الخصوصية. نحن نستثمر بشكل نشط في اقتراحات جديدة لمكافحة الاحتيال وإساءة الاستخدام للحفاظ على الإمكانات مع التغييرات الأخرى في "مبادرة حماية الخصوصية". |
| معدّل معلومات جهة الإصدار | إنّ معدّل المعلومات من جهة الإصدار إلى المصدر مرتفع بما يكفي لتحديد المستخدمين الفريدين. | لقد عدّلنا المواصفات لتوضيح مواصفات بيانات المستخدمين التي يمكن نقلها باستخدام الرموز المميّزة للحالة الخاصة. وحسب التصميم، يمكن استخدام ما يصل إلى ستة مفاتيح عامة في آنٍ واحد، والتي قد تمثل "حالة" لمستخدم معين. لا يمكن تعديل هذه المجموعات من المفاتيح إلا كل 60 يومًا (باستثناء الحالات النادرة التي يكون فيها تغيير مفتاح الطوارئ ضروريًا في هذه الحالة)، ما يؤدي إلى الإبطاء من إمكانية ضم المزيد من بيانات المستخدمين بمرور الوقت. مع أي واجهة برمجة تطبيقات ويب جديدة، هناك توازن بين الأداة المساعدة وصافي معلومات المستخدمين الجدد التي توفرها. تشير تقديراتنا إلى أنّ ملفات PST تحقّق التوازن المناسب في حماية خصوصية المستخدمين مع تفعيل حالات الاستخدام الرئيسية المتعلّقة بمكافحة الاحتيال والمتأثرة بالإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية. |
| دمج الجلب | إنّ عملية دمج "fetch" معقّدة وغير ضرورية. |
هناك إيجابيات وسلبيات من استخدام fetch، ونسعى إلى تطبيق مزيد من المعايير في منظومة الويب المتكاملة، ولكننا نعتقد أنّه سيكون من السابق لأوانه إجراء هذا التغيير إلى أن نحصل على فكرة أوضح حول المعيار. وفي حال ظهر معيار معيّن، نلتزم أيضًا بنقل مطوّري البرامج على الويب إلى هذا المعيار على نحو مسؤول. |
| موقع التخزين | يجب تخزين إعدادات مفتاح الرموز المميّزة للحالة الخاصة في الموقع نفسه الذي يتضمّن بروتوكول PrivacyPass. | أثناء إجراء الاختبارات أثناء فترة التجربة والتقييم، أشار المطوّرون إلى أنّهم يفضّلون تخزين مفاتيحهم في عناوين URL عامة بدلاً من تخزينها في دليل .well-known. إنّ تنسيق الالتزام الرئيسي في PrivacyPass غير مناسب بشكل خاص للإصدار الذي تهدف فيه مجموعات المفاتيح إلى السماح بقيمة ضمنية لـ "البيانات الوصفية العلنية". إذا انتهى الأمر بتوحيد نسخة من PrivacyPass مع البيانات الوصفية المتاحة للجميع (إما في شكل POPRF أو ستارة جزئية لـ RSA أو مجموعات مفاتيح)، قد ننتقل إلى إصدار مستقبلي من PST لإتاحة ذلك. |
| تنفيذ العنوان لواجهة برمجة التطبيقات | أسئلة حول تنفيذ واجهة برمجة التطبيقات في رأس الصفحة | نظرًا لتوحيد واجهة برمجة التطبيقات هذه وازدياد استخدام المنظومة المتكاملة لواجهة برمجة التطبيقات هذه، نأمل أن نتمكّن من دعم الإصدار العادي من واجهة برمجة التطبيقات هذه بدون عناوين وفي النهاية إيقاف إصدار العنوان إذا كان الاستخدام منخفضًا بدرجة كافية أو إذا كان هناك أدوات أو دعم كافٍ للمطوّرين للطرق العادية لربط طلبات الإصدار/تحصيل القيمة بالبيانات الأخرى. نحن نناقش المشكلة هنا. |
| تسجيل | هل جعل تسجيل جهات الإصدار لدى مورّدي المتصفِّحات عمليًا؟ | لقد عدّلنا المواصفات لوصف عملية تسجيل جهة الإصدار للرموز المميّزة للحالة الخاصة. إنّ تطبيق "مبادرة حماية الخصوصية" يشبه عمليته الخاصة، إلا أنّه يشبه خطط التسجيل لبقية أنشطة "مبادرة حماية الخصوصية"، حيث نطلب من جهات الإصدار إصدار بيان علني حول كيفية استخدام ملفات PST والإقرار بالقيود الفنية التي تحمي خصوصية المستخدمين. |