سيجبر Google Play قريبًا المطورين على تحميل حزم التطبيقات بدلاً من ملفات APK، مما يثير أسئلة أمنية غير مريحة حول هذا المطلب.
نوفمبر الماضي، أعلنت جوجل سيُطلب من المطورين نشر تطبيقات جديدة على متجر Play باستخدام تنسيق Android App Bundle (AAB) بدلاً من APK. وقبل بضعة أيام فقط، قامت شركة جوجل بتذكير المطورين بهذا المطلب القادم، مما أثار عاصفة من الجدل من المستخدمين الذين يعتقدون أن Google تقضي على ملفات APK، وتزيل التحميل الجانبي، وتعرقل متاجر تطبيقات الطرف الثالث، و ماذا.
صحيح أن Android App Bundles يمثل خروجًا كبيرًا عن تنسيق APK الكلاسيكي الذي قد تكون معتادًا عليه، سواء كمستخدم أو كمطور. في حين أن هناك عددًا لا بأس به من الفوائد لاستخدام حزم التطبيقات، إلا أن هناك جانبًا رئيسيًا واحدًا لإنشاءها يثير قلق بعض المطورين وخبراء الأمان عن حق.
في هذه المقالة، سنغطي الانتقادات التي رأيناها حول التحول إلى Android App Bundles بالإضافة إلى بعض الحلول المقترحة، وسنتحدث أيضًا عن الحل الذي اقترحته Google لهذه المشكلات.
خلفية
ولكن قبل أن يحدث ذلك، نحتاج إلى التحدث قليلاً عن كيفية عمل توزيع التطبيقات على نظام Android بشكل عام. إذا كنت تعرف بالفعل كيفية عمل توقيع التطبيق وحزم التطبيقات، فيمكنك تخطي هذا الجزء.
ملفات APK
بالنسبة للجزء الأكبر، يتم توزيع التطبيقات على Android داخل ملفات APK. يحتوي ملف APK على جميع أكواد التطبيق وموارده، إلى جانب بعض ميزات الأمان مثل بيان التوقيع. عند تثبيت ملف APK، يتم نسخه إلى مجلد معين وإضافته إلى قاعدة بيانات داخلية للتطبيقات المثبتة.
التوقيعات
أثناء التثبيت، يتم أيضًا التحقق من توقيع هذا التطبيق للتأكد من صحته. إذا كان التطبيق مثبتًا بالفعل، فسيقوم Android بالتحقق من توقيع التطبيق الجديد مقابل التوقيع المثبت بالفعل. إذا كان التوقيع غير صالح أو غير متطابق، فسيرفض Android تثبيت التطبيق.
يعد التحقق من التوقيع جزءًا مهمًا من الأمان في Android. فهو يتأكد من أن التطبيق الذي تقوم بتثبيته صالح وعلى الأقل من نفس المصدر الذي قمت بتثبيته بالفعل. على سبيل المثال، إذا قمت بتثبيت، قل، تطبيق Lockscreen Widgets الخاص بي من متجر Play، يمكنك أن تكون متأكدًا بشكل معقول من أنني أنا من وقع عليها وأنها أصلية. إذا حاولت بعد ذلك تثبيت تحديث لـ Lockscreen Widgets من بعض مواقع الطرف الثالث المشبوهة وفشلت، فستعرف أن شخصًا ما تلاعب بملف APK هذا، ربما لإضافة برامج ضارة.
المفتاح المستخدم لتوقيع التطبيق هو (بشكل مثالي) أبداً صدر علنا. يُعرف هذا بالمفتاح الخاص. يتم بعد ذلك استخدام المفتاح الخاص لإنشاء المفتاح الموضح في توقيع التطبيق، والمعروف بالمفتاح العام. هذا ما يستخدمه Android ومتاجر التطبيقات للتحقق من صلاحية التطبيق. لن أتحدث عن كيفية إنشاء مفتاح عام دون الكشف عن المفتاح الخاص، لأنه يتضمن الكثير من عمليات التشفير الرياضية. إذا كنت تريد المزيد من التفاصيل، تحقق من وثائق Google حول توقيع ملفات APK أو قم ببعض الأبحاث حول وظائف الرياضيات ذات الاتجاه الواحد.
ميزة أخرى لتوقيعات التطبيق هي القدرة على تقييد الأذونات فقط للتطبيقات ذات التوقيعات المطابقة. يقوم Android بذلك داخليًا للعديد من الوظائف، حيث يمكن فقط للتطبيقات الموقعة بنفس مفتاح الإطار الوصول إلى ميزات معينة.
حزم التطبيقات
والآن بعد أن قدمنا نظرة عامة سريعة على ملفات APK والتوقيعات، فلنتحدث عن حزم التطبيقات. هذا هو المكان الذي تأتي فيه موارد APK. الموارد هي أشياء مثل التخطيطات والصور والصوت وما إلى ذلك. في الأساس، هم أي شيء ليس كودًا. لدعم تكوينات العرض المختلفة واللغات المختلفة بشكل أفضل، يمكن للمطورين إنشاء إصدارات متعددة من نفس المورد التي يتم استخدامها اعتمادًا على الجهاز واللغة.
ولكن في ملف APK، كل هذه الموارد موجودة، بغض النظر عن ما تستخدمه. ويشغلون مساحة. اعتمادًا على مدى تعقيد تطبيقك، قد يكون هناك الكثير من الموارد غير المستخدمة للعديد من الأجهزة. هذا هو ما تم تصميم حزم التطبيقات لحله. يمكن للمطورين إنشاء حزمة تطبيقات تمامًا مثل APK، ويمكن بعد ذلك تحميل حزمة التطبيقات هذه إلى متجر Play، تمامًا مثل APK.
تستخدم Google بعد ذلك حزمة التطبيقات هذه لإنشاء مجموعة كاملة من ملفات APK المختلفة لتكوينات الأجهزة المختلفة. تحتوي كل حزمة تطبيق فقط على الموارد اللازمة لهذا التكوين. عندما يذهب المستخدم لتنزيل هذا التطبيق، يتم تقديم ملف APK الذي تم إنشاؤه والذي يتوافق مع التكوين الخاص به. ويساعد ذلك في تقليل أحجام تنزيل التطبيقات وتثبيتها، مما يوفر النطاق الترددي ومساحة التخزين.
بالطبع، تثبيت ملف APK خاص بجهازك يعني أنه من الصعب عليك نسخه إلى جهاز آخر وتثبيته دون مشكلة. اعتمادا على وجهة نظرك، يمكن أن يكون هذا أمرا جيدا أو سيئا. فمن ناحية، فإنه يجعل القرصنة أكثر صعوبة، حيث أن المستخدمين لم يعد لديهم التطبيق بأكمله. ومن ناحية أخرى، فإنه يجعل أرشفة التطبيقات بشكل قانوني أكثر صعوبة، لنفس السبب.
توقيع التطبيق
نظرًا لأن حزم تطبيقات Android ليست ملفات APK، فلا يمكنك فقط فتح ملف AAB وتثبيته مباشرة على الجهاز. عندما تقوم بتحميل ملف إلى متجر Play، تستخدم Google الحزمة لإنشاء ملفات APK مختلفة (غير موقعة). يجب بعد ذلك توقيع ملفات APK هذه قبل أن يتم تثبيتها.
بدلاً من مطالبة المطور بالتوقيع وإعادة تحميل ملفات APK التي تم إنشاؤها، تدير Google التوقيع بنفسها بدلاً من ذلك. يستخدم متجر Play إما مفتاحًا جديدًا ينشئه أو يطلب من المطور المفتاح الذي يستخدمه للتوقيع ملفات APK. باستخدام أي من الخيارين، تتولى Google التوقيع العام للمطور وتوفر التحميل مفتاح. تستخدم Google مفتاح التحميل للتحقق الداخلي وتتأكد من أن حزمة التطبيقات (أو APK في بعض الحالات) التي يقوم المطور بتحميلها هي الحزمة الصحيحة.
إذا تم اختراق مفتاح التحميل أو فقده، فيمكن للمطورين طلب مفتاح جديد، ويظل مفتاح التوقيع المستخدم لتوزيع التطبيق دون تغيير.
هناك الكثير فيما يتعلق بتوقيع التطبيق، ولكن هذا هو ما يتعلق بهذه المقالة. إذا أردت، يمكنك قراءة المزيد حول حزم التطبيقات وتسجيل التطبيقات هذه المقالة المتوسطة بقلم Wojtek Kaliciński.
نقد
من الناحية النظرية والعملية، تعد حزم التطبيقات رائعة جدًا. فهي تقلل من استخدام البيانات وحجم التثبيت، كل ذلك دون أن يضطر المستخدم إلى القيام بأي شيء. ولكن بسبب كيفية تنفيذه، أثار بعض المطورين والباحثين الأمنيين مخاوفهم في الأشهر القليلة الماضية. قبل أن ألخص هذه المخاوف، أريد أن أتوقف لحظة لأقول إن معظم ما هو مكتوب أدناه هو بشكل مباشر بناء على سلسلة من المقالات بواسطة المطور مارك ميرفي كومنز وير. يجب عليك بالتأكيد التحقق من مقالاته، لأنها توفر المزيد من التفاصيل والانتقادات من وجهة نظر المطور.
حماية
في نموذج التوزيع الكلاسيكي، يحتفظ المطور بالمفتاح الذي يستخدمه لتوقيع ملف APK خاصًا. لم تتم مشاركتها مطلقًا مع الجمهور ويجب أن يتمكن الأشخاص المصرح لهم فقط من الوصول إليها. وهذا يضمن أن هؤلاء الأشخاص فقط هم من يمكنهم إنشاء ملف APK صالح.
ولكن إذا كنت تستخدم حزم التطبيقات على متجر Play، فإن Google هي الجهة التي تدير المفتاح الذي يوقع ملفات APK التي يتلقاها المستخدمون. ال تقصير سلوك التطبيقات الجديدة التي تم تحميلها على Google Play ابتداءً من أغسطس 2021 هو أن تقوم Google بإنشاء مفتاح التوزيع الخاص بها والذي تحافظ عليه خاصًا من المطور.
تقديم المطورين تطبيقات جديدة ستجعل Google تدير مفتاحهم الخاص لهم بشكل افتراضي، على الرغم من قيام المطورين بإرسال التحديثات إلى التطبيقات الموجودة يمكنه الاستمرار في استخدام ملفات APK أو يمكنهم التبديل إلى توزيع AAB عن طريق إنشاء مفتاح جديد ليستخدمه Google للمستخدمين الجدد. التطبيقات الموجودة ليست مطلوبة للتبديل من توزيع APK إلى Android App Bundles، على الرغم من أن هذا الخيار متاح لهم إذا اختاروا ذلك. بعد بعض المعارضة، جوجل سوف تجعل ذلك ممكنا لتحميل مفتاحك الخاص ليقوم Google بالتوقيع به، لكل من التطبيقات الجديدة والحالية. لا يعد أي من هذه المواقف مثاليًا، بغض النظر عن الأمر، سيكون لدى Google حق الوصول إلى مفتاحك الخاص إذا كنت ترغب في ذلك استخدم Android App Bundles (وليس للمطورين خيار في هذا الشأن إذا كانوا يريدون إرسال تطبيق جديد بعد أغسطس 2021!)
على الرغم من أننا واثقون من أن Google تأخذ الأمان على محمل الجد، إلا أنه لا توجد شركة على وجه الأرض محصنة ضد اختراقات البيانات. إذا كان المفتاح الذي تستخدمه Google لتوقيع تطبيقك للتوزيع موجودًا في أحد هذه الانتهاكات، فيمكن لأي شخص التوقيع على نسخة من تطبيقك وجعلها تبدو وكأنها موقعة بواسطتك. وبعض المطورين وخبراء الأمن ليسوا سعداء بهذا الاحتمال. إنه احتمال ضئيل للغاية، نعم، ولكن حقيقة أنه احتمال على الإطلاق تخيف البعض في مجتمع أمن المعلومات.
إن قيام المطورين بتوقيع ملفات APK لنظام Android يعني أنه يمكن لأي شخص التحقق من ملفات APK من Google Play، ولا يلزم وجود ثقة عمياء. إنه تصميم أنيق يوفر أمانًا يمكن التحقق منه. لكن حزم التطبيقات تقلب ذلك رأسًا على عقب، وتبدو مُصممة لتعزيز تقييد البائع. هناك العديد من الأساليب التقنية البديلة التي من شأنها أن توفر ملفات APK صغيرة لا تزال موقعة من قبل المطورين، ولكن هؤلاء لا يفضلون Play. على سبيل المثال، يمكن إنشاء جميع متغيرات APK وتوقيعها بواسطة المطور، ثم تحميلها إلى أي متجر تطبيقات.
من المؤكد أن هناك حججًا يجب تقديمها حول ما إذا كان من الأفضل ترك التخزين الآمن للمفاتيح الخاصة في أيدي Google أو المطورين الفرديين. لكن هؤلاء المطورين (على الأرجح) لا يستخدمون عادةً مستودعًا مركزيًا لمفاتيحهم. من خلال إجبار المطورين على استخدام Play App Signing، لا يحتاج المهاجم الضار إلا إلى انتهاك أمان Google مرة واحدة لاسترداد آلاف أو ملايين المفاتيح.
من أجل ما يستحق، إليك ما تقوله Google حول كيفية حماية مفتاح التوقيع الخاص بك على بنيتها التحتية:
[blockquote Author="Wojtek Kaliciński, Android Developer Advocate at Google"]عند استخدام Play App Signing، يتم تخزين مفاتيحك على نفس البنية الأساسية التي تستخدمها Google لتخزين مفاتيحها الخاصة.
يخضع الوصول إلى المفتاح إلى قوائم ACL الصارمة ومسارات التدقيق الواضحة للتلاعب لجميع العمليات.
جميع العناصر التي تم إنشاؤها وتوقيعها باستخدام مفتاح المطور متاحة لك في Google Play Console للفحص/التصديق.
علاوة على ذلك، لمنع فقدان المفاتيح، نقوم بعمل نسخ احتياطية متكررة جدًا لوحدة التخزين الأساسية لدينا. يتم تشفير هذه النسخ الاحتياطية بقوة ونقوم بانتظام باختبار الاستعادة من هذه النسخ الاحتياطية.
إذا كنت تريد التعرف على البنية التحتية التقنية لشركة Google، فاقرأ مستندات Google Cloud Security.[/blockquote]
وعلى الرغم من ذلك، فإن كل الأصوات والخسارة والسرقة لا تزال ممكنة. وتساعد مسارات التدقيق فقط في منع الهجمات المستقبلية؛ لن يستعيدوا المفاتيح المكسورة.
إمكانية إجراء تعديلات غير مصرح بها
إحدى المشكلات الكبيرة المتعلقة بالطريقة التي أعدت بها Google حزم التطبيقات هي إمكانية إضافة تعديلات غير مصرح بها إلى التطبيق. تتضمن عملية استخراج ملفات APK من حزمة التطبيقات تعديلات بطبيعتها، حيث يتعين على Google إنشاء كل ملف APK يدويًا. بينما لقد وعدت Google بأنها لن تقوم بإدخال أو تعديل التعليمات البرمجية، المشكلة في عملية حزمة التطبيقات هي أن لديها القدرة على القيام بذلك.
فيما يلي بعض الأمثلة على ما تتمتع به شركة في وضع Google من القدرة على القيام به:
لنفترض أن هناك تطبيق مراسلة آمن يستخدمه الأشخاص للتواصل دون التعرض لخطر المراقبة الحكومية. يمكن أن تكون هذه أداة مفيدة بشكل لا يصدق للأشخاص الذين يحتجون على حكومة استبدادية، أو حتى الأشخاص الذين يريدون فقط الحفاظ على خصوصيتهم. يمكن لتلك الحكومة، التي ترغب في القدرة على رؤية ما يقوله مستخدمو التطبيق، أن تحاول إجبار Google على إضافة باب خلفي للمراقبة إلى رمز التطبيق.
هذا المثال غير ضار إلى حد ما، ولكنه أيضًا أمر يثير قلق بعض الأشخاص. لنفترض أن هناك تطبيقًا يحصل على ملايين التنزيلات يوميًا، لكنه لا يحتوي على أي إعلانات أو تحليلات. هذا مصدر بيانات ضخم ولا توجد طريقة للوصول إلى تلك البيانات. جوجل، كونها شركة إعلانية، قد ترغب في الوصول إلى تلك البيانات.
في نموذج APK الكلاسيكي لتوزيع التطبيقات، لا تستطيع Google تعديل التطبيقات دون تغيير التوقيع. إذا قامت Google بتغيير التوقيع، خاصة على أحد التطبيقات الشائعة، فسوف يلاحظ الأشخاص ذلك لأنه لن يتم تثبيت التحديث. ولكن باستخدام حزم التطبيقات وتوقيع التطبيقات، تستطيع Google إدخال التعليمات البرمجية الخاصة بها بصمت في التطبيقات قبل توزيعها. لن يتغير التوقيع لأن Google ستمتلك مفتاح التوقيع.
لكي نكون واضحين، من غير المرجح أن تحدث هذه الأمثلة. جوجل يميل إلى ببساطة الانسحاب من الأسواق المزعجة تماما، بدلاً من التكيف. ولكن على الرغم من أن هذا غير محتمل، فإنه لا يزال ممكنا. فقط لأن الشركة وعدت بأن شيئًا ما لن يحدث، فهي لا تضمن ذلك.
شفافية الكود
عند سماع Google لهذه المخاوف، قدمت هذا الأسبوع ميزة جديدة تسمى شفافية التعليمات البرمجية لحزم التطبيقات. تتيح ميزة Code Transparency للمطور إنشاء توقيع ثانٍ يتم شحنه مع التطبيق للمستخدمين بشكل أساسي. يجب إنشاء هذا التوقيع الإضافي من مفتاح خاص منفصل لا يستطيع الوصول إليه سوى المطور. ومع ذلك، هناك بعض القيود على هذا الأسلوب.
تغطي شفافية الكود الكود فقط. قد يبدو ذلك واضحًا نظرًا للاسم، ولكنه يعني أيضًا أنه لا يسمح للمستخدمين بالتحقق من الموارد أو البيان أو أي شيء آخر ليس ملف DEX أو مكتبة أصلية. في حين أن التعديلات الضارة على الملفات غير البرمجية عادةً ما يكون لها تأثير أقل بكثير، إلا أنها لا تزال تمثل ثغرة في أمان التطبيق.
هناك مشكلة أخرى تتعلق بشفافية الكود وهي عدم وجود تحقق متأصل. لواحد، إنها ميزة اختيارية، لذلك يتعين على المطورين أن يتذكروا تضمينه في كل ملف APK جديد يقومون بتحميله. في الوقت الحالي، يجب أن يتم ذلك من سطر الأوامر وباستخدام إصدار bundletool الذي لا يأتي مع Android Studio. حتى عندما يقوم أحد المطورين بتضمينه، لا يحتوي Android على أي نوع من التحقق المدمج للتحقق من تطابق بيان Code Transparency مع الكود الموجود في التطبيق.
الأمر متروك للمستخدم النهائي للتحقق بنفسه من خلال مقارنة البيان بالمفتاح العام الذي يمكن للمطور توفيره، أو عن طريق إرسال APK إلى المطور للتحقق.
على الرغم من أن شفافية الكود تسمح بتأكيد عدم تعديل أي تعليمات برمجية في التطبيق، إلا أنها لا تتضمن أي نوع من التحقق لأجزاء أخرى من التطبيق. ليس هناك أيضًا ثقة متأصلة في هذه العملية. يمكنك القول بأنه إذا كنت لا تثق في Google، فمن المحتمل أن تكون على مستوى مهمة التحقق بشكل مستقل، ولكن لماذا يتعين عليك القيام بذلك؟
هناك مشكلات أخرى تتعلق بميزة "شفافية التعليمات البرمجية"، مثل أشار بواسطة مارك ميرفي من كومنز وير. أوصي بقراءة مقالته للحصول على تحليل أكثر تعمقًا لهذه الميزة.
راحة المطور واختياره
السبب الثالث (والأخير لهذه المقالة) هو السبب الذي يجعل بعض المطورين يواجهون مشكلة مع App Bundles وهو تقليل الراحة والاختيار.
إذا قام أحد المطورين بإنشاء تطبيق جديد على متجر Play بعد أن بدأت Google في طلب حزم التطبيقات وقام باختيارها الخيار الافتراضي للسماح لشركة Google بإدارة مفتاح التوقيع، فلن يتمكنوا أبدًا من الوصول إلى هذا التوقيع مفتاح. إذا أراد نفس المطور بعد ذلك توزيع هذا التطبيق على متجر تطبيقات آخر، فسيتعين عليه استخدام مفتاحه الخاص، والذي لن يتطابق مع مفتاح Google.
وهذا يعني أنه سيتعين على المستخدمين إما التثبيت والتحديث من Google Play أو من مصادر خارجية. إذا أرادوا تغيير المصدر، فيجب عليهم إلغاء تثبيت التطبيق بالكامل، مما قد يؤدي إلى فقدان البيانات، وإعادة التثبيت. مجمعات APK مثل APKMirror سيتعين عليك أيضًا التعامل مع التوقيعات الرسمية المتعددة لنفس التطبيق. (من الناحية الفنية، يتعين عليهم القيام بذلك بالفعل لأن توقيع التطبيق يتيح لك إنشاء مفتاح جديد أكثر أمانًا للمستخدمين الجدد، ولكن سيكون الأمر أسوأ بالنسبة لهم وللمواقع الأخرى عندما يقوم الجميع لديه للقيام بذلك.)
تتمثل استجابة Google لهذه المشكلة في استخدام App Bundle Explorer أو Artifact explorer في Play Console لتنزيل ملفات APK الناتجة من الحزمة التي تم تحميلها. وعلى غرار شفافية الكود، لا يعد هذا حلاً كاملاً. سيتم تقسيم ملفات APK التي تم تنزيلها من Play Console لملفات تعريف الأجهزة المختلفة. على الرغم من أن Play Console يدعم تحميل ملفات APK متعددة لإصدار واحد من تطبيق واحد، إلا أن العديد من قنوات التوزيع الأخرى لا تدعم ذلك.
وبالتالي، فإن الكثير من فوائد استخدام حزم التطبيقات تختفي عندما يدير المطورون متاجر متعددة، مما يجعل التوزيع أكثر صعوبة. بالخبر ذلك ويندوز 11 يكون الحصول على دعم تطبيقات أندرويد بفضل Amazon Appstore، يعتقد البعض أن متطلبات حزم التطبيقات ستثبط المطورين عن التوزيع على Amazon. وبطبيعة الحال، فإن الاهتمام الأساسي لشركة Google هو متجر التطبيقات الخاص بها، ولكن هذا هو بالضبط ما يهم هبطتهم في الماء الساخن مع المنافسين يقودهم إلى القيام تغييرات صغيرة وتصالحية لكيفية عمل متاجر تطبيقات الطرف الثالث على Android.
هناك مشكلتان مرتبطتان بمتاجر متعددة هما التوصيل البيني للتطبيقات واختبار إطلاق النار السريع.
لنبدأ بالترابط بين التطبيقات. هل سبق لك تنزيل تطبيق يقفل الميزات خلف نظام حظر الاشتراك غير المدفوع؟ بالتأكيد تقريبا. يضع بعض المطورين الميزات خلف عملية شراء داخل التطبيق، لكن قد يختار آخرون إنشاء تطبيق منفصل ومدفوع. عندما يتم تثبيت هذا التطبيق الإضافي، يتم إلغاء قفل ميزات التطبيق الرئيسية.
ولكن ما الذي يمنع أي شخص من مجرد تثبيت الوظيفة الإضافية من مصدر قرصان؟ حسنًا، هناك الكثير من الخيارات للمطورين، ولكن واحدًا منها على الأقل يتضمن استخدام أذونات محمية بالتوقيع. لنفترض أن التطبيق الرئيسي يعلن عن إذن محمي بالتوقيع. يعلن تطبيق الوظيفة الإضافية بعد ذلك أنه يريد استخدام هذا الإذن. من الناحية المثالية، سيحتوي تطبيق الوظيفة الإضافية أيضًا على نوع من وظيفة التحقق من الترخيص، والتي تتصل بالإنترنت للتأكد من شرعية المستخدم.
إذا كان كلا التطبيقين لهما نفس التوقيع، فسيمنح Android الإذن للتطبيق الإضافي وسيتم اجتياز عمليات التحقق من الحماية من القرصنة. إذا لم يكن لدى تطبيق الوظيفة الإضافية التوقيع الصحيح، فلن يتم منح الإذن، وستفشل عملية التحقق.
باستخدام نموذج توزيع APK الكلاسيكي، يمكن للمستخدم الحصول على أي من التطبيقين من أي مصدر شرعي والانتهاء منه. مع نموذج App Bundle الافتراضي الحالي، لن تتطابق التوقيعات الموجودة على التطبيقات الرئيسية والتطبيقات الإضافية. ستقوم Google بإنشاء مفتاح فريد لكل تطبيق. يمكن للمطور دائمًا التخلص من الإذن المحمي بالتوقيع واستخدام التحقق المباشر من تجزئة التوقيع، لكن هذا أقل أمانًا بكثير.
وبعد ذلك هناك اختبار إطلاق النار السريع. يرسل المستخدمون بريدًا إلكترونيًا للمطورين طوال الوقت حول المشكلات الموجودة في تطبيقاتهم. في بعض الأحيان تكون هذه المشكلات عبارة عن إصلاحات بسيطة: قم بإعادة إظهار المشكلة، وابحث عن المشكلة، ثم أصلحها، ثم قم بتحميل إصدار جديد. لكن في بعض الأحيان لا يكونون كذلك. في بعض الأحيان لا يتمكن المطورون من إعادة إنتاج المشكلة. يمكنهم إصلاح ما يعتقدون أنه المشكلة، ولكن بعد ذلك يتعين على المستخدم اختباره. افترض الآن أن المستخدم قام بتثبيت التطبيق من خلال Google Play.
باستخدام نموذج APK، يمكن للمطور تغيير بعض التعليمات البرمجية وإنشاء ملف APK جديد وتوقيعه وإرساله إلى المستخدم للاختبار. نظرًا لأن توقيع ملف APK الاختباري يتطابق مع الملف الذي قام المستخدم بتثبيته، فهي عملية بسيطة للتحديث والاختبار وتقديم تقرير. مع حزم التطبيقات، ينهار هذا الأمر. نظرًا لأن Google تقوم بتوقيع ملف APK الذي قام المستخدم بتثبيته في الأصل، فلن يتطابق مع توقيع ملف APK الذي يرسله المطور. إذا تم نشر هذا التطبيق بعد الموعد النهائي لحزم التطبيقات، فلن يتمكن المطور من الوصول إلى استخدامات Google الرئيسية. ومن أجل الاختبار، سيتعين على المستخدم إلغاء تثبيت التطبيق الحالي قبل تثبيت الإصدار التجريبي.
هناك مجموعة من المشاكل هنا. أولاً، هناك إزعاج، سواء على جانب المطور أو المستخدم. إن الاضطرار إلى إلغاء تثبيت التطبيق فقط لاختبار الإصلاح ليس بالأمر الممتع. وماذا لو اختفت المشكلة؟ هل كانت التغييرات التي أجراها المطور أم أن ذلك يرجع إلى قيام المستخدم بمسح بيانات التطبيق بشكل فعال؟ يحتوي متجر Play على اختبار داخلي، والذي من المفترض أن يسمح للمطورين بإجراء عمليات إنشاء وتوزيع سريعة، ولكنه يتطلب من المستخدم إلغاء تثبيت إصدار الإصدار أولاً. لا يصلح أي شيء حقًا.
في حالة ما إذا كان كل هذا يبدو وكأنه مجموعة من الهراء الافتراضي، فإليك مثال حقيقي جدًا لمطور سيواجه هذه المشكلات إذا سمح لـ Google بإنشاء مفتاح خاص له: João Dias. إنه مطور تاسكر، إلى جانب مجموعة كاملة من تطبيقات المكونات الإضافية، بما في ذلك مجموعة AutoApps. مع متطلبات حزم التطبيقات الجديدة، قد تصبح دورة تطوير João أكثر تعقيدًا، على الأقل بالنسبة للتطبيقات الجديدة. سيكون إرسال إصدارات الاختبار مباشرة أقل ملاءمة. سيكون التحقق من التراخيص أقل فعالية.
قد يبدو هذا وكأنه حالة متطرفة إلى حد ما، ولكن ليس الأمر كما لو أن João هو مطور صغير، ومن المحتمل أنه ليس وحده. هناك العديد من التطبيقات على متجر Play التي تعتمد على التحقق من التوقيع لاكتشاف المستخدمين غير الشرعيين.
بالطبع، مع الخيار الجديد للمطورين لتحميل مفاتيح التوقيع الخاصة بهم إلى Google، تم تخفيف هذه المشكلات إلى حد ما على الأقل. ولكن يتعين على المطورين الاشتراك لتمكين الخيار لكل تطبيق. إذا لم يحدث ذلك، ستفشل الاتصالات البينية وسيتطلب الدعم السريع تحميل حزمة إلى Google وانتظار إنشاء ملفات APK، قبل إرسال الحزمة الصحيحة إلى المستخدم. بالإضافة إلى ذلك، لا يزال يتعين عليهم مشاركة مفتاحهم الخاص، وهو ما يعيدنا إلى المخاوف التي ناقشناها سابقًا.
حلول
هذه مشكلة قديمة نظرًا لأنه تم الإعلان عن متطلبات حزمة التطبيقات منذ أشهر، لذلك كان هناك عدد لا بأس به من الحلول المقترحة في هذه الأثناء.
أحد الحلول هو تجنب الحاجة إلى توقيع تطبيق Play. بدلاً من إنشاء حزمة تطبيقات تقوم Google بمعالجتها بعد ذلك في ملفات APK وعلامات، يمكن إجراء هذه المعالجة بواسطة Android Studio. بعد ذلك، يمكن للمطورين فقط تحميل ملف ZIP مليء بملفات APK الموقعة محليًا لكل تكوين قد ينشئه Google.
ومع هذا الحل، لن تحتاج Google إلى الوصول إلى مفاتيح المطورين على الإطلاق. ستكون العملية مشابهة جدًا لنموذج توزيع APK الكلاسيكي، ولكنها ستتضمن ملفات APK متعددة وأصغر حجمًا بدلاً من واحدة فقط.
الحل الآخر هو عدم طلب استخدام حزم التطبيقات والاستمرار في السماح للمطورين بتحميل ملفات APK الموقعة محليًا. في حين أن حزم التطبيقات قد تكون كذلك تقديم تجربة أفضل للمستخدم في كثير من الحالات، حيث لا تستفيد بعض التطبيقات فعليًا من تقسيمها حسب التكوين، مع الحد الأدنى من الحجم تخفيض.
إذا نفذت Google كلا هذين الحلين، فلن يضطر المطور الذي يريد استخدام App Bundles إلى تسليمه عبر تسجيل الدخول إلى Google، ولن يضطر المطور الذي لن يستفيد تطبيقه كثيرًا من التنسيق إلى استخدامه في الجميع.
ردود جوجل
التوقيع الذاتي
عندما سُئلوا لأول مرة عن السماح للمطورين بالتعامل مع التوقيع على حزم التطبيقات، كان رد Google غير ملزم على الإطلاق:
[blockquote Author = ""]لذا، تحدثت بإيجاز عن متطلبات العام المقبل للتطبيقات الجديدة لاستخدام حزم التطبيقات، والشيء الوحيد الذي يأتي مع ذلك هو أننا سنطلب توقيع تطبيق Play. لذلك سيحتاج المطورون إما إلى إنشاء مفتاح توقيع التطبيق على Play أو تحميل المفتاح الخاص بهم إلى Play... لأن هذا شرط أساسي لحزم التطبيقات. لقد سمعنا من المطورين أن بعضهم لا يريدون القيام بذلك. لا يريدون إدارة المفاتيح بواسطة Play. وهذا غير ممكن حاليًا إذا كنت تريد استخدام حزم التطبيقات.
لكننا سمعنا تلك التعليقات، و... لا أستطيع التحدث عن أي شيء في الوقت الحالي، ليس لدينا أي شيء لنعلنه، ولكننا نبحث في كيفية التخفيف من بعض هذه المخاوف. ليس من الضروري السماح بالاحتفاظ بمفتاحك الخاص أثناء تحميل الحزم. نحن نبحث في خيارات مختلفة. ليس لدينا حل للإعلان عنه الآن. ولكن، لا يزال أمامنا حوالي عام حتى صدور المطلب، لذلك آمل حقًا أن يكون لدينا إجابة للمطورين لهذا السؤال.[/blockquote]
كان ذلك في أواخر نوفمبر من العام الماضي، ويبدو أن شيئًا لم يحدث. مع بقاء بضعة أشهر فقط قبل تدخل متطلبات حزم التطبيقات حيز التنفيذ، لا توجد حتى الآن طريقة للمطورين للتعامل مع توقيع تطبيقاتهم الخاصة. بينما جعلت جوجل الآن من الممكن رفع مفتاحك الخاص لكل من التطبيقات الجديدة والحالية، فإن هذا لا يزال يأخذ جزء التوقيع من أيدي المطور.
تغييرات الكود
على الرغم من أن جوجل وعدت على وجه التحديد بأن متجر Play لن يقوم بتعديل رمز التطبيق، فإن الوعد ليس ضمانًا. باستخدام حزم التطبيقات وتوقيع التطبيقات، لا توجد قيود فنية نعلم أنها تمنع Google من تعديل التطبيقات التي تم تحميلها قبل التوزيع.
لقد قدمت جوجل شفافية الكود كميزة اختيارية، وعلى الرغم من أن هذا يساعد إلى حد ما، إلا أنه يحتوي على نصيبه العادل من المشاكل، كما ناقشنا سابقًا.
حزم ذاتية الصنع
عندما سُئلت Google عن السماح للمطورين بإنشاء "حزم" تطبيقاتهم الخاصة (ملفات ZIP تحتوي على ملفات APK مقسمة)، كان الرد في الأساس "لن نفعل ذلك":
ربما ليس كما هو موضح في السؤال، لأن هذا من شأنه أن يجعل عملية النشر أكثر صعوبة بالنسبة للمطورين، ونحن نريد في الواقع أن نجعلها أكثر بساطة وأمانًا. ومع ذلك، مرة أخرى، سمعنا هذه التعليقات، وسنبحث في خيارات لكيفية جعل ذلك ممكنًا، ولكن ربما ليس بالطريقة الموضحة هنا.
ومن المثير للاهتمام أن تبرير جوجل يبدو أنه سيجعل النشر أكثر تعقيدًا. ومع ذلك، لا يزال بإمكان Google إجراء العملية تلقائيًا كجزء من مربع حوار إنشاء APK في Android Studio. علاوة على ذلك، إذا كان التطبيق المعني يتم توزيعه على متاجر متعددة، فسيؤدي ذلك بالفعل إلى إنشاء تطبيق أصبحت عملية النشر أكثر بساطة، نظرًا لأن المطورين لن يضطروا إلى إدارة مفاتيح التوقيع المتعددة والشكاوى من المستخدمين.
ومع تقديم شفافية الكود، يبدو أن التعقيد ليس مشكلة على الإطلاق. تتطلب شفافية الكود، في الوقت الحالي على الأقل، من المطور استخدام أداة سطر الأوامر وأن يتحقق المستخدمون بشكل صريح من صحة التطبيق الذي يتم تقديمه لهم. يعد هذا أكثر تعقيدًا من عملية إنشاء الحزم ذاتيًا، ومن غير الواضح سبب كون هذا هو الحل الذي تفضله Google.
للمضي قدما
ستكون حزم التطبيقات هي تنسيق التوزيع المطلوب للتطبيقات الجديدة المقدمة إلى Google Play بدءًا من الأول من أغسطس. على الرغم من أن Google قد عالجت إلى حد ما معظم المشكلات التي أثارها المطورون وخبراء الأمان، إلا أن الردود تترك الكثير مما هو مرغوب فيه. هناك العديد من الفوائد الواضحة لحزم التطبيقات باعتبارها تنسيق توزيع الجيل التالي، ولكن ستكون هناك دائمًا مخاوف مستمرة بشأن منح تحكم جزئي أو كلي في توقيع التطبيق إلى Google.
من المؤكد أن استجابات جوجل وجهودها موضع تقدير، ولكن البعض، مثل مارك ميرفي، يشعرون أنهم لم يذهبوا إلى أبعد من ذلك. مع عدم تنفيذ حلول مثل الحزم ذاتية الصنع، والموعد النهائي لحزم تطبيقات Android مطلوب بسرعة مع اقتراب الوقت، لا يبدو أن المطورين على Google Play سيكونون قادرين على الاحتفاظ بالتحكم الكامل في تطبيقاتهم لفترة طويلة طويل.
سنتحدث عن الآثار المترتبة على متطلبات Android App Bundle في Twitter Space في وقت لاحق بعد ظهر هذا اليوم، لذا انضم إلينا!