تقدم Google تفاصيل مقترح تصميم SDK Runtime لـ Android Privacy Sandbox

لقد رأينا مؤخرًا أن كلاً من Apple وGoogle يسعىان جاهدين لإنشاء نظام بيئي أكثر وعيًا بالخصوصية عندما يتعلق الأمر بالإعلانات. مع Apple، كان ذلك من خلال تقديم زر لمنع التطبيقات من تتبعك، ومع Google، كان الأمر كذلك مبادرة حماية خصوصية Android. وبينما كانت المعلومات شحيحة خلال إعلانها، فقد ظهرت المزيد من التفاصيل حول "SDK Runtime" الذي يشمل جزءًا من حل Google للإعلان والخصوصية.

يتكون Android Privacy Sandbox من مكونين رئيسيين - SDK Runtime وواجهات برمجة التطبيقات للحفاظ على الخصوصية - والتي سيتم توزيعها كمكونات نظام معيارية، والتي قد تتذكرها مشروع الخط الرئيسي. قامت Google منذ ذلك الحين بنشر وثائق المطورين المحيطة بـ SDK Runtime وكيف ستعمل على تعزيز خصوصية المستخدم. تقول الشركة أن SDK Runtime سيسمح لحزم SDK التابعة لجهات خارجية بالعمل في بيئة تشغيل مخصصة في أندرويد 13، بعيدًا عن رمز التطبيق.

في Android، يعمل كل تطبيق في وضع الحماية بأذوناته الخاصة ويختلف الوصول إلى النظام اعتمادًا على الوصول الممنوح.

على حد تعبير جوجل، "إذا حاول التطبيق "أ" القيام بشيء ضار، مثل قراءة بيانات التطبيق "ب" أو الاتصال بالهاتف دون إذن، فسيتم منعه من القيام بذلك لأنه لا يملك امتيازات المستخدم الافتراضية المناسبة." يعمل SDK Runtime على توسيع نطاق الحماية هذا لتنفيذ حزم SDK التابعة لجهات خارجية في بيئة وقت تشغيل مخصصة، بعيدًا عن أي أداة محددة برنامج.

لماذا يوجد وقت تشغيل SDK

تريد Google منع حزم SDK للمعلنين من جمع البيانات التي لا ينبغي لها الوصول إليها بشكل ضار (أو حتى عن غير قصد) نتيجة لمشاركة وضع حماية التطبيق المضيف. عندما يتم تنفيذ SDK للإعلان داخل التطبيق، فإنه يتمتع بإمكانية الوصول إلى كل ما يفعله التطبيق أيضًا، وقد لا يكون مطور التطبيق على دراية تامة بحجم الوصول الفعلي. ومن خلال إزالة رمز المعلن هذا وتنفيذه في وقت التشغيل الخاص به، فإنه لا يمكنه الوصول إلا إلى البيانات التي يشاركها المطور صراحةً معه.

ونتيجة لذلك، تقول Google أن SDK Runtime يوفر الضمانات والضمانات الأقوى التالية حول جمع بيانات المستخدم ومشاركتها:

• بيئة تنفيذ معدلة
• أذونات محددة جيدًا وحقوق الوصول إلى البيانات لحزم SDK

يركز الإصدار الأول من SDK Runtime بشكل كامل على حزم SDK ذات الصلة بالإعلانات، بما في ذلك حزم SDK التي تتيح عرض الإعلانات، وقياس الإعلانات، والاحتيال في الإعلانات، واكتشاف إساءة الاستخدام.

كيف يعمل وقت تشغيل SDK

حاليًا، بدون وقت تشغيل SDK، ستستدعي عملية التطبيق SDK وسيتم تنفيذ SDK داخل نفس وضع الحماية مثل بقية التعليمات البرمجية للتطبيق. تريد Google من المطورين أن يكون لديهم بدلاً من ذلك واجهة لـ SDK تعمل في العملية الأمامية للتطبيق، ويمكن لهذه الواجهة بعد ذلك الاتصال ببيانات محددة ومشاركتها ذهابًا وإيابًا مع SDK الحالي المستخدمة.

قبل

بعد

