ستتضمّن هذه التحديثات حول مستوى التقدّم ملخّصًا للتطوّرات الجديدة والتعديلات التي تم إجراؤها على مقترحات التصميم، والأسئلة والملاحظات الرئيسية التي تلقّيناها، والتعديلات على إصدارات معاينة المطوّرين.
إصدارات جديدة
إطلاق الإصدار 7 من برنامج "معاينة المطوِّر"
يشكّل هذا الإصدار الأخير إنجازًا كبيرًا يشكّل الأساس ل الإصدارات التجريبية القادمة من "مبادرة حماية الخصوصية". يتضمّن هذا الإصدار وظائف إضافية تتعلّق بدعم التوسّط في عرض الإعلانات بدون انقطاع في "شريحة الجمهور المحمية"، وعمليات إعادة التوجيه المتسلسلة لتسجيل حدث تحديد المصدر وإعداد التقارير، وتغييرات أخرى في واجهة برمجة التطبيقات.
سنواصل تعديل مراجع "الإصدار التجريبي للمطوّرين" عند طرح وظائف جديدة في الأشهر المقبلة. ننصحك بالاشتراك لتلقّي آخر الأخبار حول المبادرة.
إصدار الإصدار التجريبي من آذار (مارس) 2023
يشير هذا الإصدار إلى توفّر واجهات برمجة التطبيقات في "مبادرة حماية الخصوصية" على الأجهزة المتاحة للجميع، وهو مكافئ وظيفيًا للإصدار 6 من "معاينة المطوّر". يمكن لمطوّري البرامج الوصول إلى واجهات برمجة التطبيقات في الإصدارات التجريبية من خلال حزمة تطوير البرامج (SDK) للإضافات.
تعديل على المخطط الزمني لإصدارات "الإصدار التجريبي للمطوّرين"
جميع التواريخ والتفاصيل عرضة للتغيير
سيتضمّن كل إصدار تجريبي وإصدار مخصّص للمطوّرين ملاحظات إصدار detailed وأدلة لوصف الوظائف المتاحة وغير المتاحة في كل إصدار.
الميزات المتاحة الآن:
- الإصدار 7 من "معاينة المطوّر": يتضمّن وظائف تتيح لك تصميم عملية دمج باستخدام واجهات برمجة التطبيقات ذات الصلة، بما في ذلك SDK Runtime وTopics وProtected Audience وAttribution Reporting APIs
- يتوفّر برنامج تجريبي لعملية إصدار محدودة. يشير الإصدار العلني في آذار (مارس) 2023 إلى توفّر واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" على الأجهزة المتاحة للجميع، وهو مكافئ وظيفيًا للإصدار 6 من "معاينة المطوّر".
أوائل 2023:
- أول إصدار ثابت لواجهات برمجة التطبيقات التي تحافظ على الخصوصية على نسبة صغيرة من أجهزة Android 13
حتى عام 2023:
- إصدارات إضافية من "إصدارات معاينة المطوّر" وإصدارات ثابتة لواجهات برمجة التطبيقات مع وظائف إضافية إتاحة الميزة للمزيد من المستخدمين وأجهزة Android
تذكير: عندما أعلنّا في شباط (فبراير) عن مبادرة حماية الخصوصية على Android، شدّدنا على أنّه أثناء تصميم هذه الحلول الجديدة وإنشائها واختبارها، نخطّط لإتاحة ميزات منصّة عرض الإعلانات الحالية لمدة عامَين على الأقل، وننوي تقديم إشعار مهم قبل إجراء أي تغييرات مستقبلية.
تعديلات على مقترح التصميم
يوضّح هذا القسم عدّة تعديلات محدّدة على اقتراحات التصميم.
Reflection APIs
في الاقتراح الأصلي لتصميم "وقت تشغيل حزمة SDK"، طلبنا ملاحظات بشأن اقتراحنا بشأن منع الوصول إلى واجهات برمجة التطبيقات لعكس البيانات وتنفيذها، بهدف مساعدة مطوّري حِزم SDK في منع التلاعب بها من خلال حِزم SDK أخرى.
لقد تلقّينا ملاحظات قيّمة حول حالات الاستخدام المتأثرة، وبعد إجراء المزيد من الفحص المتعلّق بالخدمة والمخاطر، سنسمح باستخدام ميزة التأمل وتشغيل واجهات برمجة التطبيقات ضمن وقت تشغيل حزمة SDK، وقد عدّلنا اقتراح التصميم وفقًا لذلك.
ومع ذلك، لن يُسمح لحزمة SDK باستخدام ميزة "العرض المرجعي" أو استدعاء واجهات برمجة التطبيقات في حزمة SDK أخرى مفعَّلة في وقت التشغيل. بدلاً من ذلك، بالنسبة إلى التواصل بين حِزم SDK في "وقت تشغيل حِزم SDK"، نحن بصدد تصميم واجهات برمجة تطبيقات منفصلة لاكتشاف حِزم SDK، وسيتم توضيح ذلك في تحديث مستقبلي.
نحن نبحث باستمرار عن طرق للحدّ من خطر تلاعب حِزم SDK الأخرى، وبالتالي، ما زلنا نقترح منع استخدام رمز JNI في "وقت تشغيل SDK"، وندرس جديًا واجهات برمجة التطبيقات الأخرى. سنشارك في تحديث قادم اقتراحاً كاملاً بشأن واجهات برمجة التطبيقات المحظورة.
Attribution Reporting API
- استنادًا إلى الملاحظات والآراء، أضفنا مثالاً يوضّح كيف يمكن لجهات معنية متعددة معنيّة تسجيل أحداث الإحالات الناجحة ومرّات المشاهدة والنقرات. لقد أضفنا ملاحظات وقضايا جديدة نطلب معرفة أثرها في المستقبل، ونريد معرفة رأيك بها.
Topics API
- تعرض Topics API قائمة تضمّ ما يصل إلى 3 مواضيع، موضوع واحد لكلّ من 3 مراحل سابقة (على سبيل المثال، خلال الأسابيع الثلاثة الماضية). لقد عدّلنا الاقتراح التقني لـ Topics API لتوضيح أنّ المواضيع التي يتم عرضها تمثّل اهتمامات المستخدم وأنّه يمكن استخدام جميع المواضيع المعروضة لتخصيص الإعلانات.
ملخّص للأسئلة والملاحظات الإضافية التي تمّ تلقّيها
يعرض هذا القسم بعض الأسئلة والملاحظات التي تلقيناها، إلى جانب ردودنا.
أسئلة عامة
- هل ستسري "مبادرة حماية الخصوصية" على Android على أجهزة التلفزيون المتّصلة؟
- تركز اقتراحات التصميم الحالية على توفير حالات استخدام مناسبة للأجهزة والتطبيقات الجوّالة. ونخطط لمشاركة المزيد من المعلومات حول أشكال أجهزة Android الأخرى في المستقبل.
- كيف سيتم طرح "مبادرة حماية الخصوصية" على Android على الأجهزة للإصدار التجريبي؟
- لطرح التحديثات للمستخدمين بشكلٍ مرن بمرور الوقت، سيتم توزيع المكونات الرئيسية كمكوّنات رئيسية على أجهزة Android الجوّالة المتوافقة. سيسمح لنا ذلك بتقديم تحسينات على الأجهزة المتوافقة بطريقة سلسة، خارج دورة الإصدار العادية لنظام Android الأساسي.
- ما هي خطتك للحصول على دعم بلغة Kotlin؟
- نحن نعمل على تكرار تصميم Privacy Sandbox API وننوي السماح للمطوّرين بكتابة رمز برمجي مألوف بلغة Kotlin. تتوفّر موارد المطوّرين ذات الصلة، مثل عيّنات التطبيقات في إصدار "معاينة المطوّر"، في IDE Kotlin (بالإضافة إلى Java).
- ما هي عناصر التحكّم على مستوى المستخدم في "مبادرة حماية الخصوصية" وما هي المخططات الزمنية المتوقّعة لطرح عناصر التحكّم هذه؟
لا تزال التصاميم النهائية قيد التطوير، ولكن خلال الفترة التجريبية، ننوي تزويد المستخدمين بعناصر تحكّم في إعدادات الجهاز لإجراء ما يلي:
- الخروج من حلول "مبادرة حماية الخصوصية" أو الانضمام إليها مجددًا
- إزالة مواضيع مستنتجة معيّنة من Topics API
- هل يمكن للمنظومات المتكاملة لمتجر التطبيقات غير Google Play استخدام حلول "مبادرة حماية الخصوصية"؟
تشكّل جميع حلول "مبادرة حماية الخصوصية" جزءًا من "مشروع Android المفتوح المصدر" (AOSP)، لذا يمكن لمتاجر التطبيقات الأخرى استخدامها إذا أرادت ذلك. يمكنك التواصل مع متاجر التطبيقات التي تتعامل معها لفهم خططها بشكل أفضل.
وقت تشغيل حزمة تطوير البرامج (SDK)
- كيف سيتمّ إدارة إصدارات حِزم SDK بموجب هذه الاقتراحات؟ هل ستتمكّن التطبيقات من التحكّم في التبعيات المتعلقة بإصدارات حِزم SDK إذا كان بإمكان المورّدين تحديث حِزم SDK الخاصة بهم بشكل مستقل؟
يتم حاليًا تصميم هذه الميزة، ومن بين الحلول التي ننظر فيها أن يحدِّد مطوّرو حِزم SDK الإصدار
major.minor.patchمن أي حزمة SDK يختارون توزيعها من خلال متجر تطبيقات متوافق مع "وقت تشغيل حزمة SDK".يمكن لمطوّري التطبيقات بعد ذلك اختيار إصدار
major.minorالذي يريدون الاعتماد عليه من خلال الإفصاح عنه في بيان التطبيق. سيتم تثبيت أحدث إصدار من تصحيح الإصدارmajor.minorإلى أن يتم طرح الإصدار التالي من التصحيح (الذي سيتم تثبيته تلقائيًا) أو إلى أن يعيد مطوّر التطبيق بناء تطبيقه مع تحديد تبعية مختلفة لإصدارmajor.minor.- ما هي أنواع حِزم SDK التي يستهدفها SDK Runtime؟
تم تصميم الإصدار الأولي من "وقت تشغيل SDK" لدعم حالات استخدام حِزم SDK ذات الصلة بالإعلانات، بما في ذلك حِزم SDK التي تتيح عرض الإعلانات وقياس أدائها والاحتيال في الإعلانات ورصد إساءة الاستخدام.
على الرغم من أنّ التركيز الأولي ينصبّ على حِزم SDK ذات الصلة بالإعلانات، فإنّ مطوّري حِزم SDK غير المتعلقة بالإعلانات، والتي يسعون إلى وضع أسس احترافية للخصوصية ويعتقدون أنّ بإمكانهم العمل في ظل الشروط الموضّحة أعلاه يمكنهم مشاركة ملاحظات حول تشغيل حِزم SDK في "وقت تشغيل SDK".
- نستخدم حاليًا أذونات خارج تلك المُحدّدة في الاقتراح لحالات الاستخدام. هل يمكننا طلب أذونات إضافية؟
نحن حريصون على فهم حالات الاستخدام المتعلّقة بالإعلانات التي تتطلّب أذونات وصول محدّدة تتجاوز تلك الواردة في اقتراح التصميم الأولي.
- هل سيؤدي نقل حِزم SDK إلى عملية SDK Runtime إلى توفير مساحة أو تقليل حجم التنزيل؟
في حال دمج عدة تطبيقات مع حِزم تطوير برامج (SDK) فردية يتم تفعيلها في وقت التشغيل من الإصدار نفسه، سيوفّر ذلك حجم التنزيل ومساحة القرص.
- هل يعتمد إذن حزمة تطوير البرامج (SDK) للوصول إلى المعرّف الإعلاني على Android (AD_ID) على أذونات التطبيق؟
تعتمد قدرة حزمة تطوير البرامج (SDK) لإعادة التفاعل على الوصول إلى المعرّف الإعلاني على Android على كلّ من التطبيق وحزمة SDK التي تعلن عن الإذن في بيان التطبيق. في اقتراح قادم، سنحدّد بالتفصيل واجهة برمجة التطبيقات التي ستتمكّن حِزم SDK من استخدامها للحصول على المعرّف الإعلاني على Android إذا كانت تمتلك الإذن.
- عناوين IP وإصدارات نظام التشغيل والبيانات البديلة: هل ستكون هذه البيانات متاحة لحِزم SDK ذات الصلة بالإعلانات؟
نحن نعمل حاليًا على مراجعة سمات النظام التي يمكن لحِزم SDK المتعلّقة بالإعلانات الوصول إليها، وسيتمّ مشاركة هذه المعلومات في تعديل قادم على اقتراح التصميم. لم ننشر أي سياسة بشأن استخدام هذه المواقع.
- هل رقم تعريف مجموعة التطبيقات الذي تجمعها حزمة تطوير البرامج (SDK) متطابق في العديد من التطبيقات حتى عندما تنتمي هذه التطبيقات إلى حسابات مطوِّرين مختلفة على Google Play؟ كيف يمكننا حظر المستخدمين الاحتياليين في تطبيقات متعددة بدون المعرِّف الإعلاني على Android؟
لا يمكن لأي تطبيق أو أي من حِزم SDK الخاصة به الوصول إلا إلى قيمة رقم تعريف مجموعة التطبيقات المرتبطة بحساب المطوِّر على Google Play للتطبيق المضيف. لن تقدّم "مبادرة حماية الخصوصية" على Android معرّفًا على مستوى الناشرِين لأغراض تتعلّق بالاختراق. في الوقت الحالي، يمكن للمطوّرين استخدام عنوان IP كبديل أقل قليلاً اتساقًا.
المواضيع
- هل يمكنني الاطّلاع على قائمة بجميع المواضيع المحتمَلة التي يمكن أن تعرِضها واجهة برمجة التطبيقات؟
- لأغراض الاختبار، تستخدِم الإصدارات التجريبية للمطوّرين 1 مواضيع من هذا التصنيف، الذي يخضع للتغيير. ونتوقّع تطوير هذه الميزة بمرور الوقت استنادًا إلى الملاحظات الواردة من المنظومة المتكاملة.
- إذا كان تصنيف "المواضيع" خاضعًا للتغيير، كيف يمكننا تفسير هذه التغييرات في نماذج جانب الشراء في مرحلة ما بعد الإطلاق؟
- سيتضمّن ردّ Topics API رقم إصدار للمصنّف و التصنيف.
ميزة "الجمهور المحمي" على Android
- هل سيتوفّر استهداف الاستبعاد في ميزة "شريحة الجمهور المحمية"؟
لا يتيح التصميم المقترَح الحالي الاستهداف السلبي استنادًا إلى شريحة جمهور مخصّصة في ميزة "شريحة الجمهور المحمية".
بالنسبة إلى "حملات تثبيت التطبيقات"، سنوفّر وظيفة فلترة الإعلانات لموفّري تكنولوجيا الإعلان من أجل فلترة التطبيقات المثبَّتة. ونستكشف أيضًا كيفية دعم متطلبات التصفية السلبية للحملات المستندة إلى تحديد عدد مرات الظهور. سيتم تقديم المزيد من التفاصيل في التحديثات القادمة المتعلّقة باقتراح التصميم.
- هل يمكن إنشاء شرائح جمهور مخصّصة بواسطة شبكات إعلانات البائعين؟ أم أنها تقتصر على شبكات إعلانات المشترين؟
يركز اقتراحنا الحالي لشرائح الجمهور المخصّصة على حالة استخدام "جهة الشراء"، نظرًا لأنّها مخصّصة لدعم إنشاء عروض أسعار جهة الشراء لحالة استخدام تجديد النشاط التسويقي بطريقة تحافظ على الخصوصية.
تقارير تحديد المصدر
- هل ستعمل واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" معًا لدعم حالات الاستخدام المستندة إلى الويب إلى التطبيق والتطبيق على الويب؟
- نحن نستكشف حالات الاستخدام التي يستدعي فيها تطبيق متصفّح على الأجهزة الجوّالة واجهة برمجة التطبيقات Attribution Reporting API من Android لتفعيل تحديد المصدر على مستوى التطبيق والويب على الجهاز نفسه. إذا اخترت تفعيل ميزة "الانتقال من التطبيق إلى الويب"، سيتم استخدام واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" لنظام التشغيل Android للتخزين والإحالة، وسيتم إزالة تكرار الإحالات على مستوى التطبيق والويب (على الرغم من أنّه قد يصلك تقارير منفصلة عن التطبيق والويب من واجهة برمجة التطبيقات والتي يجب دمجها).
- هل تتيح واجهة برمجة التطبيقات نماذج تحديد مصدر أخرى إلى جانب النقرة الأخيرة؟
- تتيح واجهة برمجة التطبيقات نموذج تحديد مصدر بالاستناد إلى الأولوية للمصدر. بالإضافة إلى ذلك، يتيح الاقتراح منطق تحديد مصدر اختياري للإحالات الناجحة بعد التثبيت لتحديد مصدرها إلى النقرة أو المشاهدة التي أدّت إلى التثبيت.
- هل ستؤثّر "مبادرة حماية الخصوصية" في مُحيل عمليات التثبيت على Play؟
استنادًا إلى التصميم والخطط الحالية، لن تؤثر واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" في الوظائف التي يوفّرها تطبيق Play Install Referrer.
حدّد بعض المطوّرين أشكال إعلانات يمكن من خلالها "مكافأة" المستخدمين مقابل إكمال أحداث معيّنة بعد النقر. بدون تحديد المصدر على مستوى المستخدم، سيكون من الصعب تنفيذ ذلك وفقًا للاقتراحات الحالية.
نحن ننظر في هذه المشكلة لتحديد الحلول الممكنة. ونشجّع على تقديم ملاحظات إضافية حول حالة الاستخدام هذه وحالات الاستخدام الأخرى التي قد تكون متوفّرة.
- لماذا تحدث عملية تحديد المصدر بشكل مستقل لكل منصة تكنولوجيا إعلانية؟
يعتقد العديد من المعلِنين اليوم أنّه من المهم الحصول على عرض مُزيل للتكرار لأحداث إحالاتهم الناجحة على جميع الشبكات، ومن الشائع استخدام شريك قياس أداء على الأجهزة الجوّالة (MMP). وسيظلّ من السهل إجراء ذلك باستخدام واجهات برمجة التطبيقات الجديدة، ولكنّها تسهّل أيضًا على المنصات التقنية الفردية أو المعلِنين إجراء القياس مباشرةً إذا أرادت ذلك.
يعني استخدام عمليات إعادة التوجيه أنّك لست بحاجة إلى حزمة SDK في كل تطبيق، ولكنك بحاجة إلى علاقة مع حِزم SDK لتكنولوجيا الإعلان كي تتمكّن من الاشتراك في عملية إعادة التوجيه.
ومن المزايا الرئيسية لهذا النهج أنّه يمكن للجميع الحصول على بياناته الوصفية ومفاتيح التجميع الخاصة به لتطبيق منطق نشاطه التجاري، بالإضافة إلى تحديد أولويته.
- هل هناك أي عمليات تحقُّق أو تحقّق من عمليات التثبيت من "متجر Play"؟
لا تُستخدَم عمليات التثبيت التي تم التحقّق من صحتها إلا لمنطق تحديد المصدر الاختياري للإحالة الناجحة بعد التثبيت. لن ترسِل واجهة برمجة التطبيقات عمليات التثبيت التي تم التحقّق من صحتها. لن ترسل واجهة برمجة التطبيقات تقارير إلا استنادًا إلى الإحالات الناجحة المسجّلة،ولن تعرِض أي إشارة بشأن ما إذا كان المستخدم قد ثبَّت التطبيق من قبل.
- هل تُجري أي عمليات تحقّق من النقرات أو المشاهدات؟ هل هناك حدّ أدنى لمدة التحقّق من العرض؟
يدعم اقتراح واجهة برمجة التطبيقات الحالي التحقق الأساسي من صحة النقر من خلال الإدخالEvent. ونحن نبحث في نماذج أكثر فعالية للتحقق من صحة النقرات وصحة العرض. ونشجّع على تقديم ملاحظات إضافية حول حالات الاستخدام هذه، لا سيما أنواع تعريفات الاطِّلاع التي قد تكون مفيدة للمنظومة المتكاملة.