تقرير ربع سنوي للربع الأول من العام 2023 يلخّص ملاحظات المنظومة المتكاملة التي تلقّيناها بشأن اقتراحات "مبادرة حماية الخصوصية" واستجابة Chrome.
في إطار التزاماتها تجاه "مبادرة حماية الخصوصية"، وافقت Google على تقديم تقارير ربع سنوية للجميع عن عملية تفاعل الأطراف المعنية ضمن اقتراحات "مبادرة حماية الخصوصية" (يُرجى الرجوع إلى الفقرتين 12 و17(ج)(2) من الالتزامات). يتم إنشاء تقارير ملخّص ملاحظات "مبادرة حماية الخصوصية" هذه من خلال تجميع الملاحظات التي يتلقاها Chrome من مصادر مختلفة كما هو مُدرَج في نظرة عامة على الملاحظات، بما في ذلك على سبيل المثال لا الحصر: مشاكل GitHub ونموذج الملاحظات المتاح على privacysandbox.com والاجتماعات مع الجهات المعنية في المجال ومنتديات معايير الويب. يرحب Chrome بالملاحظات الواردة من المنظومة المتكاملة ويستكشف بشكل نشط طرقًا لدمج ما تعلّمته في قرارات التصميم.
يتم ترتيب مواضيع الملاحظات والآراء حسب الانتشار حسب واجهة برمجة التطبيقات. ويتم ذلك من خلال تجميع مقدار الملاحظات التي تلقّاها فريق Chrome حول موضوع معيّن والتنظيم بترتيب تنازلي للكمية. تم تحديد موضوعات الملاحظات الشائعة من خلال مراجعة موضوعات المناقشة من الاجتماعات العامة (W3C وPatCG وIETF)، والملاحظات المباشرة، وGitHub، والأسئلة الشائعة التي تظهر من خلال الفرق الداخلية والنماذج العامة في Google.
وبشكل أكثر تحديدًا، تمت مراجعة محاضر اجتماعات اجتماعات الهيئات القياسية على الويب، وللملاحظات المباشرة، تمت مراجعة سجلات Google للاجتماعات الفردية مع الأطراف المعنية ورسائل البريد الإلكتروني التي تلقاها مهندسون فرديون والقائمة البريدية لواجهة برمجة التطبيقات ونموذج الملاحظات العامة. بعد ذلك، نسقت Google بين الفرق المشاركة في أنشطة التوعية المختلفة هذه لتحديد الانتشار النسبي للموضوعات التي تظهر فيما يتعلق بكل واجهة برمجة تطبيقات.
تم تطوير تفسيرات ردود Chrome على التعليقات استنادًا إلى الأسئلة الشائعة المنشورة، والردود الفعلية التي تم تقديمها على المشاكل التي طرحتها الأطراف المعنية، وتحديد الموضع خصيصًا لأغراض تمرين إعداد التقارير العلني هذا. مع التركيز الحالي على التطوير والاختبار، تلقّينا أسئلة وملاحظات خاصةً في ما يتعلّق بالمواضيع وFLEDGE وAttribution Reporting API.
إنّ التعليقات التي يتم تلقّيها بعد انتهاء الفترة المشمولة بالتقارير الحالية قد لا تكون قد استجابت Chrome بعين الاعتبار.
مسرد الاختصارات
- الشرائح
- ملفات تعريف الارتباط في الحالة المقسَّمة المنفصلة
- معالِج الإشارات الرقمية (DSP)
- منصّة الطلب
- FedCM
- إدارة بيانات الاعتماد الموحدة
- لقطات في الثانية
- مجموعات الطرف الأول
- مكتب الإعلانات التفاعلية (IAB)
- مكتب الإعلانات التفاعلية
- موفِّر الهوية (idP)
- موفّر الهوية
- مجموعة مهندسي شبكة الإنترنت (IETF)
- مجموعة مهندسي شبكة الإنترنت
- IP
- عنوان بروتوكول الإنترنت
- openRTB
- عروض الأسعار في الوقت الفعلي
- و إ
- تجربة المصدر
- PatCG
- مجموعة منتدى تكنولوجيا الإعلان الخاصة
- RP
- مجموعة الاعتماد
- نظام SSP
- منصة جانب المورّد
- TEE
- بيئة تنفيذ موثوقة
- UA
- سلسلة وكيل المستخدم
- UA-CH
- تلميحات إلى عميل وكيل المستخدم
- W3C
- اتحاد شبكة الويب العالمية
- قيد العمل على الإنترنت (WIPB)
- العمى النهائي لعناوين IP
ملاحظات عامة بدون تحديد واجهة برمجة التطبيقات أو التكنولوجيا
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| الاختبار والتجربة | مدى صلة الاختبار لإبلاغ تقييم CMA في حال عدم اكتمال واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" بحلول وقت بدء الاختبار | يتقدم تطوير واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" بوتيرة سريعة.
وهي متاحة بالفعل في Origin Trial للاختبار وستكون متاحة بشكل عام لجميع الزيارات هذا الصيف. بالإضافة إلى ذلك، وضّحنا المخططات الزمنية لبعض الميزات التي لن تتأثر قبل عام 2026 (مثل إعداد التقارير على مستوى الحدث في FLEDGE وعرض FLEDGE باستخدام إطارات iframe). نشجّع المنظومة المتكاملة على اختبار واجهات برمجة التطبيقات وتقديم ملاحظات بشأنها إلى "هيئة الاتصالات التفاعلية" (CMA) استنادًا إلى ما يتوقع المختبِرون الاعتماد عليه بعد الإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية. يمكن أن يساهم ذلك في تقييمهم للتأثير المحتمل للإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية. |
| عناصر تحكم المستخدم | إرشادات واضحة للمنظومة المتكاملة بشأن عناصر تحكُّم المستخدمين في واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" | ولا يمكننا تقديم مشورة قانونية حول عناصر التحكم التي يمكن أن تستخدمها المنظومة المتكاملة للمستخدم. في الوقت نفسه، يجرّب Chrome في الوقت نفسه عرض عناصر تحكّم محدّثة للمستخدمين في "مبادرة حماية الخصوصية" (المعروفة باسم "الخصوصية المحسّنة للإعلانات") على نسبة صغيرة جدًا من المستخدمين، في إطار جهودنا المتواصلة لتحسين تقنيات "مبادرة حماية الخصوصية". تتضمن التحديثات لغة وتخطيطات أوضح وأكثر فائدة. وبعد تقييم Chrome لهذه التحسينات وتحديد ما إذا كان سيتم توسيعها لتشمل فئة أكبر من السكان، يمكنهم مشاركة المزيد من المعلومات مع المنظومة المتكاملة. |
| تسرُّب البيانات | خطر تسرُّب بيانات الطرف الأول إلى Google والأطراف الأخرى في الحدث تم اختراق المتصفّح | يوضّح مفسّر FLEDGE أنّه لا تتم مشاركة بيانات إحدى تقنيات الإعلان إلا مع تكنولوجيا الإعلان نفسها (إما مع وظائفها الصغيرة أو الخوادم الموثوق بها) أو عند مشاركتها صراحةً من خلال تكنولوجيا الإعلان هذه (على سبيل المثال، يعرض مشترٍ
لبائع عنوان URL للإعلان الذي يريد عرضه). والاستثناء الوحيد لذلك هو أن يتم التحقق من إخفاء الهوية k من خلال خادم مركزي عالمي، وهو مجال نواصل تخصيص موارد كبيرة له. راجع الشرح المجهول الهوية K للحصول على عرض تفصيلي لكيفية تفكيرنا بشأن الخصوصية. بالإضافة إلى ذلك، نحن منفتحون على تقديم المزيد من التفاصيل حول كيفية عمل وسائل حماية تكنولوجيا الإعلان المستخدَمة في تصميم خادم إخفاء الهوية التصنيفية. |
| منتدى إضافي للمناقشة | طلب دعوة منتدى إضافي إلى W3C لمشاركة الملاحظات والآراء من اللاعبين حول المنظومة المتكاملة غير التقنية | إنّ نموذج الملاحظات والآراء بشأن "مبادرة حماية الخصوصية" مناسب
للتعليقات العامة والمحددة، سواء كانت فنية أو غير فنية. The Improving Web Advertising Business Group هي منتدى للمناقشة من خلال المكالمات الأسبوعية ومستودع GitHub. توضح صفحة الملاحظات ضمن "مبادرة حماية الخصوصية" على developer.chrome.com آليات أخرى لتقديم الملاحظات والمشاركة في المناقشات. يواصل Chrome أيضًا عقد أحداث مثل ساعات العمل العامة لتسهيل الأسئلة ومشاركة المحتوى. بالإضافة إلى ذلك، استضاف Chrome أو حضر أكثر من عشرات الفعاليات المتعلقة بالمجال خلال ربع العام الماضي. |
| توضيح الجدول الزمني | توضيح حول التاريخ الدقيق لتوفّر الميزة للجمهور العام في الربع الثالث من 2023 | وفقًا للمخطط الزمني المنشور على PrivacySandbox.com، سيتم استهداف مدى التوفّر للجمهور العام لبدء الطرح مع طرح الإصدار 115 من Chrome. |
| reCAPTCHA | تأثير واجهات برمجة تطبيقات "وضع الحماية" في حالة استخدام ميزة رصد المحتوى غير المرغوب فيه في reCATPCHA | نتلقّى ملاحظات من reCAPTCHA بشكل دوري للتأكّد من أنّ اقتراحات "مبادرة حماية الخصوصية" لا تؤثّر بشكل كبير في أمان الويب أو الاحتيال. فهم يطورون خطتهم الخاصة للتحضير والتعديل للإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية، لذا فإن هذا السؤال هو الأفضل لهم. |
| إضافات Chrome | هل سيتم تطبيق تقنيات "مبادرة حماية الخصوصية"، مثل إجراءات الحماية ضد التتبُّع السري (ACT) على إضافات Chrome؟ | لم نُرسل أي إشعارات بشأن ما إذا كان سيتم تطبيق إدارة إقليم العاصمة الأسترالية على إضافات Chrome. ومع ذلك، إذا كانت التقنية تجمع المعلومات خفيًا عن أحد المستخدمين، فإن ذلك لا يتوافق مع مبادئ الخصوصية لدينا. |
عرض محتوى وإعلانات ملائمة
المواضيع
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| مراجعة تصميم TAG | أصدر TAG مراجعة التصميم المبكر للموضوعات. | ما زلنا ملتزمين بـ Topics وقد شاركنا أحدث المعلومات بشأن التزامنا بالمواضيع في صفحة آخر التعديلات وفي هذه المشكلة. لقد ردّنا على مراجعتنا بشكل محدّد ونقطة بنقطة من مراجعة TAG وشاركنا رؤيتنا رفيعة المستوى هنا. ستبقى Topics API جزءًا من مجموعة واجهات برمجة التطبيقات التي يجب اختبارها في المنظومة المتكاملة للإعلانات خلال العام 2023، ونأمل أن نستفيد من ملاحظاتنا حول الاختبار التي نتلقّاها وتجربة التنفيذ التي نكتسبها في جهودنا المستقبلية الرامية إلى وضع معايير على جميع المتصفّحات في هذا المجال. نتطلّع إلى مواصلة التفاعل مع المنظومة المتكاملة حول كيفية تسهيل عملية انتقال محتملة حيث يمكن أن تكون Topics API معيارًا متفقًا عليه مع التوافق مع جميع المتصفحات. |
| التعامل مع المواضيع | دعم النهج المفتوح لدى Chrome لتطوير Topics API | نحن نقدّر هذه الآراء ونتطلّع إلى مواصلة العمل مع المجموعة المعنيّة بمجال الإعلان لتطوير Topics API تقدّم قيمة للمنظومة المتكاملة بشكل عام. |
| (تم الإبلاغ أيضًا في الربع الثالث من عام 2022) تصنيف المواضيع ليس دقيقًا بما فيه الكفاية |
لا يتضمن تصنيف المواضيع الواسع النطاق المواضيع الأكثر دقة، بما في ذلك المواضيع الخاصة بالمنطقة. | تعديل الربع الأول: إنّ التحسينات على التصنيف هي جهد متواصل، وفي الربع الثاني من العام سنعلن عن تصنيف معدَّل لـ Topics API. ولصياغة هذا التصنيف الجديد، عملنا عن كثب مع شركات على مستوى المنظومة المتكاملة. نحن نسعى جاهدين للحصول على ملاحظات بشأن التصنيف الذي قد يكون أكثر إفادة للمنظومة المتكاملة. عند تقييم ما إذا كان يجب زيادة عدد المواضيع أو تضمين مواضيع أكثر تفصيلاً، هناك بعض الاعتبارات، بما في ذلك 1) الآثار المحتملة على الخصوصية (قد يؤدي استخدام المزيد من المواضيع إلى زيادة مخاطر البصمات الرقمية) و2) القدرة على استرداد المواضيع التي تمت ملاحظتها سابقًا (كما هو الحال مع عدد أكبر من المواضيع، قد تقل فرصة ظهور الموضوع الذي تم اختياره لتكنولوجيا الإعلان في الماضي). |
| (تم الإبلاغ أيضًا في الربع الرابع من عام 2022) التأثير في إشارات الطرف الأول |
قد تكون إشارات المواضيع ذات قيمة عالية، ونتيجةً لذلك، تقلّل من قيمة الإشارات الأخرى التي تستنِد إلى اهتمامات الطرف الأول. | نحن نعتقد بأن الإعلانات التي تستهدف الاهتمامات تمثل حالة استخدام مهمة للويب، وقد تم تصميم Topics لدعم حالة الاستخدام هذه. نتفهّم أنّ بعض كبار الناشرين قلقون من أنّ Topics ستؤثر سلبًا على استراتيجيات بيانات الطرف الأول. نتطلّع إلى إجراء اختبار للمنظومة المتكاملة التي ستوفّر إحصاءات حول تأثير Topics بالنسبة إلى الناشرين. |
| حالات الاستخدام الخاصة بمواضيع غير مرتبطة بالإعلانات | استخدام المواضيع لأغراض أخرى غير عرض الإعلانات التي تستهدف الاهتمامات | تم تصميم Topics لتناول حالة استخدام الإعلانات التي تستهدف الاهتمامات، والتي نعتقد أنها حالة استخدام بالغة الأهمية لشبكة الويب المجانية والمفتوحة. نبحث حاليًا عن ملاحظات بشأن حالات استخدام أخرى ونقيّمها. |
| حالة الموافقة التلقائية | تأثير التشريعات الإقليمية في الإعدادات التلقائية للموافقة في "المواضيع" | ليس من اختصاصنا التعليق على الآراء القانونية. |
| (تم الإبلاغ أيضًا في الربع الثالث من عام 2022) المواقع الإلكترونية المصنّفة بشكل خاطئ |
استهداف الإعلانات عند إساءة تصنيف المواضيع في موقع إلكتروني معيّن | تعديل في الربع الأول: في الربع الثاني، سنعلن عن أداة تصنيف معدَّلة لواجهة Topics API ونتطلّع إلى التفاعل معها. استجابةً للملاحظات الحالية، يتم تصنيف المواقع الإلكترونية من خلال مزيج من قائمة الإلغاء التي ينظّمها المراجعون، والتي تتضمّن المواقع الإلكترونية الأكثر رواجًا، ونموذج تعلُّم الآلة على الجهاز. يواصل Chrome تقييم خيارات المواقع الإلكترونية للمساهمة في تصنيف المواضيع. ويجب الالتفات إلى أي تحسينات في الأداة مقابل مخاطر الخصوصية وإساءة الاستخدام. على سبيل المثال، تشمل بعض المخاطر ما يلي: المواقع الإلكترونية التي تستخدم التصنيف الذاتي كطريقة لترميز المعاني المختلفة (والتي قد تكون حساسة) إلى مواضيع، أو المواقع الإلكترونية التي تقدّم وصفًا مضللاً لمواضيعها لتحقيق مكاسب مالية، أو المواقع الإلكترونية التي تهاجم المواضيع بهدف التقليل من فائدتها بالنسبة إلى الآخرين (مثل إرسال محتوى غير مرغوب فيه إلى مواضيع لا معنى لها). يمكن للجميع فحص هذه المكوّنات باستخدام الأدوات المتاحة عبر chrome://topics-internals أو ملف Colab هذا. من خلال إجراء الاختبارات، نتوقّع أن يتحسّن التصنيف بمرور الوقت، ونرحب بملاحظاتك بشأن أمثلة على المواقع الإلكترونية التي قد تم تصنيفها بشكل خاطئ. |
| مصنِّف المواضيع | طلب عرض معلومات إضافية توضح أسباب إرجاع "لا مواضيع" إلى المتصل لأغراض تصحيح الأخطاء | نحن ندرك أنّ أدوات تصحيح الأخطاء مفيدة لمطوّري البرامج أثناء عملهم على دمج Topics API في أنظمتهم. ومع ذلك، من خلال عرض معلومات إضافية (مثل سبب عدم عرض Topics)، قد نشارك بدون قصد معلومات تتيح للجهات المعنيّة الكشف عن تفاصيل إضافية (على سبيل المثال، إذا كان المستخدم في وضع التصفّح المتخفي، أو أوقف واجهة برمجة التطبيقات وما إلى ذلك) غير المقصود منها، ما يسبّب إلحاق الضرر بخصوصية المستخدم. نحن لا نخطط لتوفير أدوات تصحيح أخطاء إضافية في الوقت الحالي، إلا أنّنا منفتحون لتلقي ملاحظات حول الأدوات التي ستكون ذات قيمة. |
| استرجاع المعلومات الخاصة (PIR) | طلب استخدام Topics API "استرداد المعلومات الخاصة" | لقد سبق أن أجرينا تحقيقًا باستخدام PIR وشاركنا المقايضات هنا. |
| مصدر عرض السعر | هل سيتم تمثيل المواضيع بشكلٍ مختلف عن شرائح الجمهور التي يحدّدها البائع في بث عرض الأسعار؟ | Topics API هي اقتراح "مبادرة حماية الخصوصية" الذي طوّره Chrome، ويختلف هذا الاقتراح عن اقتراح شرائح الجمهور المحدّدة من البائع من مختبر IAB التقني. نتوقع أن يتم تمثيل الاثنين بشكل واضح في تدفق عروض الأسعار. تعرّف على كيفية تمثيل المواضيع في طلبات عروض أسعار OpenRTB. |
Protected Audience API (المعروفة سابقًا باسم FLEDGE)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| مدى توفُّر ميزة FLEDGE | توضيح حول المخططات الزمنية لاختبار ميزات FLEDGE وتطبيقها، مثل فرض Fenced Frame، وإخفاء الهوية K-Anonymity، وغير ذلك. | لقد نشرنا مشاركة مدوّنة حول ميزات FLEDGE مختلفة ذات نطاق خاص ومتى ستصبح متوفّرة. نرحّب بملاحظات إضافية بشأن الإعلان ونحن نواصل تطوير FLEDGE. |
| القيود المفروضة على عرض المنتجات | طلب تخفيف قيود الإعلانات المؤلفة من أجزاء متعددة للإطارات المضمّنة في FLEDGE | كما أعلنّا في شباط (فبراير)، سيظل استخدام Fenced Frames اختياريًا حتى عام 2026 على الأقل، وستعتمد إطارات iframe على سلوك إطارات iframe. ونحن نرحب بمزيد من النقاش حول هذا الموضوع. |
| مشاكل مرتبطة بقابلية التوسّع | أداء FLEDGE كمقاييس استخدام | ونتابع بشكل نشط الملاحظات والآراء لفهم المزيد من السياق كي نتمكّن من اقتراح حلول قابلة للتنفيذ. تضمّنت الخطوة الأولى تقسيم الملاحظات إلى فئتَين، وهو ما فعلناه:
|
| (تم الإبلاغ أيضًا في الربع الثالث من عام 2022) مستوى رؤية منطق عروض الأسعار |
القلق بشأن الكشف عن منطق عرض بيانات DSP في JavaScript | تعديل في الربع الأول: لقد ناقشنا عرضًا من شأنه أن يحدّ من قدرة الخصوم على طلب البيانات من الخادم بطريقة استكشافية (فرض التصفّح الإجباري)، ونرحّب من اللاعبين بالمنظومة المتكاملة بمشاركة ملاحظاتهم أو دعمهم لاقتراح هذا الاقتراح. |
| صعوبات الاختبار | قدرة مقدمي خدمات البريد الإلكتروني الأصغر حجمًا على اختبار FLEDGE بشكل صحيح، وتخفيف المخاطرة التي لا يهتم بها المعلنون إلا عند اختبار أنظمة وسيط عرض الطلب (DSP) الأكبر حجمًا | نحن ملتزمون بالعمل مع أنظمة وسيط عرض الطلب (DSP) الصغيرة، ونشجّع بشدة على توسيع نطاق الاختبار بين أنظمة وسيط عرض الطلب (DSP) والمعلِنين من جميع الأحجام مع انتقال FLEDGE إلى التوفّر للجمهور العام. يهمّنا معرفة أفضل طريقة يمكننا من خلالها مساعدتهم في اختبار FLEDGE مع الآخرين في المنظومة المتكاملة، ونرحب بالأفكار والجهود المبذولة في المجال، ونترحيب بالأفكار والجهود المبذولة في المجال لتحفيز المعلِنين على الاختبار مع أنظمة وسيط عرض الطلب (DSP) الأصغر حجمًا. |
| تجديد النشاط التسويقي الديناميكي | هل سيظل تجديد النشاط التسويقي الديناميكي ممكنًا باستخدام FLEDGE بعد الإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية؟ | وندرس الرد على هذا السؤال ونرحب بالجهات الفاعلة في المنظومة المتكاملة لمشاركة إحصاءات إضافية عن الطريقة التي تنوي بها استخدام تجديد النشاط التسويقي الديناميكي. |
| احتيال/إساءة | كيف يمكن للمنظومة المتكاملة أن تحد من المخاطر وأن تمنع الجهات المسيئة أو المشترين من تقديم أنفسهم كجمهور مرغوب فيه؟ | ونتطلّع إلى التفاعل مع الجهات الفاعلة في المنظومة المتكاملة بشكلٍ أكبر بشأن الاحتيال وإساءة الاستخدام، ونرحّب بمزيد من الملاحظات حول هذا الموضوع. |
| الإعدادات المفضّلة لدى المستخدم | عملية حفظ إعدادات المستخدِم المفضّلة واستخدامها في اختيار الإعلانات | بالنسبة إلى إعلانات محدّدة، تكون تقنية الإعلان ذات الصلة هي أفضل طرف لتقديم عناصر تحكّم في تصميمات الإعلانات التي يتم عرضها أو كيفية اختيارها. |
| اقتراح الاختبار الكمّي | لكي يكون الاختبار الكمي عادلاً، هل يجب إجراء الاختبار على الزيارات بدون ملفات تعريف الارتباط التابعة لجهات خارجية أو من خلال مقدِّمي خدمة البريد الإلكتروني (SSP) الذين يستخدمون FLEDGE فقط؟ كيف يمكن تجنُّب خلط الإشارات من ملفات تعريف الارتباط التابعة لجهة خارجية؟ | نحن نقدّر هذه الملاحظات ونعمل مع هيئة CMA لتصميم تجارب ستقدّم صورة موثوقة لتأثير إيقاف ملفّات تعريف الارتباط التابعة لجهات خارجية وتطبيق اقتراحات "مبادرة حماية الخصوصية" في المنظومة المتكاملة. ونحن نشجّع على مشاركة الملاحظات الإضافية حول اقتراح الاختبار الكمّي من "هيئة السوق الرئيسية" (CMA) مباشرةً مع هيئة CMA. |
| مستندات أوضح | طلب مستندات أكثر وضوحًا حول ضبط المزاد | نأمل أن ننشر مشاركة مدونة تتضمن نظرة عامة إضافية حول إعداد تقارير مزادات FLEDGE خلال الأسابيع المقبلة. |
| موازاة | هل ستتيح خدمة "عروض الأسعار والمزادات" (B&A) إمكانية المزامنة؟ | يمكن لتقنية الإعلان التي تستخدم خوادم عروض الأسعار / المزادات تشغيل خوادم متعددة يمكنها عرض النتائج بالتوازي. |
| الحد من إساءة الاستخدام | هل سيكون خادم FLEDGE الذي يستخدم الرموز المميّزة للحالة الخاصة كافيًا لضمان خصوصية المستخدم؟ | يكون الدافع للمجهولية التصنيفية أقل تركيزًا على الاستهداف الدقيق وأكثر تركيزًا على وجود بعض الدعم خلال المرحلة المؤقتة حيث يسمح FLEDGE بإعداد التقارير على مستوى الحدث. وقد شاركنا المزيد من الأفكار ونرحّب بالملاحظات الإضافية. |
| تعارض في وحدة ES | طلب إزالة generateBid كدالة عمومية نظرًا لأنها تتعارض مع
وحدة ES |
نعمل حاليًا على مناقشة هذا الطلب ونرحب بملاحظات إضافية. |
| مزاد المكوّنات | مطالبة الناشرين بمزيد من التحكم في تصميمات المزادات | خطة عروض الأسعار والمزاد لدعم مزاد المكونات، تمامًا مثل Chrome على الجهاز فقط. |
| الجداول الزمنية لـ B&A | وضوح الجدول الزمني لتكنولوجيا الإعلان المهتمة باختبار خوادم B&A | لقد عدّلنا للتوّ تفسير B&A وعدّلنا قسم "المخطّط الزمني" لتضمين تعريفات واضحة للمخططات الزمنية لمراحل مختلفة من اختبار Chrome-B&A، بعد توافقه مع اتفاقية CMA. |
| مخطط التحكم في المهلة | تحسين مخطط التحكم في المهلة المتاح حاليًا لـ FLEDGE | هذا اقتراح مثير للاهتمام. سنضيف هذا إلى قائمة الاقتراحات للدراسة ونبلغ عن تطوراتنا. |
| أحداث عروض أسعار تصميمات الإعلانات | القدرة على مراجعة عرض السعر الفائز وفلترته، استنادًا إلى | هذا اقتراح مثير للاهتمام. سنضيف هذا إلى قائمة الاقتراحات للدراسة ونبلغ عن تطوراتنا. |
reportWin |
اقتراح لتوفير معلومات إضافية عن عرض السعر الذي يحقق أعلى نتيجة من مالك مجموعة اهتمام مختلف عن الفائز في دالة reportWin |
هذا اقتراح مثير للاهتمام. وسننظر في إمكانية إضافة المزيد من الإشارات في التقارير المجمَّعة ونرحب بملاحظات إضافية هنا. |
| أنواع الأحداث | يؤدي توحيد أنواع الأحداث على مستوى واجهات برمجة تطبيقات القياس عند الدمج مع FLEDGE | هذا اقتراح مثير للاهتمام. سنضيف هذا إلى قائمة الاقتراحات للدراسة ونبلغ عن تطوراتنا. يتطلّب ذلك التنسيق مع جهودنا الأوسع نطاقًا في هذا المجال، لأنّ ذلك سيؤثر في واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" الأخرى غير FLEDGE. نرحب بالملاحظات الإضافية هنا. |
| حلول طويلة المدى لإعداد التقارير على مستوى الحدث | الاهتمام بإبقاء بيانات معيّنة مثل highestScoringOtherBid متاحة
حتى بعد الإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية |
كما شاركنا في مشاركة مدونة شباط (فبراير)، سيكون بالإمكان إعداد تقارير الفوز بالمزاد على مستوى الفعالية حتى "عام 2026 على الأقلّ". ليس لدينا حاليًا المزيد من التفاصيل، ولكننا نرحّب بالملاحظات الإضافية التي توضّح أهمية إبقاء بيانات معيّنة متاحة بعد إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا. |
| حد المجموعات ذات الاهتمامات المشتركة | ما هو الحدّ الأقصى لعدد المجموعات ذات الاهتمامات المشتركة التي يمكن للمصدر إضافة متصفّح واحد إليها؟ | يسمح Chrome بما يصل إلى 1000 مجموعة اهتمام لكل مالك وما يصل إلى 1000 مالك لمجموعة الاهتمامات. من المفترض أن تكون هذه الطرق واقية من الأذى، وليس أن يتم ضربها أثناء التشغيل المنتظم. |
| الإشارات على مستوى الحدث | دعم اقتراح يتضمّن إشارات على مستوى الحدث للسمتَين generateBid وreportWin، والتي يمكن استخدامها في تدريب تعلُّم الآلة |
لقد شاركنا قرارنا بشأن الإشارات المصمّمة من المتصفِّح والإشارات المحدّدة لتكنولوجيا الإعلان هنا ونرحب بملاحظات إضافية. |
| النص البرمجي لعرض الأسعار | أدرِج رقم تعريف المستخدم في عنوان URL في النص البرمجي لعروض الأسعار. | لن يكون ذلك ممكنًا لأنّ FLEDGE يتطلّب شرطًا إضافيًا وهو أنّ صف مالك مجموعة الاهتمامات، وعنوان URL للنص البرمجي لعروض الأسعار، وتصميم الإعلان المعروض، يجب أن يكون مجهولاً حتى يتم عرض الإعلان. |
| فرض الخوارزمية التصنيفية | هل يتم فرض عدم الهوية التصنيفية على زوج (componentAd، الحجم)؟ | نعم، سيكون. يُرجى الاطّلاع على مقالة turtledove/issues/312. |
| متطلبات خدمات عروض الأسعار والمزادات | كيف تدعم خدمات B&A المشاركين الذين يندمجون مع FLEDGE على الجهاز وغيرها من خدمات B&A؟ | ما زلنا نعمل على وضع اللمسات الأخيرة على التصميم ونرحّب بتلقّي ملاحظات إضافية هنا. |
| تحديد المصدر بعد المشاهدة | هل ستتوفّر ميزة تحديد المصدر بعد المشاهدة؟ | ليس لدينا حاليًا أي نوع من التعريف العادي لإمكانية العرض ونعتمد على تصميم الإعلان نفسه لتمييز حدث مشاهدة. يُرجى الاطّلاع على مقالة turtledove/issues/452. |
| استهداف الجمهور المشابه | هل يمكن أن تتيح "مبادرة حماية الخصوصية" "الاستهداف المشابه"؟ | نحن نناقش حالة الاستخدام هنا ونرحب بالمدخلات الإضافية. |
| واجهة برمجة التطبيقات للمراقبة في الوقت الفعلي | اقتراح لمنهج رصد FLEDGE في الوقت الفعلي | ونحن نناقش الاقتراح ونرحّب بالمساهمات الإضافية هنا. |
| إعداد تقارير FLEDGE | يجب إعداد الترميزَين reportWin وreportResult بترتيب عشوائي لمنع الإبلاغ عن المحتوى بشكل زائد أو أقل. |
يجب تنفيذ الحقل "reportResult()" أولاً بواسطة البائع قبل
reportWin() من قِبل المشتري، بحيث يمكن تضمين إشارات البائع من reportResult()
في reportWin(). يمكنك الرجوع إلى الشرح للاطّلاع على مزيد من المعلومات. |
| خوادم قيمة المفاتيح المخصّصة (K/V) | هل سيتم توفير خوادم K/V مخصّصة في المستقبل؟ | نناقش السؤال هنا ونرحب بأي آراء إضافية. |
| مزاد من المستوى الأعلى | هل يجب أن يكون خادم الإعلانات لتشغيل آليات المزادات ذات المستوى الأعلى؟ | لا تحدّد FLEDGE API الجهة التي يجب أن تسميها، وليست هناك أي متطلبات بهذا المعنى في تصميم FLEDGE. يمكن لأي شخص إجراء مزاد FLEDGE (بما في ذلك المزادات متعددة البائعين). كما هو مذكور في تقرير الربع الأخير من عام 2022، يسمح FLEDGE لكل ناشر باختيار بنية المزاد، بما في ذلك اختيار البائعين من المستوى الأعلى والمكوّنات. |
| نطاق واجهة برمجة التطبيقات | هل يعمل FLEDGE مع بيانات الطرف الأول؟ | سننشر محتوى في الربع الثاني من عام 2023 لتوضيح أنّ بيانات الطرف الأول يمكن استخدامها مع FLEDGE من خلال 1) استخدامها كمنطق لتحديد العضوية في مجموعة الاهتمامات و2) لتقديم خلاصة كإشارات عروض أسعار للمستخدمين واستخدامها في إنشاء منطقتي عروض الأسعار لاحقًا. |
| مجموعات الاهتمامات عبر النطاقات | إمكانية إنشاء مجموعات الاهتمامات عبر النطاقات | ويمكن استخدام أيّ معلومات متوفّرة وقت إضافة متصفّح إلى مجموعة اهتمام لإعلام هذا الجمهور. عند الإيقاف التدريجي لملفات تعريف الارتباط التابعة لجهات خارجية، سيكون مدى توفُّر البيانات من مواقع إلكترونية مختلفة للإبلاغ عن إنشاء مجموعات الاهتمامات. |
| منطق عروض الأسعار من جهة العميل | نقل منطق عرض الأسعار الحالي من جهة الخادم إلى جهة العميل | يهمّنا معرفة المزيد من المعلومات عن المجالات التي تمثّل تحديًا أو التي تفتقر حاليًا إلى عملية النقل، ونرحب بأي ملاحظات أو إحصاءات إضافية. |
| قيم خادم K/V | هل يلزم أن تكون قيم خادم K/V من نوع السلسلة؟ | يجب أن تكون القيمة سلسلة، ولكن يمكنها تخزين الكائنات في تنسيق JSON أو مخزن مؤقت للبروتوكول وتسلسلها في سلسلة. |
| القائمة المحظورة للمعلنين | ما هي الإشارات المناسبة لتقديم مشترٍ إلى قائمة حظر المعلنين؟ | المكان المناسب إما في auctionSignals أو في perBuyerSignals. |
| وحدة عروض الأسعار | دعم وحدات عروض الأسعار المختلفة مثل التكلفة لكل تثبيت والتكلفة لكل ألف ظهور | نريد معرفة المزيد حول سبب الحاجة إلى ذلك نظرًا للتصميم الحالي، ويسعدنا سماع ملاحظات إضافية. |
| منطق المزاد | هل يحدّد المتصفح أو خادم الإعلانات الفائز في مزاد؟ | يتم تنفيذ اختيار كل الفائز داخل وضع الحماية، ويتم اتخاذ جميع القرارات من خلال رمز البائع. يوفر المتصفح ببساطة بيئة خاصة ومغلقة يتم فيها تشغيل رمز المشتري والبائع. |
| سياسة الأذونات | هل سيستمر تنفيذ سياسة أذونات FLEDGE الحالية بعد انتهاء فترة التجربة والتقييم؟ | بالنسبة إلى مرحلة التجربة والتقييم، إنّ القوائم المسموح بها التلقائية الحالية لكلتا الميزتَين هي مؤقتة وسيتم تغييرها. ويهمّنا معرفة المدة التي ستحتاجها تقنيات الإعلان للاستعداد للتغيير قبل أن نبدأ في فرضه. |
| قيد حجم الإشارة | يتم دمج طلبات إشارات عروض الأسعار الموثوقة على مستوى مجموعات اهتمامات متعددة باستخدام trustedBiddingSignalsUrl نفسه، ويشكّل الحدّ الأقصى للحجم البالغ 2 ميغابايت قيدًا. |
ويتوفر القيد على المتصلين على الجهاز لمنع تحميل الموارد المربكة على الجهاز. سيكون لدى المتصلين من خادم B&A قيد استرخاء أكثر. |
| إشارات إعداد التقارير | أضِف إشارة إضافية، وهي أخطاء النص البرمجي، للسماح باسترداد
عدد الأخطاء من جانب العميل لكل مالك في مجموعة الاهتمامات وحسب computeBid أو reportWin / reportResult. |
ننظر في المخاوف المحتملة بشأن الخصوصية في هذا الاقتراح ونرحّب بالجهات الفاعلة في المنظومة المتكاملة لمشاركة رؤى إضافية حول سبب الحاجة إليها. |
| حجم نافذة K-Anon | عليك زيادة حجم نافذة K-Anon من الحد الحالي البالغ 7 أيام. | هذا الأمر قيد المراجعة وننتظر حاليًا (ونرحّب) بالحصول على معلومات إضافية من المنظومة المتكاملة. |
| أداء الجهاز | كيف يتعامل FLEDGE مع أداء الجهاز إذا كان المستخدم في عدد كبير من مجموعات الاهتمامات؟ | يوفّر FLEDGE العديد من خيارات المُهلة، وتحديد الأولويات، والحدّ من الخيارات على مستوى مقدِّمي خدمة البريد الإلكتروني (SSP) ومقدّمي خدمة DSP، الذين يمنحون تقنيات الإعلانات تحكّمًا دقيقًا في الحالات التي قد يكون فيها أداء الجهاز أحد الأسباب التي تؤدي إلى الحدّ من المشاركة في المزاد عندما يكون الجهاز ضمن عدد كبير من مجموعات الاهتمامات. |
| اختبار خدمات الحسابات والإجابات (B&A) | مطالبة الجهات الفاعلة في المنظومة المتكاملة باستخدام خادمها أثناء مرحلة الاختبار لإتاحة المزيد من السجلات لتصحيح الأخطاء | تتيح "B&A" للمستخدمين تشغيل الخوادم وتوسيع نطاقها من مزوّدي السحابة المعتمَدين. للحفاظ على خصوصية المستخدم، نفرض تنفيذًا في بيئة تنفيذ موثوقة (TEE). سنصدر قريبًا شرحًا حول تصحيح الأخطاء في بيئة B&A TEE وسنطوّر ميزات لدعم ذلك. نطلب ملاحظات إضافية حول هذا الموضوع. |
| المتطلبات التنظيمية | هل سيعمل FLEDGE مع مقدّمي الخدمات السحابية في بلدان مختلفة لدعم الامتثال للمتطلبات التنظيمية المحلية؟ | نحن نرحب دائمًا باقتراحات مقدّمي الخدمات السحابية الآخرين، ولكننا نخطط حاليًا على الأقل لإتاحة استخدام GCP وAWS عند فرض إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا. يمكنك الرجوع إلى هذا الشرح للاطّلاع على مزيد من المعلومات. |
قياس الإعلانات الرقمية
Attribution Reporting (وواجهات برمجة التطبيقات الأخرى)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| تحليل بيانات تأثير الضوضاء | إرشادات حول كيفية إجراء تحليل البيانات حول تأثير التشويش | لقد شاركنا مستندات إضافية تتعلّق بقرارات التصميم والتشويش التي يمكن استخدامها لتغيير تأثير التشويش في بيانات تقنية الإعلان. يتوفّر أيضًا دليل أكثر تفصيلاً. |
| إعداد تقارير فارغة | وضوح بشأن تنفيذ التقارير الفارغة | نعمل حاليًا على إعداد اقتراح لتنفيذ التقارير الفارغة وسيكون لدينا المزيد من التفاصيل لمشاركتها قريبًا. سيتيح لنا تنفيذ التقارير الفارغة تقليل حالات التأخير في الإبلاغ بدون المساس بالخصوصية. |
| مستوى الضوضاء | ضبط مستوى التشويش استنادًا إلى طول فترة الإحالة | نحن نرحّب بهذا الاقتراح ونسعى إلى إضافته إلى المواصفات. نرحّب بالملاحظات الإضافية هنا. |
| حجم بيانات التشغيل | لماذا يقتصر حجم بيانات المشغِّل على 3 بت؟ | يقتصر الحجم على 3 بت و8 قيم مختلفة لضمان أنّ مقدار المعلومات المتوفرة على عدة مواقع إلكترونية أو السياق عن المستخدم محدود. نرحّب بجهات الفاعلة في المنظومة المتكاملة لإرسال ملاحظات بشأن ما إذا كانت المَعلمات الحالية لإعداد التقارير على مستوى الحدث منطقية. |
| عوامل تشغيل إعداد التقارير على مستوى الحدث | السماح بتحديد الأولويات ضمن مفتاح إزالة التكرار | نعمل على استكشاف حلول لهذه المشكلة ونرحب بالمساهمات الإضافية. |
| دعم تصحيح الأخطاء | توضيح بشأن تصحيح الأخطاء بعد الإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية | نريد دعم تصحيح الأخطاء بعد الإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية وندرس الخيارات المتاحة. نسعى إلى تلقّي ملاحظات وأفكار إضافية. |
| بدائل الإحالات الناجحة الناتجة عن النقر | اطلب الحصول على مزيد من الإرشادات حول البدائل المتاحة للإحالات الناجحة الناتجة عن النقر | ونحن نشجّع المنظومة المتكاملة على استخدام Attribution Reporting API كنظام خاص ودائم لحالات الاستخدام السارية لقياس الإحالات الناجحة. تتوفّر بدائل أخرى وسيتعين على مزوّدي تقنية الإعلان تحديد الحل المناسب استنادًا إلى احتياجات الخصوصية والخدمات المطلوبة. |
| حالات استخدام الفوترة | توضيح حول مدى دعم ميزة "تقارير الإحالة" لحالات استخدام الفوترة المستندة إلى الإحالات الناجحة | نحن نعمل على نشر المحتوى علنًا لتوضيح نطاق Attribution Reporting API للفوترة. لم يتم تحديد Attribution Reporting API في البداية بطريقة تتوافق مباشرةً مع فوترة تكلفة الإجراء، بل إنها تتيح فوترة تكلفة النقرة والتكلفة لكل ألف ظهور، أي بنية الفوترة التي يطبّقها غالبية تكنولوجيا الإعلان. يمكن أن نوفّر هذه الميزة في المستقبل إذا كانت هناك ملاحظات إضافية بشأن المنظومة المتكاملة. |
| دعم حالات الاستخدام | مستندات حالات الاستخدام الخاصة بواجهة برمجة التطبيقات Measurement API | نعمل على توضيح المستندات الخاصة بجميع مساحات عرض إعداد تقارير "مبادرة حماية الخصوصية". |
| جودة النقرة | طلب إضافة إشارة لتمييز النقرات المقصودة وغير المقصودة على أحد الإعلانات | نعمل حاليًا على مناقشة الطلب ونرحّب بالمزيد من الملاحظات. |
| حلّ لقياس الأداء | دعم حلول القياس على مستوى عدة أنظمة عرض بيانات (DSP) | يمكن لمقدّمي خدمات القياس استخدام Attribution Reporting API من أجل إزالة التكرار بين أنظمة DSP متعددة. بالإضافة إلى ذلك، نقترح
قائمة بعناوين URL في attributionsrc،
ما سيسهّل على مقدّمي خدمة DSP دعم
طلبات واجهة برمجة التطبيقات Attribution Reporting API الخاصة بمقدِّم خدمات القياس. نحن نرحب بأي
ملاحظات إضافية بشأن الاقتراح أعلاه. |
| إعداد التقارير على مستوى الحدث | يمكنك طلب أن يكون عدد الأيام قبل إرسال التقرير متاحًا | يمكن لتكنولوجيا الإعلان حاليًا احتساب هذا الطلب باستخدام المعلومات المتاحة حاليًا. لم نتلقَ أي ملاحظات أخرى بشأن المنظومة المتكاملة بخصوص هذا الطلب، لكننا على استعداد لتلقّي الملاحظات بشأنها. |
source_registration_time |
أضِف source_registration_time في تقارير الإحالة على مستوى الحدث. |
ندرس هذا الطلب ونرحب بملاحظات إضافية بشأن ما إذا كانت الجهات الفاعلة في المنظومة المتكاملة تعتبر ميزة مفيدة. |
| وضع التصفُّح المتخفي | هل ستتوفّر حلول القياس عندما يكون المستخدم في وضع التصفّح المتخفي؟ | لا، لن تكون حلول القياس متاحة عندما يكون المستخدم في وضع التصفّح المتخفي. يتم إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية بشكل افتراضي في وضع التصفّح المتخفي. |
| غرف تنظيف البيانات | هل ستكون Measurement API متوافقة مع الغرف النظيفة؟ | الغرفة النظيفة النموذجية للبيانات هي بيئة يتم فيها تحميل بيانات المعرّفات الفردية من مصادر مختلفة إلى قاعدة بيانات لإجراء تحليلات تستند إلى دمج تلك البيانات الأساسية. إطارا القياس لواجهات برمجة تطبيقات "مبادرة حماية الخصوصية" هما التقارير على مستوى الحدث والتقارير التلخيصية. تتضمّن التقارير على مستوى الحدث رقم تعريف حدث تقدّمه تكنولوجيا الإعلان ويمكن استخدامه في غرفة تنظيف البيانات، ولكن ستكون المعلومات المرتبطة بالإحالة الناجحة محدودة وصاخبة. لا يمكن استخدام التقارير المجمّعة المشفَّرة مباشرةً في غرفة نظيفة، ولكن يمكن استخدام نتائج الملخص التي تقدّمها "خدمة التجميع" كمدخل لعمليات التحليل التي تجريها أو كمعلومات تكميلية. |
خدمة التجميع
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| (تم الإبلاغ أيضًا في الربع الرابع من عام 2022) تأخيرات في الإبلاغ |
ما هو التأخير المتوقع في إعداد التقارير؟ | تعديل الربع الأول من عام 2023: بناءً على ملاحظات الشركاء، شاركنا اقتراحات من أجل تقليل التأخير والحدّ من تأثير التأخير. لقد دعمت تكنولوجيا الإعلان كلا الاقتراحَين خلال مكالمات WICG. |
| لا توجد قاعدة التكرارات | كيف يتم التعامل مع "تقرير التجميع المتأخر" إذا كانت التقارير القابلة للتجميع، التي لها المعرّف المشترك نفسه، قد تمت معالجتها بالفعل؟ | لقد شاركنا اقتراحًا بشأن إضافة تأخير إضافي في التقرير إلى المعلومات المشتركة للتقارير القابلة للتجميع وتعريف المعرّف المشترك لخدمة التجميع لمعالجة تأثير انخفاض التأخير في البيانات على واجهة برمجة التطبيقات المجمَّعة بشكل جزئي. نرحّب بأي ملاحظات بشأن هذا الاقتراح. |
| معالجة البيانات | يمكنك طلب إتاحة استخدام عدة بطاقات بيانات مع احترام الخصوصية التفاضلية باستخدام "ميزانية الخصوصية". | نحن نناقش إمكانية استخدام طريقة أكثر مرونة لاستهلاك "ميزانية الخصوصية" لتفعيل حالة الاستخدام هذه ونرحب بالملاحظات الإضافية. |
| (تم أيضًا الإبلاغ عنها في الربع الثاني من عام 2022) هندسة طلبات البحث | تفعيل طلبات البحث المجمّعة للمفاتيح. | تعديل الربع الأول من عام 2023: لا يزال طلب الميزة قيد المراجعة، ولكن ليس لدينا أي اقتراحات في الوقت الحالي. |
| حدود التجربة والتقييم | وضّح نطاق خدمة التجميع مثل "قاعدة عدم التكرار" غير المطبقة حاليًا في مرحلة التجربة والتقييم. | ونحن نبحث في تعديل مستنداتنا لتوضيح ما سيكون متاحًا في مرحلة التجربة والتقييم مقارنةً بالبيانات في GA. |
واجهة برمجة التطبيقات الخاصة بالتجميع الخاص
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| ميزانية مساهمة التجميع الخاص | إنّ ميزانية المساهمة من المستوى الأول محدودة للغاية. | يُسمى كل استدعاء لواجهة برمجة التطبيقات Private Aggregation API مساهمة. ولحماية خصوصية المستخدم، يكون عدد المساهمات
التي يمكن جمعها من الفرد محدودًا. عند جمع كل القيم القابلة للتجميع على مستوى جميع مفاتيح التجميع، يجب أن يكون المجموع أقل من ميزانية المساهمة. ضِمن التصميم الحالي، نضع حدًا للمساهمات لمصدر معيّن لإعداد التقارير خلال آخر 24 ساعة تقريبًا (كفترة عرض تتحرك بشكل منتظم). هذه هي ميزانية المساهمة من المستوى الأول المذكورة في الملاحظات. ونقترح أن يحدِّد المطوّرون القيم التي يساهمون بها استنادًا إلى الحجم المتوقّع (أي ليس باستخدام القيمة 1 فقط). لذلك، قد يكون من المنطقي استخدام قيمة أصغر للأحداث الأكثر شيوعًا لتجنب استنفاد الميزانية. نبحث حاليًا عن بعض الملاحظات حول ميزانية المساهمات في واجهة برمجة التطبيقات الخاصة بواجهة برمجة التطبيقات للتجميع الخاص بشأن كلّ من الحدود الرقمية والنطاق. نفكّر في نقل النطاق من كل مصدر إلى كل موقع إلكتروني ونقل النطاق الحالي إلى نافذة مدتها عشر دقائق ذات حدّ يومي أكبر. |
الحدّ من التتبُّع السري
تقليل مقدار وكيل المستخدم/تلميحات وكيل المستخدم/وكيل المستخدم
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| استخدام UA-R | من بين أهم 10,000 موقع في المملكة المتحدة، ترسل 1% فقط من المواقع الإلكترونية التي تستخدم الإعلانات الآلية تلميحات عن عميل HTTP. قد يكون لـ DSP الذين لم يتم النقل تأثير على إمكانات مكافحة الاحتيال. | بعد إجراء تحليل على مجموعة البيانات نفسها، اكتشفنا أنّه إذا كنت تحتسب استخدام UA-CH عبر علامة HTML <meta>، وواجهات برمجة تطبيقات JavaScript، يصبح عدد المواقع الإلكترونية التي تستخدم UA-CH أعلى بكثير من نسبة 1% المقدَّمة في الملاحظات. واستنادًا إلى هذه الحقائق، وغيرها من الحقائق، بما في ذلك الملاحظات بشأن المنظومة المتكاملة، نشعر بالثقة في المضي قدمًا من خلال الطرح التدريجي للمرحلة السادسة من برنامج "خفض الإحالات الناجحة على Universal Analytics"، وفقًا للمخطط الزمني المنشور، مع إبقاء هيئة CMA على اطّلاع بأحدث المعلومات. نلاحظ أنّ المواقع الإلكترونية قد استغرقت عامَين تقريبًا من الوقت للتحضير لعملية النقل، ولا تزال تجربة الإيقاف النهائي متاحة للمواقع الإلكترونية التي تشعر أنها غير جاهزة. |
| ملاحظات بشأن أشكال الأجهزة الإضافية | طلب UA-CH لتوفير أشكال إضافية من الأجهزة مثل التلفزيون والواقع الافتراضي | نحن نرحب بهذا الاقتراح وندرس دمجه في التصميم. نرحّب بالملاحظات الإضافية. |
| الاختبار المبرمَج | طلب إصلاح خطأ UA-CH في Chrome الذي بلا واجهة مستخدم رسومية قبل شحن المرحلة 6 من UAR | تم إصلاح الخطأ المعني. |
| دعم UA-CH على نظام التشغيل iOS | يشير موقع إلكتروني يعتمد على معلومات UA الدقيقة المتعلقة بحالات استخدام الإعلانات إلى أنّ متصفّح Chrome غير متوافق مع نظام التشغيل iOS. | بالنسبة إلى المتصفّحات التي تعمل بنظام التشغيل iOS والتي لا تستخدم Safari (بما في ذلك متصفّح Chrome على نظام التشغيل iOS)، يجب أن يضيف مشروع WebKit الدعم لـ UA-CH قبل تفعيله (لأنّها تتحكّم في حِزم الشبكة). |
حماية IP (المعروفة سابقًا باسم Gnatcatcher)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| (تم الإبلاغ أيضًا في الربع الرابع) من حالات استخدام رصد الموقع الجغرافي | قد تمنع حماية الملكية الفكرية حالات الاستخدام المشروعة لرصد الموقع الجغرافي في المستقبل، مثل تخصيص المحتوى استنادًا إلى الموقع الجغرافي. | لم يطرأ أي تغيير على استجابتنا بدءًا من الربع الأخير من عام 2022: "نحن نعمل مع الجهات المعنيّة لضمان استمرار Chrome في إتاحة حالات الاستخدام المشروعة لعناوين IP. لذلك، نسعى إلى الحصول على ملاحظات حول المنظومة المتكاملة بشأن دقة رصد الموقع الجغرافي حسب عنوان IP." |
| الالتزام بالقوانين واللوائح | فإذا كان عدد سكان المنطقة أقل من مليون، فإن الحد الحالي البالغ مليون واحد لحماية بروتوكول الإنترنت سيمنع المواقع الإلكترونية من استخدام عناوين IP للامتثال التنظيمي. | ونحن نعمل مع الجهات المعنية لضمان استمرار Chrome في دعم حالات الاستخدام المشروعة لعناوين IP. إننا نسعى للحصول على ملاحظات المنظومة المتكاملة بشأن الامتثال التنظيمي لحماية الملكية الفكرية. |
| الحد من إساءة الاستخدام | يمكن للجهات ما التحايل على حماية IP من خلال مشاركة عناوين IP غير مقنعة مع الآخرين. | نحن ندرك خطر عدم منع اقتراح حماية الملكية الفكرية الحالي للأطراف المعنية من الناحية الفنية من مشاركة عناوين IP غير المقنعة مع الآخرين. نعمل على تخفيف التدابير التي من شأنها تجنب
خطر إساءة الاستخدام هذا. بينما نعيد النظر في الاقتراح، نشجّعك على تقديم المزيد من الملاحظات والمناقشة. على وجه التحديد، نودّ معرفة أي حالات استخدام تعتقد الأطراف أنّها بحاجة إلى مشاركة عناوين IP غير مخفية مع أطراف أخرى. |
| حظر الشبكة | يمكن للأطراف المعنية التحايل على حظر الشبكات باستخدام الخوادم الوكيلة لحماية بروتوكول الإنترنت. | في هذا السيناريو، يجب على الجهة التي تُجري الحظر إيقاف حماية IP. وقد ردّنا على المشكلة ونرحّب بتلقّي ملاحظات إضافية. |
| قوائم حظر عناوين IP المتأثرة باقتراح حماية عنوان IP | تستعين العديد من شركات تكنولوجيا الإعلان بقائمة حظر أساسية لعناوين IP، مثل قائمة عناوين IP لمركز بيانات TAG لمنع تقديم عروض أسعار على المساحة المتوفّرة للإعلانات التي يُرجّح بشدة أن تكون احتيالية (أو غير قابلة لتحقيق الربح على الأقل). وفي حال كانت تقنية الإعلان هي أداة تتبُّع أيضًا ويمكن أن تخضع لاقتراح "حماية حقوق الملكية الفكرية"، قد تفقد هذه الشركة القدرة على إجراء فحص أساسي ضد الإعلانات قبل شراء المساحة المتوفّرة للإعلانات. | نحن نشجّعك على تقديم المزيد من الملاحظات والمناقشات بشأن اقتراح حماية الملكية الفكرية بشأن المشاكل والحلول المحتملة. أحد الخيارات هو تطبيق مثل هذه القوائم المشابهة على حماية IP، بحيث لا ننشئ خوادم وكيلة تنشأ من عناوين IP تم وضع علامة عليها مسبقًا. |
تعزيز حدود الخصوصية على مواقع إلكترونية متعددة
مجموعات نطاقات الطرف الأول
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| حد النطاق (تم الإبلاغ عنه أيضًا في الربع الرابع) | طلب زيادة عدد النطاقات المرتبطة | لم يطرأ أي تغيير على ردّنا اعتبارًا من الربع الأخير من عام 2022: "أوضحنا في طلبات WICG أنّ متصفّح Chrome ملتزم بتوفير حل سهل الاستخدام يراعي اهتمامات الخصوصية للمستخدمين أيضًا. وفي هذا الصدد، نقدّر ملاحظات المنتدى حول حالات استخدام معيّنة قد تتأثر بتقييد النطاق، كي يتمكّن الفريق من التفكير في طرق لمعالجة حالات الاستخدام هذه مع الاستمرار في حماية خصوصية المستخدم." |
| إرسال صور بديلة في الثانية | اقتراح لطريقة بديلة لإرسال القوائم العالمية لعدد اللقطات في الثانية | نستعدّ في الوقت الحالي لشحن مجموعات بيانات الطرف الأول (FPS) في Chrome، وقد أعددنا مستودعًا مركزيًا في GitHub لقبول الطلبات المرسَلة. بما أنّنا نأمل أن يساهم عدد اللقطات في الثانية في سد فجوة في حلول الأنظمة الأساسية الحالية على الويب تحضيرًا لعملية إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية، نتوقع أن نتعلم منهم كيفية استفادة مؤلفي المواقع الإلكترونية من هذه اللقطات. مع تزايد قائمة المجموعات بمرور الوقت، وتتكيّف المنظومة المتكاملة مع عالم ملفات تعريف الارتباط التابع لجهة خارجية، يمكننا أيضًا إعداد العملية إلى النقطة التي يمكننا من خلالها التفكير في خطط لا مركزية بديلة مثل الاقتراح. مع العملية الحالية، نتوقع بدء فترة حياة محددة، مما سيسمح لنا بتطوير عملية الاستقبال مع مرور الوقت. يمكننا النظر في هذه الفكرة بمجرد تنضج عملية الإرسال. |
| الإشراف على الريبو | فعِّل إشراف المنتدى على مستودع إرسال FPS لمنع إساءة الاستخدام. يمكن للجهات المسيئة أن تغمر بسهولة العملية التي تستخدم مصادر الناسر لاقتراح مجموعات، وقد يؤثر العدد الهائل من الطلبات على عمليات الاقتراحات الحقيقية. | نحاول جعل عمليات التحقق موضوعية قدر الإمكان من خلال الاعتماد على عمليات التحقق الفنية. ونعتقد أن هذا هو النهج الأكثر قابلية للتطوير في عملية الإرسال. وتماشيًا مع هذا الهدف، سنهدف أيضًا إلى ضمان مرونة العملية في التعامل مع عمليات الإرسال غير المرغوب فيها أو عمليات النقل. |
| المجموعات الفرعية المرتبطة | هل سيتمكّن اللقطات في الثانية من دعم حالات استخدام تدفق المورّد/خدمة تأجير البرامج (SaaS) التابعة لجهات خارجية من خلال المجموعات الفرعية المرتبطة؟ | لا تُعد تدفقات مورّدي الطرف الثالث / SaaS حالة استخدام يتم اعتبارها حاليًا في نطاق مجموعات الطرف الأول. نرحّب بالملاحظات الإضافية حول كيفية استخدام ملفات تعريف الارتباط على مواقع إلكترونية مختلفة لحالات الاستخدام هذه. |
| دمج عدد اللقطات في الثانية + الشرائح | يمكنك طلب دمج FPS + CHIPS لدعم حالات الاستخدام، مثل اختبار A/B. | نناقش حالة الاستخدام هذه وندرس أيضًا مناقشة هذا الأمر بمزيد من التفصيل في مكالمة WICG ونرحب بمدخلات إضافية هنا. |
| اللائحة العامة لحماية البيانات | اقتراح لمجموعة فرعية جديدة من اللقطات في الثانية ليتم تصميمها وفقًا لمفاهيم اللائحة العامة لحماية البيانات | لقد ناقشنا هذا الاقتراح داخليًا وقارنناه بالملاحظات الأخرى التي تلقيناها بالإضافة إلى أهداف الخصوصية. وقدمنا إجابة توضح سبب عدم متابعة هذا الاقتراح في الوقت الحالي. |
| Memory | التغيير المتوقع في حجم ذاكرة المتصفح عند دمج قائمة اللقطات في الثانية | كانت هناك سابقات للمتصفّحات لتخزين هذه الأنواع من القوائم بأقل تأثير ممكن على الذاكرة، مثل "قائمة حماية تتبُّع قطع الاتصال". وعلى الرغم من أنّه سيتم نسخ قائمة مجموعات نطاقات الطرف الأول إلى كل عميل من عملاء Chrome محليًا، سنواصل مراقبة حجم الملف ونحن على ثقة بأنّه يمكننا تحسين استهلاك الذاكرة. |
واجهة برمجة تطبيقات Fenced Frames
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| حدود "الإطارات المضمّنة" | وضوح حول القيود التي تفرضها ميزة Fenced Frames | في شهر آذار (مارس)، عدّلنا الشرح الخاص بالإطار العام الذي يوفّر معلومات حول إمكاناته، ونرحب بأي ملاحظات إضافية. |
| توسيع معلومات الوصول | طلب توسيع نطاق الوصول إلى المعلومات حول الإطارات المجاورة | نتطلّع إلى فهم المزيد من التفاصيل عن سبب اعتبار أنّ هذه التغييرات مطلوبة من المنظومة المتكاملة ونرحب بأي ملاحظات إضافية. |
| الإطارات المضمّنة وإطارات iframe | أسئلة تتعلق بتكافؤ الميزات بين Fenced Frames وiframes | ستكون جميع واجهات برمجة التطبيقات والتقارير المتاحة في "مبادرة حماية الخصوصية" متاحة لإطارات iframe وFencedFrames بالطريقة نفسها. |
| تغيير حجم الإطارات المضمّنة | يؤثر تقييد تغييرات حجم الإطار في حالات استخدام معينة. | يهمّنا معرفة المزيد من المعلومات عن أنواع حالات الاستخدام التي تتأثر بالقيود ويسرّنا تلقّي ملاحظات إضافية. |
واجهة برمجة تطبيقات مساحة التخزين المشتركة
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| الوظائف المصغّرة التابعة لجهة خارجية | هل يمكن للجهات الخارجية إرسال رسائل إلى "مساحة التخزين المشتركة" مقسَّمة حسب المصدر؟ أو طلب وظائف صغيرة أخرى للقياس التابع لطرف ثالث؟ | إنّ أصل سياق التصفّح لمكان تنفيذ الرمز البرمجي يحدّد مساحة التخزين المشتركة التي تتم كتابة البيانات إليها. عند إضافة رمز برمجي تابع لجهة خارجية إلى صفحة، يمكن تضمين الرمز البرمجي الخاص بالجهة الخارجية كإطار iframe مع سياق التصفّح الخاص به، ما يسمح للرمز البرمجي الخاص بالجهة الخارجية بالكتابة إلى مصدره الخاص. يمكن أيضًا تضمين الرمز البرمجي التابع للجهة الخارجية كنص برمجي بدلاً من إطار iframe، الذي لا يبدّل سياق التصفّح، ويمكن للجهة الخارجية الكتابة إلى مساحة التخزين المشتركة لأداة التضمين. لاحظ أن مالك مساحة التخزين المشتركة هذه فقط يمكنها القراءة من وحدة التخزين المشتركة تلك. |
| التكرارات | لن يكون إلغاء التكرار ممكنًا للتفاعلات خارج منظومة Chrome المتكاملة. | تهدف مساحة التخزين المشتركة إلى توفير مخرجات مدى الوصول الفريد مستندة إلى متصفّح Chrome ضمن Chrome. ويهمّنا العمل مع تقنيات الإعلان لفهم كيفية استخدام هذه المخرجات كجزء من نماذج مدى الوصول الأوسع نطاقًا. ونتفهم أنّ المخرجات نفسها قد تحتسب جزءًا من التفاعلات فقط، ونحن مهتمون بالعمل مع تقنيات الإعلان لاستكشاف منهجيات وضع نماذج إضافية يمكن وضعها فوقها. |
| فترة معاينة الإعلان للإحالات الناجحة | اطلب الحصول على فترة مراجعة لمعدّل الإحالات الناجحة من أجل الاطّلاع على التغييرات في الإحالات الناجحة بمرور الوقت. | ويمكن تنفيذ ذلك من خلال معالجة مسارات الإحالات الناجحة المختلفة من جهة العميل باستخدام "مساحة التخزين المشتركة"، والتي تمنح مرونة إضافية للتحليلات المتقدمة عن مساحة التخزين الآمنة غير المقسَّمة في المتصفح. |
| نافذة انتهاء صلاحية العنصر | طلب تمديد فترة انتهاء الصلاحية إلى 90 يومًا | تم تعديل سياسة الاحتفاظ بالبيانات في تشرين الثاني (نوفمبر) 2022، وتنص على أنّه تم محو كل مفتاح بعد ثلاثين يومًا من آخر عملية كتابة. نرحّب بملاحظات إضافية لفهم ما إذا كانت السياسة الجديدة تناسب المنظومة المتكاملة. |
| عرض تصميمات الإعلانات بالتناوب | ولا تعكس حالات استخدام عرض تصميمات الإعلانات بالتناوب الإجراءات الفعلية بعد انتهاء المزاد. | يهمّنا الحصول على ملاحظات المزيد من شركات تكنولوجيا الإعلان من جهة الشراء حول ما إذا كانت مستندات التناوب الإبداعي دقيقة أم لا. |
الشرائح
لم يتم استلام أي ملاحظات في هذا الربع من العام.
FedCM
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| نقطة نهاية تأكيد الهوية | السماح صراحةً بالطلبات العشوائية لنقطة نهاية تأكيد الهوية. | كنّا نتعاون مع Mozilla بشأن طلب السحب هذا للحدّ من قدرة المواقع الإلكترونية على إجراء طلبات من مصادر متعددة معتمدة بدون التسبّب في أي إزعاج للمستخدمين، وسنواصل مراجعة الملاحظات الأخرى ومعالجتها أيضًا. |
| ملء الهوية مسبقًا | هل يمكن استخدام FedCM لتعبئة نماذج تسجيل الدخول تلقائيًا باستخدام موفِّر هوية من قائمة FedCM؟ | إن مصدر قلق بشأن حالة الاستخدام هذه هو أنها قد تؤدي إلى تسريب المعلومات عندما يتمكن الموقع الذي لم يتفاعل مع المستخدم من الاستعلام عن آخر موفّر هوية استخدمه المستخدم. نعمل حاليًا على مناقشة هذه المشكلة ونرحب بملاحظات إضافية. |
| اختيار الحساب السياقي | اقتراح لإضافة الإشارات السياقية في واجهة مستخدم اختيار الحسابات | ندرس هذا الاقتراح ونرحب بمناقشات إضافية. |
مكافحة المحتوى غير المرغوب فيه والاحتيال
واجهة برمجة التطبيقات للرمز المميز للحالة الخاصة (وواجهات برمجة التطبيقات الأخرى)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
|---|---|---|
| إمكانات جمع الاستطلاع | في بداية الربع الأول، انتهينا من جمع نتائج الاستطلاع التي تلزمك الإمكانات المختلفة لحالات الاستخدام المختلفة لمكافحة الاحتيال، وتمت مشاركتها مع الجميع (دقائق و نتائج) | ونخطط لدمج هذه الملاحظات في أثناء تطوير اقتراحات ونماذج جديدة لواجهات برمجة التطبيقات المصممة لغرض محدد والتي تحافظ على الخصوصية بهدف مكافحة الاحتيال. ونتوقع أن نعطي الأولوية للتطوير عندما تكون هناك حاجة ماسة وتكنولوجيا حالية يمكننا الاعتماد عليها لتقديم إمكانية الوصول إلى الويب مع الحفاظ على خصوصية المستخدم. على سبيل المثال، حصل الجهاز وسلامة التشغيل على ترتيب مرتفع، والعديد من المنصّات تحتوي على واجهات برمجة تطبيقات حالية تشارك في تقييم سلامة الجهاز بشكل آمن، لذا فهي تناسب الاستكشاف داخل مجموعات المنتديات. |
| ملاحظات وآراء بشأن PST نيّة الشحن | كجزء من رغبة في الشحن، تلقينا شكوى في المتابعة نظرًا لأننا نستخدم إصدارًا قديمًا من Privacy Pass. كما تلقينا ملاحظات تفيد بأن المواصفات كانت غير واضحة في أقسام معينة، وأنه ينبغي تحسينها لتسهيل توافق المتصفح. | إننا نخطط لتنفيذ العديد من التغييرات المقترحة على المواصفات قبل الشحن إلى GA، فضلاً عن بعض التغييرات في واجهة برمجة التطبيقات. جاءت الملاحظات مباشرةً في نهاية الربع الأول، لذلك نتواصل معك لمتابعة مشاكل GitHub من خلال تقديم تفاصيل محدّدة وتحديث خطة الإطلاق (قيد المعالجة، اعتبارًا من نشر تقرير الملاحظات هذا). بالنسبة إلى التغييرات الكبيرة على واجهة برمجة التطبيقات، نحن مستعدون لدراسة هذه التغييرات، لكننا نعتقد أنّ أفضل طريقة للمضي قدمًا هي مواصلة عملية الإطلاق للجمهور والحصول على ملاحظات عملية من المزيد من المطوّرين. نأمل أن نواصل هذه المناقشة وأن نتّبع توحيد طريقة استخدام المتصفّح. في حالة ظهور معيار جديد، سننظر في اعتماد وتطوير خطة للانتقال إليه بعناية. |