يوضح الرسم التخطيطي "قبل" (الأول) أن رمز استدعاء SDK، بالإضافة إلى مجموعات SDK التي تتلقى المكالمات من هذا الرمز، كلها موجودة في عملية التطبيق. وهذا يعني أن SDK يمكنه الوصول إلى جميع البيانات التي يستطيع التطبيق الوصول إليها. يوضح الرسم التخطيطي "بعد" (الثاني) أنه في العملية الأمامية للتطبيق، يتصل رمز استدعاء SDK بواجهات SDK. تعبر هذه الواجهات بعد ذلك حدود العملية إلى عملية تشغيل SDK لاستدعاء حزم SDK نفسها. وهذا يعني أن SDK المستخدم لا يمكنه الوصول إلى ما يريده فحسب، بل يمكن تزويده فقط بالمعلومات من التطبيق الذي يعمل بجانبه.

نموذج توزيع جديد موثوق به لحزم SDK

في الوقت الحالي، عندما تقوم بتنزيل تطبيق باستخدام حزم SDK تابعة لجهات خارجية، يتم تضمينها بواسطة المطور في التطبيق الذي يتم تحميله وتوزيعه على متجر Google Play. بدلاً من ذلك، تريد Google أن يتم تنزيل التطبيق عند تثبيت تطبيق على هاتفك يستخدم حزم SDK هذه. بشكل منفصل من التطبيق نفسه. وهذا يعني أن مطوري SDK يمكنهم إجراء تغييرات غير منقسمة (أي عدم إجراء تغييرات على واجهات برمجة التطبيقات أو دلالاتها) إلى حزم SDK الخاصة بهم وتوزيعها على الأجهزة دون أي تدخل من التطبيق المطورين.

وفي المقابل، يمكن نشر تغييرات SDK غير المنفصلة أو التراجع عنها، دون الحاجة بالضرورة إلى الانتظار لمطوري التطبيقات إعادة بناء تطبيقاتهم باستخدام حزم SDK الجديدة، أو انتظار المستخدمين النهائيين لتحديث تطبيقاتهم تطبيقات. ستظل التغييرات العاجلة التي تغير واجهات برمجة التطبيقات ودلالاتها بحاجة إلى التحديث من قبل مطوري التطبيقات، ولكن يمكن لمطوري SDK الحصول على أحدث ما لديهم من تغييرات غير قابلة للكسر التغييرات والإصلاحات بسرعة أكبر وبشكل أكثر اتساقًا لعدد أكبر من الأشخاص في وقت واحد، دون الاعتماد على مطور التطبيق لتحديث التطبيق والحزمة في الإصدار الجديد SDK.

قبل

بعد

يوضح الرسم التخطيطي "قبل" بالضبط كيفية توزيع التطبيقات باستخدام حزم SDK الآن. يتم تجميعها في تطبيق، والتطبيق هو ما يتم إرساله إلى متجر Google Play. في الرسم التخطيطي "ما بعد"، لم يعد مطورو SDK يضعون مجموعات SDK الخاصة بهم مباشرة في التطبيقات؛ بدلاً من ذلك، سيقوم مطورو SDK بتحميل SDK ونشره على متجر Google Play. سيتعامل متجر Google Play بعد ذلك مع توزيع التطبيقات، إلى جانب أي تبعيات SDK، على أجهزة المستخدم النهائي. تستخدم Google أيضًا عبارة "متجر التطبيقات" عمدًا في مخططاتها، حيث إنها حل مفتوح وعام يمكن أن يعمل عبر المتاجر الأخرى.

تغييرات على كيفية إنشاء حزم SDK والتطبيقات وتشغيلها وتوزيعها

يقترح الاقتراح الأولي لـ SDK Runtime سلسلة من التغييرات عبر خمسة مجالات رئيسية:

• وصول
• تنفيذ
• مجال الاتصالات
• تطوير
• توزيع

تريد Google تحديد مجموعة الأذونات التالية لوقت تشغيل SDK:

