تقرير ربع سنوي للربع الثاني من عام 2022 يلخّص الملاحظات التي وردتنا من المنظومة المتكاملة بشأن اقتراحات "مبادرة حماية الخصوصية" وردّ Chrome عليها.
كجزء من التزاماتها بموجب "قانون معالجة المعاملات"، وافقت Google على تقديم تقارير ربع سنوية علانية عن عملية تفاعل الجهات المعنية بعروض "مبادرة حماية الخصوصية" (يُرجى الاطّلاع على الفقرتين 12 و17(ج)(2) من الالتزامات). يتم إنشاء تقارير الملخّصات هذه حول الملاحظات والآراء بشأن "مبادرة حماية الخصوصية" من خلال تجميع الملاحظات والآراء التي تلقّاها Chrome من المصادر المختلفة كما هو موضّح في نظرة عامة على الملاحظات والآراء، بما في ذلك على سبيل المثال لا الحصر: GitHub المشاكل، ونموذج الملاحظات والآراء المتاح على privacysandbox.com، والاجتماعات مع الجهات المعنية في المجال، ومنتديات معايير الويب. يرحّب فريق Chrome بالملاحظات التي يتم تلقّيها من المنظومة المتكاملة ويستكشف بنشاط طرق دمج الدروس المستفادة في قرارات التصميم.
يتم ترتيب مواضيع الملاحظات حسب معدّل تكرارها لكل واجهة برمجة تطبيقات. ويتم ذلك من خلال جمع ملاحظات فريق Chrome حول موضوع معيّن وتنظيمها بترتيب تنازلي حسب الكمية. تم تحديد مواضيع الملاحظات المشترَكة من خلال مراجعة مواضيع المناقشة من الاجتماعات العامة (W3C وPatCG وIETF) والملاحظات المباشرة وGitHub والأسئلة الشائعة التي تظهر من خلال الفِرق الداخلية في Google والنماذج العامة.
وعلى وجه التحديد، تمت مراجعة محاضر اجتماعات الهيئات المسؤولة عن معايير الويب، وبالنسبة إلى الملاحظات المباشرة، تمّت مراجعة سجلّات Google لاجتماعات الجهات المعنيّة وجهًا لوجه، والرسائل الإلكترونية التي تلقّاها المهندسون الفرديون، وقائمة البريد الإلكتروني لواجهات برمجة التطبيقات، ونموذج الملاحظات العلني. بعد ذلك، نسّقت Google بين الفِرق المشاركة في أنشطة التواصل المختلفة هذه لتحديد مدى رواج المواضيع التي تظهر في ما يتعلّق بكل واجهة برمجة تطبيقات.
تم تطوير تفسيرات ردود Chrome على الملاحظات من خلال عناوين الأسئلة الشائعة والمنشورة، والردود الفعلية التي تم تقديمها على المشاكل التي طرحها أصحاب المصالح، وتحديد وجهة نظر خاصة لأغراض هذا التمرين الخاص بإعداد التقارير العلنية. استنادًا إلى التركيز الحالي على التطوير والاختبار، تلقّينا أسئلة وملاحظات بشأن Topics API وFledge API وAttribution API.
قد لا يتم النظر في الملاحظات التي يتم تلقّيها بعد انتهاء فترة إعداد التقارير الحالية.
مسرد الاختصارات
- ملفات تعريف الارتباط في الحالة المقسَّمة المنفصلة (CHIPS)
- ملفات تعريف الارتباط في الحالة المقسَّمة المنفصلة
- معالِج الإشارات الرقمية (DSP)
- وسيط عرض الطلب
- FedCM
- إدارة بيانات الاعتماد الموحّدة
- عدد اللقطات في الثانية
- مجموعات نطاقات الطرف الأول
- مكتب الإعلانات التفاعلية (IAB)
- Interactive Advertising Bureau
- IDP
- موفِّر الهوية
- مجموعة مهندسي شبكة الإنترنت (IETF)
- مجموعة مهندسي شبكة الإنترنت
- عنوان IP
- عنوان بروتوكول الإنترنت
- openRTB
- عرض الأسعار في الوقت الفعلي
- الوقت بدل الضائع
- فترة التجربة في Origin
- PatCG
- مجموعة منتدى تكنولوجيا الإعلانات الخاصة
- RP
- جهة الاعتماد
- SSP
- وسيط عرض إعلانات المورّدين
- بيئة تنفيذ موثوقة (TEE)
- بيئة التنفيذ الموثوقة
- UA
- سلسلة وكيل المستخدم
- UA-CH
- تعديلات برنامج وكيل المستخدم
- W3C
- اتحاد شبكة الويب العالمية
- WIPB
- إخفاء عناوين IP عن قصد
ملاحظات عامة، ما مِن واجهة برمجة تطبيقات/تقنية محدّدة
| موضوع الملاحظات
(مرتّبة حسب معدّل الانتشار) |
ملخّص الأسئلة والمخاوف | استجابة Chrome |
| مخططات زمنية أكثر وضوحًا | جداول زمنية أكثر وضوحًا وتفصيلاً لتكنولوجيات "مبادرة حماية الخصوصية" | نوضّح خططنا الحالية لجدول النشر على privacysandbox.com، ونعدّله شهريًا. وتأخذ هذه التواريخ في الاعتبار وقت التطوير لكل من مطوّري Chrome ومطوّري الويب، بالإضافة إلى الملاحظات التي تلقّيناها من المنظومة المتكاملة الأوسع نطاقًا بشأن الوقت اللازم لاختبار التقنيات الجديدة واستخدامها. تخضع كل تقنية لخطوات متعددة بدءًا من الاختبار إلى الإصدار (الإطلاق)، ويستند توقيت كل خطوة إلى ما نتعلمه ونكشفه في الخطوة السابقة. لا نلتزم بإصدارات في الوقت الحالي، ولكن عندما نفعل ذلك، سنحرص على تعديل المخطط الزمني العلني على privacysandbox.com. |
| مدى الفائدة لأنواع مختلفة من الجهات المعنيّة | المخاوف من أنّ تقنيات "مبادرة حماية الخصوصية" تفضّل المطوّرين الأكبر حجمًا وأنّ المواقع الإلكترونية المتخصصة (الأصغر حجمًا) تساهم أكثر من المواقع الإلكترونية العامة (الأكبر حجمًا). | نحن نتفهّم أنّ بعض المطوّرين لديهم مخاوف بشأن تأثير تقنيات "مبادرة حماية الخصوصية". التزمت Google أمام هيئة CMA بعدم تصميم اقتراحات "مبادرة حماية الخصوصية" أو تنفيذها بطريقة تشوه المنافسة من خلال منح الأولوية لنشاط Google التجاري، كما التزمت بمراعاة التأثير في المنافسة في الإعلانات الرقمية وعلى الناشرين والمعلنين، بالإضافة إلى التأثيرات على نتائج الخصوصية وتجربة المستخدم. وسنواصل العمل عن كثب مع هيئة CMA لضمان امتثال عملنا لهذه الالتزامات.
مع تقدّم اختبار "مبادرة حماية الخصوصية"، سيكون أحد الأسئلة الرئيسية التي سنقيّمها هو مستوى أداء التقنيات الجديدة لأنواع مختلفة من الجهات المعنيّة. إنّ الملاحظات مهمة جدًا في هذا الشأن، خاصةً الملاحظات المحدّدة والقابلة للتنفيذ التي يمكن أن تساعدنا في تحسين التصاميم الفنية بشكل أكبر. |
| المخططات الزمنية للإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية | طلبات لتجنّب المزيد من التأخير في إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا | لقد تلقّينا ملاحظات من بعض الجهات المعنية التي تريد من Chrome مواصلة العمل على إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا بدون أي تأخير، كما تلقّينا ملاحظات من جهات أخرى تعتقد أنّه يجب توفير المزيد من الوقت لاختبار تقنيات "مبادرة حماية الخصوصية" واستخدامها. نحن ملتزمون بالمضي قدمًا بمسؤولية نظرًا لتعقيد التقنيات وأهمية اتّخاذ الإجراءات الصحيحة للمنظومة المتكاملة. لقد كانت الملاحظات الواردة من الجهات التنظيمية ومن الجهات المعنية في المجال أساسية في هذه العملية. |
| المخططات الزمنية للإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية | طلبات لتأجيل إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا، وتوفير المزيد من الوقت لاختبار واجهات برمجة التطبيقات | لقد تلقّينا ملاحظات من بعض الجهات المعنية التي تريد من Chrome مواصلة العمل على إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا بدون أي تأخير، كما تلقّينا ملاحظات من جهات أخرى تعتقد أنّه يجب توفير المزيد من الوقت لاختبار تقنيات "مبادرة حماية الخصوصية" واستخدامها. نحن ملتزمون بالمضي قدمًا بمسؤولية نظرًا لتعقيد التقنيات وأهمية اتّخاذ الإجراءات الصحيحة للمنظومة المتكاملة. لقد كانت الملاحظات الواردة من الجهات التنظيمية ومن الجهات المعنية في المجال أساسية في هذه العملية. |
| طلبات المستندات | طلبات للحصول على المزيد من المراجع التي توضّح كيفية إدارة الاختبار والتحليل والتنفيذ | نشكر المطوّرين على الاستفادة من المواد الحالية، ونحن ملتزمون بتقديم المزيد من المواد، بما في ذلك ساعات عمل المطوّرين والمستندات الفنية خلال الأسابيع والأشهر المقبلة حتى يتمكّن المطوّرون من مواصلة فهم كيفية الاستفادة من التكنولوجيات الجديدة.
لقد عقدنا أيضًا جلسات عامة مفتوحة للتطوير الخارجي لمشاركة أفضل الممارسات والعروض التوضيحية، بالإضافة إلى جلسات أسئلة وأجوبة مع قادة المنتجات والهندسة للسماح بالمناقشة أو طرح الأسئلة مباشرةً. |
| الخبرة في المجال | لا يملك فريق Chrome الذي يتعامل مع هيئات وضع المعايير الخبرة اللازمة في منظومة الإعلانات المتكاملة لتحقيق التوازن المناسب بين الخصوصية والفائدة. | ندرك أنّنا نتحمل مسؤولية كبيرة، ونحن نعتمد على ملاحظات محدّدة لتنفيذ هذه الميزة على النحو المطلوب. ونعتبر أيضًا أنّ الخصوصية والفعالية هما من معايير التصميم المهمة والضرورية. في ما يتعلّق بالفريق الذي يعمل على "مبادرة حماية الخصوصية" على الويب، يتجاوز مجموع سنوات العمل في المنظومة المتكاملة للإعلانات مئات السنوات. |
عرض محتوى وإعلانات ذات صلة
المواضيع
| موضوع الملاحظات
(مرتّبة حسب معدّل الانتشار) |
ملخّص الأسئلة والمخاوف | استجابة Chrome |
| مدى الفائدة لأنواع مختلفة من الجهات المعنيّة | تمّت إثارة مخاوف بشأن القيمة التي يتمّ إنشاؤها وتوزيعها للمواقع الإلكترونية استنادًا إلى مستوى الزيارات الواردة إليها أو مدى تخصص محتواها. | سيتم استكشاف مدى فائدة واجهة برمجة التطبيقات من خلال الاختبار. يتوقّع Chrome أن يتطوّر التصنيف والمَعلمات الأخرى استنادًا إلى نتائج الاختبار. قد لا تتطلّب عملية تطوير التصنيف أو المَعلمات إجراء تغييرات غير متوافقة مع الإصدارات القديمة. بالإضافة إلى ذلك، يتوقّع فريق Chrome أن تستمر الملاحظات في التأثير في تطوير Topics API بعد الإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية. |
| التصنيف | يريد أصحاب المصلحة في المجال أن يكون لهم رأي في التأثير في التصنيف. | يظلّ Chrome مفتوحًا لتلقّي الملاحظات بشأن التصنيف. يهمّنا في Chrome معرفة ملاحظاتك حول نموذج الإدارة لتعديل التصنيف، ومناقشة كيفية مساهمة الهيئات الأخرى في المجال في تطوير التصنيف والحفاظ عليه على المدى الطويل. |
| لا يتوفّر سجلّ تصفُّح كافٍ | اقتراح لعرض المواضيع التي شاهدها المتصل في الأسابيع السابقة إذا لم يكن لدى المستخدم سجلّ تصفّح كافٍ لإنشاء 5 مواضيع للأسبوع الأخير | في التصميم الحالي، يتم اختيارها عشوائيًا. سننظر في الارتباط بالموضوعات السابقة وننظر في إمكانية دمج هذا المحتوى، ولكن قد يكون للارتباطات اعتبارات سلبية تتعلّق بالخصوصية يجب أخذها في الاعتبار. |
| الاتصال بفريق Topics نيابةً عن ناشر | هل يمكن لمقدّم خدمة تابع لجهة خارجية مشاركة "المواضيع" مع ناشر؟ | نعم، هذه إحدى الطرق التي نتوقّع استخدام "المواضيع" بها. |
| موجّهات الهجوم المحتمَلة | تحديد المواضيع التي تتضمّن معلومات غير مفيدة | استنادًا إلى الملاحظات الواردة من العديد من المستخدمين في المنظومة المتكاملة، اختَر Chrome فلترة المواضيع وإضافة ضوضاء. تم اتخاذ هذه القرارات مع الأخذ في الاعتبار الخصوصية، وذلك للحد من الوصول إلى المعلومات إلى الأشخاص الذين لم يكن بإمكانهم الوصول إلى هذه المعلومات بخلاف ذلك، وتقديم إمكانية إنكار معقولة للمستخدمين، على التوالي. ندرك أنّ لهذه القرارات عيوبًا، مثل اتجاه الهجوم الموضّح هنا. ومع ذلك، نرى أنّ مزايا الخصوصية تفوق المخاطر المحتملة. نرحب بالمناقشة العلنية حول هذا القرار. |
| متطلبات الأهلية لاستخدام مرحلة التجربة والتقييم | هل هناك طريقة لرصد ما إذا كان المستخدم مؤهلاً للاستفادة من "تجربة الإصدار الأوّلي"؟ | قد لا تتوفّر ميزة الفترة التجريبية للمستخدم بسبب إعدادات المتصفّح أو عوامل أخرى، حتى إذا كان يزور صفحة ويب تقدّم رمز ترويجي صالحًا للفترة التجريبية وكان المتصفّح مضمّنًا في المجموعة التي تم تفعيل الفترة التجريبية لها.
لهذا السبب، يجب دائمًا استخدام ميزة رصد الميزات للتحقّق من توفّر ميزة الإصدار التجريبي من التطبيق الأصلي قبل محاولة استخدامها. |
| تأثيرات الأداء | المخاوف المتعلقة بوقت الاستجابة والتكلفة الإضافية في "المواضيع" | نحن نطلب ملاحظاتك بشأن الأساليب التي يمكن من خلالها تجنُّب استخدام إطارات iframe من مصادر مختلفة وبطيئة وباهظة التكلفة، وكذلك بشأن الاقتراح المتعلق بفصل Topics API بحيث لا يؤدي الحصول على المواضيع إلى تغيير حالة التصفّح. |
| تقسيم وظائف Topics API | توفير المزيد من التحكّم في الجوانب الثلاثة المختلفة لواجهة برمجة التطبيقات | نحن نتفهّم حالة الاستخدام وقد اقترحنا طريقة محتملة لحلّ هذه المشكلة في GitHub. نحن في انتظار المزيد من الملاحظات من المنظومة المتكاملة بشأن ما إذا كان يجب إنشاء هذه الوظيفة. يمكنك الاطّلاع على المناقشة الجارية هنا. |
| الجدول الزمني لتصنيف البيانات والمستندات ذات الصلة | طلب المطوّرون مزيدًا من المعلومات عن المصنِّف. | يمكنك الاطّلاع على مزيد من المعلومات حول المصنِّف هنا.
بالإضافة إلى هذا الرابط وهنا. |
| عناصر التحكّم في المستخدم وأمانه | قد تكون مواضيع معيّنة بديلاً لمجموعات حسّاسة، ويحتاج المستخدمون إلى المزيد من عناصر التحكّم لمنع النتائج السلبية. | تمثّل ميزة "المواضيع" خطوة مهمة إلى الأمام في ما يتعلّق بمنح المستخدمين إمكانية التحكّم في بياناتهم وتعزيز الشفافية. سيتمكّن المستخدمون من إيقاف المواضيع ومراجعة المواضيع التي تمّ تعيينها لهم وإزالة المواضيع ومعرفة الشركات التي تتفاعل مع مواضيعهم على صفحة معيّنة. بالإضافة إلى ذلك، يمكن للمستخدمين أيضًا التأثير في "المواضيع" من خلال حذف سجلّ التصفّح. نرحب بمواصلة المناقشة بشأن عناصر التحكّم المتقدّمة للمستخدمين، مثل تلك التي اقترحها المطوّرون، ولكن علينا التأكّد من أنّها تزيل المخاطر فعليًا في ما يتعلّق بالمخاوف التي تم طرحها في هذا الخطأ (على سبيل المثال، لا تحمي إزالة الموضوع "دراسة لغة أجنبية" فقط ولكن ليس المواقع الإلكترونية التي أنشأت الموضوع من سجلّ التصفّح المستخدم بالكامل). |
| استخدام المواضيع على المواقع الإلكترونية التي تستخدم prebid.js | هل يمكن استخدام Topics API على المواقع الإلكترونية التي تستخدم prebid.js؟ | الإجابة المختصرة هي نعم. يمكنك الاطّلاع على مزيد من المعلومات هنا. |
| استخدام Topics API في تطبيق مصغّر للاقتراحات | هل يمكننا استخدام Topics API في التطبيق المصغّر "المحتوى المقترَح" (مثل Outbrain)؟ | لا نحدّ من حالة استخدام المواضيع التي تم استرجاعها بعد طلب واجهة برمجة التطبيقات (سيعتمد ذلك على سياسة البيانات لكل مطوّر). |
| الخصوصية / السياسة | أسئلة حول الغرض من فلترة الردود حسب المتصل إذا كانت بعض الجهات الخارجية ستشارك مواضيعها مع أي شخص يتصل | استنادًا إلى الملاحظات الواردة من العديد من الجهات في المنظومة المتكاملة، اختار فريق Chrome هذا التصميم للحد من الوصول إلى المعلومات إلى المستخدمين الذين لم يكن بإمكانهم الوصول إلى هذه المعلومات بخلاف ذلك. بطبيعة الحال، يمكن للناشرين والجهات الخارجية التي تتلقّى Topics تحديد المعلومات التي ستشاركها مع الجهات على موقعها الإلكتروني. وفي حال اتّباع هذا النوع من المشاركة، يشجّع Chrome هذه التطبيقات بشدة على التعامل بشفافية مع المستخدمين بشأن هذه المشاركة ومنحهم عناصر تحكّم. |
| الإشارات التي تتضمّن ضوضاء | قد يؤدي عرض موضوع عشوائي بنسبة% 5 من الوقت إلى إنشاء الكثير من الضوضاء أو الإشارات الخاطئة. | إنّ الضوضاء هي طريقة مهمة لحماية خصوصية المستخدم، وسيتم استكشاف مستويات الضوضاء مقارنةً بمدى فائدة المواضيع من خلال الاختبار. |
FLEDGE
| موضوع الملاحظات
(مرتّبة حسب معدّل الانتشار) |
ملخّص الأسئلة والمخاوف | استجابة Chrome |
| تنسيق الاختبار | اختبار تأثير الأداء والأرباح | يتم مناقشة أداء FLEDGE وكيفية تقديم أفضل دعم لاختبار المنظومة المتكاملة أثناء "تجارب المصدر" و"الإصدار العلني" في اجتماعات WICG المفتوحة. |
| الخادم الموثوق به لبرنامج FLEDGE | متى سيكون "الخادم الموثوق به" متاحًا للاختبار؟ | نحن نقدّر هذه الملاحظات ونعمل بنشاط على وضع خطة أكثر تفصيلاً يمكننا مشاركتها لاستخدام الخوادم الموثوق بها في FLEDGE. |
| توحيد البروتوكول | هل سيكون هناك بروتوكول شائع لنقل البيانات بين منصّات عرض الإعلانات وأنظمة إدارة الأداء التسويقي، مثل التصنيفات الشائعة لمجموعات الاهتمامات؟ | نرحب بملاحظات من منصّات إدارة الأداء (DSP) ومنصّات عرض الإعلانات (SSP) والمنظومة المتكاملة للإعلانات الأوسع نطاقًا بشأن إمكانية توحيد المواصفات. لأغراض الاختبار الأولي في الوقت الحالي، ننصحك بالعمل مباشرةً مع شركاء الاختبار لأنّهم بصدد تجربة طرق مختلفة. ونشجّع أيضًا المؤسسات التجارية للإعلانات على تقديم ملاحظاتها وآرائها بشأن وضع معايير موحدة في حال كانت مفيدة للشركات الأعضاء فيها، ونخطّط لمواصلة العمل معها. |
| تحديد عدد مرات الظهور | عناصر التحكّم في عدد مرّات الظهور لكلّ مستخدِم ضمن حملة ومجموعة إعلانية | ستتيح FLEDGE تحديد عدد مرّات الظهور للمزادات على الجهاز والحملات التي تستهدِف المحتوى / العلامة التجارية أيضًا. يمكن أيضًا استخدام مساحة التخزين المشتركة والحدود القصوى الخاصة بالموقع الإلكتروني لأداة التحكّم الإضافية في تحديد عدد مرّات الظهور. |
| تأثير FLEDGE في الأداء | مقدّمو عروض الأسعار الذين يعتمدون على عمليات حسابية مكثفة في مزاد FLEDGE | يجري فريق Chrome مناقشات نشطة مع المطوّرين بشأن التأثير المحتمل على أداء الموقع الإلكتروني. يرحب فريق Chrome بفرص التعرّف على المزيد من المعلومات أثناء الاختبار. |
| اختبار FLEDGE مع ميزات أخرى | كيف ستتلاءم التقارير على مستوى الحدث من Attribution Reporting API وFLEDGE معًا؟ | تمت مناقشة هذا الموضوع في مكالمة WICG/conversion-measurement-api الأخيرة، مع رابط إلى الدقائق التفصيلية هنا.
في ما يلي ملخّص للاجتماع: يتيح التصميم الحالي لإعداد تقارير الإعلانات في الإطارات المُغلقة ربط معرّف تم إنشاؤه داخل الإطار المُغلق بالمعلومات السياقية. وبالتالي، يمكن دمج التقارير على مستوى الحدث التي يتم إنشاؤها داخل الإطار المحدود بالمعلومات السياقية نفسها على الخادم (باستخدام عمليتَي دمج من جهة الخادم بدلاً من عملية واحدة). |
| احتساب مرّات الظهور | المنهجية التي يجب أو يمكن استخدامها بين المشترين والبائعين لاحتساب مرّات الظهور | تتيح FLEDGE API حاليًا التنسيق في المنهجية بين البائع والمشتري أثناء المزاد. لقد تلقّينا اقتراحات بشأن عمليات التنفيذ البديلة بدون ملاحظات حول سبب عدم ملاءمة تصميمنا الحالي للمنظومة المتكاملة. |
| عرض إعلانات متعدّدة | ما إذا كان بإمكان أحدهم عرض إعلانات متعددة في مزاد واحد في إطار محدود معيّن | يمكن إجراء ذلك حاليًا من خلال الإعلانات المكوّنة (يجب عدم الخلط بين الإعلانات المكوّنة ومزادات المكوّنات). لإجراء ذلك، يجب أن تكون جميع الإعلانات في مجموعة الاهتمامات نفسها. |
| مواصفات "شرائح الجمهور المحدّدة من البائع (SDA)" وFLEDGE | هل يمكن أن تصبح تقنية FLEDGE آلية لمنع المشترين من إنشاء الملفات الشخصية من SDA في طلبات الإعلانات؟ | تم تصميم FLEDGE لتجنُّب تسرُّب المعلومات غير ذات الصلة عندما يعرف الناشر المواقع الإلكترونية التي يزورها الزوّار ويكون الاستهداف على الموقع الإلكتروني نفسه. إذا كان من المهمّ إتاحة الشراء على الإعلانات على شبكة البحث (SDA) ضمن جميع وسائل الحماية المضمّنة في FLEDGE، قد يكون أحد الحلول هو أن يُرسل البائع تصنيفات الإعلانات على شبكة البحث (SDA) إلى المزاد على الجهاز فقط، وأن تنشئ تكنولوجيا الإعلانات من جهة الشراء مجموعة مصالح خاصة بها ينصّ منطق عروض أسعارها على "أريد شراء شريحة الجمهور X". |
| إتاحة العملات غير الدولار الأمريكي | إتاحة اختبار FLEDGE باستخدام عملات غير الدولار الأمريكي | نشكرك على هذه الإشارة ونعمل على توفير العملات الأخرى ضمن قائمة الطلبات التي لم تتم معالجتها بعد. نأمل أن نتمكّن من توفير هذه الميزة قريبًا. |
| إتاحة الاستهداف السلبي للمجموعات باهتمامات مشتركة | واجهة برمجة تطبيقات تتيح استهداف IG السلبي: عرض الإعلانات فقط إذا لم يكن المستخدِم تابعًا لمجموعة IG | مناقشة جارية، بما في ذلك بعض الخيارات المقترَحة لدعمها، في مشكلة GitHub. |
| منصّات عرض إعلانات متعدّدة في FLEDGE | خطر تفضيل Google عند تنفيذ مزادات متعددة المستويات في FLEDGE | تمت إضافة دعم لخدمات SSP متعددة في FLEDGE من أجل توفير بيئة لعب عادلة ومنصفة. تعهدت Google بموجب "الالتزامات" بعدم تصميم اقتراحات "مبادرة حماية الخصوصية" أو تطويرها أو تنفيذها بطرق من شأنها تشويه المنافسة من خلال منح الأولوية لمنتجاتها وخدماتها الإعلانية. تتعامل Google مع هذا الأمر بجدية، وهي منفتحة جدًا لمناقشة أي مخاوف قد تواجهها الجهات المعنية بشأن جوانب معيّنة من التكنولوجيا. للحصول على معلومات، يمكنك الاطّلاع على مستند Chrome العلني حول آلية مزاد المكوّنات هنا. |
قياس الإعلانات الرقمية
تقارير تحديد المصدر (وواجهات برمجة التطبيقات الأخرى)
| موضوع الملاحظات
(مرتّبة حسب معدّل الانتشار) |
ملخّص الأسئلة والمخاوف | استجابة Chrome |
| تحديد المصدر بالاستناد إلى نقاط اتصال متعددة | الناشرون الذين يطلبون إتاحة ميزة تحديد المصدر بالاستناد إلى نقاط اتصال متعددة | تتطلّب الطرق الحالية لتحديد المصدر بالاستناد إلى عدّة نقاط اتصال ربط مرّات ظهور المستخدِم (وبالتالي هويته) بشكلٍ حاسم على مستوى مواقع إلكترونية مختلفة. ونتيجةً لذلك، لا تتوافق هذه الوظيفة بصورتها الحالية مع أهداف "مبادرة حماية الخصوصية" التي تهدف إلى إتاحة حالات الاستخدام الرئيسية للإعلانات بدون التتبُّع على مستوى المواقع الإلكترونية. في بعض الحالات، يمكن تقريب عملية منح الأرصدة (على سبيل المثال، باستخدام أولويات عشوائية مرجحة) بدون تتبُّع المستخدِمين الفرديين. |
| إنشاء الضوضاء | أسئلة حول مستويات الضوضاء في التقارير | تسمح تجربتنا الأولية للمطوّرين بضبط قيمة "إبسيلون" الخاصة بهم حتى يتمكّنوا من تجربة كيفية تغيُّر التقارير استنادًا إلى مستوى التشويش. اعتبارًا من الآن، يمكن للمطوّرين اختيار قيمة epsilon تصل إلى epsilon=64. لقد فعلنا ذلك على وجه التحديد لتسهيل اختبار واجهات برمجة التطبيقات على المطوّرين وتقديم ملاحظاتهم بشأن قيم مقياس epsilon المناسبة.
لقد قدّمنا أيضًا طلبًا علنيًا للحصول على هذه الملاحظات. |
| تنسيق الاختبار | هل يمكن استخدام أداة الاختبار على الجهاز لاختبار OT؟ | نعم، يمكن استخدام أداة الاختبار على الجهاز طوال فترة الاختبار المفتوح. يمكن استخدام أداة الاختبار على الجهاز فقط مع تقارير تصحيح الأخطاء طالما أنّ ملفات تعريف الارتباط التابعة لجهات خارجية متاحة. |
| سهولة استخدام طلبات البحث | تفعيل طلب تجميع المفاتيح | نوافق على أنّ هذا الإجراء يُحسِّن من سهولة استخدام واجهة برمجة التطبيقات بدون أي تكلفة واضحة للخصوصية أو بتكلفة قليلة. سنقدّم اقتراحًا ونرى ما إذا كان هناك إجماع واسع النطاق على أنّه يستحق الدعم. |
| بيانات أقل دقة للمواقع الصغيرة | قد تتلقّى المواقع الإلكترونية أو الحملات الأصغر حجمًا بيانات أقل دقة. | يدرك Chrome أنّ إجراءات حماية الخصوصية المستندة إلى التشويش لها تأثير أكبر في شرائح البيانات الأصغر حجمًا. ومع ذلك، من المحتمل أن تؤدي طُرق مثل التجميع على مدار فترات زمنية أطول إلى حلّ هذه المشكلة، كما أنّه من غير الواضح ما إذا كانت الاستنتاجات المستندة إلى شرائح بيانات صغيرة جدًا (مثل عملية شراء واحدة أو عمليتَي شراء) مفيدة للمعلِنين. خلال فترة التجربة التجريبية، يشجّع Chrome المختبِرين على الاستفادة من إمكانية تجربة مجموعة كبيرة من مَعلمات الخصوصية والضوضاء حتى يتمكّنوا من تقديم ملاحظات أكثر تحديدًا حول هذه المشكلة. |
الحد من التتبّع الخفي
تقليل معلومات وكيل المستخدم
| موضوع الملاحظات
(مرتّبة حسب معدّل الانتشار) |
ملخّص الأسئلة والمخاوف | استجابة Chrome |
| الحماية من برامج التتبُّع | تأثير Universal Analytics (UA-R) في حماية المواقع الإلكترونية من برامج التتبُّع | نحن نقدّر هذه الملاحظات، ونحن بصدد جمع معلومات عن طرق الحماية من برامج التتبّع لتوجيه تصاميمنا المستقبلية. |
| العناصر التابعة للنشر | معالجة العناصر التابعة لنشر وكيل المستخدم المنظَّم (SUA) | لقد طرحنا "المرحلة 4"، والتي تُعرف أيضًا باسم خفض إصدار الأرقام الصغرى، على جميع مستخدمي Chrome الذين يستخدمون الإصدار 101 والإصدارات الأحدث. يمكنك الاطّلاع على التحديث هنا. |
تعديلات برنامج وكيل المستخدم
| موضوع الملاحظات
(مرتّبة حسب معدّل الانتشار) |
ملخّص الأسئلة والمخاوف | استجابة Chrome |
| إدراج جميع التلميحات المتوافقة | الاهتمام بتوفير طريقة آلية لمعرفة جميع التلميحات المتوافقة مع المتصفّح | نحن نقدّر هذه الملاحظات ونحن بصدد تقييم طلب الميزة. يهمّنا معرفة ما إذا كانت هذه حالة استخدام شائعة. |
| مرونة رأس UA-CH مقارنةً برأس User-Agent | إنّ UA-CH محددة بشكل مفرط مقارنةً بالمرونة التي يوفّرها عنوان User-Agent، كما هو محدّد في rfc7231. | يرى Chrome أنّ الطبيعة التوجيهية لرؤوس UA-CH هي تحسين مهم مقارنةً بالمرونة التي تتمتع بها سلسلة UA، وذلك من وجهة نظر إمكانية التشغيل التفاعلي بين المتصفّحات المختلفة وحماية خصوصية المستخدم (من خلال منع الإضافات العشوائية للمعرّفات ذات التشويش العالي).
ستظل المشكلة مفتوحة في حال مشاركة مستخدمين آخرين لهذه المشكلة ورغبتهم في تقديم ملاحظاتهم. |
| UA-CH: Anti-Fraud / Anti-Abuse concerns | ميزات معيّنة قد تفقد إمكانية استخدامها من خلال Universal Analytics (UA-CH): خدمة تتبُّع عمليات إعادة التوجيه الناتجة عن النقرات، والنقرات الاحتيالية | يحقّق الفريق في هذه المشاكل المحتمَلة مع الجهات المعنية بمكافحة الاحتيال والقياس. |
| الأداء | هناك مخاوف بشأن وقت استجابة الحصول على التلميحات من خلال Critical-CH (عند تحميل الصفحة لأول مرة). | يبحث فريق Chrome عن طرق لتحسين الأداء. |
Gnatcatcher (قيد الإعداد)
| موضوع الملاحظات
(مرتّبة حسب معدّل الانتشار) |
ملخّص الأسئلة والمخاوف | استجابة Chrome |
| المخاوف المتعلقة بوقت الاستجابة | يمكن أن تؤثّر إضافة قفزات إضافية في وقت الاستجابة. | نحن ننظر في استخدام خادم وكيل يتضمّن خطوتَي اتصال، ونستكشف طرقًا لتحقيق التوازن الصحيح بين خصوصية المستخدم ووقت الاستجابة. نحن منفتحون على الملاحظات ونريد إجراء المزيد من المناقشات في منتديات W3C. |
| الحماية من الاحتيال والروبوتات | تأثيرات الحماية من الاحتيال والروبوتات، بما في ذلك في البلدان الأقل نموًا | تشكّل السلامة شرطًا أساسيًا بينما نبحث عن طرق لتحسين خصوصية المستخدمين بطرق فعّالة، مثل استخدام الخادم الوكيل لعناوين IP. يضمن الخادم الوكيل الذي يتضمن قفزةَين ويتعاون مع شركات موثوق بها خصوصية المستخدمين التي يمكن التحقّق منها. نحن نعمل أيضًا على تطوير أفكار لإشارات جديدة للمساعدة في تعزيز ثقة المستخدمين. |
| الامتثال لقوانين الخصوصية المحلية | إنّ إعداد تقارير البيانات الجغرافية على مستوى البلد يجعل من الصعب الامتثال للأنظمة المحلية الأكثر دقة. | لقد نشرنا المبادئ المقترَحة علنًا، والتي تتضمّن طرقًا محتملة تتيح للمواقع الإلكترونية الامتثال للمتطلبات المحلية. |
تعزيز حدود الخصوصية على جميع المواقع
مجموعات نطاقات الطرف الأول
| موضوع الملاحظات
(مرتّبة حسب معدّل الانتشار) |
ملخّص الأسئلة والمخاوف | استجابة Chrome |
| مدى الفائدة لأنواع مختلفة من الجهات المعنيّة | تأثير معدّل اللقطات في الثانية على جهات النشر الصغيرة مقارنةً بجهات النشر الكبيرة | يتمثل الهدف الأساسي من "مبادرة حماية الخصوصية" في تحسين خصوصية المستخدمين من خلال استبدال الممارسات الحالية بحلول لا تعتمد على آليات التتبُّع على مستوى المواقع الإلكترونية. نريد أن تكون هذه الحلول مفيدة على نطاق واسع قدر الإمكان لأنواع مختلفة من الجهات المعنيّة بمختلف أحجامها. نرحب بملاحظات محدّدة وقابلة للتنفيذ حول كيفية تحسين هذه الحلول، ونتوقع أن تستمر عملية تطويرها من خلال المناقشات والاختبارات في المنتدى. |
| تحسين الخصوصية | قد يؤدي وجود عدد كبير جدًا من المواقع الإلكترونية في المجموعة نفسها إلى نتائج مشابهة لنتائج ملفات تعريف الارتباط التابعة لجهات خارجية. | نحن نقدّر هذه الملاحظات ونعمل على تقييم ما إذا كان من الممكن وضع حدود مناسبة أو ما هي هذه الحدود، ونحاول أيضًا تزويد كلّ من المستخدمين والمطوّرين بإجراءات أو إشارات تتيح لهم معرفة ما إذا تمّ بلوغ هذا الحدّ. ليس لدينا اقتراح محدّد حتى الآن لمشاركته معك، ولكننا نأمل أن نفعل ذلك قريبًا جدًا. |
| توافق المنظومة المتكاملة مع عدد اللقطات في الثانية | مجموعة من الاقتراحات والمخاوف بشأن مواصلة تطوير ميزة "الإطارات في الثانية" خارج إطار "إطار عمل الخصوصية" | على الرغم من أنّنا كنا نفضّل أن يبقى اقتراح "مجموعات الطرف الأول" في إطار "إطار عمل الخصوصية"، إلا أنّنا نتطلّع إلى مواصلة متابعة الاقتراح في "إطار عمل المعالجة العادلة للبيانات". لقد شجّعنا أيضًا العديد من بيانات الدعم لمواصلة مناقشة "مجموعات الطرف الأول" وحالات الاستخدام التي يُراد معالجتها. تلتزم Google بمواصلة البحث عن حلول تسمح للويب بمواصلة النمو والازدهار بطريقة تحمي خصوصية المستخدمين وتحترمها. |
| إمكانية التشغيل التفاعلي للمتصفّحات | التنفيذ من خلال متصفّحات أخرى | ندرك أهمية إمكان التشغيل التفاعلي للمتصفّحات بالنسبة إلى المطوّرين، وسنواصل التعاون مع مطوّري المتصفّحات الأخرى لاعتماد معيار عدد اللقطات في الثانية. |
| متطلبات شائعة لسياسة الخصوصية | من غير الممكن الحفاظ على سياسة خصوصية مشتركة في جميع المنتجات ونطاقات السلطة التي يجب أن تكون جزءًا من المجموعة نفسها. | لا يزال فريق Chrome يحدّد متطلبات سياستنا، وسنأخذ هذه الملاحظات في الاعتبار. |
Fenced Frames API
| موضوع الملاحظات
(مرتّبة حسب معدّل الانتشار) |
ملخّص الأسئلة والمخاوف | استجابة Chrome |
| طلب المستندات | الاختلافات في إطارات iframe التي تم وضعها في مساحة مغلقة | نحن نقدّر الملاحظات والاقتراحات. هناك مناقشة حالية حول هذا الموضوع على GitHub، حيث نأمل أن نحصل على توضيح نهائي بشأن الطلب لنتمكّن بعد ذلك من تقييمه بالكامل. يمكنك الاطّلاع على المناقشة العامة هنا. |
| الإمكانات المتاحة في جميع واجهات برمجة التطبيقات | التوافق التلقائي مع ميزة "إعداد تقارير تحديد المصدر" في الإطارات المُغلقة | نطلب منك تقديم ملاحظاتك بشأن اقتراح السماح باستخدام Attribution Reporting API في "وضع الإعلانات غير الشفافة" للإطارات المُغلقة تلقائيًا. ونشجّع المطوّرين الذين يستفيدون من هذه الميزة على المشاركة في المناقشة. |
Shared Storage API
| موضوع الملاحظات
(مرتّبة حسب معدّل الانتشار) |
ملخّص الأسئلة والمخاوف | استجابة Chrome |
| حدود البيانات | هل سيكون هناك قيد على مقدار البيانات التي يمكن تخزينها في كل قسم؟ | نعم، ستكون هناك حدود. اطّلِع على مشكلة GitHub للحصول على مزيد من التفاصيل. سنحتاج إلى حصص مساحة التخزين. اقتراحنا الحالي هو وضع حد أقصى لحجم كل إدخال يبلغ 4 كيلوبايت، وسيتم اقتصار كل من المفاتيح والقيم على 1024 حرفًا من char16_t، والحد الأقصى لعدد الإدخالات لكل مصدر هو 10,000 إدخال مع آلية تمنع التزامن مع الإدخالات الإضافية عندما تكون سعة المصادر ممتلئة. نحن نبحث بنشاط عن ملاحظات بشأن الحدود المحدّدة المقترَحة هنا. |
| الشفافية أمام المستخدمين | الشفافية أمام المستخدمين بشأن مصادر البيانات مقابل استخدام البيانات | نحن نقدّر هذه الملاحظات، ونرى أنّ هذا النهج الواعد يستحق الاستكشاف. على وجه الخصوص، نحن نُقيّم ما إذا كان من الممكن إجراء ذلك بطريقة توفّر شفافية كافية للمستخدمين. |
ملفات تعريف الارتباط في الحالة المقسَّمة المنفصلة (CHIPS)
| موضوع الملاحظات
(مرتّبة حسب معدّل الانتشار) |
ملخّص الأسئلة والمخاوف | استجابة Chrome |
| العوائق التي تواجه استخدام الميزة | هل يجب ربط CHIPS باسم المضيف؟ (متطلّبات عدم توفّر نطاق) | نحن بصدد إزالة هذا الشرط من OT استنادًا إلى الملاحظات الواردة من المشاركين في OT بأنّ هذا الشرط أضاف تعقيدًا إضافيًا ويشكّل عائقًا أمام اعتماد CHIPS.
سنناقش هذا الشرط في مجموعة "الخصوصية" في المنتدى كجزء من مرحلة وضع المعايير هنا. |
| حالات استخدام الإعلانات في CHIPS | هل يمكن استخدام شرائح CHIPS لحالات استخدام "إعلانات Google" على موقع إلكتروني واحد؟ | إنّ تتبُّع المستخدِمين ضمن موقع إلكتروني واحد هو حالة استخدام مسموح بها. لقد عدّلنا مقالة المطوّرين للتركيز على حالة الاستخدام هذه. |
| مواد العرض المضمّنة التي تمت مصادقتها | هل يتم الاحتفاظ بحالة تسجيل الدخول باستخدام CHIPS؟ | لا يتم حاليًا الاحتفاظ بحالة تسجيل الدخول، ولكنّها ليست حالة الاستخدام المقصودة لواجهة CHIPS. نحن على دراية بحالة استخدام "عمليات التضمين المعتمَدة" ونعمل على استكشاف الحلول. |
| تنسيق الاختبار | هل هناك أي إجراءات إضافية مطلوبة من المستخدم لاختبار التقسيم؟ | طالما أنّ رمز مفتاح المرور لنظام التشغيل OT صالح ومتوفّر في رؤوس الصفحات التي تمت زيارتها، من المفترض أن تكون الميزة متاحة للمستخدمين بدون الحاجة إلى اتخاذ أي إجراءات إضافية. |
| توافُق المتصفح | الاهتمام بمعرفة كيفية تعامل المتصفّحات الأخرى مع سمات ملفات تعريف الارتباط المقسّمة | يواصل Chrome العمل مع مجموعات المعايير العامة، مثل W3C، لتحديد التصاميم وعمليات التنفيذ التي يمكن أن تعمل على جميع المتصفّحات. |
FedCM
| موضوع الملاحظات
(مرتّبة حسب معدّل الانتشار) |
ملخّص الأسئلة والمخاوف | استجابة Chrome |
| موجّهات الهجوم المحتملة | موجّهات الهجوم المحتملة من خلال زخرفة الروابط وهجمات التوقيت | نعمل جاهدين على جمع الملاحظات والآراء من الجمهور والتحقّق من الطرق المحتملة لحلّ هذه المشكلة. |
| تجربة المستخدم للسماح باستخدام موفِّري هوية متعدّدين | يمكن تقديم مزوّد خدمة تحديد الهوية (IDP) واحد فقط في كل مرة. | نحن نؤمن بأهمية دعم خدمات إدارة الهوية وإمكانية الوصول المتعددة، ونعمل بنشاط على تطوير طرق لدعم |
| التعبير | القلق من أنّه بسبب عرض المتصفّح لجزء من عملية تدفق الهوية المُوحَّدة، من الصعب التقاط جميع الاختلافات الدقيقة التي يريد موفّرو الهوية (IdP) تقديمها للمستخدمين | يُجري Chrome تجارب على تضمين تخصيصات العلامة التجارية (مثل الشعارات والألوان) وتخصيص النصوص (مثل "الوصول إلى هذه المقالة" بدلاً من "تسجيل الدخول باستخدام").
يدرك فريق Chrome هذا التوازن، وسيواصل العمل مع المنظومة المتكاملة لتغطية أكبر قدر ممكن من المحتوى والتعبير عنه بأفضل شكل ممكن. |
| مدى التوفّر وإمكانية التشغيل التفاعلي | القلق من أنّ المتصفّحات الأخرى لن تتبنّى FedCM أو تنفّذها | يتعاون فريق Chrome أيضًا مع مورّدي متصفّحات آخرين للعثور على حلول شائعة للاتحاد في مجموعة FedID Community Group. |
| اقتراح لإزالة متطلبات البيانات الشخصية في عملية الاشتراك | (1) تجربة مستخدم تشير إلى موفِّر الهوية الذي يختاره المستخدم، بدون الإشارة إلى أنّه سيتم مشاركة بريدهم الإلكتروني وصورتهم واسمائهم، ستكون أكثر ملاءمةً للخصوصية
(2) حالات الاستخدام: عملية الاشتراك نادرة في تجربة المستخدم واختيار المطالبات من موفِّر الهوية |
نحن نوافق على ذلك ونعمل على استكشاف كيفية تنفيذ الملاحظات بطريقة أكثر ملاءمةً للمستخدمين والخصوصية. |
| تفاعل المستخدم مع موفِّر الهوية | الحاجة إلى تفاعل مباشر بين المستخدم وموفِّر الهوية في حال تجاوز الحدّ الأدنى للمخاطر | نحن نحقّق في هذه الملاحظات. |
تقسيم حالة الشبكة
| موضوع الملاحظات
(مرتّبة حسب معدّل الانتشار) |
ملخّص الأسئلة والمخاوف | استجابة Chrome |
| الأداء | قد يؤدي تقسيم حالة الشبكة إلى زيادة عدد عمليات الاتصال المكثفة للموارد بخدمات CDN | ما زلنا نبحث في خصائص أداء ميزة "تقسيم حالة الشبكة"، بما في ذلك قياس مخططات المفاتيح المختلفة المحتملة. لم نتّخذ بعد قرارًا بشأن مفاضلة الأداء والأمان والخصوصية، ونحتاج إلى جمع المزيد من البيانات. |
مكافحة المحتوى غير المرغوب فيه والاحتيال
Trust Tokens API
| موضوع الملاحظات
(مرتّبة حسب معدّل الانتشار) |
ملخّص الأسئلة والمخاوف | استجابة Chrome |
| الملاحظات التنظيمية | المخاوف بشأن استثمار الوقت والموارد في الرموز المميّزة المعتمَدة بدون إشارة واضحة من الجهات التنظيمية بشأن الجدوى على المدى الطويل | هدفنا هو إنشاء تكنولوجيا تناسب المنظومة المتكاملة، لذا فإنّ الملاحظات الواردة من الجهات التنظيمية وصنّاع المحتوى مهمة جدًا في هذه العملية. سنواصل التشاور مع الجهات التنظيمية في جميع أنحاء العالم أثناء تطوير "مبادرة حماية الخصوصية" وسنوفّر الاقتراحات للمطوّرين، بما في ذلك "الرموز الموثوق بها". وكما هو الحال مع جميع التكنولوجيات الجديدة، على الشركات اتخاذ القرارات استنادًا إلى تقييمها الخاص للمتطلبات التنظيمية. |
| توقيت الإطلاق | متى سيتم إطلاق الرموز المميّزة المعتمَدة في قناة الإصدار العلني؟ | نوفّر تقديراتنا الحالية لوقت التسليم في المخطط الزمني العلني على privacysandbox.com. وبعد أن نتخذ قرارًا نهائيًا بشأن تاريخ التسليم إلى الإصدار العلني، سننشره علنًا من خلال عمليات إصدار Chrome وسنعدّل المخطط الزمني على الموقع الإلكتروني. |
| رموز Trust Tokens مقارنةً بغيرها | الدور الذي تلعبه الرموز المميّزة للثقة في ظل الرموز المميّزة الأخرى التي تخضع لمرحلة التطوير، مثل الرموز المميّزة للوصول الخاص | نحن نشارك في مناقشات حول عملية وضع المعايير، وهدفنا هو التوافق مع الجهود الأخرى قدر الإمكان، مع تفعيل حالات الاستخدام المختلفة التي توفّرها كل تقنية. على سبيل المثال، تعتمد كل من الرموز المميّزة للثقة والرموز المميّزة للوصول الخاص على بروتوكول Privacy Pass. |
| حدود البيانات | الحد الأقصى لمصدرَين لعمليات تحصيل الرموز المميّزة لكل صفحة | نحن نبحث عن خيارات طويلة المدى يمكننا من خلالها السماح للشركات باستبدال الرموز المميّزة بأمان بدون المخاطرة بزيادة فوضى المستخدمين، ربما من خلال تقسيم إمكانية الوصول إلى عمليات استبدال الرموز المميّزة. |
| قيود الوصول | يجب أن تكون مصادر الإحالات الموافَق عليها (والمُثبَتة/غير المخادعة) فقط هي القادرة على إثبات توفّر رمز مميّز واستخدامه. | نحن بصدد استكشاف طرق تحديد المستخدمين الذين يمكنهم الاطّلاع على الرموز الرقمية واستخدامها. |
| دعم الجهاز | تفرض تبعيات وقت تشغيل JavaScript قيودًا على الاستخدام على بعض الأجهزة. هل يمكن توسيع نطاق توفّر TT ليشمل أنواعًا أخرى من الأجهزة؟ | ندرس إمكانية تطوير هذه الميزة في المستقبل، ونريد معرفة المزيد من الملاحظات والآراء من المطوّرين في منتديات W3C. لدينا أيضًا مشكلة مفتوحة لمناقشة تحصيل الرموز المميّزة التي تم تنشيطها من خلال عنوان HTTP، وندعوك إلى تقديم ملاحظاتك بشأنها. |
| حالات الاستخدام | عدم الوضوح بشأن حالات الاستخدام المناسبة للرموز المميّزة المعتمَدة عدم الوضوح بشأن الاستخدامات المقصودة | هدفنا هو تسهيل الابتكار في مجال مكافحة الاحتيال، ونتفهّم أنّ كل شركة قد تستخدم أساليب خاصة بها مع الرموز المميّزة للثقة، ولهذا السبب لم نضع تعليمات بشأن الاستخدامات المقصودة. ومع ذلك، من المرجّح أن نوسّع نطاق مستنداتنا لتشمل المزيد من الأمثلة كنقاط بداية للشركاء الذين يفكرون في إجراء تجارب أو استخدام الميزة. |
| تغطية الرموز المميّزة الموثوق بها | من المفترض أن تؤدي إزالة سياسة ميزة "الاستفادة من رمز الثقة" إلى زيادة تغطية رمز الثقة بشكل كبير. | نحن نأخذ ذلك في الاعتبار بينما نجمع الملاحظات من فريق الدعم الفني ونتّخذ قرارات بشأن الخطوات التالية. |
| الثقة في جهة الإصدار | لماذا يجب أن نثق بالمواقع الإلكترونية التي أصدرت الرموز المميّزة للثقة؟ | لا توجد إرشادات حول كيفية إصدار البطاقات، ويمكن لأي شخص تنفيذ ذلك. من المتوقّع أن يعمل الناشرون مع الجهات المُصدِرة التي يثقون بها فقط. بالإضافة إلى ذلك، سيتوقّف اللاعبون الآخرون الشرعيون في المنظومة الإعلانية المتكاملة في نهاية المطاف عن شراء الزيارات المرتبطة بجهات إصدار مريبة أو غير معروفة (أو سيتوقفون عن شرائها). |
| الخدمات المضمّنة التابعة لجهات خارجية | هل يمكن للخدمات المضمّنة التابعة لجهات خارجية تحصيل و/أو طلب الرموز المميّزة للثقة؟ | نعم، يمكن لخدمة مضمّنة تابعة لجهة خارجية إصدار "الرموز الموثوق بها" واستخدامها. |
| المنظومة المتكاملة لجهات الإصدار | يمكن تحقيق فائدة أكبر إذا كان بالإمكان مشاركة إشارات الثقة مع شركات أخرى. | تم تصميم "رموز الثقة" لتكون عنصرًا أساسيًا منخفض المستوى، ويمكن لمُصدِري الرموز أو مُستردّيها المتعاونين استخدامها لمشاركة إشارات الثقة أو السمعة. |
| الوقت المستغرَق في الصيانة | إنّ عملية التشفير الأساسية لعمليات الرمز المميّز الموثوق به متوفّرة في BoringSSL، وهي الخدمة التي تتولّى Google إدارتها فقط. كيف سيتمّت إدارة صيانة المكتبة؟ | تعتمد "الرموز الموثوق بها" على عمليات تشفير موحّدة (راجِع بروتوكول Privacy Pass) التي يمكن أيضًا تنفيذها في مكتبات أخرى. ننصح المطوّرين بطلب/تطوير/الحفاظ على إمكانية تنفيذ هذه العمليات في المكتبات التي يختارونها. |
| الوقت المستغرَق في الصيانة | لا يتضح كم من الوقت ستظل إصدارات البروتوكول متوافقة. | نحن بصدد تطوير وتسجيل المزيد من التفاصيل حول الأطر الزمنية المتوقّعة للتوافق مع إصدارات البروتوكول. |
| حدود جهة الإصدار | إذا كنت في مرحلة لاحقة من السلسلة، قد لا تتوفر لك فرصة تنفيذ الرموز المميّزة الموثوق بها. | مع بدء المزيد من المؤسسات في استخدام الرموز المميّزة للثقة، يمكن أن نلاحظ بشكل متزايد هذه الأنواع من الديناميكيات الزمنية، ونحن نبحث عن الحلول المحتملة. كما سبق أن ذكرنا، نبحث عن خيارات طويلة المدى يمكننا من خلالها السماح للشركات باسترداد الرموز المميّزة بأمان بدون المخاطرة بزيادة فوضى المستخدمين، ما سيقلّل من أهمية الموقع على الصفحة أو ترتيب التحميل. |
حلول جديدة لمكافحة الاحتيال في مرحلة التطوير
| موضوع الملاحظات
(مرتّبة حسب معدّل الانتشار) |
ملخّص الأسئلة والمخاوف | استجابة Chrome |
| إشارات التحقق من سلامة الجهاز | دعم قوي بشكل عام لمتابعة إشارات سلامة الجهاز التي تُثبت صحتها المنصات وتُتاح على الويب | سنواصل جمع الملاحظات ومتابعة الاقتراح من خلال التصميم العلني والتكرار. |
| إشارات التحقق من سلامة الجهاز | أسئلة حول مقدار كمية المعلومات العشوائية للمستخدم التي يمكن نقلها من خلال الإشارات الجديدة، وما إذا كانت حالات استخدام معيّنة (مثل تسجيل مستخدِم الدخول إلى حسابه المصرفي) يمكن أن تبرر إشارات ذات معلومات عشوائية أعلى | نحن نميل إلى تقديم إشارات ذات قيمة عالية مع أقل قدر ممكن من التشويش في بيانات المستخدمين للحفاظ على خصوصيتهم. |
| إشارات التحقق من سلامة الجهاز | هل سيؤدي ذلك إلى حظر الوصول إلى الأجهزة القديمة أو الأنظمة الأساسية المعدَّلة أو الأنظمة الأساسية المفتوحة المصدر؟ | يجب أن تراعي أي إشارات جديدة إمكانية الوصول الشاملة كأحد المبادئ الرئيسية في التطوير، وهذه أسئلة مهمة يجب معالجتها في البداية مع مواصلة فترة الحضانة. |
| إشارات التحقق من سلامة الجهاز | كان هناك بعض القلق بشأن ما إذا كانت الإشارات الجديدة تؤدي إلى اعتماد شركات الأمان ومكافحة الاحتيال بشكلٍ مفرط على المتصفّح والمنصات.
|
يجب التعامل مع أي إشارة جديدة على أنّها بيانات تكميلية وليس مؤشرًا على "الثقة" من المتصفّح. نتوقع تمامًا أن تواصل شركات الأمان الاعتماد على البيانات والنماذج ومحرّكات القرارات التي تملكها، مع استخدام إثبات ملكية الجهاز كمدخل إضافي. نأمل أن تؤدي أي إشارة جديدة إلى تحسين جهود رصد الاحتيال في جميع المنظومة المتكاملة، ما يجعل تنفيذ الاحتيال أكثر صعوبة. |
| إشارة عمر ملفّ تعريف الارتباط | مفهوم مثير للاهتمام، ولكن من المحتمل أن يتطلّب إجراء المزيد من التحقيق في حالات الاستخدام السارية. | استنادًا إلى مستويات الاهتمام، قد يقدّم فريق Chrome أفكارًا إضافية حول هذا المفهوم ويطوّرها لإنشاء فيديو توضيحي يعرض الملاحظات المستقبلية حول المنظومة المتكاملة. |
| الخوادم الموثوق بها لمكافحة الاحتيال | مفهوم مثير للاهتمام، ولكن من المحتمل أن يتطلب المزيد من التحقيق في حالات الاستخدام السارية. | استنادًا إلى مستويات الاهتمام، قد يقدّم فريق Chrome المزيد من الأفكار حول هذا المفهوم، ويطوّره ليصبح شرحًا لملاحظات المنظومة المتكاملة المستقبلية. |