تقرير ربع سنوي للربع الثاني من عام 2023 يلخّص ملاحظات المنظومة المتكاملة التي تم تلقّيها بشأن اقتراحات "مبادرة حماية الخصوصية" وردود Chrome.
في إطار التزاماتها تجاه هيئة الأسواق والمنصات (CMA)، وافقت Google على أن تقدّم بشكل علني تقارير ربع سنوية عن عملية تفاعل الأطراف المعنية في "مبادرة حماية الخصوصية" الاقتراحات (يُرجى الرجوع إلى الفقرتين 12 و17(ج)(2) من الالتزامات يتم إنشاء تقارير ملخّص ملاحظات "مبادرة حماية الخصوصية" هذه من خلال تجميع التي تلقّيناها من Chrome من مصادر مختلفة كما هو موضّح في الملاحظات والآراء نظرة عامة، بما في ذلك على سبيل المثال لا الحصر: GitHub المشكلات، فإن نموذج الملاحظات الذي تمت إتاحة privacysandbox.com واجتماعات مع المجال والأطراف المعنية ومنتديات معايير الويب. يرحّب Chrome بالملاحظات التي تم تلقّيها من المنظومة المتكاملة وتستكشف بشكل نشط طرقًا لدمج الدروس المستفادة في قرارات التصميم.
يتم ترتيب مواضيع الملاحظات حسب مدى الانتشار وفقًا لواجهة برمجة التطبيقات. يتم ذلك عن طريق أخذ كثرة الملاحظات التي تلقاها فريق Chrome حول موضوع معين وتنظيمه بترتيب تنازلي للكمية. الملاحظات الشائعة تم تحديد الموضوعات من خلال مراجعة موضوعات المناقشة في الاجتماعات العامة (W3C وPatCG وIETF) والملاحظات المباشرة وGitHub والأسئلة الشائعة من خلال فرق Google الداخلية والنماذج العامة.
وبشكل أكثر تحديدًا، كانت محاضر اجتماعات الهيئات القياسية على الويب التي تمت مراجعتها للحصول على ملاحظات مباشرة، سجلات Google للاجتماعات الفردية مع الأطراف المعنية، الرسائل الإلكترونية التي يتلقّاها المهندسون الأفراد، والقائمة البريدية لواجهة برمجة التطبيقات، والجمهور النظر في نموذج الملاحظات. بعد ذلك تعاونت Google مع الفرق المشاركة في أنشطة التوعية المختلفة هذه لتحديد أقرب مدى انتشار المواضيع الناشئة في ما يتعلّق بكل واجهة برمجة تطبيقات.
تم تطوير التفسيرات لردود Chrome على الملاحظات من الإصدارات المنشورة الأسئلة الشائعة، والردود الفعلية التي يتم تقديمها على المشكلات التي يطرحها الأطراف المعنية، وتحديد بشكل خاص لأغراض تمرين الإبلاغ العام هذا. يعكس التركيز الحالي للتطوير والاختبار والأسئلة والملاحظات تم تلقّيها على وجه الخصوص في ما يتعلّق بـ "المواضيع" و"الجمهور المحمي" و"تحديد المصدر" Reporting API:
قد لا تكون الملاحظات التي تم استلامها بعد نهاية الفترة المشمولة بالتقارير الحالية متوفرة بعد استجابة Chrome مناسبة.
مسرد الاختصارات
- ملفات تعريف الارتباط في الحالة المقسَّمة المنفصلة (CHIPS)
- ملفات تعريف الارتباط ذات الحالة المقسَّمة المستقلة
- معالِج الإشارات الرقمية (DSP)
- المنصة جانب الطلب
- FedCM
- إدارة بيانات الاعتماد الموحّدة
- إطار في الثانية
- مجموعات منتجات الطرف الأول
- مكتب الإعلانات التفاعلية (IAB)
- مكتب الإعلانات التفاعلية
- IDP
- موفّر الهوية
- مجموعة مهندسي شبكة الإنترنت (IETF)
- فريق فريق هندسة الإنترنت
- عنوان IP
- عنوان بروتوكول الإنترنت
- openRTB
- عروض الأسعار في الوقت الفعلي
- الوقت بدل الضائع
- مرحلة التجربة والتقييم
- PatCG
- مجموعة منتدى تكنولوجيا الإعلانات الخاصة
- الجهة المحظورة
- الطرف المعتمد
- SSP
- وسيط عرض إعلانات المورِّدين
- بيئة تنفيذ موثوقة (TEE)
- بيئة تنفيذ موثوقة
- UA
- سلسلة وكيل المستخدم
- UA-CH
- تلميحات عن برنامج وكيل المستخدم
- W3C
- اتحاد شبكة الويب العالمية
- WIPB
- العمى المتعمّد لعنوان IP
ملاحظات عامة، لا يلزم تحديد واجهة برمجة تطبيقات/تقنية
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| حوكمة البيانات الامتثال التنظيمي | إرشادات المنظومة المتكاملة حول استخدام "مبادرة حماية الخصوصية" بما يتوافق مع المتطلبات التنظيمية | وكما هو الحال مع أي تكنولوجيا جديدة، تتحمّل كل شركة مسؤولية ضمان امتثال استخدامها لـ "مبادرة حماية الخصوصية" للقانون. لا يمكن لشركة Google تقديم المشورة القانونية للآخرين. ونحن ندرك أنّ هذا الموضوع من مجالات الاهتمام الرئيسية للمنظومة المتكاملة. لقد نشرنا مستندات فنية شاملة عن كل واجهة برمجة تطبيقات، ومن المفترض أن توفّر الأساس اللازم لإجراء التقييمات القانونية اللازمة، كما نعمل على إتاحة مواد إضافية لدعم الشركات الجهود للالتزام بالمتطلبات التنظيمية. |
| اقتراح الاختبار الكمي لـ 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 في حال الموافقة على الطلب. |
| الانتقال من مرحلة التجربة والتقييم إلى مرحلة التوفّر للجمهور العام | هل سيؤثر الانتقال من مرحلة التجربة والتقييم إلى مرحلة التوفّر للجمهور العام في مختبري تلك الفترة؟ | اعتبارًا من تموز (يوليو)، سيتمكّن المختبِرون من الوصول إلى واجهات برمجة التطبيقات ذات الصلة بالقياس ومدى الصلة بالموضوع بشكل متاح للجمهور العام. سيؤدي ذلك إلى تداخل بين مدى توفّر الإصدار التجريبي من المصدر ومدى توفّره للجمهور العام. |
| دراسة عن AdExchanger | مزيد من المعلومات حول منهجية الاستبيان | طلب الاستطلاع من المشاركين تقدير معدلات المزامنة والأرباح لأنشطتهم التجارية. المجيبون كانت منهجية للإجابة على أسئلتهم الفردية متروكة لهم. |
| قيم المَعلمات | كيف يتم تحديد قيم المَعلمات مثل مستوى الضوضاء وحدود إخفاء الهوية وميزانية الخصوصية؟ | يوضِّح هذا الفيديو التوضيحي على GitHub المبادئ الأكثر عمومية وراء واجهات برمجة تطبيقات "مبادرة حماية الخصوصية". لا تزال العديد من القيم قيد العمل، ونرحب بملاحظاتك حول هذا الموضوع. |
إظهار المحتوى ذي الصلة الإعلانات
المواضيع
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| الحفاظ على الخصوصية | بحث لتقييم واجهة برمجة التطبيقات Topics API بشأن الحفاظ على الخصوصية | ونحن نعمل بشكل نشط مع مجتمع الأبحاث، ونقدّم أبحاثنا حول خصائص الخصوصية في Topics API في الأبحاث والتقارير وعروض تقديمية ورش العمل. يسعدنا أن نرى المزيد من الأعضاء الخارجيين في منتدى البحث يتفاعلون مع هذا المجال. تحمي Topics API المستخدمين من التتبّع العام على الويب لأنّها تصعِّب تتبُّع المستخدمين على نطاق واسع. وقد أظهرت هذه الأبحاث أننا ننجح في تحقيق ذلك من خلال Topics API. وهو أكثر خصوصية من ملفات تعريف الارتباط التابعة لجهات خارجية، ويحمي المستخدمين مع دعم المواقع الإلكترونية التي يستمتعون بزيارتها. |
| تصنيف المواضيع غير دقيق بدرجة كافية | ولا يشمل تصنيف المواضيع العامة مواضيع أكثر تفصيلاً، بما في ذلك تلك الخاصة بالمنطقة. | استجابة للملاحظات السابقة التي تلقّيناها من المنظومة المتكاملة، نشرنا مشاركة مدونة في 15 حزيران (يونيو) توضّح بالتفصيل تصنيفًا محدّثًا جديدًا يتضمّن العديد من التحسينات بعد الملاحظات الواردة من المنظومة المتكاملة. وكجزء من عملنا على التصنيف المنقح، تواصلنا مع العديد من الشركات عبر المنظومة المتكاملة، مثل Raptive (المعروف سابقًا باسم CafeMedia) وCriteo. يزيل التصنيف المحدّث الفئات التي رأينا أنها أقل فائدة، لصالح الفئات التي تتطابق بشكل أفضل مع اهتمامات المعلنين، مع الحفاظ على التزامنا باستبعاد المواضيع التي يحتمل أن تكون حساسة. ونحن نشجع المنظومة المتكاملة على مراجعة أحدث التصنيفات وتقديم ملاحظات وآراء بشأن التغييرات. |
| عملية تحديث التصنيف والمصنِّف | تعرَّف على مزيد من المعلومات حول وتيرة إصدار المصنِّفات وتصنيف "المواضيع" وكيفية الاستعداد للشركات لهذه التحديثات. | وفقًا لما نشرناه في مشاركة المدونة الأخيرة، نتوقع أن يتطور التصنيف بمرور الوقت، ولكي تؤدي حوكمة التصنيف في النهاية إلى الانتقال في النهاية إلى جهة خارجية تمثل الجهات المعنية في المجال. شاركنا أيضًا خطة الزيادة في مجموعة الإعلان عن المواضيع. |
| التأثير في إشارات الطرف الأول | قد تكون الزيادة في عدد "المواضيع" في التعديل الأخير على نظام التصنيف ذات قيمة كبيرة، ونتيجةً لذلك، فإنّها تؤدي إلى خفض قيمة الإشارات الأخرى المستندة إلى الاهتمامات من الطرف الأول. | في تقرير الربع الأول من عام 2023، علّقت "هيئة الأسواق" (CMA) قائلاً: "ندرك أنّ Google كانت تناقش تصنيفها الجديد المقترَح مع العديد من المشاركين في السوق على مستوى سلسلة إمداد تكنولوجيا الإعلان. على الرغم من ذكر عدد قليل من مؤسسات النشر الكبيرة أن استخدام المواضيع بشكل أكبر سيؤدي إلى زيادة الضغط التنافسي على الحلول المستندة إلى بيانات الطرف الأول، فإن وجهة نظرنا الأولية هي أن فائدة أكبر للمنافسة بشكل عام، لا سيما قدرة الناشرين الأصغر حجمًا على مواصلة تحقيق الربح من المساحة المتوفّرة للإعلانات بعد الإيقاف النهائي لملفات تعريف الارتباط التابعة لجهة خارجية". تتوافق وجهة نظرنا مع هذا التعليق الذي نشرته هيئة الأسواق والتسويق (CMA). |
| فائدة الأنواع المختلفة من الأطراف المعنية | قد تكون لتقنيات الإعلان التي تؤدي دور مقدِّمي خدمة SSP ومنصات DSP مزايا كبيرة على الجهات الفاعلة الأخرى في المنظومة المتكاملة. | لم يتغيّر ردّنا عن الأرباع السابقة: "التزمت Google بتصميم عروض "مبادرة حماية الخصوصية" وتنفيذها بطريقة لا تشوّه المنافسة من خلال منح الأولوية لنشاط Google التجاري، مع مراعاة التأثير على المنافسة في الإعلانات الرقمية وعلى الناشرين والمعلنين بغض النظر عن حجمها. ونواصل العمل بشكل وثيق مع هيئة السلع والخدمات لضمان التزام عملنا بهذه الالتزامات. في إطار عملية اختبار "مبادرة حماية الخصوصية"، يتمثّل أحد الأسئلة الرئيسية التي سنقيّمها في كيفية أداء التكنولوجيات الجديدة لمختلف أنواع الجهات المعنيّة. الملاحظات مهمة في هذا الصدد، خاصة الملاحظات المحددة والقابلة للتنفيذ التي يمكن أن تساعدنا في تحسين التصميمات الفنية بشكل أكبر. لقد تعاونّا مع الهيئة لتطوير نهجنا في مجال الاختبار الكمي، ونحن ندعم نشر ملاحظة حول تصميم التجربة للهيئة من أجل توفير المزيد من المعلومات للمشاركين في السوق وفرصة للتعليق على المناهج المقترحة". |
| المواضيع التابعة | بما أنّ معايير اختيار المواضيع تمثّل تكرار زيارات المتصفّح، هل سيؤدي تقسيم الشرائح إلى عدم وصول المواضيع التابعة إلى الأعلى مطلقًا؟ | يعمل Chrome حاليًا على تقييم منهجيات الترتيب الأخرى، واستكشاف إشارات أخرى قد تؤدي إلى تحسين الترتيب. وسنبلغ المنظومة المتكاملة بخططنا المعدَّلة في الوقت المناسب. |
| الحساسية | يجب أن يكون هدف Topics API هو ضمان أن تكون معلومات المستخدمين التي يتم الحصول عليها أو اشتقاقها من Topics API أقل حساسية على مستوى شخصي مما يمكن استخلاصه باستخدام طرق التتبُّع الحالية. | نعتقد أنّ Topics API أكثر خصوصية بشكل كبير من التكنولوجيات الحالية، وتحدّ بشكل كبير من إعادة تحديد هوية المستخدمين، وتم تصميمها لاستبعاد المواضيع الحسّاسة. نحن ندرك أنّه يمكن ربط المواضيع أو دمجها مع بيانات الطرف الأول لإنشاء فئات إعلانية حساسة، ولكنّنا نعتقد أنّ Topics API تقدّم خطوة جديدة نحو خصوصية المستخدم ونلتزم بمواصلة تحسين واجهة برمجة التطبيقات. |
| هيكل التصنيف | إضافة تركيبة رقم التعريف وإصدار الإصدارات وغيرها من البيانات الوصفية إلى تصنيف المواضيع | في الوقت الحالي، في ردّ واجهة برمجة التطبيقات، نُدرج رقم تعريف التصنيف. ومع توجّهنا نحو الإدارة طويلة الأمد، من المنطقي مراجعة عنصر Topics وتضمين بيانات وصفية إضافية عند تحديد النُسخ إذا لزم الأمر. |
| تحكّم الناشر | يجب أن يكون للناشرين رأيهم في Topics التي يجب تصنيف مواقعهم الإلكترونية عليها. | قد يؤدي التصنيف الخاطئ للمواقع الإلكترونية إلى جعل إشارة "المواضيع" أقل فائدة بشكل عام كإشارة بشكل عام، إلا أنّ المواقع الإلكترونية المحدّدة التي تم تصنيفها عن طريق الخطأ لم تعد أكثر أو أقل ضررًا من أي مواقع إلكترونية أخرى. ويرجع ذلك إلى أنّ المعلومات السياقية للموقع الإلكتروني ستكون متاحة دائمًا للمزادات على ذلك الموقع، ما سيوفّر معلومات مشابهة للموضوع الصحيح، حتى في حال التصنيف الخاطئ. ونرحّب بالملاحظات حول هذا الموضوع هنا. هناك مخاطر تتعلق بالسماح للناشرين بالتحكّم في تصنيفاتهم. قد تصنِّف المواقع الإلكترونية المواقع الإلكترونية بشكل غير صحيح عن قصد، أو يقلّل ذلك من فائدة للجميع، أو يعمل على ترميز المعاني الحساسة في مواضيع أقل شيوعًا، أو الإضرار بخصوصية المستخدم. |
| إضافات Chrome | السماح لإضافات Chrome بإدارة Topics وفلترتها، مثلما الحال مع إضافات إدارة ملفات تعريف الارتباط الحالية | كما ناقشنا على GitHub، نتوقّع أن يكون ذلك ممكنًا، لكنّنا نرحّب بملاحظات إضافية من المنظومة المتكاملة. |
| الانتقال إلى التوفّر للجمهور العام | هل سيكون هناك أي تأثير في Topics API عند الانتقال من مرحلة التجربة والتقييم إلى مرحلة التوفّر للجمهور العام؟ | لن يتم فقدان أي بيانات للمستخدمين الذين ينتقلون من مرحلة التجربة والتقييم إلى مرحلة التوفّر للجمهور العام. |
| الخصوصية | قد تحتوي أسماء المضيفين على معلومات خاصة قد يتم الكشف عنها من خلال Topics API. | لقد اتّخذنا عددًا من إجراءات التخفيف لضمان الخصوصية، كما هو موضّح هنا. |
| الاحتيال وإساءة الاستخدام | كيفية منع التلاعب بـ Topics من خلال الزيارات الاحتيالية | يتم توضيح إجراءات التخفيف هنا. |
| مصنِّف المواضيع | هل يمكن للمواقع الإلكترونية طلب تغيير تصنيف "المواضيع"؟ | يهمّنا الحصول على آراء من المنظومة المتكاملة حول هذا الموضوع كما نرحّب بالملاحظات والآراء هنا. |
| المواقع الإلكترونية لموفّري المواضيع | تعيين مواقع ويب معينة تستضيف محتوى للعديد من الموضوعات على أنها "مواقع لمقدمي المواضيع الخاصة" وتدريب المصنِّفات بناءً على العلامات المتوفرة في صفحات الويب. | نحن نناقش الاقتراح هنا، ونرحب بالتعليقات الإضافية. |
Protected Audience API (المعروفة سابقًا باسم FLEDGE)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| تشكيل حركة المرور | تأثير الأداء للفلترة المستندة إلى SSP لتحسين تحميل طلبات البحث في الثانية (QPS) | ولقد قضينا وقتًا طويلاً في التفكير في كيفية تشكيل الزيارات، وننصح SSP بالاستفادة من التخزين المؤقت. |
| مستوى صوت الاختبار | يمثل تحدي اختبار ميزة Protected Audience على سبيل المثال صعوبة في جذب أعداد كبيرة من الزيارات ومنصات SSP وDSP. | ونحن نعمل باستمرار على التعاون مع شركاء SSP وDSP لاستخدام ميزة "الجماهير المحمية" واختبارها. بدأ مدى التوفُّر للجمهور العام ونحن على ثقة من أنّ نسبة الزيارات التي تم فيها تفعيل "الإعلانات المخصّصة" ستجعل تجربة الشركاء أكثر جاذبيةً. |
| مستوى التعقيد | يتطلّب استخدام حلول Protected Audience جهودًا وتكاليف كبيرة. | ندرك أنّه من الصعب استخدام التكنولوجيات الجديدة، بما في ذلك "مبادرة حماية الخصوصية". يعمل فريق "مبادرة حماية الخصوصية" عن كثب مع مجموعة واسعة من الجهات المعنيّة لتثقيف جهودها ودعمها، كما يعمل باستمرار على تقييم المسرّعات الأخرى لدعم استخدام المنظومة المتكاملة. |
| بيئات التنفيذ الموثوق بها | دعم بيئات التنفيذ الموثوق بها (TEE) في بيئات السحابة الإلكترونية غير العامة | وبينما نستكشف خيارات محتملة غير الحلول المستندة إلى السحابة الإلكترونية، ليس من المجدٍ حاليًا دعم بيئة التنفيذ الموثوقة (TEE) داخل المؤسسات نظرًا لقيود الأمان داخل المؤسسة والتي قد تتطلب تقييمًا مستهلكًا للوقت من أجل "مبادرة حماية الخصوصية". بسبب متطلبات الأمان في "مبادرة حماية الخصوصية" والتحديات الكبيرة التي تفرضها عمليات النشر داخل المؤسسات، نعتقد أنّ مواصلة توسيع وتحسين عمليات النشر المستنِدة إلى السحابة الإلكترونية (مثل إتاحة Google Cloud Platform بالإضافة إلى AWS) هي الأكثر فائدة للمنظومة المتكاملة. ومع ذلك، نرحب بملاحظات إضافية حول سبب أهمية هذا الشرط. |
| بنية التكلفة | عروض الأسعار سيؤدي عرض "خدمات المزاد" إلى زيادة التكلفة والتعقيد لتقنيات الإعلان مقارنةً بالنماذج من جهة العميل. | نعمل حاليًا على تطوير دليل لتقدير تكاليف إتاحة سير عمل عروض الأسعار والمزادات في "عروض الأسعار" خادم المزاد، الذي يرتبط باستخدام تقنية الإعلان، يحقِّق أحد أهداف تصميماتنا |
| المخططات الزمنية لـ "كي أنون" | متى سيتم فرض قيود المجهولة المصدر المخطط لها على "renderUrl"؟ | نحن نعمل على تقديم توضيح بشأن المخطط الزمني لإجراءات التنفيذ الذي سنطرحه قريبًا. |
| قيود runAdAuction | هل يستطيع Chrome تقييد إمكانية الاتصال بـ runAdAuction من الصفحة العلوية فقط؟ |
على الرغم من أن تصميمنا يتوافق بشكل كامل مع runAdAuction ليكون بالإمكان طلبه من الصفحة العليا، إلا أننا نعتقد أن جعله أكثر ضررًا على الناشرين بحيث لا يمكن طلبه إلا من النطاق الأعلى.لقد علِمنا من المنظومة المتكاملة تحديدًا بأنّ "مبادرة حماية الخصوصية" تحتاج إلى تخفيف العبء الواقع على الناشرين والمعلنين. تتوافق هذه الملاحظات مع المبدأ العام لتطوير الويب، وهو أنّه يمكن لمالكي المواقع الإلكترونية استخدام أدوات خارجية في إدارة مواقعهم الإلكترونية. كان هدف "مبادرة حماية الخصوصية" هو تشجيع منظومة متكاملة سليمة بدون الحاجة إلى وصف كيفية عمل الناشرين وتكنولوجيات الإعلان. من خلال السماح للناشر باختيار طريقة الاتصال بـ runAdAuction على موقعه الإلكتروني والأشخاص الذين يتصلون به، فإننا نعتقد أننا نقدّم المرونة للناشرين في العثور على أفضل مسار لتلبية متطلباتهم. |
| دعم عملية التنفيذ | هل يمكن لمتصفِّح Chrome إنشاء مزاد مفتوح المصدر أو المساهمة في تنفيذه مفتوح المصدر لمزاد متعدد البائعين؟ | تهدف "مبادرة حماية الخصوصية" إلى تطوير تقنيات للحفاظ على الخصوصية لا تعتمد على ملفات تعريف الارتباط التابعة لجهات خارجية أو غيرها من المعرّفات على مواقع إلكترونية متعددة. نريد تشجيع منظومة متكاملة سليمة بدون الحاجة إلى وصف كيفية عمل تقنيات الإعلان. لقد نشرنا إرشادات حول طريقة عمل واجهات برمجة التطبيقات في مستودع جيت هب، ونحن مستعدون لاستكشاف الحلول في المجال. لا نخطط لإجراء أي عملية تنفيذ محددة، لأنّ مهمتنا الأساسية هي إنشاء تكنولوجيات للأنظمة الأساسية، وليس تحديد استراتيجيات لاستخدام تلك التكنولوجيات. ستساعد تقنياتنا في تمكين شركات تكنولوجيا الإعلان من تقديم أفضل خدمة لعملائها من خلال تطبيق تدابير حماية الخصوصية المناسبة للمستهلكين. |
| مزادات متعددة البائعين | هل سيفرض Chrome مشاركة "سياق" الفائز في مزادات المكونات؟ | تم تصميم Protected Audience API لمنح الجهات التي تبدأ المزاد المتعدد البائعين تمرير المعلومات إلى مزاد المكوّنات (ملاحظة: قبل بدء المزاد فقط). مع ذلك، لا نرى أي طريقة تمكّن المتصفّح من تمييز ما إذا كانت إحدى المعلومات هي الفائزة من حيث السياق أم لا، لذلك لا يمكننا فرض الحظر أو طلب معلومات معيّنة. |
| تفضيل المستخدم لتتبُّع الموافقة | تكنولوجيا الإعلان تسأل من الإعلانات المخصّصة عن كيفية تنفيذ تتبُّع موافقة المستخدم بشكل صحيح | تتضمّن ردّنا ما قلناه في السؤال الأول: "بالنسبة إلى إعلانات محدّدة، تكون تكنولوجيا الإعلان ذات الصلة هي الجهة الأفضل لتقديم عناصر تحكّم في تحديد تصميمات الإعلانات أو كيفية اختيارها". ناقشنا عددًا من السيناريوهات المتعلقة بهذه المشكلة خلال اجتماع الجمهور المحمي في WICG ونرحب بالملاحظات والمناقشات الإضافية حول هذه المشكلة. |
| الجمهور المخصّص | هل ستتم إتاحة حالات الاستخدام على SSP ذات الصلة بإنشاء شرائح جمهور مخصّصة في Protected Audience API؟ | تسمح Protected Audience API لمنصّات SSP ومزوّدي تقنية الإعلان الآخرين بامتلاك شرائح الجمهور المخصَّصة وإدارتها. نعمل حاليًا على تطوير المزيد من الإرشادات حول كيفية دمج منصة SSP مع واجهة برمجة تطبيقات PA، وستتم إتاحتها لمقدّمي الخدمات الذاتية (SSP) ومزوّدي تقنية الإعلان الآخرين بهدف دعم جهود الدمج. |
| التنسيقات | هل تتوافق واجهة برمجة التطبيقات Protected Audience API مع الفيديوهات؟ | يتم عرض إعلانات الفيديو بإحدى الطريقتين التاليتين: VAST XML أو HTML (إعلان خارج البث يمكن أن يحمّل في النهاية ملف VAST XML في مشغّل الفيديو أيضًا). يمكن للمشترين عرض أي من التنسيقين عبر عنوان URL للعرض. تم تعديل مواصفات نموذج عرض إعلانات الفيديو (VAST) مؤخرًا لإتاحة Attribution Reporting API. إذا كانت المواقع الإلكترونية تعرض إعلانات الفيديو، يجب أن تستعد لطريقة عرض الإعلانات من خلال Protected Audience API. وهذا يعني التأكّد من أنّ علامات مواضع الإعلان يمكنها تمرير عنوان URL من إطار iframe في Protected Audience API إلى مشغّل فيديو. بالنسبة إلى ميزة Fenced Frames، سنعمل على تلبية متطلبات الفيديو قبل الحاجة إلى استخدام ميزة Fenced Frames، أي في موعد أقصاه 2026. |
| تعديل الفيديو | كيف تعمل حالة استخدام مستوى السرعة مع Protected Audience API؟ | نحن نقدّر الملاحظات التي نتلّقاها. يهمّنا الاطّلاع على المزيد من حالات هذا الطلب مع مزيد من التفاصيل من المزيد من شركاء SSP، لأنّ هذه المشكلة كانت غالبًا أحد أسباب المشكلة في مقدِّم خدمة DSP. |
| فترة تكرار التحديث | قد لا يكون معدل تكرار المكالمات من "dailyUpdate" (ما يصل إلى مكالمة واحدة لكل مجموعة اهتمام في اليوم) كافيًا لحالات استخدام معيّنة، مثل تعديل معلومات المنتجات. |
نحن نقدّر الملاحظات التي نتلّقاها. تتوفّر حلول أخرى تتيح لتكنولوجيا الإعلان استخدام الإشارات التي يتم تحديثها بوتيرة مختلفة، مثل عمليات البحث عن K/V. |
| مراقبة جودة الإعلانات | كيف ينفّذ الناشرون مراقبة جودة الإعلانات؟ | في الوقت الحالي، توفّر Protected Audience API وظيفة تتيح للناشرين إعلام مقدّمي الخدمات الاستراتيجيين ببعض عناصر التحكّم التي يمكنهم ضبطها كجزء من إعدادات المزاد، أي قبل تقديم عرض السعر (أي قوائم الحظر المستندة إلى التصنيفات المرتبطة بالإعلانات). نحن نرحّب بملاحظاتك حول أي وظائف إضافية قد تتطلّبها المنظومة المتكاملة. |
| تصحيح الأخطاء | متى ستتم إزالة وظيفة "forDebuggingOnly"؟ |
ونخطّط لإيقاف forDebuggingOnly في حال حدوث خسارة بسبب الإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية. ونخطّط لإيقاف forDebuggingOnly في أقرب وقت ممكن إذا كانت لديك أحداث فائزة في 2026. |
| مجموعات الاهتمامات على جميع الأجهزة | اقتراح لتفعيل مجموعات الاهتمامات المشتركة على جميع الأجهزة لبرامج وكيل المستخدم التي تمت مصادقتها | نحن نقيّم هذا الاقتراح، إلا أن الدقة العالية للاستهداف على جميع الأجهزة تثير مخاوف كبيرة متعلقة بالخصوصية، كما تمت مناقشته في مشكلة GitHub هذه. |
| (تم الإبلاغ أيضًا في الربع الأول) تجديد النشاط التسويقي الديناميكي | هل ستظل ميزة تجديد النشاط التسويقي الديناميكي متاحة باستخدام Protected Audience API بعد إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا؟ | ونعتقد أنّ حالة الاستخدام هذه ممكنة باستخدام Protected Audience كما هو موضّح هنا. |
| البيانات المرتبطة بالنقرات | إضافة البيانات ذات الصلة بالنقرات إلى browserSignals. |
نطلب حاليًا توضيحًا بشأن الوقت الذي حدث فيه النقر لتقديم موضع أولي. |
| (تم الإبلاغ أيضًا في الربع الرابع من عام 2022) وظائف من تحديد المستخدم في Protected Audience | كيف سيتم توفير الوظائف المحدّدة من قِبل المستخدم (UDF) في Protected Audience API؟ هذه هي الدوال التي يمكن للمستخدمين برمجتها لتوسيع وظائف واجهة برمجة التطبيقات. | أشارت أيضًا خبراء تكنولوجيا الإعلان الذين أثاروا هذه المشكلة إلى أنّهم ما زالوا يقيّمون ما يمكن فعله باستخدام "الحلّ المخصّص بدون إعلانات" (UDF)، لذلك لا تتوفّر أي ملاحظات قابلة للتنفيذ هنا بعد للتفاعل معها، وليس إلى أن تتوفّر للجمهور العام على الأقل. |
| العملة | يجب عدم تمثيل مبالغ العملات باستخدام النقاط العائمة. | لقد تناولنا هذه المشكلة بمزيد من التفصيل. |
| إمكانات اختيار الإعلانات التي لا تستخدم وسيط عرض الطلب (DSP) | ما الدور الذي تلعبه خوادم الإعلانات في مزادات Protect Audience API؟ | نحن على دراية بطلبات استمرار خوادم الإعلانات في تقديم خدمات اختيار الإعلانات بعد عرض السعر / تحسين تصميمات الإعلانات الديناميكية. نعمل حاليًا على تقييم التحليل التفصيلي للفجوات بين واجهة Protected Audience API الحالية وهذه الطلبات. |
| GenerateBid | دعم "إعلانات Google" اقتراح لعرض أكثر من إعلان مرشّح واحد لكل مجموعة اهتمام إعلانية من generateBid وتسجيل هؤلاء المرشحين في "scoreAd". |
يتم تقييم ذلك حاليًا. ونرحّب بالملاحظات الإضافية هنا. |
| طلب المزاد | هل يجب أن تكون مزادات Protected Audience API هي آخر مزادات يمكن عرضها حتى تتمكّن من الحصول على معلومات من نتائج جميع المزادات الأخرى؟ | ما مِن متطلبات فنية لكي يتم تشغيل Protected Audience API في النهاية. |
| تنقُّل لا يبدأه المستخدم | عرض التنقّل الذي بدأه غير المستخدم | نحن نراجع هذا الطلب ونناقشه هنا ونرحب بملاحظاتك الإضافية. |
| التخزين المؤقت | يجب ألا ينشئ SSP قيمة perمشتريSignals لوسيط عرض الطلب (DSP) من ذاكرة تخزين مؤقت في حال تغيّرت حالة المستخدم. | نحن ندرك أنّ التخزين المؤقت لا يناسب كل حالة استخدام للإشارات الخاصة بكل مشترٍ، ونحن نقيّم خيارات إضافية. نحن نرحّب بأي ملاحظات إضافية من المنظومة المتكاملة حول ما إذا كان التخزين المؤقت مناسبًا لحالات الاستخدام لديهم. |
| تقارير تحديد المصدر والجمهور المحمي | كيف يمكن أن تعمل Attribution Reporting API وProtected Audience API معًا؟ | تتوفّر حاليًا عمليات دمج لواجهة Protected Audience API في كلٍّ من وضعَي Attribution Reporting API (التقارير على مستوى الحدث والتقارير التلخيصية). لقد شاركنا المزيد من المعلومات عن الدمج المحسَّن لواجهة Protected Audience API وAttribution Reporting في 1 حزيران (يونيو). يمكنك الاطّلاع على معلومات عنها هنا. |
| نقطة نهاية الخادم | هل ستكون نقطة نهاية الخادم هي خادم التجميع الموثوق به في التصميم النهائي؟ | نقطة نهاية الخادم هي نقطة نهاية تعتمد على تكنولوجيا الإعلان ومستقلة عن خوادم التجميع الموثوق بها المستخدَمة لمعالجة التقارير التي تم جمعها وتحويلها. لا نخطط حاليًا لأي تغييرات تم إجراؤها على نقطة نهاية إعداد التقارير. يهدف التصميم الحالي إلى ضمان أنّ التقارير القابلة للتجميع نفسها (باستخدام حمولات بيانات مشفّرة) لا تسرّب بيانات من مواقع إلكترونية متعددة، لذلك من غير الضروري استخدام نقطة نهاية موثوقة. وهناك تعقيد إضافي يتمثل في أنّه من المحتمل أن يكون لتقنيات الإعلان المختلفة استراتيجيات مختلفة مطلوبة لتجميع البيانات. ونرحّب بالملاحظات الإضافية هنا. |
| WebIDL | لا تتوافق مواصفات Protected Audience API الحالية مع مواصفات WebIDL. | نقيّم هذه الملاحظات ونناقش المشكلة هنا. |
| إدارة الموافقة | كيف سيتم التعامل مع تمرير إشارة الموافقة في Protected Audience API؟ | لا تندرج المعلومات السياقية ضمن نطاق Protected Audience API. نحن نناقش هذه المشكلة ونرحب بملاحظاتك الإضافية. |
| التسويق المستنِد إلى الحساب | هل ستكون حالات الاستخدام المستندة إلى الحساب ممكنة؟ | تتيح Protected Audience API استخدام مجموعة متنوعة من حالات الاستخدام للتسويق المستند إلى الجمهور. نحن نواصل فهم كيفية الاستفادة من Protected Audience API لتوفير أفضل دعم لحالة الاستخدام هذه تحديدًا، ونرحّب بالملاحظات الإضافية حول هذه المشكلة من المنظومة المتكاملة. |
| مزاد المكونات | ما النتيجة التي يحصل عليها المشاركون في مزاد المكوّنات؟ | لا تسجِّل مزادات المكوّنات مجموعات الاهتمامات مباشرةً، بل تسجّل الإعلانات وعروض الأسعار التي يرسلها مزوّد وسيط عرض الطلب من الدالة generateBid. يتم تشغيل الدالة 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 تحديد إصدار الرمز المستخدَم في طلب المزاد (أي لأغراض عروض الأسعار أو المزاد وإعداد التقارير أيضًا). |
| مساحة التخزين المشتركة | دعم الكتابة في مساحة التخزين المشتركة في خدمة "عروض الأسعار والمزادات" | في الوقت الحالي، لا تتيح "خدمات عروض الأسعار والمزادات" "مساحة التخزين المشتركة"، لكننا نرحّب بالتعليقات الإضافية حول سبب أهمية حالات الاستخدام هذه للمنظومة المتكاملة. |
| الانتقال من الويب إلى التطبيق | إتاحة مشاركة المجموعات ذات الاهتمامات المشتركة من الويب إلى التطبيق | لا تتوفّر ميزة الانتقال من الويب إلى التطبيق حاليًا ضمن نشر Protected Audience API على Chrome وAndroid، ولكنّنا مهتمون بمعرفة مدى أهمية حالة الاستخدام هذه من المنظومة المتكاملة. |
| المجهولة المصدر باللغة الجارية | كيفية التعامل مع الإجراءات الاحتياطية للهوية المجهولة | نحن نناقش المشكلة ونرحب بملاحظاتك الإضافية. |
قياس الإعلانات الرقمية
Attribution Reporting (وواجهات برمجة التطبيقات الأخرى)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| إعدادات التقرير البديل على مستوى أحداث الإحالات الناجحة بعد رؤية الإعلان فقط | ملاحظات بشأن إعدادات التقارير البديلة للإحالات الناجحة على مستوى الحدث | لقد وصلتنا بعض الملاحظات التي تفيد بأنّ الإعدادات الحالية على مستوى الحدث ليست مثالية، ونطلب منك تقديم ملاحظات بشأن الإعدادات العامة المثلى. ويسعدنا تلقّي أي ملاحظات إضافية بهذا الخصوص، ونعتقد أنّ الشرح المرن على مستوى الحدث يساعد في حلّ هذه المشكلة أيضًا. |
| عمليات الضبط المرنة على مستوى الحدث | ما هي حالة ميزة الإعدادات المرنة على مستوى الحدث؟ | وقد شاركنا مستندات حول الإعداد المرن على مستوى الحدث. لا تزال الميزة في مرحلة الاقتراح ونحن نسعى إلى الحصول على مزيد من الملاحظات حول ما إذا كانت ذات قيمة للمنظومة المتكاملة. |
| عمليات الضبط المرنة على مستوى الحدث | كيف يمكن تسوية البلاغات المتضاربة من أطراف مختلفة؟ | تتم معالجة معظم سيناريوهات إعداد التقارير من خلال استخدام التقارير المجمّعة، في حين أن اقتراح الضبط المرن على مستوى الحدث مخصّص على وجه التحديد لتوفير مرونة إضافية للتقارير على مستوى الحدث، والتي تُستخدم غالبًا لحالات استخدام التحسين. نرحّب بأي تعليقات أو ملاحظات إضافية حول المنظومة المتكاملة بشأن هذا السيناريو. |
| تسجيل المصدر | ماذا لو تم تسجيل المصدر بعد تسجيل المشغّل؟ | في الوقت الحالي، إذا تم تسجيل المصدر بعد تسجيل العامل المشغِّل، لن يمكن نسب المصدر والعامل إلى بعضهما البعض. يبدو أن هذا هو سيناريو حالة هامشية. يسعدنا تلقّي أي ملاحظات إضافية بشأن هذه المشكلة وسنعالجها إذا كان ذلك سيناريو يواجهه العديد من خبراء تكنولوجيا الإعلان. |
| التعامل مع وكالات إعلانية متعدّدة | كيف يمكن لمقدّمي الخدمات الرقمية استخدام Attribution Reporting API عندما يعمل أحد المعلنين مع وكالات إعلانية متعددة؟ | تتيح واجهة برمجة التطبيقات عمليات إعادة التوجيه، وبالتالي يمكن استخدامها حتى عندما يعمل المعلِن مع عدة وكالات إعلانية. بالإضافة إلى ذلك، هناك بعض القيود المفروضة في ما يتعلق بعمليات إعادة التوجيه لضمان تحسين واجهة برمجة التطبيقات للخصوصية. لقد حدّدنا أيضًا حلاً بديلاً محتملاً لاستخدام واجهة برمجة التطبيقات Shared Storage API للسيناريو المحدّد الذي طرحته تكنولوجيا الإعلان. نرحّب بأي ملاحظات إضافية بشأن هذا السيناريو، وسنواصل التكرار بناءً على تلك الملاحظات. |
| حدود الوجهة | قد تتأثّر حالة استخدام الإعلانات التي تتم إعادة تحميلها تلقائيًا بسبب فرض حدود على الوجهة. | لقد ناقشنا هذه المشكلة في اجتماع WICG في 1 أيار (مايو) ونتطلّع إلى الحصول على ملاحظات حول الحدّ المعقول المطلوب. أضفنا إلى الشرح التوضيحي لإعداد تقارير تحديد المصدر مع التقارير على مستوى الحدث والذي يفيد بأنّ المتصفِّح يمكن أن يحدّ من عدد نطاقات eTLD+1 في "الوجهة" التي تمثّلها المواقع المصدر. (يُرجى الاطّلاع على طلب سحب البحث). |
| تقارير تحديد المصدر والجمهور المحمي | كيف يمكن أن تعمل Attribution Reporting API وProtected Audience API معًا؟ | تتوفّر حاليًا عمليات دمج لواجهة Protected Audience API في كلٍّ من وضعَي Attribution Reporting API (التقارير على مستوى الحدث والتقارير التلخيصية). لقد شاركنا المزيد من المعلومات عن الدمج المحسَّن لواجهة Protected Audience API وAttribution Reporting في 1 حزيران (يونيو). يمكنك الاطّلاع على معلومات عنها هنا. |
| عمليات الضبط المرنة على مستوى الحدث | شارك أفضل الممارسات لمحاكاة التشويش الآن بعد أن أصبحت المعلمات قابلة للتهيئة. | لدينا رمز برمجي مشترك على GitHub يمكن لأي شخص استخدامه لتقييم تحصيل المعلومات وتأثير التشويش لأي تهيئات مرنة على مستوى الحدث يريد اختبارها. تسرّنا معرفة آراء أي شخص يختار الاختبار باستخدام الرمز ويريد مشاركة ملاحظاته. |
| قياس الإحالة على مستوى التطبيقات وعلى الويب | متى سيكون قياس تحديد المصدر على مستوى التطبيقات وعلى الويب متاحًا؟ | أعلنّا في 9 أيار (مايو) عن تجربة "قياس أداء جميع التطبيقات" و"تحديد المصدر على الويب" من خلال Attribution Reporting API. على الرغم من تخطيط "التوفّر العام" لواجهات برمجة التطبيقات ذات الصلة والقياس في Chrome 115، فليس من المخطَّط حاليًا إطلاق "قياس أداء جميع التطبيقات" و"تحديد المصدر على الويب" في الإصدار 115 من Chrome للجمهور العام. |
| إزالة تكرار الإحالات الناجحة | كيف يمكن التوفيق بين حلول القياس المستقلة مقابل ARA؟ | كما هو الحال مع الممارسات العادية الحالية، يمكن أن يعمل المعلِنون مع مقدّم قياس مستقل تابع لطرف ثالث لإزالة تكرار تقارير الإحالات الناجحة. وقد قدّمنا مراجع عن كيفية إزالة تكرار الإحالات الناجحة لإعداد التقارير على مستوى الحدث. |
| فقدان البيانات أثناء إجراء تعديلات على قاعدة بيانات "تقارير تحديد المصدر" | هل سيكون هناك أي فقدان للبيانات عند تحديث Chrome لقاعدة بيانات "تقارير تحديد المصدر" كما أعلنّا؟ | بدءًا من الإصدار الثابت 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 بالإضافة إلى AWS) هي الأكثر فائدة للمنظومة المتكاملة. ومع ذلك، نرحب بملاحظات إضافية حول سبب أهمية هذا الشرط. |
| إعادة معالجة التقارير لفترات زمنية مختلفة | القدرة على إعادة معالجة التقارير لفترات زمنية مختلفة | لقد وصلتنا طلبات مشابهة تتيح لنا تقسيم الدفعات حسب نطاقات زمنية مختلفة. أحد الاقتراحات هو السماح بإمكانية توسيع رقم التعريف المشترَك باستخدام تصنيف مخصّص لتقنية الإعلان، حتى يمكن تقسيم التقارير إلى دفعات مختلفة. نحن في مرحلة مبكرة من تقييم هذه العملية، وسنحرص على تعديل المنظومة المتكاملة كلما تطوّر هذا الاقتراح. |
| الآثار المترتبة على الخصوصية في بيئة التنفيذ الموثوق به | الآراء الإيجابية تجاه الآثار المترتبة على الخصوصية في بيئات التنفيذ الموثوق بها | يسرّنا معرفة ردود أفعال إيجابية من المنظومة المتكاملة بشأن مقترحاتنا، ونرحب بتلقّي ملاحظات إضافية بينما نواصل تكرار عمليات التحسين وتطويرها. |
| بنود الخدمة | ما هو الموعد النهائي لقبول بنود خدمة "خدمة التجميع"؟ | على الرغم من أننا لم نحدد حتى الآن موعدًا نهائيًا لقبول الأحكام والشروط، إلا أننا نشجع شركات المنظومة المتكاملة على قبول الأحكام والشروط في أقرب وقت ممكن لتجنّب أي تأخير في التسجيل. نشجّع الشركات على التواصل معنا إذا كانت لديها أيّ أسئلة. |
| اكتشاف المفتاح | ستسمح ميزة الاكتشاف الرئيسي للمختبرين بطلب البحث عن التقارير المجمّعة بدون الحاجة إلى قائمة صريحة من مجموعات المفاتيح المحتملة من أجل معالجة التقارير الموجزة لتحديد المصدر على جميع الشبكات لتحسين الأداء والدقة. | نستكشف حاليًا الحلول والحلول الممكنة، ونرحب بالتعليقات الإضافية من المنظومة المتكاملة. |
Private Aggregation API
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| مصدر إعداد التقارير | كيف يتم تحديد مصدر إعداد التقارير؟ | يكون أصل إعداد التقارير دائمًا هو أصل النص البرمجي لمتصل التجميع الخاص. |
| مساحة المفاتيح 128 بت | وضوح قيود المساحة على المفاتيح التي تبلغ 128 بت | سنجعل قيد المساحة الرئيسية هذا أكثر وضوحًا ونحل التناقضات في جميع الصفحات. وننصحك باستخدام استراتيجيات التجزئة للبقاء ضمن هذه المساحة الرئيسية. |
| الحد الأقصى للمساهمة لكل تقرير | الحد الحالي الذي يبلغ 20 مساهمة لكل تقرير منخفض جدًا. | وبدلاً من زيادة العدد الأقصى من المساهمات، نقبل تقسيم التقارير بدلاً من اقتطاعها عند الحدّ الأقصى. وسنحرص على استخدام المنظومة المتكاملة مع تطوّر هذا الاقتراح. |
| تقارير مدى الوصول | يمكنك طلب الوصول إلى التقارير على مستوى الأنظمة الأساسية أو جميع الأجهزة. يُعد مدى الوصول أحد المقاييس الأساسية للإعلان عن العلامة التجارية. يعتمد المعلنون على التقريبات على مستوى عدّة منصات/على جميع الأجهزة لإعداد تقارير مدى الوصول وعدد مرات الظهور لتحليل حملاتهم وتخصيص الإنفاق. تستخدِم نماذج مدى الوصول ملفات تعريف الارتباط التابعة لجهات خارجية كإشارة لقياس الإعلانات التي تظهر في بيئات تابعة لجهات خارجية، لذا طلبت تقنيات الإعلان حلاً بديلاً عند الإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية. |
يستكشف فريق "مبادرة حماية الخصوصية" ميزات لدعم منهجيات الوصول على جميع النطاقات بعد الإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية. ونرحّب بملاحظات وآراء إضافية من المنظومة المتكاملة. |
الحد من التتبُّع الخفي
تقليل وكيل المستخدم/تلميحات العميل لوكيل المستخدم
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| (تم إدراج هذه المعلومات أيضًا في الربع الأول من عام 2023) تلميحات حول أشكال الأجهزة الإضافية | طلب حقول معلومات الوكيل المستخدم (UA-CH) لتوفير أشكال أجهزة إضافية، مثل التلفزيون والواقع الافتراضي | ما زلنا نعمل على اتخاذ بعض قرارات التصميم الرئيسية (سواء لتقديم قيمة واحدة مثل "التلفزيون" أو قائمة من إمكانيات أشكال الأجهزة)، ولكنّنا نبقى مهتمين بإنشاء نماذج أولية لهذه الفكرة. |
| ميزانية الخصوصية | يمكن أن تؤدي قيود ميزانية الخصوصية إلى أن تصبح طلبات UA-CH غير محددة عند إرسال عدد كبير جدًا من الطلبات. | لا نُجري أي تعديلات جديدة على اقتراح "ميزانية الخصوصية" في الوقت الحالي، ولكنّنا التزمنا بعدم حظر طلبات الحصول على تلميحات عملاء Universal Analytics قبل الإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية. |
| توافُق المواقع الإلكترونية | تستخدم مواقع الويب العلامة التجارية UA-CH لتقييد وصول متصفحات معينة إلى المواقع. | هناك حالات استخدام صالحة لإنشاء قائمة علامات تجارية، وأحد هذه الحالات هو التوافق الدقيق. تتوفّر في Universal Analytics بشكل مجاني علامات تجارية متعدّدة لحلّ هذه المشاكل. |
بروتوكول حماية عنوان IP (المعروف سابقًا باسم Gnatcatcher)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| الاحتيال و إساءة الاستخدام | كيف يمكن للشركات وضع تدابير لمكافحة الاحتيال باستخدام حماية عنوان IP؟ | نحن ندرك أهمية حالات الاستخدام لمكافحة الاحتيال والتأثير المحتمل على حالات الاستخدام هذه. نخطط لنشر المزيد من التفاصيل حول دعم مكافحة الاحتيال في وقتٍ لاحقٍ من هذا الصيف. ونسعى إلى الحصول على ملاحظات بشأن المنظومة المتكاملة حول كيفية دعم حالات الاستخدام في مجال مكافحة الاحتيال بشكل أفضل. |
| 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 |
|---|---|---|
| حظر الإعلانات | قد تسهّل ميزة Fenced Frames على أدوات حظر الإعلانات حظر الإعلانات. | يمكن أن تتفاعل الإضافات مع الإطارات المحمية بشكل مشابه لطريقة تفاعلها مع إطارات iframe. وسيظهر أيضًا للإضافات عنوان URL الفعلي الذي يوشك الإطار المحدود على الانتقال إليه، وبالتالي يمكنها تطبيق أي قواعد مطابقة لعنوان URL لحظر الفهرسة كما هو الحال في إطارات iframe. وقد يؤدي حظر جميع الإطارات المحظورة بدون أي شروط إلى إيقاف حالات استخدام هذه الإطارات غير الإعلانية. |
Shared Storage API
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| استخدام أوسع | يجب أن تكون مساحة التخزين المشتركة معيارًا على مستوى المجال ومتاح على جميع المتصفحات. | نحن نرحّب بهذه الملاحظات ونقدّرها. يواصل Chrome المشاركة بشكل نشط في منتدى W3C لدعم الاقتراح وطلب الملاحظات والآراء وتعزيز الاستخدام. |
| بوابات الإخراج | بوابات ناتج مساحة التخزين المشتركة محدودة جدًا. | ونأخذ في الاعتبار هذه الملاحظات ونرحب بملاحظات المنظومة المتكاملة الإضافية حول سبب تقييد بوابات الإخراج بشكل كبير. |
| الالتزام باللوائح التنظيمية | كيف ستتعامل مساحة التخزين المشتركة مع الامتثال التنظيمي، مثل سياسات الاحتفاظ بالبيانات؟ | توفّر مساحة التخزين المشتركة مرونة تنفيذ وتخصيص المنطق للتحكّم في مدة صلاحية أي بيانات مخزَّنة وانتهاء صلاحيتها. يمكن لتقنيات الإعلانات تعديل بيانات "مساحة التخزين المشتركة" أو محوها استنادًا إلى الطوابع الزمنية المكتوبة. |
| اختبار A/B | كيف يمكن إجراء اختبار A/B على "مساحة التخزين المشتركة" وProtected Audience API؟ | ونحن نعمل على نشر إرشادات إضافية في هذا الشأن ونأمل أن نشارك معك المزيد من التفاصيل في المستقبل. |
| الحد الأقصى لمساحة التخزين المشتركة | ماذا سيحدث عند بلوغ حد مساحة التخزين المشتركة؟ | إذا تم بلوغ الحد الأقصى، لن يتم تخزين أي إدخالات أخرى. |
| الوصول المتعدد في تحميل الصفحة نفسه | ماذا يحدث عند الوصول إلى مساحة التخزين المشتركة عدة مرات أثناء تحميل الصفحة نفسها؟ | أفضل طريقة للتعامل مع هذا الأمر هي استخدام الدالة window.sharedStorage.append(key, value). بدلاً من تعديل قيمة كل إعلان، ما قد يؤدي إلى حدوث تضارب في حال توفّر إعلانات متعدّدة. ستضيف دالة append القيمة الجديدة فقط إلى نهاية القيمة الموجودة مسبقًا. |
| وظائف iframe | هل ستتوافق مساحة التخزين المشتركة مع وظائف iframe معيّنة إذا لم تعد تعمل بعد الإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية؟ | بعد الإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية، سيتم تقسيم مساحة التخزين المحلية في إطارات iframe من خلال الموقع الإلكتروني ذي المستوى الأعلى، ولكن لن يتم حظر إطارات iframe نفسها. لا يمكن نسخ البيانات في مساحة التخزين المحلية لإطار iframe عبر العديد من المواقع الإلكترونية ذات المستوى الأعلى، ولكن لا يزال بالإمكان استخدام التخزين المحلي ضمن إطار iframe. |
ملفات تعريف الارتباط في الحالة المقسَّمة المنفصلة (CHIP)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| الحد الأقصى للتقسيم | وما زال حجم 10 كيبيبايت لكل موقع إلكتروني مقسّمًا كقيمة أقل، لذا ننصح بتخفيضه. | سبق أن أشار Firefox إلى موضع إيجابي على ملفات تعريف الارتباط في الحالة المقسَّمة المنفصلة (CHIPS). للحصول على دعم Webkit، ننصح المطوّرين بتقديم ملاحظاتهم وآرائهم لشركة Apple مباشرةً حول مشكلة GitHub في ما يتعلق بحالات الاستخدام التي يُفضّل فيها استخدام ملفات تعريف الارتباط المقسَّمة بدلاً من مساحة التخزين المُقسَّمة. |
| التضمينات التي تمت مصادقتها | قد تؤثر ملفات CHIP في التدفق الحالي لتسجيل الدخول المُوحَّد (SSO) بسبب اختلاف تأثير التقسيم في التضمينات التي تمت مصادقتها. | نعتزم الاستفادة من واجهة برمجة التطبيقات Storage Access (من خلال طلبات من المستخدمين) لإتاحة حالة استخدام التضمينات التي تمت مصادقتها، وأرسلنا مؤخرًا نموذجًا أوّليًا إلى نموذج أوّلي. |
| السياسات الدائمة | هل سيتم تطبيق السياسات الدائمة المحتملة على ملفات تعريف الارتباط للطرف الأول؟ | لا ننوي حاليًا فرض حدود دائمة على ملفات تعريف الارتباط الخاصة بالطرف الأول. |
FedCM
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| دعم تفويض OAuth | الموافقة على السماح لنطاقات Oauth غير المرتبطة بالملف الشخصي | نسعى جاهدين للحصول على ملاحظات من منتدى "هوية الويب" من خلال برنامج W3C FedID CG حول أفضل الطرق لدعم التفويض في ما بعد المصادقة الأساسية بعد الإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية. |
| التوافق مع SAML | التوافق مع متطلبات دعم SAML | يبحث الفريق بنشاط عن مدخلات من منتديات البحث والتعليم بشأن احتياجات دعم SAML (بالإضافة إلى دعم OpenID-connect) بعد الإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية. |
مكافحة المحتوى غير المرغوب فيه والاحتيال
Private State Token API (وواجهات برمجة التطبيقات الأخرى)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| استكشاف إشارات جديدة | وقد عبّر العديد من الشركاء عن آرائهم الإيجابية بشأن استكشاف الإشارات التي يسهِّلها المتصفّح والتي تدلّ على سلامة الجهاز أو ثقة المستخدم. بشكل عام، هم أيضًا حذرون بشأن الإشارات الجديدة المصمَّمة لغرض معيّن والتي تكون كافية للاحتفاظ بالمستويات الحالية من رصد الاحتيال. | نحن متحمّسون بشأن استكشاف مقترحات جديدة معًا ضمن منتدى مكافحة الاحتيال وتعزيز أمان الويب، ونقدّر أيضًا مخاوفهم وشاركها. وهذا هو سبب "مكافحة المحتوى غير المرغوب فيه والاحتيال". كانت إحدى مهام "مبادرة حماية الخصوصية" الأساسية، ولذلك نواصل منح الأولوية للاستثمار في الحفاظ على أمان الويب بينما نعمل على تحسين خصوصية المستخدمين. |
| ملاحظات إيجابية حول توقيت المحيط الهادئ | عبّر العديد من الشركاء عن اهتمامهم باختبار أو استخدام ملفات PST من أجل عدة حالات استخدام لمكافحة الاحتيال أو أمان الويب. | ويسعدنا معرفة الدعم والاهتمام باستكشاف الحلول الجديدة التي تستخدم ملفات PST. تتوفّر لدينا موارد ورمز نموذجي من خلال الموقع الإلكتروني لمطوّري Chrome ونرحب بمزيد من الملاحظات. |
| الاحتيال وإساءة الاستخدام | إرشادات لمنع الإعلانات الاحتيالية / رصد عمليات القياس بعد الإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية عند عدم توفّر المعرّفات. | لقد طرحنا أدوات، مثل الرموز المميّزة للحالة الخاصة، والتي تساعد في استرداد بعض الإشارات المفقودة بسبب ملفات تعريف الارتباط التابعة لجهات خارجية لأغراض مكافحة الاحتيال، إلا أنّها تتوفّر أيضًا عناصر تحكّم جديدة في الخصوصية. نحن نستثمر بشكل نشط في اقتراحات جديدة لمكافحة الاحتيال وإساءة الاستخدام للحفاظ على القدرات المرتبطة بالتغييرات الأخرى في "مبادرة حماية الخصوصية". |
| معدّل المعلومات من جهة الإصدار إلى المصدر | معدّل معلومات جهة الإصدار إلى المصدر مرتفع بما يكفي لتحديد المستخدمين الفرديين. | وقد عدّلنا المواصفات لتكون أكثر وضوحًا بشأن بيانات المستخدمين التي يمكن نقلها باستخدام الرموز المميّزة للحالة الخاصة. حسب التصميم، يمكن استخدام ما يصل إلى ستة مفاتيح عامة في وقت واحد، وهو ما قد يمثل "حالة" لمستخدم معين. ولا يمكن تحديث مجموعات المفاتيح هذه إلا كل 60 يومًا (باستثناء الحالات النادرة التي يكون فيها تغيير مفتاح الطوارئ ضروريًا)، ما يؤدي إلى إبطاء إمكانية دمج بيانات إضافية للمستخدمين بمرور الوقت. مع أي واجهة برمجة تطبيقات جديدة على الويب، يتوفر توازن بين الأداة ومعلومات المستخدم الجديد التي تقدمها. تشير تقديراتنا إلى تحقيق ملفات PST التوازن المناسب في حماية خصوصية المستخدم، مع إتاحة الإجراءات الرئيسية ذات الصلة بمكافحة الاحتيال والمتأثرة بالإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية. |
| دمج الجلب | إنّ عملية دمج "fetch" معقّدة وغير ضرورية. |
هناك إيجابيات وسلبيات لاستخدام "fetch"، ونودّ اعتماد المزيد من توحيد المقاييس ضمن المنظومة المتكاملة على الويب، ولكننا نعتقد أنّه سيكون من السابق لأوانه إجراء هذا التغيير إلى أن نتوصّل إلى فكرة أوضح عن شكل المعيار. وفي حال ظهور معيار، نلتزم أيضًا بنقل مطوّري البرامج على الويب بمسؤولية إلى هذا المعيار. |
| موقع التخزين | يجب تخزين إعدادات مفاتيح الرموز المميّزة للحالة الخاصة في الموقع نفسه الذي يتم فيه تخزين بروتوكول PrivacyPass. | أثناء إجراء الاختبار خلال مرحلة Origin نسخة تجريبية، أشار المطوّرون إلى أنّهم يفضّلون تخزين مفاتيحهم في عناوين URL عامة بدلاً من تخزينها في دليل .well-known. إنّ تنسيق التزام المفتاح في PrivacyPass غير مناسب بشكل خاص للإصدار الذي تهدف فيه مجموعات المفاتيح إلى السماح بإنشاء "بيانات وصفية علنية" ضمنية. إذا تم توحيد أحد إصدارات PrivacyPass مع بيانات وصفية عامة (إما بروتوكول POPRF أو تشفير RSA جزئي أو مجموعات مفاتيح)، قد ننتقل إلى إصدار مستقبلي من PST لإتاحة ذلك. |
| تنفيذ عنوان واجهة برمجة التطبيقات | أسئلة حول تنفيذ عنوان واجهة برمجة التطبيقات | ومع توحيد واجهة برمجة التطبيقات ونضج استخدام المنظومة المتكاملة لهذه الواجهة، نأمل أن نتيح استخدام الإصدار العادي الذي لا يتضمّن عناوين من واجهة برمجة التطبيقات هذه، ومن المحتمل أن يتم في النهاية إيقاف إصدار العنوان إذا كان الاستخدام منخفضًا بدرجة كافية أو في حال توفُّر أدوات أو دعم كافٍ للمطوّرين للطرق العادية للربط بين طلبات الإصدار/تحصيل القيمة بالبيانات الأخرى. نناقش المشكلة هنا. |
| تسجيل | هل جعل جهات الإصدار تسجِّل مع مورِّدي المتصفِّح عملية عملية؟ | لقد عدّلنا المواصفات لوصف عملية تسجيل المُصدِر للرموز المميّزة للحالة الخاصة. ومع أنّها تستخدم العملية الخاصة بها، فإنّها تشبه خطط التسجيل في باقي عمل "مبادرة حماية الخصوصية"، حيث نطلب من جهات الإصدار تقديم بيان علني حول الطريقة التي ينوون فيها استخدام ملفات PST والإقرار بالقيود الفنية التي تحمي خصوصية المستخدم. |