تقرير ربع سنوي للربع الثاني من عام 2023 يلخّص الملاحظات التي وردتنا بشأن المنظومة المتكاملة حول اقتراحات "مبادرة حماية الخصوصية" واستجابة Chrome
كجزء من التزاماتها بموجب "قانون معالجة المعاملات"، وافقت Google على تقديم تقارير ربع سنوية علانية عن عملية تفاعل الجهات المعنية باقتراحات "مبادرة حماية الخصوصية" (يُرجى الرجوع إلى الفقرتين 12 و17(ج)(2) من الالتزامات). يتم إنشاء تقارير الملخّصات هذه حول الملاحظات والآراء بشأن "مبادرة حماية الخصوصية" من خلال تجميع الملاحظات والآراء التي تلقّاها Chrome من المصادر المختلفة كما هو موضّح في نظرة عامة على الملاحظات والآراء، بما في ذلك على سبيل المثال لا الحصر: GitHub المشاكل، ونموذج الملاحظات والآراء المتاح على privacysandbox.com، والاجتماعات مع الجهات المعنية في المجال، ومنتديات معايير الويب. يرحّب فريق Chrome بالملاحظات التي يتم تلقّيها من المنظومة المتكاملة ويستكشف بنشاط طرق دمج الدروس المستفادة في قرارات التصميم.
يتم ترتيب مواضيع الملاحظات حسب معدّل تكرارها لكل واجهة برمجة تطبيقات. ويتم ذلك من خلال جمع ملاحظات فريق Chrome حول موضوع معيّن وتنظيمها بترتيب تنازلي حسب الكمية. تم تحديد مواضيع الملاحظات المشترَكة من خلال مراجعة مواضيع المناقشة من الاجتماعات العامة (W3C وPatCG وIETF) والملاحظات المباشرة وGitHub والأسئلة الشائعة التي تظهر من خلال الفِرق الداخلية في Google والنماذج العامة.
وعلى وجه التحديد، تمت مراجعة محاضر اجتماعات الهيئات المسؤولة عن معايير الويب، وبالنسبة إلى الملاحظات المباشرة، تمّت مراجعة سجلّات Google لاجتماعات الجهات المعنيّة وجهًا لوجه، والرسائل الإلكترونية التي تلقّاها المهندسون الفرديون، وقائمة البريد الإلكتروني لواجهات برمجة التطبيقات، ونموذج الملاحظات العلني. بعد ذلك، نسّقت Google بين الفِرق المشاركة في أنشطة التواصل المختلفة هذه لتحديد مدى رواج المواضيع التي تظهر في ما يتعلّق بكل واجهة برمجة تطبيقات.
تم تطوير تفسيرات ردود Chrome على الملاحظات من خلال عناوين الأسئلة الشائعة والمنشورة، والردود الفعلية التي تم تقديمها على المشاكل التي طرحها أصحاب المصالح، وتحديد وجهة نظر خاصة لأغراض هذا التمرين الخاص بإعداد التقارير العلنية. استنادًا إلى التركيز الحالي على التطوير والاختبار، تلقّينا أسئلة وملاحظات خاصةً بشأن واجهات برمجة التطبيقات Topics API وProtected Audience API وAttribution Reporting API.
قد لا يتم النظر في الملاحظات التي يتم تلقّيها بعد انتهاء فترة إعداد التقارير الحالية.
مسرد الاختصارات
- ملفات تعريف الارتباط في الحالة المقسَّمة المنفصلة (CHIPS)
- ملفات تعريف الارتباط في الحالة المقسَّمة المنفصلة
- معالِج الإشارات الرقمية (DSP)
- وسيط عرض الطلب
- FedCM
- إدارة بيانات الاعتماد الموحّدة
- عدد اللقطات في الثانية
- مجموعات نطاقات الطرف الأول
- مكتب الإعلانات التفاعلية (IAB)
- Interactive Advertising Bureau
- IDP
- موفِّر الهوية
- مجموعة مهندسي شبكة الإنترنت (IETF)
- مجموعة مهندسي شبكة الإنترنت
- عنوان IP
- عنوان بروتوكول الإنترنت
- openRTB
- عرض الأسعار في الوقت الفعلي
- الوقت بدل الضائع
- فترة التجربة في Origin
- PatCG
- مجموعة منتدى تكنولوجيا الإعلانات الخاصة
- RP
- جهة الاعتماد
- SSP
- وسيط عرض إعلانات المورّدين
- بيئة تنفيذ موثوقة (TEE)
- بيئة التنفيذ الموثوقة
- UA
- سلسلة وكيل المستخدم
- UA-CH
- تعديلات برنامج وكيل المستخدم
- W3C
- اتحاد شبكة الويب العالمية
- WIPB
- إخفاء عناوين IP عن قصد
ملاحظات عامة، ما مِن واجهة برمجة تطبيقات/تقنية محدّدة
| موضوع الملاحظات | ملخّص | ردّ Chrome |
|---|---|---|
| إدارة البيانات والامتثال التنظيمي | إرشادات حول استخدام "مبادرة حماية الخصوصية" بما يتوافق مع المتطلبات التنظيمية | كما هو الحال مع أي تقنية جديدة، تتحمّل كل شركة مسؤولية التأكّد من امتثال استخدامها لـ "مبادرة حماية الخصوصية" للقانون، ولا يمكن لشركة Google تقديم مشورة قانونية للآخرين. ندرك مع ذلك أنّ هذا المجال هو أحد الجوانب الرئيسية التي تهمّ المنظومة المتكاملة. بالنسبة إلى كل واجهة برمجة تطبيقات، نشرنا مستندات فنية مفصّلة من المفترض أن تقدّم الأساس لإجراء التقييمات القانونية اللازمة، ونحن نعمل على إتاحة مواد إضافية لدعم جهود الشركات في الامتثال للمتطلبات التنظيمية. |
| اقتراح الاختبار الكمي لشهادة CMA | مزيد من المعلومات حول اقتراح الاختبار الكمي لتحليل التكلفة والأداء | نحن نعمل مع هيئة CMA لتصميم تجارب تقدّم صورة عن تأثير إيقاف ملفّات تعريف الارتباط التابعة لجهات خارجية نهائيًا وتأثير اقتراحات "مبادرة حماية الخصوصية" على المنظومة المتكاملة. في نيسان (أبريل)، نشرت CMA إرشادات عامة حول ما يمكن توقّعه خلال فترة الاختبار والتجربة، ثمّ نشرت إرشادات مفصّلة في حزيران (يونيو). ننصحك بمشاركة الأسئلة أو الملاحظات حول اقتراح "الاختبار الكمي" الذي قدّمته هيئة CMA مع الهيئة مباشرةً. |
| أوضاع الاختبار المُبسَّطة في Chrome | مزيد من المعلومات والتوضيحات حول جداول الاختبار | لقد نشرنا مشاركة مدونة في 18 أيار (مايو) تتضمن المزيد من المعلومات حول وضعَي الاختبار المُبسَّط في Chrome. هذه التفاصيل ليست نهائية، وسننشر المزيد من إرشادات التنفيذ أثناء تقدّمنا في الربع الثالث من عام 2023. |
| مساحة التخزين المقسَّمة | هل سيتم استخدام مساحة التخزين المقسّمة أثناء الاختبار الذي يسهّله Chrome؟ | سيتم طرح ميزة تقسيم مساحة التخزين لجميع المستخدمين قبل تجربة إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا. لذلك، سيتم تفعيله لجميع مجموعات التجربة. سيتوفّر للمواقع الإلكترونية خيار تفعيل فترة تجريبية لإيقاف هذا الإصدار نهائيًا لاسترداد مساحة التخزين غير المُقسَّمة خلال هذه الفترة الزمنية. |
| دعم في الإنتاج | ما هي العملية المتّبعة في Chrome لدعم المشاكل الفنية في "مبادرة حماية الخصوصية" وعمليات التصعيد التي تؤثّر في المنظومة المتكاملة؟ | توفّر Google مجموعة من القنوات للسماح لخبراء التكنولوجيا الإعلانية بالإبلاغ عن المشاكل وتفعيل أي تصعيدات ضرورية. يُرجى الاطّلاع على نظرة عامة حول الملاحظات للحصول على مزيد من المعلومات عن المنتديات العامة والخاصة المخصّصة لتلقّي الملاحظات وحلّ المشاكل. |
| المخطط الزمني للتسجيل | الإطار الزمني الحالي للتسجيل قصير جدًا | لا نزال نُقيّم الموعد النهائي للتنفيذ ونريد معرفة رأي المنظومة المتكاملة بشأن المخطط الزمني الأنسب. |
| رقم D-U-N-S | مزيد من المعلومات عن متطلبات رقم D-U-N-S للتسجيل والإقرار | يمكن للمشاركين العثور على متطلبات الحصول على رقم D-U-N-S على الموقع الإلكتروني لشركة Dun and Bradstreet. تختلف المتطلبات حسب السوق، لذا على المشاركين التأكّد من مراجعة الموقع الإلكتروني للسوق المحدّد الذي يهمّهم. بشكل عام، على المشاركين تقديم معلومات أساسية عن نشاطهم التجاري، مثل اسم النشاط التجاري والعنوان ومعلومات الاتصال الخاصة بمالك النشاط التجاري أو مديره. قد يُطلب من المشاركين أيضًا تقديم معلومات مالية، مثل الأرباح السنوية للنشاط التجاري. بعد اكتمال الطلب، ستراجعه شركة D&B وستصدر رقم D-U-N-S في حال الموافقة على الطلب. |
| الانتقال من مرحلة التجربة والتقييم إلى مرحلة التوفّر للجميع | هل سيؤثّر الانتقال من مرحلة التجربة والتقييم إلى مرحلة التوفّر العلني في المختبِرين الحاليين في مرحلة التجربة والتقييم؟ | اعتبارًا من تموز (يوليو)، سيتمكّن المختبِرون من الوصول إلى واجهات برمجة التطبيقات ذات الصلة بالملاءمة والقياس في مرحلة الطرح العام. سيؤدي ذلك إلى تداخل بين توفّر الفترة التجريبية للإصدار الأول وفترة توفّره للجمهور العام. |
| دراسة AdExchanger | مزيد من المعلومات حول المنهجية المستخدَمة في الاستطلاعات | طلب الاستطلاع من المشاركين تقدير معدّلات المزامنة والأرباح لأنشطة تجارية. كان بإمكان المستجيبين اختيار المنهجية التي يريدونها للإجابة عن الأسئلة الفردية. |
| قيم المَعلمات | كيف يتم تحديد قيم المَعلمات، مثل مستوى الضوضاء ومعايير إخفاء الهوية وميزانية الخصوصية؟ | يوضّح الشرح التالي على GitHub المبادئ العامة التي تستند إليها واجهات برمجة التطبيقات في "مبادرة حماية الخصوصية". لا تزال العديد من القيم في مرحلة المراجعة النهائية، ونحن نرحّب بملاحظاتك وآرائك حول هذا الموضوع. |
عرض محتوى وإعلانات ذات صلة
المواضيع
| موضوع الملاحظات | ملخّص | ردّ Chrome |
|---|---|---|
| الحفاظ على الخصوصية | أبحاث تقييم Topics API في ما يتعلّق بالحفاظ على الخصوصية | نحن نشارك بنشاط في منتدى الأبحاث، ونعرض أبحاثنا حول خصائص الخصوصية في Topics API في الأوراق والتقارير وعروض ورش العمل. يسرّنا رؤية المزيد من الأعضاء الخارجيين في منتدى الأبحاث يشاركون في هذا المجال. تحمي Topics API المستخدمين من التتبّع العام على الويب من خلال جعل تتبُّع المستخدمين على نطاق واسع أمرًا صعبًا للغاية. وتوضّح هذه الأوراق أنّنا نحقّق ذلك بنجاح باستخدام Topics API. وهي أكثر خصوصية من ملفات تعريف الارتباط التابعة لجهات خارجية وتحمي المستخدمين مع إتاحة المواقع الإلكترونية التي يستمتعون بزيارتها. |
| تصنيف المواضيع غير دقيق بما يكفي | لا يتضمّن التصنيف الواسع النطاق للمواضيع مواضيع أكثر دقة، بما في ذلك المواضيع المتعلّقة بمنطقة معيّنة. | استجابةً للملاحظات السابقة الواردة من المنظومة المتكاملة، نشرنا مشاركة في مدوّنتنا في 15 حزيران (يونيو) توضّح تصنيفًا جديدًا معدّلاً يتضمّن العديد من التحسينات بناءً على الملاحظات الواردة من المنظومة المتكاملة. في إطار عملنا على التصنيف المعدَّل، تعاونّا مع عدة شركات في المنظومة المتكاملة، مثل Raptive (المعروفة سابقًا باسم CafeMedia) وCriteo. تزيل التصنيفات المعدّلة الفئات التي تبيّن لنا أنّها أقلّ فائدة، وتستبدلها بفئات تتوافق بشكل أفضل مع اهتمامات المعلِنين، مع الحفاظ على التزامنا باستبعاد المواضيع التي يُحتمل أن تكون حسّاسة. ننصح المنظومة المتكاملة بمراجعة أحدث التصنيف وتقديم ملاحظات بشأن التغييرات. |
| عملية تعديل التصنيفات والمعرّفات | مزيد من المعلومات حول مخطّط إصدارات التصنيف والمصنّف في Topics وكيفية استعداد الشركات لهذه التعديلات | كما ذكرنا في مشاركة المدونة الأخيرة، نتوقّع أن تتطوّر التصنيفات بمرور الوقت، وأن يتم نقل إدارتها في نهاية المطاف إلى جهة خارجية تمثّل الجهات المعنية من جميع أنحاء المجال. شاركنا أيضًا خطة التوسّع في المجموعة topics-announce. |
| التأثير في إشارات الطرف الأول | قد تكون الزيادة في عدد المواضيع في تحديث التصنيف الأخير ذات قيمة عالية، ما يؤدي إلى خفض قيمة المؤشرات الأخرى المستندة إلى الاهتمامات من الطرف الأول. | في تقرير الربع الأول من عام 2023، علّق مكتب CMA على ذلك بقوله: "ندرك أنّ Google كانت تناقش التصنيف الجديد المقترَح مع العديد من المشاركين في السوق على مستوى سلسلة الإمداد لتكنولوجيا الإعلان. على الرغم من أنّ بعض الناشرين الكبار أشاروا إلى أنّ زيادة فائدة المواضيع ستؤدي إلى زيادة الضغط التنافسي على الحلول المستندة إلى بيانات الطرف الأول، إلا أنّ رأينا الأوّلي هو أنّ زيادة الفائدة أفضل للمنافسة بشكل عام، لا سيما بالنسبة إلى قدرة الناشرين الأصغر حجمًا على مواصلة تحقيق الربح من مستودعاتهم الإعلانية بعد إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا". تتوافق وجهة نظرنا مع هذا التعليق الذي أدلى به مجلس CMA. |
| مدى الفائدة لأنواع مختلفة من الجهات المعنيّة | قد تتمتع تكنولوجيات الإعلان التي تعمل كخدمات عرض وشراء للإعلانات (SSP وDSP) بمزايا كبيرة مقارنةً بجهات أخرى في منظومة الإعلانات المتكاملة. | لم يتغيّر ردّنا عن الربع السابق: "التزمت Google بموجب اتفاقية CMA بتصميم اقتراحات "مبادرة حماية الخصوصية" وتنفيذها بطريقة لا تشوه المنافسة من خلال منح الأولوية لنشاط Google التجاري، كما التزمت بمراعاة التأثير على المنافسة في الإعلانات الرقمية وعلى الناشرين والمعلنين بغض النظر عن حجمهم. وسنواصل العمل عن كثب مع هيئة CMA لضمان امتثال عملنا لهذه الالتزامات. مع تقدّم اختبار "مبادرة حماية الخصوصية"، سيكون أحد الأسئلة الرئيسية التي سنقيّمها هو مستوى أداء التقنيات الجديدة لأنواع مختلفة من الجهات المعنيّة. إنّ الملاحظات مهمة جدًا في هذا الشأن، خاصةً الملاحظات المحدّدة والقابلة للتنفيذ التي يمكن أن تساعدنا في تحسين التصاميم الفنية بشكل أكبر. لقد تعاونّا مع هيئة CMA لتطوير نهجنا في الاختبار الكمي، ونؤيد نشر هيئة CMA لملاحظة حول تصميم التجربة لتقديم المزيد من المعلومات للمشاركين في السوق وفرصة للتعليق على الأساليب المقترَحة". |
| المواضيع الفرعية | بما أنّ معايير اختيار المواضيع هي معدّل تكرار زيارات المتصفّح، هل سيؤدي تجزئة الشرائح إلى عدم صعود المواضيع الفرعية إلى القمة مطلقًا؟ | يُجري Chrome حاليًا تقييمًا لمنهجيات أخرى لترتيب نتائج البحث، ويستكشف إشارات أخرى قد تؤدي إلى تحسين الترتيب. سنُعلم المنظومة المتكاملة بخططنا المعدَّلة في الوقت المناسب. |
| الحساسية | يجب أن يكون هدف Topics API هو ضمان أن تكون معلومات المستخدم التي يتم الحصول عليها أو استنتاجها من Topics API أقل حساسية من الناحية الشخصية مقارنةً بما يمكن استنتاجه باستخدام طرق التتبّع الحالية. | نعتقد أنّ Topics API أكثر خصوصية بكثير من التقنيات الحالية، وأنّها تحدّ بشكل كبير من إعادة تحديد هوية المستخدمين، وأنّها مصمّمة لاستبعاد المواضيع الحسّاسة. ندرك أنّه يمكن ربط المواضيع أو دمجها مع بيانات الطرف الأول لإنشاء فئات حسّاسة، ولكنّنا نعتقد أنّ Topics API هي خطوة إلى الأمام في ما يتعلّق بخصوصية المستخدمين، ونحن ملتزمون بمواصلة تحسين واجهة برمجة التطبيقات. |
| بنية التصنيف | إضافة بنية المعرّف ونظام الإصدار والبيانات الوصفية الأخرى إلى تصنيف المواضيع | في الوقت الحالي، نُدرِج معرّف التصنيف في ردّ واجهة برمجة التطبيقات. مع سعينا إلى تحقيق الإدارة على المدى الطويل، من المنطقي مراجعة عنصر Topics وتضمين بيانات وصفية إضافية حول الإصدارات إذا لزم الأمر. |
| عنصر التحكّم الخاص بالناشر | يجب أن يكون للناشرين رأي في المواضيع التي يجب تصنيف مواقعهم الإلكترونية ضمنها. | قد تؤدي التصنيفات الخاطئة للمواقع الإلكترونية إلى جعل إشارة Topics أقل فائدة بشكل عام، ولكنّ المواقع الإلكترونية المحدّدة التي تم تصنيفها بشكل خاطئ لا تستفيد من هذه الإشارة أكثر أو أقل من أي مواقع إلكترونية أخرى. ويعود السبب في ذلك إلى أنّ المعلومات السياقية للموقع الإلكتروني ستكون متاحة دائمًا للمزادات على موقعه الإلكتروني، ما سيقدّم معلومات مشابهة للموضوع الصحيح، حتى في حال التصنيف الخاطئ. نرحب بملاحظاتك حول هذا الموضوع هنا. إنّ السماح للناشرين بالتحكّم في تصنيفهم قد يعرّضهم للمخاطر. قد تصنّف المواقع الإلكترونية مواقعها الإلكترونية بشكل غير صحيح عن قصد، ما يقلل من فائدتها للجميع، أو قد تُشفِّر معاني حسّاسة في مواضيع أقل شيوعًا، ما يضر بخصوصية المستخدم. |
| إضافات Chrome | السماح لإضافات Chrome بإدارة "المواضيع" وفلترها، على غرار إضافات "إدارة ملفات تعريف الارتباط" الحالية | من المفترض أن يكون هذا الإجراء ممكنًا، كما ناقشنا على GitHub، ولكننا نرحب بملاحظات إضافية من المنظومة المتكاملة. |
| الانتقال إلى مرحلة التوفّر للجمهور العام | هل سيكون هناك أي تأثير على Topics API عند الانتقال من مرحلة التجربة والتقييم إلى مرحلة التوفّر للجمهور العام؟ | لن يتم فقدان أي بيانات للمستخدمين الذين ينتقلون من "الإصدار التجريبي من الإصدار الأول" إلى "الإصدار العلني". |
| الخصوصية | قد تحتوي أسماء المضيفين على معلومات خاصة قد تكشف عنها Topics API. | لدينا عدد من الإجراءات التي نتّخذها لضمان الخصوصية، كما هو موضّح هنا. |
| الاحتيال وإساءة الاستخدام | كيفية منع التلاعب بميزة "المواضيع" من خلال الزيارات الاحتيالية | يمكنك الاطّلاع على الإجراءات التخفيفية هنا. |
| مصنِّف المواضيع | هل يمكن للمواقع الإلكترونية طلب تغيير تصنيفها في "المواضيع"؟ | يهمّنا معرفة آراء المنظومة المتكاملة بشأن هذا الموضوع، ونرحب بملاحظاتك هنا. |
| المواقع الإلكترونية لمقدّمي المواضيع | نحدّد مواقع إلكترونية معيّنة تستضيف محتوى حول مواضيع متعدّدة على أنّها "مواقع إلكترونية تقدّم مواضيع خاصة" ونُدرِّب المصنّفات استنادًا إلى العلامات المقدّمة على صفحات الويب. | نحن نناقش الاقتراح هنا، ونرحّب بملاحظاتك الإضافية. |
Protected Audience API (المعروفة سابقًا باسم FLEDGE)
| موضوع الملاحظات | ملخّص | ردّ Chrome |
|---|---|---|
| تشكيل الزيارات | تأثير الأداء للفلترة المستندة إلى منصّة عرض الإعلانات لتحسين عدد طلبات البحث في الثانية (QPS) | لقد قضينا وقتًا طويلاً في التفكير في كيفية توجيه الزيارات، وننصحك بأن تستفيد منصة SSP من ميزة التخزين المؤقت. |
| حجم الاختبار | من الصعب اختبار ميزة "الجمهور المحمي" لأنّ منصّات عرض الإعلانات وأنظمة إدارة الأداء الإعلاني تواجه صعوبة في الحصول على أعداد كبيرة من الزيارات. | نحن نتواصل باستمرار مع شركاء منصّات عرض الإعلانات (SSP) وأنظمة إدارة العروض (DSP) لاعتماد ميزة "شرائح الجمهور المحمية" واختبارها. لقد بدأنا بطرح الميزة للجميع ونثق بأنّ النسبة المئوية للزيارات التي تم تفعيل ميزة "الإعلانات المتجاوبة على شبكة البحث" فيها ستجعلها أكثر قبولاً لدى الشركاء لاختبارها. |
| مستوى التعقيد | يتطلّب تنفيذ حلول "شرائح الجمهور المحمي" جهدًا وتكاليف كبيرة. | ندرك أنّه من الصعب استخدام التقنيات الجديدة، بما في ذلك "مبادرة حماية الخصوصية". يعمل فريق "مبادرة حماية الخصوصية" عن كثب مع مجموعة كبيرة من الجهات المعنية لتقديم المعلومات اللازمة حول جهودها وتقديم الدعم لها، كما يعمل على تقييم العوامل الأخرى التي تساهم في تسريع عملية استخدام المنظومة المتكاملة. |
| بيئات التنفيذ الموثوق بها | إتاحة بيئة التنفيذ الموثوقة (TEE) في بيئات السحابة الإلكترونية غير العامة | في حين أنّنا نستكشف الخيارات التي يمكن أن نوفّرها خارج نطاق الحلول المستندة إلى السحابة الإلكترونية، لا يمكن حاليًا إتاحة تقنية TEE على الأجهزة الداخلية بسبب القيود الأمنية على الأجهزة الداخلية التي تتطلّب تقييمًا يستغرق وقتًا طويلاً لـ "مبادرة حماية الخصوصية". نظرًا لمتطلبات أمان "مبادرة حماية الخصوصية" والتحديات الكبيرة التي تواجه عمليات النشر على الأجهزة الداخلية، نعتقد أنّ مواصلة توسيع نطاق عمليات النشر المستندة إلى السحابة الإلكترونية وتحسينها (مثل إتاحة Google Cloud Platform بالإضافة إلى AWS) هو الخيار الأكثر فائدة للمنظومة المتكاملة. ومع ذلك، نرحب بملاحظات إضافية حول سبب ضرورة هذا الشرط. |
| بنية التكلفة | سيؤدي اقتراح خدمات عروض الأسعار والمزادات إلى زيادة التكلفة والتعقيد في تقنيات الإعلان مقارنةً بالنماذج من جهة العميل. | نعمل حاليًا على تطوير دليل لتقدير تكاليف دعم سير عمل عروض الأسعار والمزادات في خادم عروض الأسعار والمزادات، والذي سيكون مرتبطًا باستخدام تكنولوجيا الإعلان، ما يحقّق أحد أهداف تصاميمنا. |
| المخططات الزمنية لـ K-Anon | متى سيتم فرض قيود "المعادلة الكيانية" المخطّط لها على renderUrl؟ | نعمل على إعداد شرح للجدول الزمني لتطبيق هذه السياسة وسننشره قريبًا. |
| قيود runAdAuction | هل يمكن أن يفرض Chrome قيودًا على runAdAuction بحيث لا يمكن الاتصال به إلا من الصفحة الرئيسية؟ |
على الرغم من أنّ تصميمنا يتيح تمامًا إمكانية استدعاء runAdAuction من أعلى الصفحة، نعتقد أنّه سيكون أكثر ضررًا للناشرين حصر إمكانية استدعائه من أعلى النطاق فقط.لقد تلقّينا ملاحظات من المنظومة المتكاملة بشكل خاص بأنّ "مبادرة حماية الخصوصية" يجب أن تقلّل من الأعباء على الناشرين والمعلنين. تتوافق هذه الملاحظات مع المبدأ العام لتطوير الويب، وهو أنّه يمكن لمالكي المواقع الإلكترونية استخدام أدوات تابعة لجهات خارجية في إدارة مواقعهم الإلكترونية. كان الهدف من "مبادرة حماية الخصوصية" هو تشجيع منظومة متكاملة فعّالة بدون الحاجة إلى تحديد كيفية عمل الناشرين وتقنيات الإعلان. من خلال السماح للناشر باختيار كيفية الاتصال بـ runAdAuction على موقعه الإلكتروني والجهات التي يمكنها الاتصال به، نعتقد أنّنا نقدّم للناشرين المرونة اللازمة للعثور على أفضل مسار لتلبية متطلباتهم. |
| دعم التنفيذ | هل يمكن لمتصفّح Chrome إنشاء مزاد متعدد البائعين أو المساهمة في تنفيذه باستخدام رمز مفتوح المصدر؟ | تهدف "مبادرة حماية الخصوصية" إلى تطوير تقنيات تحافظ على الخصوصية ولا تعتمد على ملفات تعريف الارتباط التابعة لجهات خارجية أو معرّفات أخرى على مستوى المواقع الإلكترونية. نريد تشجيع منظومة متكاملة سليمة بدون الحاجة إلى تحديد كيفية عمل تكنولوجيات الإعلان. لقد نشرنا إرشادات حول آلية عمل واجهات برمجة التطبيقات في مستودع GitHub، ونحن منفتحون على استكشاف الحلول مع الجهات المعنية في المجال. لا ننوي إنشاء أيّ عملية تنفيذ محدّدة لأنّ مهمتنا الأساسية هي إنشاء تقنيات المنصات، وليس فرض استراتيجيات لاستخدام هذه التقنيات. ستساعد تقنياتنا شركات تكنولوجيا الإعلان في تقديم أفضل خدمة ممكنة لعملائها من خلال توفير معايير الخصوصية المناسبة للمستهلكين. |
| المزادات المتعددة البائعين | هل سيفرض Chrome مشاركة إعلان الفائز "السياقي" مع مزادات المكوّنات؟ | تم تصميم Protected Audience API لتزويد الأطراف التي تبدأ مزاد البائعين المتعدّدين بإمكانية تمرير المعلومات إلى مزاد المكوّنات (ملاحظة: قبل بدء المزاد فقط). مع ذلك، لا نرى طريقة يتمكّن بها المتصفّح من التمييز بين ما إذا كانت المعلومات هي الفائز السياقي أم لا، لذا لا يمكننا فرض حظر معلومات معيّنة أو طلبها. |
| الإعدادات المفضّلة للمستخدِم لتتبُّع الموافقة | شركة تكنولوجيا إعلان تسأل شركة PA عن كيفية تنفيذ تتبُّع موافقة المستخدِم بشكلٍ صحيح | يتضمّن ردّنا ما قلناه في السؤال 1: "بالنسبة إلى إعلانات معيّنة، تكون تكنولوجيا الإعلان ذات الصلة هي الجهة الأنسب لتقديم عناصر تحكّم في تصميمات الإعلانات التي يتم عرضها أو كيفية اختيارها". ناقشنا عددًا من السيناريوهات المتعلّقة بهذه المشكلة خلال اجتماع WICG حول "الجمهور المحمي" في أيار (مايو)، ونرحّب بتلقّي المزيد من الملاحظات والمناقشات حول هذه المشكلة. |
| الجمهور المخصّص | هل ستتيح Protected Audience API حالات استخدام منصّات عرض الإعلانات من جهة المورّدين ذات الصلة بإنشاء شرائح جمهور مخصّصة؟ | تسمح Protected Audience API لوسطاء عرض إعلانات المورِّدين (SSP) ومقدّمي تقنية الإعلان الآخرين بملكية شرائح الجمهور المخصّصة وإدارتها. يتم حاليًا تطوير إرشادات إضافية حول كيفية دمج منصّة عرض الإعلانات مع PA API، وسيتم توفيرها لمنصّات عرض الإعلانات ومقدّمي تكنولوجيا الإعلان الآخرين لدعم جهود الدمج. |
| التنسيقات | هل يمكن استخدام الفيديو مع Protected Audience API؟ | يتم عرض إعلانات الفيديو بطريقتَين: بتنسيق VAST XML أو HTML (إعلان خارج البث المباشر قد يحمّل VAST XML في مشغّل فيديو أيضًا). يمكن للمشترين عرض أيّ من التنسيقَين من خلال renderURL. تم تعديل مواصفات VAST مؤخرًا لتتوافق مع واجهة برمجة التطبيقات Attribution Reporting API. على المواقع الإلكترونية التي تعرض إعلانات فيديو الاستعداد لطريقة عرض الإعلانات من خلال Protected Audience API. ويعني ذلك التأكّد من أنّ علامات مواضع الإعلانات يمكنها تمرير عنوان URL من عنصر iframe في Protected Audience إلى مشغّل الفيديو. بالنسبة إلى "اللقطات المُحيطة"، سنعمل على تلبية احتياجات الفيديو قبل أن يصبح استخدامها إلزاميًا في العام 2026. |
| تعديل الفيديو | كيف تعمل حالة استخدام "تحديد الوتيرة" مع Protected Audience API؟ | نحن نقدّر الملاحظات التي نتلّقاها. يهمّنا معرفة المزيد من حالات هذا الطلب مع الحصول على المزيد من التفاصيل من المزيد من شركاء SSP، لأنّ هذا الطلب كان يخصّ منصّات إدارة الأداء إلى حدّ كبير حتى الآن. |
| فترة تكرار التحديث | قد لا يكون معدّل تكرار المكالمات الواردة من dailyUpdate (ما يصل إلى مكالمة واحدة لكل مجموعة اهتمامات في اليوم) كافيًا لبعض حالات الاستخدام، مثل تعديل معلومات المنتجات. |
نحن نقدّر الملاحظات التي نتلّقاها. تتوفّر حلول أخرى للسماح لتكنولوجيات الإعلان باستخدام إشارات يتمّ تعديلها بمعدّلات مختلفة، مثل عمليات البحث عن مفاتيح/قيم. |
| التحكّم في جودة الإعلانات | كيف ينفّذ الناشرون عملية التحكّم في جودة الإعلانات؟ | في الوقت الحالي، توفّر Protected Audience API وظائف تتيح للناشرين إبلاغ منصّات عرض الإعلانات (SSP) بعناصر تحكّم معيّنة يمكنهم إعدادها كجزء من إعدادات المزاد، وعروض الأسعار المُسبَقة (أي قوائم الرفض المستندة إلى التصنيفات المرتبطة بالإعلانات). ونرحّب بملاحظاتك بشأن أي وظائف إضافية قد تتطلّبها المنظومة المتكاملة. |
| تصحيح الأخطاء | متى ستتم إزالة وظائف forDebuggingOnly؟ |
نخطّط لإيقاف forDebuggingOnly نهائيًا لأحداث الخسارة بسبب الإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية. نخطّط لإيقاف forDebuggingOnly نهائيًا في أحداث الفوز في العام 2026 كأقرب وقت ممكن. |
| المجموعات ذات الاهتمامات المشتركة على جميع الأجهزة | اقتراح لتفعيل مجموعات الاهتمامات على جميع الأجهزة لبرامج وكلاء المستخدمين التي تمّت مصادقتها | نحن بصدد تقييم هذا الاقتراح، ولكنّ التحديد العالي لميزة الاستهداف على جميع الأجهزة يثير مخاوف كبيرة بشأن الخصوصية، كما هو موضّح في هذه المشكلة على GitHub. |
| (تمّ الإبلاغ عنها أيضًا في الربع الأول) تجديد النشاط التسويقي الديناميكي | هل سيظلّ بإمكانك استخدام ميزة "تجديد النشاط التسويقي الديناميكي" مع Protected Audience API بعد إيقاف ملفّات تعريف الارتباط التابعة لجهات خارجية نهائيًا؟ | نعتقد أنّ حالة الاستخدام هذه ممكنة باستخدام ميزة "الجمهور المحمي"، كما هو موضّح هنا. |
| انقر على "البيانات ذات الصلة". | إضافة بيانات ذات صلة بالنقرات إلى browserSignals. |
نطلب حاليًا توضيحًا بشأن وقت حدوث النقرة لتقديم موضع أولي. |
| (تم الإبلاغ عن ذلك أيضًا في الربع الرابع من عام 2022) الدوالّ المحدّدة من المستخدِم في شريحة الجمهور المحمية | كيف ستتم إتاحة الدوالّ المحدَّدة من المستخدِم (UDF) في Protected Audience API؟ هذه هي الوظائف التي يمكن للمستخدمين النهائيين برمجةها لتوسيع وظائف واجهة برمجة التطبيقات. | أشار فريق تكنولوجيا الإعلان الذي طرح هذه المشكلة أيضًا إلى أنّه لا يزال يُقيّم الإجراءات التي يمكنه اتّخاذها بشأن الدوالّ غير المحدّدة، وبالتالي لا تتوفّر أيّ ملاحظات قابلة للتنفيذ حتى الآن، ولن تتوفّر إلا بعد توفّر الميزة للجميع على الأقل. |
| العملة | يجب عدم تمثيل مبالغ العملات باستخدام النقاط العائمة. | لقد عالجنا هذه المشكلة بالتفصيل هنا. |
| إمكانات اختيار الإعلانات غير المستندة إلى منصّة إدارة الأداء | ما هو الدور الذي تلعبه خوادم الإعلانات في مزادات Protected Audience API؟ | نحن على دراية بطلبات مزوّدي "خوادم الإعلانات" لمواصلة تقديم خدمات اختيار الإعلانات بعد عروض الأسعار / تحسين المواد الإبداعية الديناميكية. نحن بصدد تقييم تحليل الفجوة التفصيلي بين واجهة برمجة التطبيقات الحالية Protected Audience API وهذه الطلبات. |
| GenerateBid | إتاحة اقتراح "إعلانات Google" لعرض أكثر من إعلان مرشح واحد لكل مجموعة اهتمامات إعلانية من generateBid وتسجيل نتائج لهذه الإعلانات المرشحة في scoreAd |
يتم حاليًا تقييم هذه المشكلة. نرحب بتلقّي ملاحظات إضافية هنا. |
| طلب المزاد | هل يجب أن تكون مزادات Protected Audience API هي آخر مزادات يتم إجراؤها حتى تتمكّن من الحصول على مدخلات من نتائج جميع المزادات الأخرى؟ | ما مِن متطلبات فنية لتشغيل Protected Audience API في آخر خطوة. |
| التنقّل الذي لا يبدأه المستخدم | عرض التنقّل الذي لم يبدأه المستخدم | نحن بصدد مراجعة هذا الطلب ومناقشته هنا ونرحّب بملاحظاتك الإضافية. |
| التخزين المؤقت | يجب ألا تنشئ منصّة SSP رسائل perBuyerSignals الخاصة بخدمة إدارة الأداء المحدّدة من ذاكرة التخزين المؤقت في حال تغيّر حالة المستخدِم. | ندرك أنّ ميزة التخزين المؤقت لا تعمل مع كل حالات استخدام إشارات perBuyer، ونحن بصدد تقييم خيارات إضافية. ونرحّب بأي ملاحظات إضافية من المنظومة المتكاملة حول ما إذا كان التخزين المؤقت مناسبًا لحالات الاستخدام. |
| تقارير تحديد المصدر وProtected Audience | كيف يمكن أن تعمل 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() لكلّ مجموعة اهتمامات، ويعرض نظام إدارة الطلبات ما يلي عند تنفيذ generateBid: return {
'ad': adObject,
'adCost': optionalAdCost,
'bid': bidValue,
'render': renderUrl,
'adComponents':
[adComponent1, adComponent2, ...],
'allowComponentAuction': false,
'modelingSignals': 123};
}
|
| المساهمات الخارجية | طلب إتاحة المساهمات الخارجية في قاعدة رموز Key/Value Server على GitHub | نحن نسعى إلى تعديل عملياتنا ذات الصلة لدعم المساهمات الخارجية في رمز GitHub. |
| حجم مجموعة الاهتمامات | ما هو الحد الأقصى المسموح به لعدد المفاتيح التي يمكن أن تتعامل معها أداة IG؟ | الحدّ الأقصى الحالي هو 50 كيلوبايت لحجم ملف IG واحد، ويتم احتساب المفاتيح كجزء من ذلك. نرحب بمزيد من المناقشة حول الحد الأقصى للحجم. |
| تجميع البيانات | كيف يمكن تقليل عدد طلبات خادم "مفتاح/قيمة"؟ | يمكنك استخدام عناوين التحكّم في ذاكرة التخزين المؤقت في HTTP لتقليل عدد طلبات الحصول على القيم من ذاكرة التخزين المؤقت. على سبيل المثال، يمكن أن يتم تخزينها مؤقتًا في مزادات المكوّنات، وكذلك في شرائح الإعلانات على صفحة واحدة. |
| التحكم في الإصدارات | إتاحة نُسخ متعددة من رمز تكنولوجيا الإعلان | ستتيح خدمات عروض الأسعار والمزادات إصدارات متعدّدة من رمز تكنولوجيا الإعلان. في Bidding and Auction API، يمكن أن يحدِّد طلب SelectAd إصدار الرمز المستخدَم لطلب المزاد (أي لعروض الأسعار / المزاد وإعداد التقارير أيضًا). |
| مساحة التخزين المشتركة | إتاحة الكتابة في مساحة التخزين المشتركة في خدمة عروض الأسعار والمزادات | لا تتيح حاليًا خدمات عروض الأسعار والمزادات مساحة التخزين المشتركة، ولكننا نرحب بملاحظات إضافية حول أهمية حالات الاستخدام هذه للمنظومة المتكاملة. |
| من الويب إلى التطبيق | إتاحة مشاركة مجموعات الاهتمامات من الويب إلى التطبيق | لا يتم حاليًا توسيع نطاق واجهة برمجة التطبيقات Protected Audience API لتشمل عمليات نقل البيانات من الويب إلى التطبيقات على Chrome وAndroid، ولكننا مهتمون بمعرفة رأي المنظومة المتكاملة في أهمية حالة الاستخدام هذه. |
| K-Anonymity | كيفية التعامل مع العناصر الاحتياطية لميزة "المعرّفة بالعدد K" | نحن بصدد مناقشة المشكلة ونرحّب بملاحظاتك الإضافية. |
قياس الإعلانات الرقمية
تقارير تحديد المصدر (وواجهات برمجة التطبيقات الأخرى)
| موضوع الملاحظات | ملخّص | ردّ Chrome |
|---|---|---|
| الإعدادات البديلة لتقارير أحداث الفيديو المباشر | ملاحظات حول إعدادات تقارير أحداث الفيديو البديل على مستوى الحدث | لقد وصلتنا بعض الملاحظات التي تفيد بأنّ الإعدادات الحالية على مستوى الحدث ليست مثالية، لذا نطلب منك تقديم ملاحظاتك حول الإعدادات العالمية المثالية. نحن منفتحون على تلقّي ملاحظات إضافية بشأن هذا الموضوع ونعتقد أنّ الشرح المرن على مستوى الحدث يساعد في معالجة هذه المشكلة أيضًا. |
| إعدادات مرنة على مستوى الحدث | ما هي حالة ميزة الإعدادات المرنة على مستوى الحدث؟ | لقد شاركنا مستندات حول الإعدادات المرنة على مستوى الحدث. لا تزال الميزة في مرحلة الاقتراح، ونبحث عن المزيد من الملاحظات حول ما إذا كانت الميزة ستكون مفيدة للمنظومة المتكاملة. |
| إعدادات مرنة على مستوى الحدث | كيف يمكن التوفيق بين التقارير المتضاربة الواردة من جهات مختلفة؟ | يتمّ التعامل مع معظم سيناريوهات إعداد التقارير من خلال استخدام التقارير المجمّعة، في حين أنّ اقتراح الإعداد المرن على مستوى الحدث مخصّص خصيصًا لتوفير مرونة إضافية للتقارير على مستوى الحدث، والتي غالبًا ما يتم استخدامها لحالات استخدام التحسين. نرحب بأي تعليقات أو ملاحظات إضافية بشأن منظومة الخدمات المتكاملة في ما يتعلّق بهذا السيناريو. |
| تسجيل المصدر | ماذا لو حدث تسجيل المصدر بعد تسجيل العامل المشغِّل؟ | في الوقت الحالي، إذا حدث تسجيل مصدر بعد تسجيل العامل المشغِّل، لن يكون بالإمكان إسناد المصدر إلى العامل المشغِّل. يبدو أنّ هذا سيناريو حالة هامشية. نرحب بأي ملاحظات إضافية بشأن هذه المشكلة وسنسعى إلى حلّها إذا كانت تمثل سيناريو يواجهه العديد من تكنولوجيات عرض الإعلانات. |
| العمل مع وكالات إعلانية متعدّدة | كيف يمكن لمنصّات عرض الإعلانات استخدام Attribution Reporting API عندما يعمل المعلِن مع وكالات إعلانية متعدّدة؟ | تتيح واجهة برمجة التطبيقات عمليات إعادة التوجيه، وبالتالي يمكن استخدامها حتى إذا كان المعلِن يعمل مع وكالات إعلانية متعدّدة. بالإضافة إلى ذلك، هناك بعض القيود المفروضة في ما يتعلق بعمليات إعادة التوجيه لضمان أنّ واجهة برمجة التطبيقات تحسّن الخصوصية. لقد حدّدنا أيضًا حلًا بديلاً محتملًا باستخدام Shared Storage API للسيناريو المحدّد الذي طرحته تكنولوجيا الإعلان. نرحب بأي ملاحظات إضافية بشأن هذا السيناريو وسنواصل إجراء التحسينات استنادًا إلى هذه الملاحظات. |
| حدود الوجهات | قد يتأثّر استخدام الإعلانات التي يتمّ تحديثها تلقائيًا بوجود حدود للوجهات. | لقد ناقشنا هذه المشكلة في اجتماع WICG في 1 أيار (مايو) ونبحث عن ملاحظات بشأن الحدّ المعقول. أضفنا إلى تقرير تحديد المصدر مع شرح التقارير على مستوى الحدث توضيحًا يفيد بأنّ المتصفّح يمكنه الحدّ من عدد نطاقات eTLD+1 "الوجهة" التي تمثّلها المواقع الإلكترونية المصدر. (اطّلِع على طلب سحب). |
| تقارير تحديد المصدر وProtected Audience | كيف يمكن أن تعمل Attribution Reporting API وProtected Audience API معًا؟ | تتوفّر عمليات الدمج حاليًا لواجهة برمجة التطبيقات Protected Audience API لكلا وضعَي Attribution Reporting API (التقارير على مستوى الحدث والتقارير الملخّصة). لقد شاركنا في 1 حزيران (يونيو) المزيد من المعلومات حول عملية الدمج المحسّنة بين Protected Audience API وAttribution Reporting API. يمكنك الاطّلاع على المزيد من المعلومات حولها هنا. |
| إعدادات مرنة على مستوى الحدث | شارِك أفضل الممارسات لمحاكاة الضوضاء الآن بعد أن أصبحت المَعلمات قابلة للضبط. | لدينا رمز مشترَك على GitHub يمكن لأي شخص استخدامه لتقييم معلومات الزيادة وتأثير الضوضاء لأيّ إعدادات مرنة على مستوى الحدث يريد اختبارها. يهمّنا معرفة رأي أي مستخدم يختبر الرمز ويريد مشاركة ملاحظاته. |
| قياس تحديد المصدر على مستوى التطبيقات والويب | متى ستتوفّر ميزة قياس تحديد المصدر على مستوى التطبيقات والويب؟ | أعلنّا في 9 أيار (مايو) عن تجربة لقياس تحديد المصدر على مستوى التطبيقات والمواقع الإلكترونية من خلال واجهة برمجة التطبيقات Attribution Reporting API. على الرغم من أنّه من المخطّط أن تصبح واجهات برمجة التطبيقات لقياس مدى الصلة بالموضوع والقياس متاحة للجميع في الإصدار 115 من Chrome، لا يُخطّط حاليًا لطرح ميزة "قياس تحديد المصدر على مستوى التطبيقات والويب" للجميع في الإصدار 115 من Chrome. |
| إزالة تكرار الإحالات الناجحة | كيف يمكن التوفيق بين حلول قياس الأداء المستقلة وARA؟ | وكما هو الحال مع الممارسات العادية الحالية، سيتعاون المعلِنون مع مزوّد قياس مستقل تابع لجهة خارجية لإزالة تكرار تقارير الإحالات الناجحة. لقد قدّمنا موارد حول كيفية إزالة تكرار الإحالات الناجحة لإعداد التقارير على مستوى الحدث. |
| فقدان البيانات أثناء تعديلات قاعدة بيانات "تقارير تحديد المصدر" | هل سيحدث أي فقدان للبيانات عند تحديث Chrome لقاعدة بيانات إعداد تقارير تحديد المصدر كما أعلنّا؟ | بدءًا من الإصدار 115 من Chrome الثابت، سنبدأ في تفعيل واجهات برمجة التطبيقات Relevance وMeasurement لمجموعة من مستخدمي 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) لتوفير أشكال أجهزة إضافية، مثل التلفزيون والواقع الافتراضي | ما زلنا نعمل على بعض القرارات الرئيسية المتعلقة بالتصميم (ما إذا كان سيتم تقديم قيمة واحدة مثل "تلفزيون" أو قائمة بإمكانات الشكل)، ولكننا ما زلنا مهتمين بإنشاء نماذج أولية لهذه الفكرة. |
| ميزانية الخصوصية | يمكن أن تؤدي قيود "ميزانية الخصوصية" إلى أن تصبح طلبات Universal Analytics للعملاء المحتملين غير محدّدة عند إرسال عدد كبير جدًا من الطلبات. | ليس لدينا أيّ معلومات جديدة بشأن اقتراح "ميزانية الخصوصية" في الوقت الحالي، ولكنّنا التزمنا بعدم تقييد طلبات الحصول على إشارات عملاء Universal Analytics قبل إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا. |
| توافق الموقع الإلكتروني | تستخدم المواقع الإلكترونية العلامة التجارية UA-CH لحظر متصفّحات معيّنة من الوصول إلى المواقع الإلكترونية. | هناك حالات استخدام صالحة لاستخدام قائمة علامات تجارية، ومن بين هذه الحالات التوافق الدقيق. يمكن لحساب Universal Analytics أن يتضمّن علامات تجارية متعددة لحلّ هذه المشاكل. |
حماية عنوان IP (المعروفة سابقًا باسم Gnatcatcher)
| موضوع الملاحظات | ملخّص | ردّ Chrome |
|---|---|---|
| الاحتيال وإساءة الاستخدام | كيف يمكن للشركات إعداد إجراءات مكافحة الاحتيال باستخدام ميزة "حماية عنوان IP"؟ | ندرك أهمية حالات استخدام مكافحة الاحتيال والتأثير المحتمل لهذه الحالات. نخطط لنشر المزيد من التفاصيل حول إتاحة ميزات مكافحة الاحتيال في وقت لاحق من هذا الصيف. نطلب منك تقديم ملاحظاتك حول كيفية تحسين حالات استخدام منظومة الخدمات في ما يتعلّق بمكافحة الاحتيال. |
| GeoIP | مزيد من المعلومات حول المخطط الزمني لاختبار ونشر ميزة "الاستناد إلى الموقع الجغرافي" | نشر فريق Chrome مؤخرًا معلومات جديدة تفصّل خططنا المتعلّقة بتحديد الموقع الجغرافي بالاستناد إلى عنوان IP. ونخطّط لنشر المزيد من المعلومات حول المخططات الزمنية للنشر في الربع الثالث. نتوقّع إطلاق ميزة "حماية عنوان IP" كميزة يوافق عليها المستخدمون على نسبة صغيرة من الزيارات في البداية. يرجع السبب في ذلك إلى أنّنا ندرك أنّ هذا الاقتراح قد يتضمن بعض التغييرات المهمة للشركات، ونريد منح المنظومة المتكاملة الوقت الكافي للتكيّف وتقديم الملاحظات قبل طرح الميزة على نطاق أوسع. |
| مصادقة الحساب | كيف ستتم المصادقة على الحساب باستخدام الخادم الوكيل؟ | نخطّط لنشر المزيد من التفاصيل حول مصادقة الحساب في وقت لاحق من هذا الصيف، على الرغم من أنّنا شاركنا بعض الاعتبارات الأولية من قبل. |
الحدّ من التتبّع الارتدادي
| موضوع الملاحظات | ملخّص | ردّ Chrome |
|---|---|---|
| إرشادات حول الاختبار | معلومات حول كيفية اختبار إجراءات الحدّ من التتبُّع الارتدادي | نشرنا مشاركة مدونة في أيار (مايو) تتضمّن مزيدًا من المعلومات حول كيفية اختبار ميزة "التخفيف من تتبُّع الارتدادات". |
| الوثائق | الوضوح في اقتراح تتبُّع الارتداد | لا يزال الاقتراح الحالي قيد التطوير، ويواصل فريق Chrome تعديله لتوفير المعلومات والوضوح للمنظومة المتكاملة. نحن نعمل على تقديم المزيد من التفاصيل ونرحّب بأي ملاحظات إضافية. |
| حذف ملفات تعريف الارتباط | هل سيؤدي ميزة "التخفيف من تتبُّع عمليات الارتداد" إلى حذف جميع ملفات تعريف الارتباط في نطاق معيّن؟ | سيؤدي تخفيف تتبُّع الارتداد (BTM) إلى محو جميع مساحات التخزين وذاكرة التخزين المؤقت، كما هو موضّح هنا. |
| التحايل على إجراءات الحدّ من التتبّع الارتدادي | يمكن تجاوز تصنيف خدمة تتبُّع الارتداد من خلال تنفيذ عمليات إعادة توجيه باستخدام النوافذ المنبثقة أو علامات التبويب الجديدة. | لا تزال مواصفات الحدّ من التتبّع الارتدادي قيد التطوير. لقد ركّزنا إلى حدّ كبير على عمليات إعادة التوجيه في علامة التبويب نفسها حتى الآن، ولكننا نخطّط للعمل على عمليات إعادة التوجيه في النوافذ المنبثقة في المستقبل. نرحب بتلقّي ملاحظات إضافية هنا. |
ميزانية الخصوصية
| موضوع الملاحظات | ملخّص | ردّ Chrome |
|---|---|---|
| الاستهداف القريب | قد تؤثر "ميزانية الخصوصية" في حالات استخدام الاستهداف بالقرب. | لقد تلقّينا ملاحظات بشأن هذه المشكلة ونريد معرفة المزيد من المعلومات عن التأثيرات المحتملة للمنظومة المتكاملة. |
تعزيز حدود الخصوصية على جميع المواقع
مجموعات نطاقات الطرف الأول
| موضوع الملاحظات | ملخّص | ردّ Chrome |
|---|---|---|
| (تم الإبلاغ عنه أيضًا في الربعَين السابقَين) الحد الأقصى للنطاقات | طلب توسيع عدد النطاقات المرتبطة | يُقيّم Chrome الحدّ الرقمي المناسب للمجموعة الفرعية المرتبطة الذي سيوازن بين الخصوصية والفائدة لحالات الاستخدام التي تم تحديدها. منذ البداية، أشار فريق Chrome إلى أنّه لم يتم تحديد العدد الدقيق للمجموعة الفرعية المرتبطة بعد. |
| حالة الاستخدام المضمّنة | إتاحة حالات الاستخدام المضمّنة التي تتطلّب "مجموعات نطاقات الطرف الأول" و"شرائح CHIP" ومساحة تخزين مشتركة | تلقّى فريق 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 API
| موضوع الملاحظات | ملخّص | ردّ Chrome |
|---|---|---|
| حظر الإعلانات | قد تجعل "الإطارات المُحيطة" من السهل على أدوات حظر الإعلانات حظر الإعلانات. | يمكن للإضافة التفاعل مع الإطارات المُغلقة بالطريقة نفسها التي تتفاعل بها مع إطارات iframe. سيكون عنوان URL الفعلي الذي سيتم الانتقال إليه من الإطار المحدود مرئيًا أيضًا للإضافات، وبالتالي يمكنها تطبيق أي قواعد مطابقة لعنوان URL لحظره كما في إطارات iframe. قد يؤدي حظر جميع الإطارات المُحدودة بشكل غير مشروط إلى إيقاف حالات استخدام الإطارات المُحدودة غير الإعلانية. |
Shared Storage API
| موضوع الملاحظات | ملخّص | ردّ Chrome |
|---|---|---|
| استخدام أوسع نطاقًا | يجب أن تكون "مساحة التخزين المشتركة" معيارًا على مستوى المجال متاحًا في جميع المتصفّحات. | نرحّب بهذه الملاحظات ونأخذها في الاعتبار. يواصل Chrome المشاركة بنشاط في منتديات W3C للترويج للاقتراح وطلب الملاحظات وتعزيز عملية اعتماده. |
| بوابات الإخراج | بوابات الإخراج في "مساحة التخزين المشتركة" محدودة جدًا. | نحن نأخذ هذه الملاحظات في الاعتبار ونرحّب بملاحظات إضافية حول المنظومة المتكاملة بشأن سبب محدودية بوابات الإخراج. |
| الالتزام باللوائح التنظيمية | كيف ستتعامل "مساحة التخزين المشتركة" مع الامتثال التنظيمي، مثل سياسات الاحتفاظ بالبيانات؟ | توفّر مساحة التخزين المشتركة المرونة في تنفيذ المنطق وتخصيصه للتحكّم في مدة صلاحية أي بيانات مخزّنة وانتهائها. يمكن لتكنولوجيات الإعلان تعديل بيانات "مساحة التخزين المشتركة" أو محوها استنادًا إلى الطوابع الزمنية للكتابة. |
| اختبار A/B | كيف يمكن إجراء اختبار أ/ب لميزة "مساحة التخزين المشتركة" وProtected Audience API؟ | نحن نعمل على نشر إرشادات إضافية حول هذا الموضوع ونأمل مشاركة المزيد من التفاصيل في المستقبل. |
| الحد الأقصى لمساحة التخزين المشتركة | ماذا سيحدث عند بلوغ الحد الأقصى لمساحة التخزين المشتركة؟ | وفي حال بلوغ الحدّ الأقصى، لن يتم تخزين أي إدخالات أخرى. |
| عمليات وصول متعددة في عملية تحميل الصفحة نفسها | ماذا يحدث عند الوصول إلى "مساحة التخزين المشتركة" عدة مرات عند تحميل الصفحة نفسها؟ | وأفضل طريقة للتعامل مع ذلك هي من خلال الدالة window.sharedStorage.append(key, value). بدلاً من تعديل القيمة لكل إعلان، ما قد يؤدي إلى حدوث تعارضات في حال توفّر إعلانات متعددة. ستضيف دالة الإضافة القيمة الجديدة إلى نهاية القيمة الحالية. |
| وظائف إطار iframe | هل ستتيح ميزة "مساحة التخزين المشتركة" وظائف معيّنة لإطار iframe بعد إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا؟ | بعد الإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية، سيتم تقسيم مساحة التخزين المحلية في إطارات iframe بواسطة الموقع الإلكتروني من المستوى الأعلى، ولكن لن يتم حظر إطارات iframe نفسها. لا يمكن تكرار البيانات في مساحة التخزين المحلية لإطار iframe على مستوى مواقع إلكترونية متعددة من المستوى الأعلى، ولكن لا يزال بإمكانك استخدام مساحة التخزين المحلية داخل إطار iframe. |
CHIPs
| موضوع الملاحظات | ملخّص | ردّ Chrome |
|---|---|---|
| الحد الأقصى لعدد الأقسام | لا يزال حجم 10 كيلوبايت لكل موقع إلكتروني مُقسَّم كبيرًا، ونريد خفضه. | أشار Firefox سابقًا إلى موضع إيجابي في CHIPS. للحصول على دعم Webkit، ننصحك بأن يقدّم المطوّرون ملاحظاتهم إلى Apple مباشرةً بشأن هذه المشكلة على GitHub في ما يتعلق بحالات الاستخدام التي يُفضّل فيها استخدام ملفات تعريف الارتباط المقسّمة على مساحة التخزين المقسّمة. |
| مواد العرض المضمّنة التي تمت مصادقتها | قد تؤثر شرائح CHIP في عملية تسجيل الدخول الحالية باستخدام خدمة الدخول المُوحَّد (SSO) بسبب التقسيم المختلف الذي يؤثّر في عمليات التضمين التي تمّت المصادقة عليها. | وننوي الاستفادة من واجهة برمجة التطبيقات Storage Access API (مع طلبات المستخدمين) لدعم حالة استخدام "عمليات التضمين التي تمّت المصادقة عليها"، وقد أرسلنا مؤخرًا بيان نية إنشاء نموذج أولي. |
| السياسات الدائمة | هل ستسري سياسات مدة الصلاحية المحتملة على ملفات تعريف الارتباط التابعة للطرف الأول؟ | لا ننوي حاليًا فرض حدود زمنية على ملفات تعريف الارتباط للطرف الأول. |
FedCM
| موضوع الملاحظات | ملخّص | ردّ Chrome |
|---|---|---|
| إتاحة تفويض OAuth | المواءمة بشأن تفويض نطاقات OAuth غير المتعلقة بالملف الشخصي | نحن نسعى جاهدين للحصول على ملاحظات من منتدى Web Identity من خلال مجموعة عمل W3C FedID بشأن أفضل الطرق لدعم التفويض خارج المصادقة الأساسية بعد إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا. |
| إتاحة بروتوكول SAML | التوافق مع متطلبات دعم SAML | يسعى الفريق جاهدًا للحصول على ملاحظات من مجتمعات البحث والتعليم بشأن احتياجات دعم SAML (بالإضافة إلى دعم OpenID Connect) بعد إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا. |
مكافحة المحتوى غير المرغوب فيه والاحتيال
Private State Tokens API (وواجهات برمجة التطبيقات الأخرى)
| موضوع الملاحظات | ملخّص | ردّ Chrome |
|---|---|---|
| استكشاف إشارات جديدة | أبدى العديد من الشركاء شعورًا إيجابيًا تجاه استكشاف الإشارات التي تسهّلها المتصفّح لسلامة الجهاز أو ثقة المستخدم. بشكل عام، يحرصون أيضًا على أن تكون الإشارات الجديدة المخصّصة لهذا الغرض كافية للحفاظ على المستويات الحالية لرصد عمليات الاحتيال. | يسرّنا استكشاف اقتراحات جديدة معًا في إطار منتدى مكافحة الاحتيال وأمان الويب، كما ندرك مخاوفهم ونشاركها معهم. لهذا السبب تحديدًا، كان "مكافحة المحتوى غير المرغوب فيه والاحتيال" أحد مسارات العمل الأساسية في "مبادرة حماية الخصوصية"، ولهذا السبب نواصل منح الأولوية للاستثمار في الحفاظ على أمان الويب أثناء تحسين خصوصية المستخدمين. |
| ملاحظات إيجابية حول "الإعلانات الصورية" | أبدى العديد من الشركاء اهتمامهم باختبار علامات ملفات تعريف الارتباط هذه أو استخدامها في حالات استخدام مختلفة لمكافحة الاحتيال أو أمان الويب. | يسرّنا معرفة أنّك تدعم مزيدًا من الاستكشاف للحلول الجديدة التي تستخدِم خدمات معالجة الوقت. تتوفّر لدينا مراجع ونماذج رموز برمجية من خلال الموقع الإلكتروني لمطوّري Chrome، ونرحّب بملاحظات إضافية. |
| الاحتيال وإساءة الاستخدام | إرشادات لمنع / رصد الاحتيال الإعلاني في القياس بعد إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا عندما لا تتوفّر المعرّفات | لقد طرحنا أدوات، مثل الرموز المميّزة للحالة الخاصة، والتي تساعد في استرداد بعض الإشارات التي فقدتها ملفات تعريف الارتباط التابعة لجهات خارجية لأغراض مكافحة الاحتيال، ولكن مع وضع عناصر تحكّم جديدة في الخصوصية. نحن نستثمر بنشاط في اقتراحات جديدة لمكافحة الاحتيال وإساءة الاستخدام من أجل الحفاظ على الإمكانات مع التغييرات الأخرى في "مبادرة حماية الخصوصية". |
| معدّل معلومات المصدر إلى جهة الإصدار | يكون معدّل معلومات المصدر إلى الجهة المُصدِرة مرتفعًا بما يكفي لتحديد المستخدِمين الفرديين. | لقد عدّلنا المواصفات لتكون أكثر وضوحًا بشأن بيانات المستخدمين التي يمكن نقلها باستخدام "الرموز المميّزة للحالة الخاصة". يمكن استخدام ما يصل إلى ستة مفاتيح عامة في الوقت نفسه، وقد تم تصميمها لتمثّل "حالة" لمستخدم معيّن. لا يمكن تعديل مجموعات المفاتيح هذه إلا كل 60 يومًا (باستثناء الحالات النادرة التي يكون فيها تغيير مفاتيح الطوارئ ضروريًا)، ما يبطئ إمكانية دمج بيانات المستخدمين الإضافية بمرور الوقت. مع أي واجهة برمجة تطبيقات ويب جديدة، هناك توازن بين الأداة المقدَّمة ومعلومات المستخدم الجديدة التي تقدّمها. نعتقد أنّ ملفات تعريف الارتباط التي لا تتبّع المستخدمين توفّر التوازن المناسب بين حماية خصوصية المستخدمين وتفعيل حالات الاستخدام الرئيسية لمكافحة الاحتيال المتأثرة بإيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا. |
| دمج Fetch | عملية دمج fetch معقّدة وغير ضرورية. |
هناك مزايا وعيوب لاستخدام fetch، ونريد مواصلة تطوير المزيد من المعايير ضمن المنظومة المتكاملة للويب، ولكن نعتقد أنّه من المبكر جدًا إجراء هذا التغيير إلى أن نحصل على فكرة أوضح عن الشكل الذي سيظهر به المعيار. وفي حال ظهور معيار، نحن ملتزمون أيضًا بنقل مطوّري الويب إلى هذا المعيار بمسؤولية. |
| موقع التخزين | يجب تخزين إعدادات مفاتيح الرموز المميّزة للحالة الخاصة في الموقع نفسه الذي يتوفّر فيه بروتوكول PrivacyPass. | أثناء الاختبار خلال الفترة التجريبية لميزة "مصدر البيانات"، أشار المطوّرون إلى أنّهم يفضّلون المرونة في تخزين مفاتيح التشفير في عناوين URL عامة بدلاً من تخزينها في دليل .well-known. لا يكون تنسيق التزام المفتاح في PrivacyPass مناسبًا بشكل خاص للإصدار الذي تهدف فيه مجموعات المفاتيح إلى السماح بقيمة "بيانات وصفية عامة" ضمنية. إذا تمّ اعتماد أحد أنواع PrivacyPass وفقًا للمعايير باستخدام البيانات الوصفية العامة (إما كملف POPRF أو تشويش RSA الجزئي أو مجموعات المفاتيح)، قد ننتقل إلى إصدار مستقبلي من PST ليتيح ذلك. |
| تنفيذ عنوان واجهة برمجة التطبيقات | أسئلة حول تنفيذ الرأس لواجهة برمجة التطبيقات | مع إتاحة واجهة برمجة التطبيقات بشكل موحّد ونضوج استخدام المنظومة المتكاملة لهذه الواجهة، نأمل أن نتمكّن من توفير كلّ من الإصدار العادي من واجهة برمجة التطبيقات غير المزوّدة برؤوس البيانات، وربما إيقاف إصدار واجهة برمجة التطبيقات المزوّدة برؤوس البيانات نهائيًا إذا كان معدّل الاستخدام منخفضًا بما يكفي أو إذا توفّرت أدوات أو دعم كافٍ للمطوّرين لاستخدام الطرق العادية لربط طلبات الإصدار أو تحصيل القيمة بالبيانات الأخرى. نحن نناقش المشكلة هنا. |
| التسجيل | هل من العملي أن يُطلب من الجهات المُصدِرة التسجيل لدى مورّدي المتصفّحات؟ | لقد عدّلنا المواصفة لوصف عملية تسجيل جهة إصدار الرموز المميّزة للحالة الخاصة. على الرغم من أنّ هذه العملية تستخدم إجراءات خاصة بها، إلا أنّها تشبه خطط التسجيل في باقي أعمال "مبادرة حماية الخصوصية"، حيث نطلب من الجهات المُصدِرة تقديم بيان علني عن الطريقة التي تنوي بها استخدام ملفات تعريف الارتباط هذه والاعتراف بالقيود الفنية التي تحمي خصوصية المستخدمين. |