تقرير ربع سنوي للربع الثالث من عام 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 |
| (تم الإبلاغ أيضًا في الربع الثاني)
الفائدة لأنواع مختلفة من الأطراف المعنية |
مخاوف من أنّ تقنيات "مبادرة حماية الخصوصية" تفضِّل المطوّرين الكبار، وأنّ المواقع الإلكترونية المتخصّصة (الأصغر حجمًا) تساهم بأكثر من المواقع الإلكترونية العامة (الكبيرة). | تعديل الربع الثالث:
التزمت Google بـ CMA لتصميم عروض "مبادرة حماية الخصوصية" وتنفيذها بطريقة لا تشوّه المنافسة من خلال الاختيار الذاتي للأنشطة التجارية الخاصة بشركة Google، ولمراعاة التأثير على المنافسة في الإعلان الرقمي وعلى الناشرين والمعلنين، بغض النظر عن الحجم. نواصل العمل عن كثب مع CMA لضمان امتثال عملنا لهذه الالتزامات. مع تقدّم عملية اختبار "مبادرة حماية الخصوصية"، أحد الأسئلة الرئيسية التي سنقيّمها هو مستوى أداء التكنولوجيات الجديدة لأنواع مختلفة من الجهات المعنيّة. تمثّل الملاحظات أهمية كبيرة في هذا الصدد، لا سيّما الملاحظات المحدّدة والقابلة للتنفيذ التي يمكن أن تساعدنا في تحسين التصميمات الفنية بشكل أكبر. لقد عملنا مع CMA لتطوير نهجنا في ما يتعلق بالاختبار الكمي، ونؤيد نشر ملاحظة حول تصميم التجربة لتقديم مزيد من المعلومات للمشاركين في السوق وفرصة للتعليق على الأساليب المقترحة. |
| (تم الإبلاغ أيضًا في الربع الثاني)
طلبات المستندات |
طلبات للحصول على مزيد من الموارد التي توضح بالتفصيل كيفية إدارة الاختبار والتحليل والتنفيذ | تعديل الربع الثالث:
ندرك أنّ المطوّرين قد وجدوا أنّ المواد الحالية مفيدة، ونحن ملتزمون بتقديم المزيد من المواد خلال الأسابيع والأشهر المقبلة حتى يتمكّن المطوّرون من مواصلة فهم كيفية الاستفادة من التكنولوجيات الجديدة. وعقدنا أيضًا جلسات علنية ضمن ساعات عمل المطوّرين لمشاركة أفضل الممارسات والعروض التوضيحية، بالإضافة إلى جلسات أسئلة وأجوبة مع خبراء المنتجات والهندسة للسماح بالمناقشة المباشرة أو طرح الأسئلة. |
| التوافق مع جميع المتصفحات | مورّدو المتصفِّح الآخرون الذين يستخدِمون واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" | وهناك مورّدو برامج آخرون، مثل Apple وMozilla وMicrosoft، مشاركين نشطين في المنتديات العامة التي تتم فيها مناقشة مبادئ الخصوصية والأساليب المستندة إلى المتصفح. نحن تشجعنا المناقشات التعاونية في منتديات مثل الاجتماع السنوي لـ TPAC الأخير الذي تم عقده لـ W3C ومنتديات W3C PATCG الحالية حيث نرى علامات على التقارب. |
| الاختلافات بين المنصات | يمكنك طلب مواءمة مجموعات الميزات على الويب وAndroid قدر الإمكان للمساعدة في تقليل الموارد اللازمة لعملية الانتقال. | نعمل جاهدين على مواءمة نهجنا عبر Chrome وAndroid لتجنُّب حدوث ارتباك أو تجزئة في المجال. تعود أي اختلافات في نهجنا إلى حد كبير إلى الاختلافات الفنية الضرورية بين الويب والأنظمة الأساسية للتطبيقات المتوافقة مع الأجهزة الجوّالة التي سيأخذها مطوّرو البرامج في الاعتبار. |
| مراجع اختبار واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" | صعوبات تخصيص قدر كافٍ
لاختبار واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" في ضوء الرياح الاقتصادية المعاكسة الحالية. |
تعمل Google باستمرار على تحسين المستندات والدعم المتاح للمختبرين بهدف تسهيل التعقيد والمساعدة في استخدام واجهات برمجة التطبيقات. وتشمل هذه الجهود ما يلي: القوائم البريدية الخاصة بواجهة برمجة التطبيقات وساعات العمل المفتوحة والتحديثات المستمرة على developers.chrome.com. |
| إشارة إيقاف Sandbox API | يمكنك طلب تقديم إشارة "ألغى المستخدم تفعيل واجهات برمجة تطبيقات وضع الحماية"، والتي يمكن لتقنية الإعلان والمواقع الإلكترونية استخدامها. | لقد رأينا العديد من الحالات السابقة التي تتفاعل فيها المواقع الإلكترونية مع خيارات المستخدم، مثل "إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية" من خلال الضغط على المستخدم لتغيير إعداداته، بما في ذلك أحيانًا حظر الوصول إلى المواقع الإلكترونية ما لم يتم ذلك. قد يتم أيضًا استخدام إشارة الإيقاف كإشارة إضافية للبصمات الرقمية. لا تعتزم Google حاليًا توفير إشارة إيقاف. |
| (تم الإبلاغ أيضًا في الربع الثاني)
مخططات زمنية أكثر وضوحًا |
جداول إصدارات أكثر وضوحًا وتفصيلاً | تعديل الربع الثالث:
كما هو موضّح في قسم "التغييرات استجابةً للملاحظات" أدناه، عدّلت Google المخطط الزمني الخاص بـ "مبادرة حماية الخصوصية" في تموز (يوليو) لمنح السوق وقتًا إضافيًا للاختبارات الأولية والملاحظات، بالإضافة إلى المزيد من الوقت للاختبار بعد الإطلاق الكامل لواجهات برمجة تطبيقات "مبادرة حماية الخصوصية" قبل إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا. |
| (تم الإبلاغ أيضًا في الربع الثاني)
المخطّطات الزمنية للإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية |
طلبات لتجنُّب المزيد من التأخير بسبب إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا | تعديل الربع الثالث:
في تموز (يوليو)، أعلن Chrome عن مخطّط زمني معدَّل للإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية، ما يوضِّح التزامنا بالتصرّف بمسؤولية نظرًا لتعقيد التكنولوجيات وأهميتها بالنسبة إلى المنظومة المتكاملة. قبل إجراء هذا التغيير، تم أخذ الملاحظات الواردة من الجهات التنظيمية والعاملين في المجال بعين الاعتبار، ونواصل العمل عن كثب مع جميع الجهات المعنيّة. |
| ملفات تعريف الارتباط الخاصة بالطرف الأول | هل يتم أيضًا اقتراح قيود على ملفات تعريف الارتباط للطرف الأول؟ إذا كان الأمر كذلك، فإن المخاوف بشأن الاستقرار الطويل الأمد، ومخاطر من حدوث تغييرات أخرى غير متوقعة في المتصفح، وبالتالي إهدار الجهود الهندسية الآن. | لم نأخذ في الاعتبار أي قيود مرتبطة بملفات تعريف الارتباط للطرف الأول. تركِّز "مبادرة حماية الخصوصية" على الإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية. |
عرض محتوى وإعلانات ملائمة
المواضيع
| موضوع الملاحظات | ملخّص | استجابة Chrome |
| (تم الإبلاغ أيضًا في الربع الثاني)
الفائدة لأنواع مختلفة من الأطراف المعنية |
برزت بعض المخاوف بشأن فائدة المواقع الإلكترونية بناءً على مستوى عدد الزيارات أو مدى تخصص المحتوى. | تعديل الربع الثالث:
سيتم استكشاف مدى فائدة واجهة برمجة التطبيقات من خلال الاختبار. وعلى النحو المطلوب بموجب الفقرة 17.ج.2 من الالتزامات، ستشارك Google نتائج هذه الاختبارات مع هيئة CMA. يتوقع Chrome أن يتطور التصنيف والمعلَمات الأخرى استنادًا إلى نتائج الاختبار. قد لا يتطلب تطور التصنيف أو المعلَمات تغييرات غير متوافقة مع الأنظمة القديمة. بالإضافة إلى ذلك، يتوقّع Chrome استمرار تأثير هذه الملاحظات في تطوّر Topics API بعد إيقاف ملفّات تعريف الارتباط التابعة لجهات خارجية. |
| الخصوصية/السياسة | طلب إزالة متطلبات الفلترة حسب الموضوع لكل المتصل. | واستنادًا إلى الملاحظات الواردة من مؤيدي الخصوصية والمدافعين عن الخصوصية وخبراء الأمان ومجموعات الحقوق الرقمية وغيرها في المنظومة المتكاملة، اختار متصفّح Chrome هذا التصميم لإتاحة الوصول إلى المعلومات فقط لأولئك الذين حصلوا على مثل هذه المعلومات. وقد شملت الأسباب، على سبيل المثال لا الحصر، الحدّ من التسرّب المتزايد للبيانات من جهات متعددة، وضمان الشفافية والوضوح، واعتماد نهج سهل التنفيذ والوصف، والحدّ من مخاطر البصمات الرقمية. يمكن للناشرين والجهات الخارجية التي تتلقّى Topics أن يقرروا بأنفسهم المعلومات التي سيشاركونها مع أطراف على موقعهم الإلكتروني. وفي حال مشاركة جهات خارجية لهذه المعلومات، يحثها Chrome بشدة على التحلي بالشفافية مع المستخدمين بشأن عمليات المشاركة هذه، وتقديم عناصر التحكم لها. |
| المواقع التي تم تصنيفها بشكل خاطئ | يتم تصنيف المواقع الإلكترونية بشكل خاطئ ضمن موضوع غير صحيح، ما قد يؤدي إلى استهداف غير دقيق للإعلانات. | يتم تصنيف المواقع الإلكترونية من خلال مزيج من قائمة تجاوز ينظّمها المراجعون، وتتضمّن المواقع الإلكترونية الأكثر رواجًا، ونموذج تعلُّم الآلة على الجهاز. يواصل Chrome تقييم خيارات المواقع الإلكترونية للمساهمة في تصنيف المواضيع. ويجب الالتفات إلى أي تحسينات في الأداة مقابل مخاطر الخصوصية وإساءة الاستخدام. على سبيل المثال، تتضمن بعض المخاطر ما يلي:
ويمكن للجميع فحص هذه المكوّنات باستخدام الأدوات المتاحة عبر chrome://topics-internals أو colab هذا. من خلال إجراء الاختبارات، نتوقّع أن يتحسّن التصنيف بمرور الوقت، ونرحب بملاحظاتك بشأن أمثلة على المواقع الإلكترونية التي قد تم تصنيفها بشكل خاطئ. |
| متطلبات الوصول | متطلبات المواضيع الحالية لكيان DOM على الصفحة كنص برمجي أو إطار iframe للوصول قد يؤدي إلى سلوكيات غير مرغوب فيها من قِبل اللاعبين في المنظومة المتكاملة للإعلانات. | تم دمج تغيير في شرح جيت هب. ننوي إتاحة Topics في عناوين HTTP. |
| تصنيف المواضيع ليس دقيقًا بما فيه الكفاية | إنّ تصنيفات المواضيع الحالية واسعة جدًا، ولا تشمل مواضيع أكثر تفصيلاً، مثل المواضيع الإقليمية. | التحسينات التي يتم إجراؤها على التصنيف هي جهد مستمر، ونتوقع أن يتطور التصنيف باختبار المنظومة المتكاملة وإدخالها.
ونسعى جاهدين إلى طلب الحصول على ملاحظات بشأن التصنيف الذي قد يكون أكثر إفادة للمنظومة المتكاملة. عند تقييم ما إذا كان يجب زيادة عدد المواضيع أو تضمين مواضيع أكثر دقة، هناك بعض الاعتبارات، بما في ذلك 1) الآثار المحتملة بشأن الخصوصية (على سبيل المثال، قد يؤدي المزيد من المواضيع إلى زيادة مخاطر البصمات الرقمية) و2) القدرة على استرداد المواضيع التي تمت ملاحظتها سابقًا (على سبيل المثال، مع زيادة عدد المواضيع، قد تقل احتمالية ظهور تقنية الإعلان للموضوع المحدّد في الماضي). التوسّع برقم 2، تسعى Google إلى زيادة قدرة المتصلين على استرداد المواضيع التي تمت ملاحظتها سابقًا، وذلك في إطار متطلبات الفلترة الحالية، وذلك بهدف تحقيق فائدة وخصوصية. |
| الحد الأقصى لعدد المواضيع | هناك ثلاثة مواضيع في كل موقع إلكتروني لا تتيح للمعلنين عرض إعلانات سوى القليل جدًا من المعلومات. | وستستمرّ الملاحظات التي تصلنا من المنظومة المتكاملة، لا سيّما نتائج الاختبار في "مراحل التجربة"، في التأثير على تطوّر واجهة برمجة التطبيقات. تجدر الإشارة إلى أنّه من المفترض أن تُكمِّل المواضيع إشارات أخرى، مثل السياق، للمساعدة في العثور على إعلان مناسب للزائر. لذلك، يمكن أن يتوفر المزيد من المعلومات للمعلن بخلاف المواضيع. |
| (تم الإبلاغ أيضًا في الربع الثاني)
عناصر تحكُّم المستخدم وأمانه |
قد تكون بعض المواضيع خوادم وكيلة للمجموعات الحساسة ويحتاج المستخدمون إلى مزيد من عناصر التحكُّم لمنع النتائج السلبية. | تعديل الربع الثالث:
تمثل الموضوعات خطوة كبيرة للأمام في ما يتعلق بالتحكم والشفافية لدى المستخدم. سيتمكن المستخدمون من إلغاء الاشتراك في المواضيع ومراجعة المواضيع التي تم تعيينها لهم وإزالة المواضيع ومعرفة الشركات التي تتفاعل مع مواضيعها على صفحة معيّنة. بالإضافة إلى ذلك، يمكن للمستخدمين محو المواضيع عن طريق حذف سجلّ التصفّح الذي يتم اشتقاق المواضيع منه. يتم تنفيذ عناصر التحكّم هذه حاليًا في متصفّح Chrome على مستوى الجهاز. نرحّب بالنقاشات المستمرة حول عناصر تحكّم أكثر تقدّمًا للمستخدمين، مثل تلك التي اقترحها المطوّرون. ومع ذلك، يجب أن نتأكّد من أنّ الإضافات الجديدة قد تمّت معايرتها بشكل جيد لمعالجة المشاكل المثارة وعدم التسبب في إجراء تغييرات مدمَجة. |
| التأثير في تحسين محركات البحث | إنّ الناشرين الذين يعدّلون أسماء المضيفين على مواقعهم الإلكترونية بطريقة تعكس Topics بشكل أفضل قد يؤثر سلبًا في تحسين محركات البحث. | وننصح المواقع الإلكترونية بعدم تغيير أسماء المضيفين لأغراض خاصة فقط بـ Topics. صحيح أنّ الموقع الإلكتروني قد يتمكن من التأثير في المواضيع التي تم إسنادها إليه بهذه الطريقة. مع ذلك، تكون الفوائد التي تعود على الناشرين من ذلك غير واضحة في أفضل الحالات، وقد يؤدي ذلك إلى تقويض قيمة Topics بالنسبة إلى المنظومة المتكاملة بأكملها إذا حاولت المواقع الإلكترونية "التلاعب" بنموذج التصنيف. كما أن مهام الموضوعات لا يتم إصلاحها أيضًا، ولكننا نتوقع أن يستمر التصنيف في التطور من خلال الاختبار والمدخلات. في ما يتعلّق بهذا الاختبار، ننصحك بإبداء ملاحظات، بما في ذلك أي أمثلة عن المواقع الإلكترونية التي قد تم تصنيفها بشكل خاطئ. |
| الاحتيال وإساءة الاستخدام | توفير طريقة للجهة الشرائية للتأكّد من أنّ الموضوع الذي يرونه قد تم إنشاؤه من خلال المتصفّح | نحن نُقدِّر اقتراح دعم آلية للمشترين على تكنولوجيا الإعلان من أجل التحقّق من المواضيع التي يُجريها البائعون في مزادات الإعلانات الآلية. ونحن نشجّع المنظومة المتكاملة على المشاركة في المناقشات النشطة هنا. بينما نركز حاليًا على التحسينات الأخرى ذات الأولوية الأعلى، ندرك أن هذه قد تكون إضافة مستقبلية مهمة للتصميم. |
| الاحتيال وإساءة الاستخدام | السماح بالمراجعة العلنية للجهات التي تمثّل مستخدمين مشروعين لبيانات Topics، من خلال نفس نوع المشاركة العلنية والمراجعة التي تخضع لها مجموعة الطرف الأول. | نحن نقدّر الاقتراح ونوافق على أنّ المساءلة العامة هي أداة مهمة للمساعدة في تحقيق أهداف "مبادرة حماية الخصوصية". إنّ طلبات البيانات من Topics API تكون متاحة للجميع بطبيعتها، لأنّه يمكن لأي مستخدم زيارة موقع إلكتروني ومراقبة استدعاءات النطاق لواجهة برمجة تطبيقات JavaScript. وبالتالي، يمكن للأفراد والمؤسسات الاطّلاع على الأنشطة ذات الصلة وتقييم المواقع الإلكترونية التي تستخدم Topics وكيفية إجراء ذلك. ونعتقد أنّ هذه الطريقة أفضل من إجراء عمليات تقييم لمستوى "مشروعية" الموقع الإلكتروني ضمن وظائف واجهة Topics API نفسها. |
| التأثير في إشارات الطرف الأول | قد تكون إشارات المواضيع ذات قيمة عالية، ما يؤدي إلى خفض قيمة الإشارات الأخرى المستندة إلى اهتمامات الطرف الأول. | ونحن نعتقد أن الإعلانات التي تستهدف الاهتمامات تمثل حالة استخدام مهمة للويب، وقد تم تصميم Topics لدعم حالة الاستخدام هذه. كما هو موضّح أعلاه، أعربت جهات معنيّة أخرى بشأن المنظومة المتكاملة عن مخاوف تتعلّق بأنّ Topics قد لا تكون مفيدة بما يكفي لتقديم قيمة. وفي جميع الحالات، تشكّل التحسينات على التصنيف جهدًا مستمرًا، ونتوقع أن يتطور التصنيف باختبار المنظومة المتكاملة وإدخالها. |
FLEDGE
| موضوع الملاحظات | ملخّص | استجابة Chrome |
| مزاد FLEDGE | كيف يمكن لمقدِّمي الخدمات الأولية تنسيق البيانات المرسلة إلى "إعلانات Google" لتقديم عروض أسعار في مزاد FLEDGE. | يتم تشجيع الشركات التي تشارك في الاختبار على نشر وثائق حول خطط الاختبار والعمل معًا حيثما كان ذلك مناسبًا.
لقد عملنا مع CMA لتطوير نهجنا في ما يتعلق بالاختبار الكمي، ونؤيد نشر ملاحظة حول تصميم التجربة لتقديم مزيد من المعلومات للمشاركين في السوق الذين يخططون للمشاركة في التجربة وفرصة للتعليق على المناهج المقترحة. نشر فريق "مدير الإعلانات" مستندات للبائعين المهتمين باختبار FLEDGE مع الناشرين الذين يستخدمون "مدير الإعلانات" كخادم إعلانات هنا. هناك تفاصيل فنية إضافية موضّحة هنا. |
| FLEDGE في Fenced Frames المتداخلة | تسمح الإطارات السياجية باختبار أقل تقييدًا، مع تقييد أكثر في المستقبل غير المحدد. يشكّل هذا الجدول الزمني غير المعروف تحديًا للمنظومة المتكاملة. | يمكن للشركات اختبار FLEDGE باستخدام Fenced Frames اليوم. لتوفير خيار إعداد أسهل، يمكن للشركات اختيار استخدام FLEDGE أولاً. بعد تنفيذ FLEDGE، يمكنهم اختبار Fenced Frames باستخدام تصميم FLEDGE. |
| سياسة التعامل مع البيانات | ما هي سياسة معالجة البيانات لمجموعات الاهتمامات أو FLEDGE؟ | في تصميم FLEDGE، تظل جميع البيانات المخزنة في مجموعات الاهتمامات، أو حول الأشخاص المُدرَجين في مجموعات الاهتمامات، على الجهاز. ولا يتم إرسال أي من هذه البيانات إلى خادم Google.
تتضمن بعض إجراءات حماية الخصوصية التي يخطط Chrome لتطبيق FLEDGE التفاعل مع خادم k-anonymity تديره Google. ويتم تصميم هذا التفاعل بعناية لتجنُّب مشاركة المعلومات عن المستخدِمين، ولتنفيذه في بيئة تنفيذ موثوقة (TEE) لضمان تكافؤ المعلومات في منظومة الإعلانات المتكاملة. \ التزمت Google بـ CMA لتصميم اقتراحات "مبادرة حماية الخصوصية" وتنفيذها بطريقة لا تشوّه المنافسة من خلال الاختيار الذاتي للأنشطة التجارية الخاصة بشركة Google، ولمراعاة التأثير على المنافسة في الإعلانات الرقمية وعلى الناشرين والمعلنين. نواصل العمل عن كثب مع CMA لضمان امتثال عملنا لهذه الالتزامات. |
| سياسات العمر | كيف يضمن Chrome امتثال شرائح الجمهور التي أنشأها FLEDGE للحظر على فئات عمرية معيّنة؟ | من الأفضل للناشرين والمعلنِين تقييم ما إذا كانت شرائح الجمهور التي ينشئونها باستخدام FLEDGE متوافقة مع القانون الساري. لتوفير المزيد من الحماية للمستخدمين، لن تكون واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" نشطة لأي مستخدم سجّل الدخول إلى Chrome إذا كان سنّ المستخدم المرتبط بحسابه يقلّ عن 18 عامًا، حتى خلال فترة الاختبار. (بالنسبة إلى المستخدمين الذين سجّلوا خروجهم، لا يجمع Chrome إشارات الملف الشخصي التي تتيح للمتصفّح استنتاج عمر المستخدم). |
| مفتاح FLEDGE/خدمات القيمة | وضوح أكثر بشأن ما ستسمح به خدمة مفتاح/قيمة FLEDGE، مثل عدد المفاتيح وعدد مرات تعديلها. | يمكن للشركات التي تستخدم FLEDGE الحصول على أكبر عدد ممكن من المفاتيح في ذاكرة الوصول العشوائي (RAM). لمزيد من التفاصيل، يُرجى الاطّلاع على الشرح هنا.
نسعى إلى توفير مسار أسرع لتعديل البيانات والاقتراحات الترحيبية لأي متطلبات. |
| الاختبار | صعوبة اختبار FLEDGE باستخدام "إعلانات Google" | يُرجى الرجوع إلى مستندات الإعداد في "إعلانات Google" لمعرفة أفضل طريقة للمشاركة والاختبار في مرحلة التجربة والتقييم. |
| واجهة برمجة تطبيقات خدمات عروض الأسعار والمزادات | ما توجيهات Google بشأن واجهة برمجة التطبيقات لخدمات عروض الأسعار والمزادات؟ هل سيتم منحها الأولوية أعلى أو أقل من FLEDGE في متصفّح Chrome في مزادات الأجهزة؟ | ما زلنا ملتزمين بالتصميم الحالي لعروض الأسعار على الجهاز فقط في FLEDGE. تم اقتراح تقديم خدمات عروض الأسعار والمزادات لاستكشاف الحلول الممكنة لدعم مجموعة فرعية من حالات الاستخدام التي قد تكون فيها القدرة الحاسوبية أو سرعة الشبكة للجهاز محدودة. |
| التقارير الإجمالية | طلب دعم التقارير المجمّعة استنادًا إلى جميع الإشارات المتاحة لإنشاء عرض السعر. | نخطط لمشاركة المزيد من المعلومات حول هذا الموضوع قريبًا. |
| الإعلانات السياقية | عرض الإعلانات السياقية باستخدام FLEDGE. | لقد درسنا هذا الخيار وللأسباب الموضحة في هذه المناقشة، لا ننصح حاليًا باستخدام FLEDGE للإعلانات السياقية. |
| إجراء الاختبارات في العالم الحقيقي | إرشادات حول كيفية عزل FLEDGE عن ملفات تعريف الارتباط التابعة لجهات خارجية من أجل الاختبار في العالم الحقيقي. | ونحن نبحث في طرق لتوفير مجموعات الاختبار.
لقد عملنا مع CMA لتطوير نهجنا في ما يتعلق بالاختبار الكمي، ونؤيد نشر ملاحظة حول تصميم التجربة من أجل توفير مزيد من المعلومات للمشاركين في السوق وفرصة للتعليق على الأساليب المقترحة. |
| اختبار FLEDGE وAttribution Reporting API | ما هي أفضل طريقة لتنفيذ Attribution Reporting API باستخدام FLEDGE؟ هل من المفيد الفصل بين FLEDGE والإحالة أو اختبارهما معًا؟ | سنتيح في النهاية اختبار كلّ من FLEDGE وAttribution Reporting API كحلّ متكامل، لكننا نشجع المطوّرين أولاً على اختبار Attribution Reporting API بشكل مستقل ثم باستخدام FLEDGE عند اكتمال عملية الدمج. |
| إمكانية رؤية سعر عرض السعر | طلب تشويش أسعار عروض الأسعار. | من الممكن ضبط نقاط التوقف ضمن "generateBid() " أو "scoreAd()" للوصول إلى قيم عروض الأسعار من "أدوات مطوري البرامج". نظر فريق Chrome في متجه الهجوم الضيق الذي تم طرحه في هذه الملاحظات والآراء حول FLEDGE. ومع ذلك، تعتبر نماذج الأمان والخصوصية في Chrome المستخدمين الموثوق بهم للقيام بأي شيء يريدونه باستخدام المعلومات المتوفرة على أجهزتهم، وبالتالي ليست هناك طريقة مجدية لإخفاء بيانات عروض الأسعار على النحو المطلوب. |
| طلبات المستندات | مستندات وأمثلة للاختبارات في نظام بيئي مباشر | ندرك أنّ المطوّرين قد وجدوا أنّ المواد الحالية مفيدة، ونحن ملتزمون بتقديم المزيد من المواد خلال الأسابيع والأشهر المقبلة حتى يتمكّن المطوّرون من مواصلة فهم كيفية الاستفادة من التكنولوجيات الجديدة.
وعقدنا أيضًا ساعات عمل خارجية علنية لمشاركة أفضل الممارسات والعروض التوضيحية، بالإضافة إلى جلسات أسئلة وأجوبة مع خبراء المنتجات والهندسة للسماح بالمناقشة المباشرة أو طرح الأسئلة. |
| واجهة برمجة التطبيقات الخاصة بالتجميع الخاص | هل تريد الحصول على مزيد من المعلومات حول واجهة برمجة التطبيقات Private Aggregation API؟ | يتوفّر شرح علني يتضمّن أحدث المعلومات التي يمكننا مشاركتها في الوقت الحالي. سيتم توفير المزيد من الوثائق عند تطوير واجهة برمجة التطبيقات هذه وتحديد حالات الاستخدام. |
| وقت استجابة البيانات | هل سيتم استرداد بيانات خادم القيمة/مفتاح FLEDGE في الوقت الفعلي؟ | إنّ مقدار القِدم قليلاً بترتيب الدقائق، وليس حسب الساعات قد يكون متوقّعًا قبل أن يتمكّن الخادم من عرض البيانات المعدَّلة لطلبات البحث، كما هو موضَّح في مشكلة مفتوحة في GitHub. إننا نتطلّع أيضًا إلى الحصول على ملاحظات المطوّرين. |
| خدمات عروض الأسعار والمزادات | هل سيتم إخفاء عروض الأسعار عن المستخدم في حال استخدام خدمات عروض الأسعار والمزادات؟ | بالنسبة إلى النهج الذي يتبعه الخادم من جهة وB&A، لا يظهر سعر عرض السعر المنفرد للمستخدم، نظرًا لأن طلب عرض السعر يتم تقديمه من خدمة مزاد SSP مباشرةً إلى خدمة مزاد وسيط عرض الطلب (DSP)، وبالتالي لا يكون متاحًا في المتصفح بعد الآن.
ومع ذلك، سيظل عرض السعر الفائز مرئيًا للمتصفح (تمت مناقشته بمزيد من التفاصيل أعلاه، في ما يتعلق بطلبات التشويش على أسعار عروض الأسعار). |
| خدمات عروض الأسعار والمزادات | كيف يمكننا تحميل عروض الأسعار المتوازنة وخدمات المزادات؟ | ليست لدينا حاليًا أي إرشادات بشأن موازنة التحميل، ولكنها مصدر قلق مهم من منظور كلٍّ من الأداء والخصوصية. سنقدّم المزيد من التفاصيل في المستقبل. |
| حدود FLEDGE | يمكنك طلب زيادة الحد الأقصى لمدة joinAdinterestGroup من 30 يومًا إلى 90 يومًا. | ونرى أنّ الإطار الزمني للاحتفاظ بالبيانات لمدة 30 يومًا يتماشى مع واجهات برمجة التطبيقات الأخرى لإعلانات "مبادرة حماية الخصوصية"، مثل الحد الأقصى البالغ 30 يومًا في Attribution Reporting و3 أسابيع في تقرير Topics. يلبي هذا الإطار الزمني احتياجات كل من تكنولوجيا الإعلان وتوقعات الخصوصية لدى المستخدمين.
ومع ذلك، نرحّب بمزيد من الملاحظات والآراء بينما نواصل مناقشة المشكلة هنا. |
| مساحة التخزين المشتركة في FLEDGE | هل من الممكن استخدام واجهة برمجة تطبيقات مساحة التخزين المشتركة في FLEDGE؟ | ننوي إتاحة واجهة برمجة التطبيقات Shared Storage في FLEDGE في المستقبل، ونعمل على توفير هذه الواجهة في مرحلة التجربة والتقييم قادمة. |
| التحكّم في عدد مرات الظهور حسب النقرات | هل من الممكن تحديد عدد مرات الظهور حسب النقرات (وليس عدد مرات الفوز) في FLEDGE؟ | يحدّد FLEDGE أن الإطار المحيط يمكن أن يستدعي navigator.stickAdinterestGroup() (بدون معلَمات) لمغادرة مجموعة الاهتمام التي تسببت في عرض الإعلان؛ ويمكن إجراء هذا الطلب في المرة الأولى التي يتم فيها تلقّي نقرة لمنع تقديم عروض أسعار في المستقبل، كشكل من أشكال تحديد عدد مرات الظهور. وفي الوقت الحالي، لا يصلح هذا الحل لوضع الحد بعد أكثر من نقرة واحدة. |
| FLEDGE في Fenced Frames المتداخلة. | يتعذّر تسجيل النقرات من خلال إعداد تقارير إعلانات الإطار المحيطي إذا حدثت على إطار Fenced Frame متداخل. | لقد نشرنا اقتراحًا لحلّ المشكلة هنا. |
| قياس | كنت بحاجة إلى إرشادات حول كيفية جمع بيانات وقت الاستجابة بشأن أنظمة عروض الأسعار في مزاد FLEDGE. | نحن نعمل على نشر مستند قياس الأداء قريبًا. |
| إعداد التقارير | كيف سيتم التعامل مع إعداد تقارير FLEDGE؟ | إعداد تقارير FLEDGE عن الفوز ونتيجة مزاد الإعلانات والأحداث، مثل النقرات ستتاح من خلال واجهات برمجة تطبيقات FLEDGE مثل reportResult() . عند إعداد التقارير باستخدام الإحالة الناجحة للإعلانات، سيكون التكامل مع Attribution Reporting API مستقلاً عن FLEDGE، ولكن هناك مناقشات مستمرة مع المنظومة المتكاملة بشأن الأساليب الممكنة.
ويمكن أيضًا استخدام واجهة برمجة التطبيقات الخاصة لتجميع البيانات، وذلك للإبلاغ عن نتائج المزادات من داخل بيئات التنفيذ المعزولة. يمكنك الاطّلاع على الشرح هنا. |
| حجم مجموعة الاهتمامات | هل تتوفّر أي طريقة تمكّن تكنولوجيا الإعلان من التحقّق من حجم مجموعة الاهتمامات (أي عدد المستخدمين في المجموعة)؟ | يتم تخزين عضوية مجموعة الاهتمامات بواسطة المتصفح على جهاز المستخدم، ولا تتم مشاركتها مع مورّد المتصفح أو أي شخص آخر.
مع ذلك، يمكن لمالك مجموعة الاهتمامات تتبّع نظريًا كل استدعاء إلى navigator.joininterestgroup(...). لا يضمن تتبّع هذا الاستدعاء الحجم الدقيق للمجموعة (إذ يمكن للمستخدمين مغادرة المجموعة في أي وقت)، ولكنه يمنح المالك حدًا أعلى وتقريباً لما يمكن أن يكون المقاس. |
| عروض أداء | هل يتم تجميع رمز JavaScript/WebAssembly المخصّص لعرض الأسعار في كل مزاد؟ | يتم تجميع رمز JavaScript/WebAssembly الذي يتم تقديم عروض الأسعار له مرة واحدة خلال كل مزاد. |
| عروض أداء | ما هو نطاق BidDurationMsec؟ | تتضمن returnDurationMsec وقت تجميع النص البرمجي. ولا يتضمّن وقت التنزيل أو وقت التجميع في Wasm أو وقت الشبكة أو استرجاع الوقت من خادم القيمة الرئيسية أو أيّ عنصر قبل تجميع JavaScript. |
| التخصيص | هل من الممكن تحديث adComponent بحيث يتم تخصيصه للمستخدم؟ | يمكن تعديل مكوِّن الإعلان عند تعديل "مجموعات الاهتمامات" إما من خلال المتصل عند الاتصال JoininterestGroup أو عند إجراء Chrome اتصالاً بـ dailyUpdateURL. ويسمح هذا للمتصل بتعديل عنصر الإعلان استنادًا إلى معرفة المستخدم من الموقع الإلكتروني الحالي أو استنادًا إلى المعلومات المجهولة المصدر في التصنيف k على التوالي.يمكنك العثور على الاقتراح الأصلي للنموذج المجهول على مستوى المنتج هنا والذي يتضمن بعض التحليلات التي أجرتها RTB House بشأن التأثير على المقاييس الأساسية لحالة استخدام التوصية. |
| مجموعة الاهتمامات | هل من الممكن لمالك مجموعة الاهتمامات إزالة مستخدمين معيّنين بشكل مشروط؟ | يتم تخزين عضوية مجموعة الاهتمامات في متصفح المستخدم فقط ولا يمكن إزالتها إلا من جانب المستخدم (على سبيل المثال، عن طريق محو بيانات الموقع).
ومع ذلك، من الممكن لمالك مجموعة الاهتمامات استدعاء navigator.RemoveAdinterestGroup() (مع بعض المنطق الشرطي حولها)، إذا عاد المستخدم إلى صفحة تحت سيطرة مالك المجموعة ذات الاهتمامات المشتركة. |
| عروض أداء | كيف يمكن قياس أداء generateBid؟ | يمكن قياس وقت التجميع والتنفيذ باستخدام viewDurationMsec. يمكن قياس وقت التنزيل باستخدام chrome://net-export. في الإصدارات الحديثة من Chrome، سيظهر وقت التجميع والتنفيذ في علامة التبويب "أداء أدوات مطوّري البرامج". |
| معدل تكرار التحديثات المتعلقة بالمجموعات ذات الاهتمامات المشتركة | كم سيكون معدّل تكرار تحديث مجموعة الاهتمامات من المتصفّحات؟ | بالنسبة إلى مجموعات الاهتمامات التي لم يتم تعديلها خلال آخر 24 ساعة، يحاول Chrome تعديلها عند استدعاء navigator.updateAdinterestGroups() أو عندما تتاح لها فرصة المشاركة في مزاد. لمزيد من التفاصيل، اطّلِع على الشرح هنا. |
| مقدمو خدمات التجميع | متى سيتم توفير خدمات السحابة الإلكترونية الأخرى ضِمن "خدمة التجميع"؟ | ليس لدينا حاليًا أي معلومات بشأن الأوقات المحدّدة، ولكن سنشارك المزيد من المعلومات بمجرد فعل ذلك. في الوقت الحالي، تستوفي خدمات AWS فقط متطلبات الأمان الخاصة بخدمة التجميع. |
| المخطط الزمني لاختبار FLEDGE | ما هي مدة اختبار FLEDGE في نظام التشغيل BYOS؟ هل سيكون هناك وقت كافٍ للتبديل من نموذج نظام BYOS إلى النموذج المستند إلى بيئة التنفيذ الموثوقة (TEE)؟ | ولضمان توفّر وقت كافٍ لاختبار المنظومة المتكاملة، لا نتوقّع أن نطلب استخدام بيئة التنفيذ الموثوقة (TEE) إلا بعد إيقاف ملفّات تعريف الارتباط التابعة لجهات خارجية نهائيًا. وسنرسل إشعارًا مهمًا للمطوّرين لبدء عملية الاختبار والاعتماد قبل إجراء عملية النقل هذه. ليس لدينا حاليًا أي معلومات أخرى، ولكن سنشارك المزيد من المعلومات بعد ذلك. يمكنك الاطّلاع على أحدث المعلومات هنا. |
| الحدّ الأقصى المسموح به لحجم البيانات | ما هو الحدّ الأقصى المسموح به لحجم البيانات بالنسبة إلى Wasm في دالة عروض الأسعار. | هناك شرط يقضي بعدم أن تؤدي تعديلات مجموعات الاهتمامات إلى إنشاء مجموعة اهتمام تتجاوز 50 كيلوبايت، كما تمت مناقشته هنا، ولكن لم يتم تحديد الحد الأقصى لحجم البيانات في Wasm بعد، لذا يسرّنا تقديم المعلومات حول هذا الموضوع. |
| إشارات مزاد الإعلانات | هل ستكون هناك بنية بيانات موحّدة خاصة بإشارات مزاد الإعلانات؟ | لم يتم تحديد ذلك بعد، ولكننا مستعدون لتلقي الملاحظات. |
| الاستعلام عن خوادم تكنولوجيا الإعلان | هل من الممكن إجراء طلب بحث عن بيانات خادم تكنولوجيا الإعلان في الوقت الفعلي من خادم K/V؟ | لا، يعمل خادم K/V باستخدام نموذج ثقة يفرض "عدم الوصول إلى الشبكة أو الوصول إلى القرص أو الموقّتات أو التسجيل" لتجنُّب تسرُّب بيانات المستخدم. يُرجى الاطّلاع على الشرح حول نموذج الثقة هنا للحصول على مزيد من التفاصيل. |
| معدّل تعديل المكوّنات الإعلانية | لا يمكن حاليًا تعديل حقل "المكوّنات الإعلانية" (حاليًا في إعداد IG فقط) حسب سجلّ تصفّح المستخدِم. | تهدف "مبادرة حماية الخصوصية" إلى دعم احتياجات المنظومة المتكاملة على الويب بدون تتبُّع إجراءات المستخدم على مواقع إلكترونية متعددة، ما يعني منع الوصول إلى سجلّ التصفُّح. وننصح باستخدام بدائل مثل Topics. |
| نتائج المزاد | هل هناك أي طريقة تمكّن تكنولوجيا الإعلان من معرفة الأسعار الفائزة بالمزاد؟ | يتم الإبلاغ عن نتيجة المزاد عن طريق استدعاء الدالتين reportResult() وreportWin() في رمز المزاد المقدم من البائع والمشتري الفائز على التوالي، بحيث تتاح لكل منهما فرصة لإجراء التسجيل وإعداد التقارير عن نتيجة المزاد. |
| (تم الإبلاغ أيضًا في الربع الثاني)
دعم استهداف مجموعة اهتمامات سلبية |
واجهة برمجة تطبيقات لدعم الاستهداف السلبي لمجموعات الاهتمامات: يتم عرض الإعلانات فقط إذا كان المستخدم لا ينتمي إلى مجموعة اهتمام معيّنة. | تعديل الربع الثالث:
لقد شاركنا اقتراحًا جديدًا، ويسعدنا معرفة رأيك. |
قياس الإعلانات الرقمية
Attribution Reporting (وواجهات برمجة التطبيقات الأخرى)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
| متطلبات الوقت الإضافي | يمكنك إزالة قيود سياسة الأذونات أثناء وقت إضافي / على الوقت الإضافي فقط. | يُرجى الاطّلاع على التغييرات التي تم الإعلان عنها على سياسة الأذونات أثناء الاختبار. يتمثل مخاوف الأطراف المعنية الأساسية التي يعالجها هذا التغيير في السماح لأنظمة DSP باختبار واجهة برمجة التطبيقات على كمية أكبر من إطارات iframe المتعددة المصادر. في الأصل، كان يتعين على أنظمة وسيط عرض الطلب (DSP) التنسيق مع الناشرين/مقدمي الخدمات على الإنترنت للتأكد من ضبط سياسة الأذونات الصحيحة من أجل اختبار واجهة برمجة التطبيقات على إطارات iframe من مصادر متعددة، ولكن مع هذا التغيير، سيكون بإمكان أنظمة وسيط عرض الطلب (DSP) استدعاء واجهة برمجة التطبيقات تلقائيًا ويمكن لمنسقي خدمة البريد الإلكتروني (SSP)/الناشرون إيقاف واجهة برمجة التطبيقات إذا لزم الأمر أثناء الفترة التجريبية المصدر. |
| الضوضاء | تعقيبات على أن مستوى التشويش مرتفع جدًا ويؤثر على جدوى التقارير. | نرحّب بالتعليقات المتعلقة بالتشويش، والتي سنستخدمها لتحديد كيفية ضبط معلَمات ذات صلة بالضوضاء. نتطلّع أيضًا إلى نشر المزيد من الموارد والأدوات ومستندات أخرى لمساعدة المختبِرين. |
| الإحالات الناجحة عبر النطاقات | كيف يتم تتبع الإحالات الناجحة التي تتم عبر النطاقات، مثل الإحالات الناجحة مع وجهتين أو أكثر؟ | نحن نناقش حاليًا هذا السؤال ونطلب الحصول على ملاحظات بشأنه. |
| متطلبات تصحيح الأخطاء | هل تريد طلب السماح للمطوّرين بالتحقّق من ميزانية الخصوصية المتبقية عند نشر أو اختبار تقرير ملخّص؟ | يمكنك تتبُّع طلب الميزة هذا هنا. |
| سياسات استخدام واجهة برمجة التطبيقات | تقترح التعليقات سياسات حول من يمكنه استخدام واجهة برمجة تطبيقات معينة بناءً على قيود تتعلق بأشياء مثل البصمات الرقمية | هذه فكرة شيقة للغاية وأمر يسعدنا مواصلة التفاعل معه مع مزوّدي المتصفّحات الآخرين والمنظومة المتكاملة للويب الأوسع نطاقًا. |
| إعداد انتهاء الصلاحية في تقرير الإحالات الناجحة | طلب إتاحة فلتر التقرير / انتهاء صلاحيته لأقل من 24 ساعة | تشكّل عمليات انتهاء الصلاحية على مستوى الساعة مصدر قلق بشأن الخصوصية، لأنّها تتيح لتكنولوجيا الإعلانات معرفة الساعة التي يزور فيها المستخدِم الموقع الإلكتروني للمعلِن. ستتيح تاريخ انتهاء الصلاحية على مستوى اليوم لتكنولوجيا الإعلان فلترة مرات الظهور غير الصالحة بدون تحديد الساعة التي زار فيها المستخدم الموقع الإلكتروني. |
| انتهاء صلاحية رمز OT | طلب تمديد فترة صلاحية رموز OT الحالية لتقليل النفقات التشغيلية العامة. | ندرك أنّه يجب تجديد الرموز المميّزة، ونعمل على تسهيل الأمر على المطوّرين ونقدّم إشعارًا إضافيًا. |
| الدعم الإقليمي | لا تتوفر خدمة التجميع حاليًا في جميع المناطق. | وهذا قيد الاستخدام حاليًا على الإصدار التجريبي. ونتوقع دعمها في مناطق إضافية مع تقدم الاختبارات، ولكن ليس هناك جدول زمني واضح لذلك. |
| التأخير في إعداد التقارير على مستوى الحدث | وقد يكون التأخير لمدة يومَين إلى 30 يومًا في إعداد التقارير على مستوى الحدث طويلاً جدًا بالنسبة إلى حالات استخدام معيّنة. | لقد شاركنا اقتراحًا هنا للسماح لتكنولوجيا الإعلان بالتحكّم في وقت إرسال التقارير على مستوى الحدث عن طريق انتهاء الصلاحية. الإعداد التلقائي هو 30 يومًا، ولكن يمكن ضبطه لوقت أقصر. |
| (تم الإبلاغ أيضًا في الربع الثاني)
تحديد المصدر بالاستناد إلى نقاط اتصال متعددة |
السماح بإحالة نقاط الاتصال المتعددة، مثل على جميع الأجهزة أو على جميع التطبيقات. | تعديل الربع الثالث:
تتطلب الطرق الحالية لتحديد المصدر بالاستناد إلى نقاط الاتصال المتعددة الربط حاسمًا بين مرّات ظهور المستخدِم (وبالتالي هويته) على مستوى المواقع الإلكترونية المختلفة. نتيجةً لذلك، لا تتوافق هذه الوظيفة في شكلها الحالي مع أهداف "مبادرة حماية الخصوصية" التي تهدف إلى دعم حالات استخدام الإعلانات الرئيسية بدون تتبُّع إجراءات المستخدم على مواقع إلكترونية متعددة. |
| المخطط الزمني لدمج FLEDGE وإعداد تقارير الإحالة | ما هو المخطط الزمني لدمج FLEDGE وAttribution Reporting API؟ | ليس لدينا حاليًا أي تعديلات لمشاركتها، ولكن سنوفّر المزيد من المعلومات بشكل علني بعد أن نتمكّن من الالتزام بجدول زمني محدّد. |
| أنواع المشغلات المتعددة | طلب مزيد من المرونة في تسجيل المشغّل | اقترحنا نظامًا لإزالة التكرار لواجهة برمجة التطبيقات المجمّعة يمنح تكنولوجيات الإعلانات مزيدًا من المرونة في كيفية تحكّمها في التقارير على مستوى الحدث والتقارير القابلة للتجميع. |
| قياس | اطلب تلقّي بيانات القياس حول ما إذا كان المستودع يحقِّق أداءً جيدًا. | نحن نقدّر الملاحظات ونطلب مزيدًا من التوضيح بشأن حالات الاستخدام لهذا الطلب. |
| انتهاء صلاحية الإحالة الناجحة | يمكنك طلب إتاحة انتهاء صلاحية الإحالة الناجحة في علامة عامل التفعيل بدلاً من العلامة المصدر فقط. | نحن نقدّر الملاحظات ونطلب مزيدًا من التوضيح بشأن حالات الاستخدام لهذا الطلب. |
| إعداد التقارير المجمّعة | اطلب قياسًا إضافيًا في التقارير المجمّعة. | ونقدّر الملاحظات التي نتلقّاها بينما نواصل التفكير في تأثير خدمة تجميع البيانات. يهمّنا معرفة رأي تكنولوجيا الإعلان بشأن تجميع التقارير ومعدّل تكرارها المتوقّع، بالإضافة إلى أي ملاحظات حول كيفية تغيُّر استراتيجية تجميع البيانات على مدار العام. |
| Epsilon | متى سيتم تحديد قيمة إبسيلون؟ | ونعمل جاهدين مع مختبري المنظومة المتكاملة لوضع اللمسات الأخيرة على قيمة إبسيلون وكيفية تنفيذها في "إحصاءات Google". ستكون القيمة مرئية علنًا إلى جانب المناقشة التي أدت إلى اتخاذ قرار بشأن القيمة. إذا كان لديك أي ملاحظات، يُرجى نشرها في مشكلة GH. |
الحدّ من التتبُّع السري
تقليل عدد وكيل المستخدم
| موضوع الملاحظات | ملخّص | استجابة Chrome |
| تبعيات النشر | معالجة تبعيات نشر وكيل المستخدم المنظَّم (SUA). | لقد أطلقنا "المرحلة الرابعة"، وهي تُعرف باسم تخفيض عدد الإصدارات الثانوية إلى 100% من مستخدمي Chrome في الإصدارات 101 والإصدارات الأحدث. عرض التحديث هنا |
| الاختبار | يمكنك طلب تمديد الفترة التجريبية لخفض وكيل المستخدم من Meta. | لقد مدّنا فترة التجربة والتقييم، وحصلنا على إذن لإزالة الحدود القصوى لعدد الزيارات لاستيعاب المواقع الإلكترونية الأكبر حجمًا. تنطبق الحدود غير المحدودة لعدد الزيارات على أي موقع إلكتروني، كبيرًا كان أم صغيرًا. |
تلميحات العميل الخاصة ببرنامج وكيل المستخدم
| موضوع الملاحظات | ملخّص | استجابة Chrome |
| (تم الإبلاغ أيضًا في الربع الثاني)
مخاوف مكافحة الاحتيال / إساءة الاستخدام |
بعض الميزات التي قد يتم فقدانها من خلال بروتوكول UA-CH، وهي: أداة تتبُّع إعادة توجيه النقرات والنقرات الاحتيالية. | تعديل الربع الثالث:
لقد تلقّينا ملاحظات إيجابية من شركات أبلغَت أنّها لم تلاحظ أي آثار سلبية على عمليات مكافحة عمليات الاحتيال التي تستخدمها (يمكن العثور على النتائج هنا وهنا). يواصل الفريق التحقيق في هذه المشكلات المحتملة مع الأطراف المعنية بمكافحة الاحتيال والقياس. |
| سياسة الأذونات | هل يتم إجراء تخزين مؤقت لسياسة الأذونات؟ | لا يتم إجراء تخزين مؤقت لسياسة الأذونات كما هو موضّح في مشكلة جيت هب هذه. |
Gnatcatcher (قيد الإعداد)
| موضوع الملاحظات | ملخّص | استجابة Chrome |
| حالات استخدام رصد الموقع الجغرافي | قد يمنع Gnatcatcher من العمل في المستقبل لحالات الاستخدام المشروعة لرصد الموقع الجغرافي، مثل تخصيص المحتوى استنادًا إلى رصد الموقع الجغرافي. | ونحن نعمل مع الجهات المعنية لضمان استمرار دعم Chrome لحالات الاستخدام المشروعة لعناوين IP. |
تعزيز حدود الخصوصية على مواقع إلكترونية متعددة
مجموعات نطاقات الطرف الأول
| موضوع الملاحظات | ملخّص | استجابة Chrome |
| السياسات | القلق من أنّ اللقطات في الثانية لا تتوافق مع أحكام التزامات "هيئة حماية البيانات" في ما يخص "تشريعات حماية البيانات السارية"، استنادًا إلى أنّ اللائحة العامة لحماية البيانات لا تفرض حدًا على عدد المواقع الإلكترونية في المجموعة بينما تشترط FPS تحديد 3 مواقع إلكترونية | التزمت Google بـ CMA لتصميم اقتراحات "مبادرة حماية الخصوصية" وتنفيذها بطريقة لا تشوّه المنافسة من خلال الاعتراف الذاتي للأنشطة التجارية الخاصة بشركة Google، ومراعاة التأثير في الإعلانات الرقمية والناشرين والمعلنين وكذلك التأثير على نتائج الخصوصية والامتثال لمبادئ حماية البيانات على النحو المنصوص عليه في "تشريعات حماية البيانات السارية". ولا تفصح المشكلة المعنيّة عن أي عدم توافق مع "اللائحة العامة لحماية البيانات". نواصل العمل عن كثب مع CMA لضمان امتثال عملنا لهذه الالتزامات. يمكنك الاطّلاع على مزيد من التفاصيل في قسم "التغييرات استجابةً للملاحظات" أدناه. |
| الوثائق | اطلب الحصول على أمثلة إضافية وتعديل الشروحات الحالية. | الأمثلة الواردة في التفسيرات قيد المراجعة حاليًا، وسنوضّح أو نزيل أي منها حسب الحاجة. |
| مشاركة التفضيل | اقتراح لإجراء تفضيلات عبر مجموعات الطرف نفسه. | نحن نرحّب بملاحظات المستخدمين ونناقشها بنشاط هنا. |
| فرض السياسات | قد تؤدي عمليات التنفيذ الشفافة إلى خطر إساءة استخدام الجهات المسيئة. | نحن نقدّر الملاحظات ونتفاعل بنشاط مع الجهات المعنيّة على GitHub (مع الأخذ في الاعتبار النقاط المطروحة في هذه المشكلة، ونسعى إلى دمج الاقتراحات التي تم طرحها في هذه المشكلة) والمنتديات الأخرى لتقييم هذه المخاطر وتحديد إجراءات التخفيف المحتملة. |
| الملكية المشتركة | اقتراح لبيان الملكية الذي يمكن للأجهزة قراءته من أجل الملكية المشتركة. | ونُرحّب بالملاحظات الواردة في اقتراحنا ونحن نرحّب بها. |
| ملكية النطاقات الفرعية | هل يجب أن تكون النطاقات الفرعية المختلفة التي تضم وحدات تحكّم مختلفة بالبيانات أو سياسات خصوصية مختلفة أو تديرها كيانات مختلفة جزءًا من مجموعة الطرف الأول نفسها؟ | استنادًا إلى الملاحظات التي تلقّيناها، نخطط لإزالة حالة الاستخدام الشائعة لنطاق eTLD. |
| الحد من إساءة الاستخدام | اطلب الحصول على مزيد من التفاصيل حول إجراءات الحدّ من إساءة الاستخدام. | وتتم حاليًا دراسة إدارة هذه العملية، وستتم مشاركة المزيد من التفاصيل في الأشهر المقبلة. |
| متجه الهجوم المحتمل | يمكن استخدام مجموعة مخادعة مرتبطة بصفحات يمكن العثور عليها بسهولة لتوجيه الزيارات إلى صفحات أخرى يتم تقديمها بشكل مخادع على أنّها مستقلة. | ونعمل جاهدين على جمع الآراء العامة والتحقيق في الطرق المحتملة لمعالجة هذه المشكلة. |
| ضبط إعدادات التحقق من الصحة | التحقق من صحة المجموعة من خلال السياسات المشتركة التي تمت الموافقة عليها | أشار العديد من أفراد منتدى معايير الويب والمنظومة المتكاملة على نطاق أوسع إلى أنّ هذه العملية غير ممكنة. |
| حد النطاق | طلب زيادة عدد النطاقات المرتبطة | نعمل جاهدين على إجراء مناقشات بشأن الحدّ المسموح به للنطاقات من عدد اللقطات في الثانية، ويسرّنا تلقّي المزيد من الملاحظات من المنتدى بشأن عدد النطاقات المرتبطة التي تتطلّبها حالات الاستخدام. |
| تفاعل خدمة المجموعة الفرعية | القلق بشأن الخدمة والتفاعل مع المجموعة الفرعية المرتبطة بها. | نحن نقدّر الملاحظات وسننظر في إمكانية جعلها أكثر وضوحًا في المواصفات المستقبلية. |
| (تم الإبلاغ أيضًا في الربع الثاني)
تحسين الخصوصية |
قد يؤدّي عدد كبير جدًا من المواقع الإلكترونية في المجموعة نفسها إلى نتائج مشابهة لملفات تعريف الارتباط التابعة لجهات خارجية. | تعديل الربع الثالث:
يقترح أحدث اقتراح حدّ ثلاثة نطاقات للمجموعة الفرعية "المرتبطة" (التي لا تشمل نطاقات المستوى الأعلى التي يتم ترميزها حسب البلد (ccTLD) ونطاقات الخدمة). يتفاعل Chrome بشكل نشط مع المنظومة المتكاملة لتحديد ما إذا كان هذا الحدّ مناسبًا. |
| (تم الإبلاغ أيضًا في الربع الثاني)
المتطلبات الشائعة لسياسة الخصوصية |
لا يمكن تطبيق سياسة خصوصية مشتركة على مستوى جميع المنتجات ونطاقات السلطة التي يجب أن تكون جزءًا من المجموعة نفسها. | تعديل الربع الثالث:
لم تعد سياسة الخصوصية الشائعة من المتطلبات لتكون جزءًا من المجموعة نفسها. |
واجهة برمجة تطبيقات Fenced Frames
| موضوع الملاحظات | ملخّص | استجابة Chrome |
| لماذا تم استخدام عنصر جديد بدلاً من السمات في إطارات iframe؟ | سؤال يتعلق باقتراح إطار iframe بدلاً من اقتراحات iframe الحالية. | ونحن نرحّب بملاحظات المستخدمين ونرحّب بأفكار حول كيفية تحقيق التوافق بين الوضع الحالي كما تمت مناقشته هنا. |
| راقِب تقاطع في إطار مسور | أسئلة تتعلّق بإمكانية عرض المعلومات داخل Fenced Frame | تتم المشاركة في المناقشة النشطة وفي فترة التعليق في هذا المستند وعلى GitHub. نرحّب بمشاركة الشركاء في حالات الاستخدام معنا لفهم كيفية تقديم الدعم بشكل أفضل. |
| دعم مستودع الفيديوهات والإعلانات المدمجة مع المحتوى | هل تتيح ميزة Fenced Frames استخدام فيديوهات ومستودعات الإعلانات المدمجة مع المحتوى؟ | ومن حيث إمكانات تشغيل الفيديو، لا تختلف Fenced Frames عن إطارات iframe، ولهذا لم يتم ذكرها صراحةً في أي مستندات عامة. عند رصد أيّ مشاكل متعلّقة بإعلانات الفيديو، سيكون من المفيد تقديم ملاحظاتك إلينا حتى نتمكّن من إجراء المزيد من التحقيق. |
| حِزم الويب | هل سيصبح عرض الإعلانات أو عرضها من خلال حِزم الويب متطلبًا في المستقبل عند استخدام Fenced Frame x FLEDGE؟ | وهدفنا على المدى الطويل هو إتاحة استخدام حِزم الويب لعرض محتوى الإعلان في إطار مضمّن مستقل. مع ذلك، لا يتيح التطبيق الحالي لـ FLEDGE هذا، ويتطلب عرض مورد HTML الذي تم استرداده من RenderUrl. |
| أبعاد مادة العرض | طلب Render_url لإتاحة وحدة ماكرو لارتفاع الخانة وعرضها بحيث يمكننا الاستجابة بتصميم إعلان ذي حجم مناسب | هذا موضوع قيد المناقشة هنا. |
واجهة برمجة تطبيقات مساحة التخزين المشتركة
| موضوع الملاحظات | ملخّص | استجابة Chrome |
| دمج FLEDGE | كيف سيتم دمج مساحة التخزين المشتركة وFLEDGE؟ | نحن لا نتابع هذه العملية حاليًا، إلا أنّنا نريد استكشاف هذه الفكرة إذا كان بإمكاننا ضمان الحفاظ على إجراءات حماية الخصوصية. نشجّع الأطراف المهتمة على تقديم اقتراحات لحالات الاستخدام المحتملة التي يمكن أن يتيحها هذا الاقتراح في مستودع GitHub ذي مساحة التخزين المشتركة أو مستودع GitHub FLEDGE. . |
| الاحتفاظ بالبيانات | يؤدي محو مساحة التخزين المشتركة إلى تقليل فائدة ذلك. هل تم اعتبار التمديدات المؤدية إلى فترة الاحتفاظ بالبيانات أو إمكانية حذف مفتاح/قيم فردية كبدائل؟ | نحن نسعى دائمًا إلى تحقيق التوازن بين خصوصية المستخدم والمفاضلات بين الأفراد. ونحن مستعدّون لتلقّي الملاحظات حول التعديلات، ونشجّع الشركاء على تقديم المزيد من الملاحظات والتفاصيل أثناء اختبارهم لمساحة التخزين المشتركة. |
| إشارة سلبية | إشارة سلبية من Mozilla بشأن اقتراح مساحة التخزين المشتركة. | ونشكر Mozilla على مراجعته الدقيقة لاقتراحنا. ونحن نخطط للاستجابة لملاحظاتهم في المستقبل القريب. |
الشرائح
| موضوع الملاحظات | ملخّص | استجابة Chrome |
| المتطلبات المقسَّمة | أضِف شرط السلوك الصريح للسمة "مقسم" في ملفات تعريف الارتباط للطرف الأول. | لقد ناقشنا هذا الأمر خلال مكالمة PrivacyCG، وتابعنا مشكلة GitHub مع إرسال ملاحظات. نواصل العمل مع المتصفّحات والمطوّرين ومنتدى الخصوصية للتوافق مع السلوك وتحديده. |
| التضمينات التي تمت مصادقتها | قد تؤثر CHIPS في تدفق تسجيل الدخول الموحَّد (SSO) الحالي بسبب اختلاف التقسيم الذي يؤثر في الأجزاء التي تمت مصادقتها. | نحن على دراية بحالة استخدام التضمينات التي تمت مصادقتها ونعمل على استكشاف الحلول. |
| حدّ تقسيم ملفات تعريف الارتباط | القلق من أنّ الحدّ الأقصى الحالي لملفات تعريف الارتباط العشرة قد لا يكون كافيًا لحالات استخدام معيّنة. | نحن بصدد الانتقال من الحد الأقصى لعدد ملفات تعريف الارتباط إلى الحد الأقصى للذاكرة 12 كيلوبايت. يتيح لنا ذلك معالجة المشاكل المتعلّقة بحدّ ملفات تعريف الارتباط مع ضمان عدم تأثّر الأداء وذاكرة المتصفّح بالسلب. |
| المخطط الزمني للتجربة والانطلاق | يمكنك تمديد الوقت الإضافي بعد إزالة متطلبات حدود اسم المضيف. | لقد مدّدنا الموعد النهائي لمرحلة التجربة والتقييم بعد تلقّي ملاحظات وآراء من المنظومة المتكاملة. |
| قيود الاختبار في Chrome | إمكانية اختبار CHIPS في Firefox بسبب القيود الحالية في Chrome. | يختلف تنفيذ متصفِّح فايرفوكس تقريبًا، كما أن الحد الأدنى لملفات تعريف الارتباط في المتصفح Chrome، وتقنية CHIPS هي آلية للتفعيل، ولكن يتم تقسيم Firefox بشكلٍ تلقائي. |
| (تم الإبلاغ أيضًا في الربع الثاني)
التضمينات التي تمت مصادقتها |
هل يتم الاحتفاظ بحالة تسجيل الدخول باستخدام CHIPS؟ | تعديل الربع الثالث:
لا يتم حاليًا الاحتفاظ بحالة "تسجيل الدخول"، ولكنّها ليست حالة الاستخدام المقصودة للشرائح. نحن على دراية بحالة استخدام التضمينات التي تمت مصادقتها ونعمل على استكشاف الحلول. |
FedCM
| موضوع الملاحظات | ملخّص | استجابة Chrome |
| (تم الإبلاغ أيضًا في الربع الثاني)
متجهات الهجوم المحتمل |
متجهات الهجوم المحتملة من خلال إضافة الرابط وهجمات التوقيت. | تعديل الربع الثالث:
لقد تعاونّا مع Mozilla للتوصّل إلى مفهوم مشترك حول كيفية التعامل مع مشكلة الهجوم المرتبط بالتوقيت المناسب. يمكنك الاطّلاع على التفاصيل هنا. نعمل الآن على وضع نماذج أولية لهذا التغيير المعماري ونتوقع إجراء التجارب خلال الأرباع القليلة القادمة. |
| موفّرو الهوية | أداة اختيار الحساب: موفِّر هوية واحد طلب السماح بالعديد من موفّري الهوية | لقد عملنا مع مورّدي المتصفِّح وFedID CG بشأن كيفية إتاحة إمكانية السماح بالعديد من موفِّري الهوية، وتوصلنا إلى صيغة تبدو تستحق التجربة. يتوفّر وصف الاقتراح هنا، ونتوقع تطوير نماذج أولية وتنفيذ التجارب خلال الأرباع القليلة المقبلة. |
| المشاكل المعروفة في الاتحاد | طلب سرد الحالات التي قد يواجه فيها الاتحاد مشاكل بشأن الإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية. | يتضمن FedID CG بند عمل يتمثل في تعداد الطرق التي يقطع بها الاتحاد هنا وهنا. ويتعاون الفريق أيضًا على إنشاء مصفوفة قرارات لربط الأعطال بواجهات برمجة تطبيقات Web Platform هنا. |
| راود المعلمة | هل يمكن أن تؤثر مَعلمة اللفظ في تدفق تسجيل الدخول؟ | يمكن اعتبار ذلك تتبُّعًا لمواقع إلكترونية متعددة، ولكننا لا نزال نجمع مدخلات ونحلّل كيفية التعامل مع هذه الحالات. |
| موافقة المستخدم | ربط جهات اعتماد مختلفة (RP) وموافقة المستخدم لكل مصدر | لا يمكن لهذه المواصفات التحكّم في كيفية مشاركة المصادر ضمن النطاق نفسه لملفات تعريف الارتباط. تسمح هذه المواصفات باستخدام المعرّف من مصدر موفّر الهوية (idP) إلى أصل الجهة المحظورة، ولكن يرجع الأمر إلى الجهة المحظورة (RP) في اختيار ما إذا كان يجب تخزين حالة تسجيل دخول المستخدم في ملف تعريف ارتباط مغلق على هذا المصدر المفرد أو ملف تعريف ارتباط مشترك مع المصادر ضمن النطاق نفسه. |
| حساب موفِّر الهوية
إمكانية النقل |
خيار المستخدم لنقل موفِّري الهوية إذا اختاروا ذلك عند النقل بين موفِّري هوية (IdP). | يبدو أن المستخدم يحتاج إلى تنفيذه مباشرةً في صفحة الاشتراك في موفِّر الهوية الجديد الذي يختاره، وليس من خلال واجهة برمجة تطبيقات FedCM. |
| حذف الحساب | إبطال موفّر الهوية (idP) - مع احتساب حذف الحساب باستخدام موفِّر الهوية (idP). | طلب هذه الميزة هذا مفتوح للإدخال وقيد التحقيق. |
| مطالبة واجهة المستخدم | المطالبات المتعلقة بجوانب الواجهة الخاصة بكل متصفح | يمكنك مراجعة طلب السحب لمعالجة هذه المشكلة. |
| التحقق من الإحالة لموفّر الهوية | يتم التحقّق من موفِّر الهوية لمحيل الجهة المحظورة. | تمت إضافة التحقق الإلزامي من مُحيل موفِّر الهوية إلى المواصفات. يُرجى الاطّلاع على طلب السحب. |
| مسار تسجيل الدخول | طلب تخصيص مسارات تسجيل الدخول استنادًا إلى الإعدادات المفضّلة للجهة المحظورة | نحن نرحب بالفكرة ونناقشها بنشاط. |
مكافحة المحتوى غير المرغوب فيه والاحتيال
واجهة برمجة تطبيقات Trust Tokens
| موضوع الملاحظات | ملخّص | استجابة Chrome |
| الاحتيال وإساءة الاستخدام | أدوات لضمان أنّ برنامج التتبُّع لم يخدع جهة إصدار لمنحه رمزًا مميّزًا، وأنّ برنامج التتبُّع لم يستولي على رمز مميّز تم إصداره لمستخدم حقيقي، ومنع برامج التتبُّع من إصدار رموز مميّزة ضارة؟ | وفي حين قد تتمكّن برامج التتبُّع من الحصول على رموز مميزة من جهة الإصدار، ننصح جهات الإصدار بوضع حدود لعدد مرات إصدار الرموز المميّزة والطرق الفعّالة لإصدار الرموز المميّزة وتعديل منطق الإصدار لأنّ الجهات الضارّة تحاول التحايل عليها. من المحتمل أن تصبح جهات الإصدار التي لا تعتمد على منطق قوي في إصدار الرموز المميّزة أقل موثوقية في المنظومة المتكاملة، لأنّ المواقع الإلكترونية تعطي الأولوية لها اعتمادًا على جهات الإصدار الأكثر فعالية. |
| الاحتيال وإساءة الاستخدام | هل هناك طريقة يمكن من خلالها لمستخدمي الرموز المميّزة الموثوق بها تحديد أنّهم لن يقبلوا الرموز المميّزة Trust Tokens إلا من كيانات معيّنة؟ | نعم، هذا ممكن. يوضّح قسم تحصيل قيمة الرمز المميّز الموثوق به في الشرح طريقة تطبيق هذه الطريقة. |
| الاحتيال وإساءة الاستخدام | هل مِن طريقة لجهة إصدار الرموز المميّزة Trust Token لتحديد قائمة بعمليات تحصيل القيمة وعدم السماح لأي شخص آخر بتحصيل قيمة الرموز المميّزة؟ | ليس في الوقت الحالي، ولكن الفريق ينظر حاليًا في حالة الاستخدام هذه. |
| المخطط الزمني | متى سيصبح Trust Token API متاحًا للجميع؟ | سنشارك المزيد من المعلومات بشكل علني عندما نوافق على الالتزام بجدول زمني. |
| (تم الإبلاغ أيضًا في الربع الثاني)
النفقات العامة للصيانة |
ليس من الواضح المدة التي ستظل إصدارات البروتوكول فيها متاحة. | تعديل الربع الثالث:
ويجري حاليًا إضافة المزيد من الدعم في واجهات برمجة التطبيقات لدعم الإصدارات المتعددة المتزامنة للسماح بعملية الانتقال السلس بين الإصدارات، على الرغم من أن الأطر الزمنية للدعم / الإيقاف لا تزال قيد التنفيذ. |