تقرير ربع سنوي للربع الثاني من العام 2022 يلخّص الملاحظات التي تم تلقّيها بشأن المنظومة المتكاملة حول اقتراحات "مبادرة حماية الخصوصية" واستجابة Chrome.
في إطار التزاماتها تجاه "مبادرة حماية الخصوصية"، وافقت Google على تقديم تقارير ربع سنوية للجميع عن عملية تفاعل الأطراف المعنية ضمن اقتراحات "مبادرة حماية الخصوصية" (يُرجى الاطّلاع على الفقرتين 12 و17(ج)(2) من الالتزامات). يتم إنشاء تقارير ملخّص ملاحظات "مبادرة حماية الخصوصية" هذه من خلال تجميع الملاحظات التي يتلقاها Chrome من مصادر مختلفة كما هو مُدرَج في نظرة عامة على الملاحظات، بما في ذلك على سبيل المثال لا الحصر: مشاكل GitHub ونموذج الملاحظات المتاح على privacysandbox.com والاجتماعات مع الجهات المعنية في المجال ومنتديات معايير الويب. يرحب Chrome بالملاحظات الواردة من المنظومة المتكاملة ويستكشف بشكل نشط طرقًا لدمج ما تعلّمته في قرارات التصميم.
يتم ترتيب مواضيع الملاحظات والآراء حسب الانتشار حسب واجهة برمجة التطبيقات. ويتم ذلك من خلال تجميع مقدار الملاحظات التي تلقّاها فريق Chrome حول موضوع معيّن والتنظيم بترتيب تنازلي للكمية. تم تحديد موضوعات الملاحظات الشائعة من خلال مراجعة موضوعات المناقشة من الاجتماعات العامة (W3C وPatCG وIETF)، والملاحظات المباشرة، وGitHub، والأسئلة الشائعة التي تظهر من خلال الفرق الداخلية والنماذج العامة في Google.
وبشكل أكثر تحديدًا، تمت مراجعة محاضر اجتماعات اجتماعات الهيئات القياسية على الويب، وللملاحظات المباشرة، تمت مراجعة سجلات Google للاجتماعات الفردية مع الأطراف المعنية ورسائل البريد الإلكتروني التي تلقاها مهندسون فرديون والقائمة البريدية لواجهة برمجة التطبيقات ونموذج الملاحظات العامة. بعد ذلك، نسقت Google بين الفرق المشاركة في أنشطة التوعية المختلفة هذه لتحديد الانتشار النسبي للموضوعات التي تظهر فيما يتعلق بكل واجهة برمجة تطبيقات.
تم تطوير تفسيرات ردود Chrome على التعليقات استنادًا إلى الأسئلة الشائعة المنشورة، والردود الفعلية التي تم تقديمها على المشاكل التي طرحتها الأطراف المعنية، وتحديد الموضع خصيصًا لأغراض تمرين إعداد التقارير العلني هذا. مع التركيز الحالي على التطوير والاختبار، تلقينا أسئلة وتعليقات خاصة في ما يتعلق بـ Topics API وFledge وAttribution Reporting APIs.
إنّ التعليقات التي يتم تلقّيها بعد انتهاء الفترة المشمولة بالتقارير الحالية قد لا تكون قد استجابت Chrome بعين الاعتبار.
مسرد الاختصارات
- الشرائح
- ملفات تعريف الارتباط في الحالة المقسَّمة المنفصلة
- معالِج الإشارات الرقمية (DSP)
- منصّة الطلب
- FedCM
- إدارة بيانات الاعتماد الموحدة
- لقطات في الثانية
- مجموعات الطرف الأول
- مكتب الإعلانات التفاعلية (IAB)
- مكتب الإعلانات التفاعلية
- موفِّر الهوية (idP)
- موفّر الهوية
- مجموعة مهندسي شبكة الإنترنت (IETF)
- مجموعة مهندسي شبكة الإنترنت
- IP
- عنوان بروتوكول الإنترنت
- openRTB
- عروض الأسعار في الوقت الفعلي
- و إ
- تجربة المصدر
- 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 مع ناشر؟ | نعم، هذه هي الطريقة التي نتوقّع أن يتم بها استخدام Topics. |
| متجهات الهجوم المحتمل | تحديد الموضوعات الصاخبة | واستنادًا إلى الملاحظات الواردة من العديد من أفراد المنظومة المتكاملة، اختار متصفّح Chrome فلترة المواضيع وإضافة مصادر تشويش. وقد تم اتّخاذ هذه القرارات مع أخذ الخصوصية في الاعتبار، أي لحصر إمكانية الوصول إلى المعلومات على المستخدمين الذين لم يكونوا بمقدورهم الوصول إليها بأي شكل من الأشكال، وجعل تلك المعلومات غير معقولة للمستخدمين على التوالي. وندرك أنّ هذه القرارات لها عيوب، مثل متجه الهجوم الموضح هنا. ومع ذلك، يتبيّن لنا أنّ الفوائد المتعلّقة بالخصوصية تفوق المخاطر المحتملة. نحن نرحّب بالنقاش العام حول هذا القرار. |
| الأهلية للاستفادة من الفترة التجريبية المجانية | هل هناك طريقة لمعرفة ما إذا كان المستخدم مؤهَّلاً للاستفادة من فترة تجريبية قبل المصدر؟ | قد لا تتوفّر ميزة مرحلة التجربة والتقييم للمستخدمين، بسبب إعدادات المتصفّح أو عوامل أخرى، حتى إذا كانوا يزورون صفحة ويب توفّر رمزًا مميّزًا صالحًا للإصدار التجريبي وكان المتصفّح مضمَّنًا في المجموعة التي تم تفعيل الإصدار التجريبي فيها.
لهذا السبب، يجب دائمًا استخدام ميزة رصد الميزات للتحقّق مما إذا كانت ميزة مرحلة التجربة والتقييم متاحة، قبل محاولة استخدامها. |
| تأثيرات الأداء | المشاكل المتعلقة بالحالات العامة ووقت الاستجابة في Topics | نحن نطلب ملاحظات حول الأساليب لتجنُّب إطارات iframe المُكلِّفة والبطيئة المصدر ولتجنُّب إرباك Topics API بما يجعل الحصول على المواضيع لا يغيِّر حالة التصفُّح. |
| وظائف تقسيم Topics API | توفير المزيد من التحكم في الجوانب الثلاثة المختلفة لواجهة برمجة التطبيقات | نحن نتفهّم حالة الاستخدام واقترحنا طريقة ممكنة لحل هذه المشكلة من خلال GitHub. ننتظر حاليًا المزيد من الملاحظات من المنظومة المتكاملة حول ما إذا كان يجب إنشاء هذه الوظيفة. اطلع على المناقشة الجارية هنا. |
| الجدول الزمني للمصنِّف والتوثيق فيه | لقد طلب المطوّرون مزيدًا من المعلومات حول المصنِّف. | يمكنك الاطّلاع على مزيد من المعلومات حول المصنِّف هنا.
بالإضافة إلى هنا وهنا. |
| عناصر تحكُّم المستخدم وأمانه | قد تكون بعض المواضيع خوادم وكيلة للمجموعات الحساسة ويحتاج المستخدمون إلى مزيد من عناصر التحكُّم لمنع النتائج السلبية. | تمثل الموضوعات خطوة كبيرة للأمام في ما يتعلق بالتحكم والشفافية لدى المستخدم. سيتمكن المستخدمون من إلغاء الاشتراك في المواضيع ومراجعة المواضيع التي تم تعيينها لهم وإزالة المواضيع ومعرفة الشركات التي تتفاعل مع مواضيعها على صفحة معيّنة. بالإضافة إلى ذلك، يمكن للمستخدمين أيضًا التأثير في "المواضيع" من خلال حذف سجلّ التصفُّح. نرحّب بالنقاشات المستمرة حول عناصر تحكّم أكثر تقدّمًا للمستخدمين، مثل تلك التي اقترحها المطوّرون. ومع ذلك، علينا التأكّد من إزالة المخاطر المطروحة في ما يتعلّق بالمخاوف التي أثارها هذا الخطأ (على سبيل المثال، إنّ إزالة الموضوع "دراسة لغات أجنبية" فقط، وليس المواقع الإلكترونية التي أنشأت الموضوع من "سجلّ التصفُّح" لا تحمي المستخدم بالكامل). |
| استخدام مواضيع على المواقع الإلكترونية التي تستخدم prebid.js | هل يمكن استخدام Topics API على المواقع الإلكترونية التي تستخدم prebid.js؟ | الإجابة المختصرة هي نعم. تم نشر المزيد من المعلومات هنا. |
| استخدام Topics API في أداة الاقتراحات | هل يمكننا استخدام Topics API في الأداة المقترَحة (مثل Outbrain)؟ | لا نحدّ من حالة استخدام المواضيع التي تم استردادها بعد طلب البيانات من واجهة برمجة التطبيقات (سيعتمد ذلك على سياسة بيانات كل مطوِّر). |
| الخصوصية / السياسة | الأسئلة المتعلقة الغرض من فلترة الردود حسب المتصل إذا ستشارك بعض الجهات الخارجية مواضيعها مع أي شخص يتصل. | استنادًا إلى الملاحظات الواردة من العديد من أفراد المنظومة المتكاملة، اختار متصفّح Chrome هذا التصميم لحصر الوصول إلى المعلومات على المستخدمين الذين لم يكونوا ليصلوا إلى مثل هذه المعلومات بدون هذه الميزة. بالطبع، يمكن للناشرين والجهات الخارجية التي تتلقّى Topics أن يقرروا بأنفسهم المعلومات التي سيشاركونها مع أطراف على موقعهم الإلكتروني. وفي حال إجراء هذا النوع من المشاركة، يشجعهم Chrome بشدّة على أن يتحلّى بالشفافية مع المستخدمين بشأن عمليات المشاركة هذه، كما يوفّر لهم عناصر التحكم. |
| إشارات مزعجة | قد يؤدي تقديم موضوع عشوائي بنسبة% 5 من الوقت إلى إحداث تشويش كبير أو إشارة خاطئة. | يُعد الضجيج طريقة مهمة لحماية خصوصية المستخدم، وسيتم استكشاف مستويات الضوضاء مقابل فائدة الموضوعات من خلال الاختبار. |
FLEDGE
| موضوع الملاحظات
(مرتبة حسب الأولوية) |
ملخّص الأسئلة والمخاوف | استجابة Chrome |
| تنسيق الاختبارات | اختبار التأثير في الأداء والأرباح | تتم مناقشتنا بنشاط في اجتماعات WICG العامة حول أداء FLEDGE وكيف يمكننا توفير أفضل دعم لاختبار المنظومة المتكاملة أثناء مرحلة التجربة والتقييم بالإضافة إلى مدى التوفّر للجمهور العام. |
| خادم موثوق به لـ FLEDGE | متى سيكون الخادم الموثوق به متاحًا للاختبار؟ | نحن نقدّر هذه الملاحظات ونعمل جاهدين على وضع خطة أكثر تفصيلاً يمكننا مشاركتها من أجل استخدام الخوادم الموثوق بها في FLEDGE. |
| توحيد البروتوكول | هل سيكون هناك بروتوكول مشترك لتمرير البيانات بين أنظمة أسماء النطاقات (SSP) وأنظمة معالجة البيانات (DSP)، مثل التصنيفات المشتركة لمجموعات الاهتمامات؟ | نرحّب بالتعليقات الواردة من أنظمة عرض الإعلانات (DSP) و (SSP) والمنظومة المتكاملة للإعلانات على نطاق أوسع بشأن توحيد المواصفات في المستقبل. ولأغراض الاختبار الأولي في الوقت الحالي، ننصحك بالعمل مع شركاء الاختبار مباشرةً لأنهم ما زالوا في مرحلة تجربة أساليب مختلفة. ونشجّع أيضًا المؤسسات التجارية لعرض الإعلانات ونخطط لمواصلة العمل معها لبذل جهدها لوضع توحيد معاييرة إذا كان ذلك مفيدًا لشركاتها الأعضاء. |
| تحديد عدد مرات الظهور | عناصر التحكّم في عدد مرّات الظهور لكلّ مستخدم ضمن الحملة والمجموعة الإعلانية | سيدعم FLEDGE تحديد عدد مرات الظهور في المزادات على الجهاز فقط والحملات السياقية / حملات العلامات التجارية. ويمكن أيضًا استخدام مساحة التخزين المشتركة والحد الأقصى المخصّص للموقع الإلكتروني لعناصر التحكّم الإضافية لتحديد عدد مرات الظهور. |
| تأثير FLEDGE على الأداء | أنظمة عروض الأسعار الأكثر استخدامًا من الناحية الحسابية في مزاد FLEDGE | يُجري Chrome حاليًا مناقشات نشطة مع مطوّري البرامج حول التأثير المحتمل على أداء الموقع الإلكتروني. يرحب Chrome بفرصة معرفة المزيد من المعلومات أثناء الاختبار. |
| اختبار FLEDGE مع ميزات أخرى | كيف ستلائم التقارير على مستوى الحدث من Attribution Reporting API وFLEDGE معًا؟ | تمت مناقشة ذلك في مكالمة حديثة لواجهة برمجة التطبيقات WICG/conversion-measurement-api، مع رابط للدقائق التفصيلية هنا.
يوضِّح ملخّص الاجتماع أنّ التصميم الحالي لميزة إعداد تقارير إعلانات الإطارات المضمّنة يتيح ربط المعرِّف الذي يتم إنشاؤه داخل "الإطار المحمي" بمعلومات سياقية. وبالتالي، يمكن ضم التقارير على مستوى الحدث، التي يتم إنشاؤها داخل الإطار المتداخل، إلى المعلومات السياقية نفسها على الخادم (باستخدام علامتَي الضم من جانب الخادم بدلاً من 1). |
| حساب عدد مرات الظهور | ما هي منهجية حساب مرات الظهور التي ينبغي أو يمكن استخدامها بين المشترين والبائعين | توفّر FLEDGE API حاليًا مواءمة بشأن المنهجية بين البائع والمشتري أثناء المزاد. لقد تلقينا اقتراحات حول عمليات التنفيذ البديلة دون تعقيبات حول سبب عدم أهلية تصميمنا الحالي للعمل مع النظام الشامل. |
| عرض إعلانات متعددة | ما إذا كان بإمكان المرء عرض إعلانات متعددة في مزاد واحد في إطار مُحدَث | هذا ممكن حاليًا عبر إعلانات المكوّنات (يجب عدم الخلط بينه ومزادات المكوّنات). لإجراء ذلك، يجب أن تكون جميع الإعلانات في مجموعة الاهتمامات نفسها. |
| مواصفات "شرائح الجمهور المحددة من قِبل البائع (SDA)" وFLEDGE | هل يمكن أن يصبح FLEDGE آلية لمنع المشترين من إنشاء ملفات شخصية من SDA في طلبات الإعلانات؟ | صُمِّم FLEDGE لتجنب تسرُّب البيانات غير ذي الصلة عندما يكون الناشر على دراية حاليًا بالمحتوى الذي يعرضه زوّاره وكان الاستهداف في الموقع الإلكتروني نفسه. إذا كان من المهم دعم الشراء على SDA ضمن جميع إجراءات الحماية المضمَّنة في FLEDGE، قد يتمثل أحد الحلول في تزويد البائع بتصنيفات SDA في المزاد على الجهاز، وتقنية الإعلان من جهة الشراء لإنشاء مجموعة اهتمامات خاصة بها وفقًا لمنطق عروض الأسعار "أريد شراء الجمهور س". |
| دعم العملات غير الدولار الأمريكي | إتاحة اختبار FLEDGE بعملات خارج الدولار الأمريكي | نحن نقدّر وسيلة الشرح هذه وأضفنا دعمًا للعملات الأخرى ضمن قائمة طلبات الميزات لدينا. نأمل أن يتم توفير هذه الميزة في وقت قريب جدًا. |
| دعم استهداف مجموعة اهتمامات سلبية | واجهة برمجة تطبيقات لدعم استهداف المواقع الإلكترونية العامة السلبية: يتم عرض الإعلانات فقط إذا كان المستخدم لا ينتمي إلى إحدى مجموعات المواقع الإلكترونية (IG). | مناقشة مستمرة، بما في ذلك بعض الخيارات المقترحة للدعم، في مشكلة github. |
| مقدمو خدمات بريد إلكتروني متعددة في FLEDGE | مخاطر تفضيل Google عند تنفيذ مزادات متعددة المستويات في FLEDGE | تمت إضافة دعم العديد من مقدّمي الخدمات المشتركين في FLEDGE لتوفير فرص تكافؤ عادلة ومنصفة. لقد تعهدت Google بموجب هذه الالتزامات بعدم تصميم اقتراحات "مبادرة حماية الخصوصية" أو تطويرها أو تنفيذها بطرق من شأنها تشويه المنافسة من خلال تفضيل منتجاتها وخدماتها الإعلانية. تأخذ Google هذا الأمر على محمل الجد، وهي منفتحة جدًا لمناقشة أي مخاوف قد تكون لدى الأطراف المعنية بشأن جوانب معينة من التكنولوجيا. لمزيد من المعلومات، وثق Chrome علنًا آلية مزاد المكوّنات هنا. |
قياس الإعلانات الرقمية
Attribution Reporting (وواجهات برمجة التطبيقات الأخرى)
| موضوع الملاحظات
(مرتبة حسب الأولوية) |
ملخّص الأسئلة والمخاوف | استجابة Chrome |
| تحديد المصدر بالاستناد إلى نقاط اتصال متعددة | الناشرون الذين يطلبون دعم إحالة نقاط الاتصال المتعددة | تتطلب الطرق الحالية لتحديد المصدر بالاستناد إلى نقاط الاتصال المتعددة الربط حاسمًا بين مرّات ظهور المستخدِم (وبالتالي هويته) على مستوى المواقع الإلكترونية المختلفة. نتيجةً لذلك، لا تتوافق هذه الوظيفة في شكلها الحالي مع أهداف "مبادرة حماية الخصوصية" التي تهدف إلى دعم حالات استخدام الإعلانات الرئيسية بدون تتبُّع إجراءات المستخدم على مواقع إلكترونية متعددة. في بعض الحالات، يمكن تقدير الأرصدة (على سبيل المثال، باستخدام أولويات مرجّحة وموزّعة بشكل عشوائي) بدون تتبُّع مستخدمين فرديين. |
| إنشاء الضوضاء | أسئلة تتعلق بمستويات التشويش في التقارير | تتيح تجربتنا الأولية للمطوّرين ضبط قيمة إبسيلون الخاصة بهم بحيث يمكنهم تجربة كيفية تغيّر التقارير استنادًا إلى مستوى التشويش. اعتبارًا من الآن، يمكن للمطوّرين اختيار قيمة إبسيلون تصل إلى epsilon=64. وقد أجرينا هذا تحديدًا لكي نسهّل على المطوّرين اختبار واجهات برمجة التطبيقات وتزويدنا بملاحظات حول قيم الإبسيلون المناسبة.
لقد أرسلنا أيضًا طلبًا علنيًا للحصول على هذه الملاحظات. |
| تنسيق الاختبارات | هل يمكن استخدام أداة الاختبار المحلية في الوقت الإضافي؟ | نعم، يمكن استخدام أداة الاختبار المحلية طوال مدة الوقت الإضافي. يمكن استخدام أداة الاختبار المحلي مع تقارير تصحيح الأخطاء ما دامت ملفات تعريف الارتباط التابعة لجهات خارجية متاحة. |
| هندسة الاستعلام | تفعيل طلبات البحث المجمّعة للمفاتيح | ونحن نوافق على أنّ هذا الإجراء يحسّن سهولة استخدام واجهات برمجة التطبيقات من خلال توفير القليل من التكلفة الواضحة للخصوصية أو عدم فرضها على الإطلاق. سوف نقدم اقتراحًا ونرى ما إذا كان هناك إجماع واسع على أن هذا الأمر يستحق دعمه. |
| بيانات أقل دقة للمواقع الإلكترونية الصغيرة | وقد تتلقى المواقع أو الحملات الأصغر حجمًا بيانات أقل دقة. | يدرك Chrome أنّ إجراءات حماية الخصوصية المستندة إلى التشويش يكون لها تأثير أكبر في شرائح البيانات الأصغر حجمًا. ومع ذلك، من الممكن أن تحل طرق مثل التجميع على فترات زمنية أطول هذه المشكلة؛ وليس من الواضح أيضًا ما إذا كانت الاستنتاجات المستندة إلى شرائح بيانات صغيرة جدًا (مثل عملية شراء واحدة أو عمليتَي شراء) ذات مغزى بالنسبة إلى المعلِنين. خلال مرحلة التجربة والتقييم، يشجِّع Chrome المختبِرين على الاستفادة من إمكانية تجربة مجموعة كبيرة من مَعلمات الخصوصية والضوضاء ليتمكنوا من تقديم ملاحظات أكثر تحديدًا حول هذه المشكلة. |
الحدّ من التتبُّع السري
تقليل عدد وكيل المستخدم
| موضوع الملاحظات
(مرتبة حسب الأولوية) |
ملخّص الأسئلة والمخاوف | استجابة Chrome |
| الحماية من برامج التتبُّع | تأثير UA-R في الحماية من برامج التتبُّع | نحن نقدّر هذه الملاحظات، ونعمل على جمع معلومات حول أساليب حماية برامج التتبُّع من أجل تحديد تصميماتنا المستقبلية. |
| تبعيات النشر | معالجة تبعيات نشر وكيل المستخدم المنظَّم (SUA) | لقد أطلقنا "المرحلة الرابعة"، وهي تُعرف أيضًا بتقليل إصدار الإصدار الثانوي إلى 100% من مستخدمي Chrome في الإصدارات 101 والإصدارات الأحدث. يمكنك الاطّلاع على التحديث هنا. |
تلميحات العميل الخاصة ببرنامج وكيل المستخدم
| موضوع الملاحظات
(مرتبة حسب الأولوية) |
ملخّص الأسئلة والمخاوف | استجابة Chrome |
| تعداد جميع التلميحات المتوافقة | الاهتمام بالحصول على طريقة آلية لمعرفة جميع التلميحات المتوافقة مع المتصفّح | نحن نقدّر هذه الملاحظات، ونعمل على تقييم طلب الميزة. يهمّنا معرفة ما إذا كانت هذه حالة استخدام شائعة. |
| مرونة عنوان UA-CH في مقابل عنوان وكيل المستخدم | تكون ميزة UA-CH صارمة بشكل مفرط عند مقارنتها بالمرونة التي يوفّرها عنوان وكيل المستخدم، كما هو محدَّد في RFC7231. | يرى Chrome الطبيعة الإلزامية لرؤوس UA-CH كتحسين مهم بشأن مرونة سلسلة Universal Analytics، سواء من منظور إمكانية التشغيل التفاعلي على جميع المتصفِّحات في النهاية وحماية خصوصية المستخدم (من خلال منع الإضافات العشوائية لمعرّفات عالية الإنتروبيا).
تبقى المشكلة مفتوحة إذا شارك مستخدمون آخرون هذه المشكلة أيضًا وأرادوا تقديم ملاحظات وآراء. |
| UA-CH: مخاوف متعلقة بمكافحة الاحتيال / إساءة الاستخدام | بعض الميزات التي قد يتم فقدانها من خلال بروتوكول UA-CH، وهي: أداة تتبُّع إعادة توجيه النقرات والنقرات الاحتيالية. | ينظر الفريق في هذه المشاكل المحتملة مع الجهات المعنيّة بمكافحة الاحتيال والقياس. |
| عروض أداء | هناك مخاوف بشأن وقت استجابة الحصول على التلميحات من خلال المعالجة الحرجة (عند تحميل الصفحة الأولى). | يعمل Chrome حاليًا على استكشاف طرق لتحسين الأداء. |
Gnatcatcher (قيد الإعداد)
| موضوع الملاحظات
(مرتبة حسب الأولوية) |
ملخّص الأسئلة والمخاوف | استجابة Chrome |
| مشاكل متعلقة بوقت الاستجابة | قد تؤثر إضافة المزيد من القفزات في وقت الاستجابة | ندرس استخدام خادم وكيل من قفزة واحدة ونستكشف طرقًا لتحقيق التوازن الصحيح بين خصوصية المستخدم ووقت الاستجابة. نحن نرحب بتلقّي الملاحظات، ويسرّنا تقديم مزيد من النقاش في منتديات W3C. |
| الحماية من الاحتيال وبرامج التتبُّع | التأثيرات على الحماية من الاحتيال وبرامج التتبُّع، بما في ذلك في البلدان الأقل تطورًا | إنّ الأمان هو شرط أساسي في الوقت الذي نبحث فيه عن طرق لتحسين خصوصية المستخدمين بطرق مجدية، مثل استخدام الخوادم الوكيلة لعناوين IP. يوفّر الوكيل المكوّن من قفزتين من خلال الشراكة مع شركات موثوق بها خصوصية يمكن التحقق من خصوصيتها للمستخدم. ونعمل أيضًا على تطوير أفكار لإشارات جديدة للمساعدة في منح ثقة المستخدمين. |
| الامتثال لقوانين الخصوصية المحلية | يؤدي إعداد تقارير البيانات الجغرافية على مستوى البلد إلى صعوبة الامتثال للأنظمة المحلية الأكثر دقة. | لقد نشرنا المبادئ المقترَحة للجميع، والتي تتضمّن مناهج محتملة تسمح للمواقع الإلكترونية بالحفاظ على امتثالها للمتطلبات المحلية. |
تعزيز حدود الخصوصية على مواقع إلكترونية متعددة
مجموعات نطاقات الطرف الأول
| موضوع الملاحظات
(مرتبة حسب الأولوية) |
ملخّص الأسئلة والمخاوف | استجابة Chrome |
| الفائدة لأنواع مختلفة من الأطراف المعنية | تأثير عدد اللقطات في الثانية بالنسبة إلى الناشرين الصغار مقابل الكبار | الهدف الأساسي من "مبادرة حماية الخصوصية" هو تحسين خصوصية المستخدمين عن طريق استبدال الممارسات الحالية بحلول لا تعتمد على آليات التتبُّع في جميع المواقع الإلكترونية. نريد أن تكون هذه الحلول مفيدة على نطاق واسع قدر الإمكان لأنواع وأحجام مختلفة من الأطراف المعنية. نرحب بالمساهمات المحددة والقابلة للتنفيذ حول كيفية تحسين هذه الحلول، ونتوقع أن تستمر في التطور من خلال المناقشة والاختبارات في المنتدى. |
| تحسين الخصوصية | قد يؤدّي عدد كبير جدًا من المواقع الإلكترونية في المجموعة نفسها إلى نتائج مشابهة لملفات تعريف الارتباط التابعة لجهات خارجية. | نحن نقدّر هذه الملاحظات ونقيّم ما إذا كانت الحدود الصحيحة أو ما يمكن أن تنطبق عليها، ونحاول أيضًا تزويد كل من المستخدمين والمطوّرين بمعالجة أو إشارات ليتمكّنوا من فهم حالات بلوغ هذا الحدّ. ليس لدينا اقتراح محدد حتى الآن لمشاركته، ولكن نأمل أن ننشره في وقت قريب. |
| اعتماد المنظومة المتكاملة للقطات في الثانية | جمع الدعم والمخاوف لمواصلة تطوير عدد اللقطات في الثانية خارج إطار سياسة الخصوصية | كنا نفضل أن يظل اقتراح مجموعات نطاقات الطرف الأول في PrivacyCG، ولكننا نتطلع إلى مواصلة متابعة الاقتراح في WICG. شجّعتنا أيضًا عبارات الدعم المتعددة على مواصلة المناقشة حول مجموعات نطاقات الطرف الأول وحالات الاستخدام المُراد معالجتها. تظل Google ملتزمة بإيجاد حلول تسمح للإنترنت بمواصلة النمو والازدهار بطريقة تحمي خصوصية المستخدمين وتحترمها. |
| إمكانية التشغيل التفاعلي للمتصفّح | التنفيذ بواسطة متصفحات أخرى | نحن ندرك أهمية إمكانية التشغيل التفاعلي للمتصفِّحات للمطوّرين، وسنواصل التعاون مع المتصفّحات الأخرى بهدف توحيد معايير FPS. |
| المتطلبات الشائعة لسياسة الخصوصية | لا يمكن تطبيق سياسة خصوصية مشتركة على مستوى جميع المنتجات ونطاقات السلطة التي يجب أن تكون جزءًا من المجموعة نفسها. | ما زال Chrome يُحدِّد متطلبات سياستنا، وسيضع هذه الملاحظات والآراء في الاعتبار. |
واجهة برمجة تطبيقات Fenced Frames
| موضوع الملاحظات
(مرتبة حسب الأولوية) |
ملخّص الأسئلة والمخاوف | استجابة Chrome |
| طلب المستندات | الاختلافات مع إطارات iframe في وضع الحماية | نحن نقدّر الملاحظات والمقترحات. هناك مناقشة حالية حول هذا الأمر على GitHub، حيث نأمل في الحصول على توضيح نهائي بشأن الطلب حتى نتمكن من تقييمه بالكامل. المناقشة العامة متاحة هنا. |
| الإمكانيات على مستوى واجهات برمجة التطبيقات | إتاحة إعداد تقارير الإحالة في الإطارات المضمّنة | نحن نطلب الحصول على ملاحظات حول اقتراح للسماح لواجهة Attribution Reporting API في "وضع الإعلانات غير الشفافة" للإطارات المضمّنة في أذونات الوصول تلقائيًا. ونحن نشجع المطورين الذين قد يجدون هذا قيمة لآرائهم في المناقشة. |
واجهة برمجة تطبيقات مساحة التخزين المشتركة
| موضوع الملاحظات
(مرتبة حسب الأولوية) |
ملخّص الأسئلة والمخاوف | استجابة Chrome |
| الحدود القصوى للبيانات | هل سيكون هناك قيود على كمية البيانات التي يمكن تخزينها لكل قسم؟ | نعم، ستكون هناك حدود. راجِع مشكلة في GitHub لمزيد من التفاصيل. سنحتاج إلى حصص تخزين. نقترح حاليًا أن يكون الحد الأقصى لحجم كل إدخال هو 4 كيلوبايت، وسيقتصر عدد الأحرف على كل من المفاتيح والقيم على 1024 حرفًا 16_t، والحد الأقصى لعدد الإدخالات لكل مصدر هو 10,000 إدخال، مع توفير آلية تمنع استخدام الإدخالات الإضافية عندما تكون سعة المصادر ممتلئة. نحن نسعى جاهدين للحصول على ملاحظات بشأن الحدود المعيّنة المقترحة هنا. |
| شفافية المستخدمين | شفافية المستخدم لمصادر البيانات مقابل استخدام البيانات | نحن نقدّر هذه الملاحظات والآراء، ونعتقد أنّ هذا النهج الواعد جدير بالاستكشاف. ونحن نقيّم على وجه الخصوص ما إذا كان من الممكن إجراء ذلك بطريقة توفّر شفافية كافية للمستخدمين. |
الشرائح
| موضوع الملاحظات
(مرتبة حسب الأولوية) |
ملخّص الأسئلة والمخاوف | استجابة Chrome |
| عوائق الاعتماد | هل يجب أن تكون CHIPS مرتبطة باسم المضيف؟ (متطلبات عدم استخدام النطاق) | سنزيل هذا الشرط من الوقت الإضافي بناءً على الملاحظات الواردة من المشاركين في البرنامج والتي تفيد بأنّ هذا المطلب أدّى إلى زيادة مستوى التعقيد ويشكّل عائقًا أمام استخدام "الشرائح المبسطة".
سنناقش هذه المتطلبات في "مجموعة منتدى الخصوصية" كجزء من عملية تطبيق المعايير هنا. |
| حالات استخدام الإعلانات من أجل الشرائح | هل يمكن استخدام الشرائح لحالات استخدام الإعلانات على موقع إلكتروني واحد؟ | إنّ تتبُّع المستخدم ضمن موقع إلكتروني واحد هو حالة استخدام مسموح بها. لقد عدّلنا مقالة المطوّر لتسليط الضوء على حالة الاستخدام هذه. |
| التضمينات التي تمت مصادقتها | هل يتم الاحتفاظ بحالة تسجيل الدخول باستخدام CHIPS؟ | لا يتم حاليًا الاحتفاظ بحالة "تسجيل الدخول"، ولكنّها ليست حالة الاستخدام المقصودة للشرائح. نحن على دراية بحالة استخدام التضمينات التي تمت مصادقتها ونعمل على استكشاف الحلول. |
| تنسيق الاختبارات | هل هناك أي إجراءات إضافية مطلوبة من المستخدم لاختبار عملية التقسيم؟ | ما دام الرمز المميّز للإضافة صالح ومتوفّرًا في عناوين الصفحات التي تمت زيارتها، يجب أن تكون الميزة متاحة للمستخدمين بدون الحاجة إلى أيّ إجراءات إضافية من جانب المستخدم. |
| توافُق المتصفح | الاهتمام بفهم كيفية تعامل المتصفحات الأخرى مع سمات ملفات تعريف الارتباط المُقسَّمة. | يستمر Chrome في العمل ضمن مجموعات المعايير العامة، مثل W3C لتحديد التصميمات وعمليات التنفيذ التي يمكن أن تعمل عبر المتصفحات. |
FedCM
| موضوع الملاحظات
(مرتبة حسب الأولوية) |
ملخّص الأسئلة والمخاوف | استجابة Chrome |
| متجهات الهجوم المحتمل | متجهات الهجوم المحتملة من خلال إضافة الرابط وهجمات التوقيت | ونعمل جاهدين على جمع الآراء العامة والتحقيق في الطرق المحتملة لمعالجة هذه المشكلة. |
| تجربة المستخدم للسماح بالعديد من موفِّري الهوية (idP) | لا يمكن عرض أكثر من موفّر هوية واحد في كل مرة. | نحن نؤمن بأهمية دعم العديد من موفِّري الهوية، ونعمل جاهدين على تطوير أساليب لدعم |
| التعبير | توخَّ الحذر من أنّه من الصعب تحديد جميع الفروقات الدقيقة التي يريد موفِّرو الهوية إبرازها للمستخدمين لأن المتصفّح يعرض جزءًا من عملية الهوية الموحدة. | يعمل Chrome على استكشاف إضافة تخصيصات للعلامة التجارية (مثل الشعارات والألوان) وتخصيص السلاسل (مثل "الوصول إلى هذه المقالة" بدلاً من "تسجيل الدخول باستخدام").
يدرك Chrome الحلّ المناسب بشأن هذه المشكلة وسيواصل العمل مع المنظومة المتكاملة لتحقيق أكبر قدر ممكن من الأهداف وإتاحة أكبر قدر ممكن من التعبير. |
| قابلية التطبيق وقابلية التشغيل التفاعلي | القلق من أن المتصفحات الأخرى لن تعتمد أو تطبق برنامج FedCM. | بالإضافة إلى ذلك، يعمل Chrome مع مورِّدي المتصفِّحات الآخرين للعثور على حلول شائعة للاتحاد في مجموعة FedID Community Group. |
| اقتراح بشأن إزالة متطلبات البيانات الشخصية خلال عملية الاشتراك | (1) تجربة مستخدم توضّح للمستخدم موفِّر الهوية الذي يختاره، بدون الإشارة إلى مشاركة عنوان بريده الإلكتروني وصورته واسمه على نحوٍ أكثر مراعاة للخصوصية
(2) يكون الاشتراك في حالات الاستخدام متفرقًا من حيث تجربة المستخدم واختيار المطالبات التي يقدّمها موفِّر الهوية. |
لقد اتفقنا على هذه الملاحظات وندرس كيفية تنفيذها بطريقة أكثر ودية ومناسبة للمستخدمين والخصوصية. |
| تفاعل المستخدم مع موفِّر الهوية | ضرورة التفاعل المباشر بين المستخدم وموفِّر الهوية في حال تجاوز حد الخطر | نعمل جاهدين على التحقق من هذه الملاحظات. |
تقسيم حالة الشبكة
| موضوع الملاحظات
(مرتبة حسب الأولوية) |
ملخّص الأسئلة والمخاوف | استجابة Chrome |
| عروض أداء | قد يؤدي تقسيم حالة الشبكة إلى زيادة الاتصالات التي تستهلك موارد كثيرة بشبكات توصيل المحتوى (CDN) | ما زلنا نتحقّق من خصائص أداء ميزة تقسيم حالة الشبكة، بما في ذلك قياس أنظمة المفاتيح المحتملة المختلفة. لم نتخذ بعد أي قرار بشأن المفاضلات بين الأداء والأمان والخصوصية، ونحتاج إلى جمع المزيد من البيانات. |
مكافحة المحتوى غير المرغوب فيه والاحتيال
واجهة برمجة تطبيقات Trust Tokens
| موضوع الملاحظات
(مرتبة حسب الأولوية) |
ملخّص الأسئلة والمخاوف | استجابة Chrome |
| ملاحظات حول اللوائح التنظيمية | مخاوف بشأن استثمار الوقت والموارد في الرموز المميّزة Trust Tokens بدون إشارة واضحة من الهيئات التنظيمية بشأن استمرارية استخدامها على المدى الطويل | يكمن هدفنا في تطوير تكنولوجيا مناسبة للمنظومة المتكاملة، بحيث تكون الملاحظات والآراء في المجال والجهات التنظيمية ضرورية لهذه العملية. وسنواصل التشاور مع الهيئات التنظيمية حول العالم أثناء تطويرنا "مبادرة حماية الخصوصية" وتقديم العروض للمطوّرين، بما في ذلك Trust Tokens. وكما هو الحال مع جميع التقنيات الجديدة، يجب على الشركات اتخاذ القرارات بناءً على تقييمها للمتطلبات التنظيمية. |
| توقيت الإطلاق | متى سيتم إطلاق Trust Tokens في "إحصاءات Google"؟ | ونقدّم تقديراتنا الحالية للتسليم في مخططنا الزمني المتاح للجميع على privacysandbox.com. وبعد أن نتّخذ قرارًا نهائيًا بشأن تاريخ التسليم إلى إحصاءات Google، سننشره بشكلٍ علني من خلال عمليات إصدار Chrome وسنعدِّل المخطط الزمني على الموقع الإلكتروني. |
| الرموز المميّزة Trust Tokens مقارنةً بالرموز المميّزة الأخرى | ما هو الدور الذي تؤديه الرموز المميّزة Trust Tokens في ضوء الرموز المميّزة الأخرى الخاضعة للتوحيد، مثل رموز الدخول الخاصة؟ | نحن نشارك في مناقشات حول توحيد معايير المشروع ونهدف إلى مواكبة الجهود الأخرى قدر الإمكان مع إتاحة حالات الاستخدام المختلفة التي توفّرها كل تكنولوجيا. على سبيل المثال، تعتمد الرموز المميّزة Trust Tokens ورموز الدخول الخاص على بروتوكول Privacy Pass. |
| الحدود القصوى للبيانات | يمكن أن تحدّ جهة إصدار البطاقة المعنيّة باسترداد الرمز المميّز لكل صفحة كحد أقصى من كل صفحة. | نبحث عن خيارات على المدى الطويل تتيح لنا السماح للشركات بتحصيل قيمة الرموز المميّزة بشكل آمن بدون المخاطرة بزيادة قصور المستخدم، ربما من خلال تقسيم الوصول إلى الرموز المميّزة. |
| قيود الوصول | يجب أن تكون المصادر التي تمت الموافقة عليها (والمُحيل الذي تم التحقّق منه/لم يتم انتحال هويته) متاحة لإثبات توفّر رمز مميّز وتحصيل قيمته. | إنّنا نستكشف طرقًا تتيح تحديد المستخدمين الذين يمكنهم الاطّلاع على الرموز المميّزة وتحصيل قيمتها. |
| خيارات الدعم الخاصة بالجهاز | تحدّ تبعيات وقت تشغيل JavaScript من الاستخدام على أجهزة معيّنة. هل يمكن توسيع نطاق دعم TT للعمل على أنواع أخرى من الأجهزة؟ | هذا أمر يمكننا أخذه في الاعتبار للتطوير المستقبلي، كما يسعدنا معرفة المزيد من الملاحظات عن المطوّرين في منتديات W3C. لدينا أيضًا مشكلة مفتوحة لمناقشة تحصيل قيمة الرمز المميّز الذي تم تشغيله من خلال عنوان HTTP ولدينا ملاحظات بشأنه. |
| حالات الاستخدام | حالات الاستخدام الصحيحة للرموز المميّزة Trust Tokens غير واضحة. عدم وضوح الاستخدامات المقصودة. | يكمن هدفنا في تسهيل الابتكار في مجال مكافحة الاحتيال، وفهم أنّه يجوز لكل شركة استخدام أساليب مملوكة لها مع رموز الثقة، ولذلك لم نفرض شروطًا على الاستخدامات المقصودة. ومع ذلك، من المرجَّح أن نوسّع نطاق مستنداتنا لتشمل المزيد من الأمثلة كنقاط بداية للشركاء الذين يفكّرون في إجراء التجارب أو اعتمادها. |
| تغطية الرموز المميّزة للاعتماد | من المفترض أن تؤدي إزالة سياسة ميزة "تحصيل قيمة الرمز المميّز للثقة" هذه إلى زيادة كبيرة في تغطية الرمز المميّز للثقة. | نأخذ ذلك في الاعتبار أثناء جمع الملاحظات من الفريق الإضافي ونتّخذ قرارات بشأن الخطوات التالية. |
| جهة الإصدار الموثوقة | لماذا يجب أن نثق بالمواقع الإلكترونية التي تصدر رموزًا مميزة للثقة؟ | ما مِن إرشادات تحدّد طريقة إصدار المحتوى، وبإمكان الجميع فعل ذلك. من المتوقَّع ألا يعمل الناشرون إلا مع جهات الإصدار التي يثقون بها. إضافةً إلى ذلك، فإنّ الجهات الشرعية الأخرى في منظومة الإعلانات المتكاملة ستخفّض في النهاية (أو ستتوقّف عن الشراء) الزيارات المرتبطة بجهات الإصدار المشبوهة أو غير المعروفة. |
| الخدمات المضمّنة التابعة لجهات خارجية | هل يمكن للخدمات المضمّنة التابعة لجهات خارجية تحصيل قيمة رموز الثقة المميزة و/أو طلبها؟ | نعم، يمكن لخدمة مضمّنة تابعة لجهة خارجية إصدار الرموز المميّزة الموثوق بها وتحصيل قيمتها. |
| المنظومة المتكاملة لجهات الإصدار | يمكن تحقيق فائدة أكبر إذا كان من الممكن مشاركة إشارات الثقة مع شركات أخرى | تم تصميم رموز Trust Tokens لتكون أساسية منخفضة المستوى، ويمكن استخدامها من خلال جهات إصدار البطاقات المتعاونة أو جهات تحصيل القيمة لمشاركة إشارات الثقة أو السمعة. |
| النفقات العامة للصيانة | تقع عمليات تنفيذ التشفير الأساسية في عمليات "الرمز المميز الموثوق به" في BoingSSL، وهي الجهة الوحيدة المسؤولة عن صيانة Google. كيف ستتم إدارة صيانة المكتبة؟ | تعتمد الرموز المميّزة Trust Tokens على عمليات التشفير الموحّدة (راجِع بروتوكول Privacy Pass) التي يمكن تنفيذها أيضًا في مكتبات أخرى. وننصح بأن يطلب المطوِّرون الدعم لهذه العمليات في المكتبات التي يختارونها أو تطويرها أو الحفاظ عليها. |
| النفقات العامة للصيانة | ليس من الواضح كم من الوقت سيكون هناك دعم لإصدارات البروتوكولات | ونعمل على تطوير وتوثيق المزيد من التفاصيل حول الأطر الزمنية المتوقعة للدعم بالنسبة إلى إصدارات البروتوكولات. |
| الحدود القصوى المسموح بها لجهات الإصدار | إذا كنت في أسفل السلسلة، قد لا تنحصر فرصتك في تنفيذ الرموز المميّزة Trust Tokens. | مع زيادة عدد المؤسسات التي تبدأ في استخدام رموز الثقة، أصبح بإمكاننا رؤية هذه الأنواع من العوامل الديناميكية للتوقيت بشكل متزايد، ونبحث عن الحلول الممكنة. كما وضّحنا سابقًا، نحن نبحث عن خيارات طويلة الأمد تتيح لنا السماح للشركات بتحصيل قيمة الرموز المميّزة بأمان بدون المخاطرة بمزيد من قصور المستخدم، ما يقلّل من أهمية تحديد مكانها في الصفحة أو طلب التحميل. |
حلول جديدة لمكافحة الاحتيال في مجال حضانة الأعمال
| موضوع الملاحظات
(مرتبة حسب الأولوية) |
ملخّص الأسئلة والمخاوف | استجابة Chrome |
| إشارات التحقّق من سلامة الجهاز | بشكل عام، توافقًا قويًا على تتبُّع إشارات سلامة الجهاز التي تصادق عليها المنصات ومتاحة على الويب. | سنواصل جمع الملاحظات ومتابعة الاقتراح من خلال التصميم العام والتكرار التحسيني. |
| إشارات التحقّق من سلامة الجهاز | أسئلة حول مقدار قصور المستخدم الذي يمكن نقله من خلال إشارات جديدة، وما إذا كانت بعض حالات الاستخدام (مثل تسجيل دخول المستخدم إلى المصرف الذي يتعامل معه) يمكن أن تبرر إشارات قصور أعلى. | ونحن نميل إلى تقديم إشارات عالية القيمة مع أقل قدر ممكن من قصور المستخدم للحفاظ على خصوصية المستخدم. |
| إشارات التحقّق من سلامة الجهاز | هل ستؤدي هذه الإشارة إلى تقييد وصول الأجهزة القديمة أو الأنظمة الأساسية مفتوحة المصدر/المعدَّلة؟ | وينبغي أن تراعي أي إشارات جديدة الوصول العالمي كمبدأ رئيسي في عملية التطور، وهذه أسئلة مهمة يجب معالجتها مسبقًا بينما نواصل بدء تطوير هذه الحلول. |
| إشارات التحقّق من سلامة الجهاز | كانت هناك بعض المخاوف إذا تسببت الإشارات الجديدة في جعل شركات الأمان ومكافحة الاحتيال تعتمد بشكل مفرط على المتصفِّح والأنظمة الأساسية.
|
يجب عرض أي إشارة جديدة على أنّها بيانات تكميلية وليست إشارة إلى "الثقة" من المتصفّح. نتوقع تمامًا أن تواصل شركات الأمان الاعتماد على البيانات والنماذج ومحركات القرارات الخاصة بها مع المصادقة على الأجهزة كإدخال إضافي. نأمل أن تساهم أي إشارة جديدة في تحسين جهود الرصد على مستوى المنظومة المتكاملة وجعل عمليات الاحتيال أكثر صعوبة. |
| إشارة العمر الخاصة بملفات تعريف الارتباط | مفهوم مثير للاهتمام ولكن من المحتمل أن يتطلب المزيد من التحقيق في حالات الاستخدام السارية. | استنادًا إلى مستويات الاهتمام، قد يضع Chrome مزيدًا من الأفكار بشأن هذا المفهوم ويحوّله إلى شرح للملاحظات المستقبلية بشأن المنظومة المتكاملة. |
| الخوادم الموثوق بها لمكافحة الاحتيال | مفهوم مثير للاهتمام ولكن من المحتمل أن يتطلب المزيد من التحقيق في حالات الاستخدام السارية. | استنادًا إلى مستويات الاهتمام، قد يضع Chrome مزيدًا من الأفكار بشأن هذا المفهوم ويحوّله إلى شرح للملاحظات المستقبلية بشأن المنظومة المتكاملة. |