• INTERNET: الوصول إلى الإنترنت لتتمكن من التواصل مع خدمة الويب.
• ACCESS_NETWORK_STATE: الوصول إلى المعلومات حول الشبكات.
• أذونات الوصول إلى واجهات برمجة التطبيقات التي تحافظ على الخصوصية، والتي توفر إمكانات إعلانية أساسية دون الحاجة إلى الوصول إلى المعرفات عبر التطبيقات. لم يتم الانتهاء من أسماء الأذونات ولكن سيتم تقييد واجهات برمجة التطبيقات هذه من خلال وصول التطبيق إلى هذه الأذونات.
• AD_ID: القدرة على طلب معرف الإعلان. سيتم أيضًا تقييد هذا من خلال وصول التطبيق إلى هذا الإذن.
• BIND_GET_INSTALL_REFERRER_SERVICE: القدرة على استخدام Google Play Install Referrer API لإسناد مصدر تثبيت التطبيق.

تريد الشركة أيضًا تقييد وصول حزم SDK إلى ذاكرة التطبيق قيد التشغيل، ولكن أيضًا منع التطبيق من الوصول إلى بيانات SDK الخاصة أيضًا. لن يتمكن التطبيق من الوصول مباشرة إلى مساحة تخزين SDK الخاصة به، والعكس صحيح، لن يتمكن التخزين الخارجي من ذلك مفتوحة لمجموعات تطوير البرامج (SDKs)، وسيكون هناك مساحة تخزين يمكن الوصول إليها لجميع مجموعات تطوير البرامج (SDKs)، ومساحة تخزين خاصة لمجموعة محددة SDK.

أما بالنسبة لكيفية تشغيل حزم SDK، فسيتم تشغيلها بأولوية أقل قليلاً من التطبيق نفسه. وهذا يعني أنه من المحتمل جدًا أن يتم إنهاء التطبيق بعد وقت قصير من إنهاء SDK Runtime إذا نشأ موقف يتطلب إغلاقه من قبل النظام. وفي حالة عدم إنهائه في نفس الوقت، أو في حالة وجود سبب مختلف، فإن الاقتراح يقدم أساليب رد الاتصال ذات الصلة بدورة الحياة لمطوري التطبيقات ليتمكنوا من التعامل مع هذا الاستثناء وإعادة تهيئة SDK مدة العرض. لن تتمكن حزم SDK الخاصة بوقت التشغيل من استخدام واجهات برمجة تطبيقات الإشعارات لإرسال إشعارات المستخدم في أي وقت.

أخيرًا، تشير جوجل إلى أن هذا اقتراح عام وليس فريدًا لأي متجر تطبيقات معين. على الرغم من أنه من المفترض أن يتم دمجه في متجر Google Play، فلا يوجد سبب يمنع متاجر التطبيقات الأخرى من دمج بنية مماثلة. تقول جوجل أن الفوائد التالية واضحة:

• ضمان جودة واتساق SDKs.
• تبسيط النشر لمطوري SDK.
• الإسراع في نشر تحديثات إصدار SDK الثانوية للتطبيقات المثبتة.

تبدو آلية حماية خصوصية Android واعدة

الجدول الزمني لشركة Google للإصدار هو أن الربع الأول من عام 2022 يتضمن مقترحات التصميم الأولية وتعليقات التصميم والتكرارات. ستأتي معاينات المطورين في وقت لاحق من العام، مع إصدار تجريبي في نهاية العام. وأخيرًا، سيشهد عام 2023 بدء الاختبارات الموسعة. ستكون هذه المعاينات والإصدارات التجريبية مستقلة عن إيقاع إصدار Android 13. وستكون هناك أيضًا عناصر تحكم تواجه المستخدم في تطبيق الإعدادات، بمجرد طرحها.

في رأيي، Sandbox للخصوصية في Android تبدو واعدة، ولكن علينا أن ننتظر ونرى كيف ستنفذها الشركة. من المحتمل جدًا أن المطورين لن يعجبهم ذلك، أو أنه سيسبب مشاكل أكثر مما يحل. يتم تشجيع المطورين على قراءة الوثائق التي نشرتها Google للتعرف بشكل أفضل على ما سيأتي في مستقبل خصوصية Android.

وهذا حاليًا اقتراح وليس نظرة نهائية لماهية بالضبط سيحدث في إصدار Android المستقبلي، ولكن من المحتمل أن ينتهي به الأمر قريبًا جدًا. سنراقب أي تطورات أخرى!

---

مصدر: وثائق مطوري أندرويد