هل يجب على الويب الكشف عن قدرات الأجهزة؟

لقد كنت مؤخرًا مهتمًا بالاختلاف في الآراء بين بائعي المستعرضات المختلفين حول مستقبل الويب - وتحديداً في الجهود المختلفة لدفع إمكانات منصة الويب أقرب إلى الأنظمة الأساسية الأصلية ، مثل مشروع Fugu في Chromium.

يمكن تلخيص المواقف الرئيسية على النحو التالي:

• تعمل Google (جنبًا إلى جنب مع شركاء مثل Intel و Microsoft و Samsung) بقوة على المضي قدمًا والابتكار مع عدد كبير من واجهات برمجة التطبيقات الجديدة مثل تلك الموجودة في Fugu ، وشحنها في Chromium ؛
• تقاوم شركة آبل نهجًا أكثر تحفظًا ، حيث تضع علامة على العديد من واجهات برمجة التطبيقات الجديدة على أنها تثير مخاوف تتعلق بالأمان والخصوصية ؛
• أدى هذا (جنبًا إلى جنب مع قيود Apple على اختيار المتصفح في iOS) إلى إنشاء موقف يصف Safari بأنه IE الجديد مع الادعاء بأن Apple تعمل على إبطاء تقدم الويب ؛
• يبدو أن Mozilla أقرب إلى Apple من Google في هذا الصدد.

أعتزم في هذه المقالة النظر في الادعاءات المحددة مع Google ، وتحديداً تلك الموجودة في نظرية تجاور النظام الأساسي بواسطة قائد مشروع Fugu Alex Russell ، والنظر في الأدلة المقدمة في هذه الادعاءات ، وربما الوصول إلى استنتاجي الخاص.

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

نظرية تجاور المنصة

النظرية المذكورة أعلاه تقدم الادعاءات التالية:

• تنتقل البرمجيات إلى الويب لأنها نسخة أفضل من الحوسبة ؛
• الويب عبارة عن منصة تعريف - منصة مستخلصة من نظام التشغيل الخاص بها ؛
• يعتمد نجاح النظام الأساسي على إنجاز الأشياء التي نتوقع أن تقوم بها معظم أجهزة الكمبيوتر ؛
• رفض إضافة إمكانيات مجاورة لمنصة الويب الوصفية لأسباب أمنية ، مع تجاهل نفس مشكلات الأمان في الأنظمة الأساسية الأصلية ، سيؤدي في النهاية إلى جعل الويب أقل أهمية ؛
• تقوم Apple و Mozilla بفعل ذلك بالضبط - حيث رفضت إضافة إمكانات الحوسبة المجاورة إلى الويب ، وبالتالي "إرسال الويب إلى اللون الكهرماني".

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

المنصات الفوقية

لفهم مصطلح "المنصة الفوقية" ، نظرت إلى ما تستخدمه النظرية لهذا الاسم - جافا وفلاش ، وكلاهما نتاج مطلع الألفية.

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

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

من جانب العميل ، لا يأتي Qt ، وهو إطار عمل متعدد المنصات قائم على C ++ ، مع وقت تشغيل منفصل ، إنه مجرد مكتبة (جيدة) عبر الأنظمة الأساسية لتطوير واجهة المستخدم.

الأمر نفسه ينطبق على Rust - إنها لغة ومدير حزم ، ولكنها لا تعتمد على أوقات التشغيل المثبتة مسبقًا.

تعتبر الطرق الأخرى لتطوير التطبيقات من جانب العميل خاصة بالنظام الأساسي بشكل أساسي ، ولكنها تتضمن أيضًا بعض حلول الأجهزة المحمولة عبر الأنظمة الأساسية مثل Flutter و Xamarin.

القدرات مقابل الوقت

يوضح الرسم البياني الرئيسي في النظرية أهمية المنصات الوصفية على محور القدرات ثنائي الأبعاد مقابل الوقت:

أستطيع أن أرى كيف يكون الرسم البياني أعلاه منطقيًا عند الحديث عن أطر التطوير عبر الأنظمة الأساسية المذكورة أعلاه مثل Qt و Xamarin و Flutter و Rust ، وكذلك لمنصات الخوادم مثل node.js و Java / Scala.

لكن كل ما سبق له اختلاف رئيسي عن الويب.

البعد الثالث

تتنافس المنصات الوصفية المذكورة سابقًا بالفعل ضد أنظمة تشغيل مضيفة في السباق للحصول على القدرات ، ولكن على عكس الويب ، فهي ليست لديها آراء حول الثقة والتوزيع - البعد الثالث ، الذي في رأيي مفقود في الرسم البياني أعلاه.

تعد Qt و Rust طرقًا جيدة لإنشاء تطبيقات يتم توزيعها عبر WebAssembly ، وتنزيلها وتثبيتها مباشرة على نظام التشغيل المضيف ، أو تدار من خلال مديري الحزم مثل توزيعات Cargo أو Linux مثل Ubuntu. تعد كل من React Native و Flutter و Xamarin طرقًا جيدة لإنشاء تطبيقات يتم توزيعها عبر متاجر التطبيقات. عادةً ما يتم توزيع خدمات node.js و Java عبر حاوية عامل إرساء أو جهاز افتراضي أو آلية خادم أخرى.

لا يدرك المستخدمون في الغالب ما تم استخدامه لتطوير المحتوى الخاص بهم ، لكنهم على دراية إلى حد ما بكيفية توزيعه. لا يعرف المستخدمون ما هو Xamarin و node.js ، وإذا تم استبدال تطبيق Swift الخاص بهم يومًا ما بتطبيق Flutter ، فلن يهتم به معظم المستخدمين ، ومن الناحية المثالية لا ينبغي أن يهتموا به.

لكن المستخدمين يعرفون الويب - فهم يعرفون أنه عندما "يتصفحون" في Chrome أو Firefox ، فإنهم "متصلون" ويمكنهم الوصول إلى محتوى لا يثقون به بالضرورة. إنهم يعلمون أن تنزيل البرنامج وتثبيته يمثل خطرًا محتملاً ، وقد يحظره مسؤول تكنولوجيا المعلومات لديهم. في الواقع ، من المهم لمنصة الويب أن يعرف المستخدمون أنهم "يتصفحون الويب" حاليًا. لهذا السبب ، على سبيل المثال ، يُظهر التبديل إلى وضع ملء الشاشة موجهًا واضحًا للمستخدم ، مع إرشادات حول كيفية العودة منه.

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

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

لذلك ، لا يمكن مقارنة الويب بأطر التطوير عبر الأنظمة الأساسية ، دون مراعاة نموذج التوزيع الفريد الخاص بها.

من ناحية أخرى ، تُستخدم تقنيات الويب أيضًا للتطوير عبر الأنظمة الأساسية ، مع أطر مثل Electron و Cordova. لكن هذه ليست بالضبط "الويب". عند مقارنتها بـ Java أو node.js ، يجب استبدال مصطلح "الويب" بمصطلح "تقنيات الويب". ولا تحتاج "تقنيات الويب" المستخدمة بهذه الطريقة بالضرورة إلى أن تكون قائمة على المعايير أو تعمل على متصفحات متعددة. المحادثة حول Fugu APIs عرضية إلى حد ما لإلكترون وكوردوفا.

التطبيقات الأصلية

عند إضافة قدرات إلى منصة الويب ، لا يمكن تجاهل البعد الثالث - نموذج الثقة والتوزيع - أو الاستخفاف به. عندما يدعي المؤلف أن "مواقف Apple و Mozilla بشأن المخاطر من القدرات الجديدة تتناقض مع المخاطر المقبولة للنظام الأساسي الأصلي" ، فإنه يضع الويب والأنظمة الأساسية المحلية في نفس البعد فيما يتعلق بالثقة.

التطبيقات الأصلية الممنوحة لها مشكلات وتحديات أمنية خاصة بها. لكني لا أرى كيف أن هذه حجة لصالح المزيد من إمكانيات الويب ، كما هو الحال هنا. هذه مغالطة - يجب أن يكون الاستنتاج هو إصلاح مشكلات الأمان مع التطبيقات الأصلية ، وليس تخفيف الأمان لتطبيقات الويب لأنها في لعبة اللحاق بالركب ذات الصلة بإمكانيات نظام التشغيل.

لا يمكن مقارنة المحتوى الأصلي والويب من حيث القدرات ، دون مراعاة البعد الثالث للثقة ونموذج التوزيع.

قيود متجر التطبيقات

أحد الانتقادات حول التطبيقات الأصلية في النظرية هو الافتقار إلى اختيار محرك المتصفح على نظام iOS. هذا خيط مشترك من النقد الموجه ضد شركة آبل ، ولكن هناك أكثر من منظور واحد لذلك.

يدور النقد بشكل خاص حول البند 2.5.6 من إرشادات مراجعة متجر تطبيقات Apple:

"يجب أن تستخدم التطبيقات التي تتصفح الويب إطار عمل WebKit وجافا سكريبت WebKit المناسبين."

قد يبدو هذا مخالفًا للمنافسة ، ولدي تحفظي الخاص حول مدى تقييد نظام iOS. لكن لا يمكن قراءة العنصر 2.5.6 بدون سياق بقية إرشادات مراجعة متجر التطبيقات ، على سبيل المثال البند 2.3.12:

"يجب أن تصف التطبيقات بوضوح الميزات الجديدة وتغييرات المنتج في نص" الجديد "."

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

تصبح هذه مشكلة أكبر عندما ترسل المتصفحات ميزات تجريبية ، مثل تلك الموجودة في مشروع Fugu ، والتي لم يتم اعتبارها معيارًا بعد. من الذي يحدد ما هو المتصفح؟ من خلال السماح للتطبيقات بشحن أي إطار عمل ويب ، سيسمح متجر التطبيقات بشكل أساسي لـ "التطبيق" بتشغيل أي رمز غير مدقق ، أو تغيير المنتج بالكامل ، مما يؤدي إلى التحايل على عملية مراجعة المتجر.

بصفتي مستخدمًا لكل من مواقع الويب والتطبيقات ، أعتقد أن لكل منهما مساحة في عالم الحوسبة ، على الرغم من أنني آمل أن ينتقل أكبر قدر ممكن إلى الويب. ولكن عند النظر في الحالة الحالية لمعايير الويب ، وكيف أن بُعد الثقة ووضع الحماية حول أشياء مثل Bluetooth و USB بعيدًا عن الحل ، لا أرى كيف أن السماح للتطبيقات بتنفيذ المحتوى بحرية من الويب سيكون مفيدًا للمستخدمين .

السعي وراء التطبيق

في منشور مدونة آخر ذي صلة ، يتناول نفس المؤلف بعضًا من هذا ، عند التحدث عن التطبيقات المحلية:

"كونك" تطبيقًا "هو مجرد تلبية مجموعة من قواعد نظام التشغيل التعسفية والقابلة للتغيير".

أوافق على فكرة أن تعريف "التطبيق" تعسفي ، وأن تعريفه يعتمد على من يحدد سياسات متجر التطبيقات. لكن اليوم ، الأمر نفسه ينطبق على المتصفحات. الادعاء من المنشور بأن تطبيقات الويب آمنة بشكل افتراضي هو أيضًا تعسفي إلى حد ما. من يرسم الخط في الرمال "ما هو المتصفح"؟ هل تطبيق Facebook المزود بمتصفح مدمج "متصفح"؟

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

كل شيء يمكن أن يكون متصفحًا

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

عندما أستخدم تطبيقًا على iOS ، أعلم أن أفعالي تتعرض حاليًا للاعبين: Apple والشركة المصنعة للتطبيق المحدد. عندما أستخدم موقعًا على الويب على Safari أو في Safari WebView ، فإن أفعالي تتعرض لـ Apple ولصاحب نطاق المستوى الأعلى لموقع الويب الذي أشاهده حاليًا. عندما أستخدم متصفحًا داخل التطبيق مزودًا بمحرك غير معروف ، أتعرض لأبل ، الشركة المصنعة للتطبيق ، ومالك نطاق المستوى الأعلى. يمكن أن يؤدي ذلك إلى حدوث انتهاكات لنفس المصدر يمكن تجنبها ، مثل تتبع مالك التطبيق جميع نقراتي على مواقع الويب الأجنبية.

أوافق على أنه ربما يكون الخط في رمال "WebKit فقط" قاسيًا جدًا. ما هو التعريف البديل للمتصفح الذي لا ينشئ بابًا خلفيًا لتتبع تصفح المستخدم؟

انتقادات أخرى حول شركة آبل

تدعي النظرية أن رفض Apple لتنفيذ الميزات لا يقتصر على مخاوف الخصوصية / الأمان. يتضمن رابطًا يعرض بالفعل الكثير من الميزات التي يتم تنفيذها في Chrome وليس في Safari. ومع ذلك ، عند التمرير لأسفل ، فإنه يسرد أيضًا قدرًا كبيرًا من الميزات الأخرى التي يتم تنفيذها في Safari وليس في Chrome.

يحتوي مشروعا المستعرضين هذين على أولويات مختلفة ، لكنهما بعيدان عن العبارة القاطعة "تصبح اللعبة واضحة عند التصغير" ومن الانتقادات القاسية حول محاولة Apple نشر الويب باللون الكهرماني.

أيضًا ، الروابط التي تحمل عنوان "صعب" ولا نريد أن نحاول أن تقودنا إلى تصريحات Apple بأنهم سيطبقون ميزات في حالة تلبية مخاوف الأمان / الخصوصية. أشعر أن وضع هذه الروابط مع تلك العناوين مضلل.

أود أن أتفق مع عبارة أكثر توازناً ، وهي أن Google أكثر تفاؤلاً من Apple فيما يتعلق بتطبيق الميزات وتطوير الويب.

موجه الإذن

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

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

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

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

أنا أتفق مع الحجة القائلة بأنه يجب على Mozilla & Apple على الأقل محاولة الابتكار في هذا المجال بدلاً من "رفض التنفيذ". لكن ربما هم كذلك؟ أعتقد أن isLoggedIn من Apple ، على سبيل المثال ، هو اقتراح مثير للاهتمام وذات صلة في البعد الثالث الذي يمكن أن تبني عليه واجهات برمجة التطبيقات للأجهزة المستقبلية - على سبيل المثال ، يمكن إتاحة واجهات برمجة التطبيقات للأجهزة المعرضة لبصمات الأصابع عندما يعرف موقع الويب الحالي بالفعل هوية المستخدم.

WebUSB

في القسم التالي سوف أتعمق في WebUSB ، والتحقق مما يسمح به ، وكيف يتم التعامل معه في البعد الثالث - ما هو نموذج الثقة والتوزيع؟ هل يكفي؟ ما هي البدائل؟

المبنى

تسمح واجهة برمجة تطبيقات WebUSB بالوصول الكامل إلى بروتوكول USB لفئات الأجهزة غير المدرجة في القائمة.

يمكنه تحقيق أشياء قوية مثل الاتصال بلوحة Arduino أو تصحيح أخطاء هاتف Android.

من المثير رؤية مقاطع فيديو Suz Hinton حول كيف يمكن لواجهة برمجة التطبيقات هذه أن تساعد في تحقيق أشياء كان تحقيقها مكلفًا للغاية من قبل.

أتمنى حقًا أن تجد المنصات طرقًا لتكون أكثر انفتاحًا وتسمح بالتكرار السريع لمشاريع الأجهزة / البرامج التعليمية ، كمثال.

شعور مضحك

لكن مع ذلك ، أشعر بشعور مضحك عندما ألقي نظرة على ما يمكّن WebUSB ، ومشكلات الأمان الحالية مع USB بشكل عام.

يبدو USB قويًا للغاية كبروتوكول معرض للويب ، حتى مع مطالبات إذن.

لذا فقد بحثت أكثر.

عرض موزيلا الرسمي

لقد بدأت بقراءة ما قاله ديفيد بارون حول سبب رفض Mozilla لـ WebUSB ، في موقف المعايير الرسمية لموزيلا:

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

موجه الإذن الحالي

هذا ما تبدو عليه مطالبة إذن WebUSB من Chrome في وقت نشر هذا المنشور:

مجال معين يريد Foo الاتصال بشريط جهاز معين. لفعل ماذا؟ وكيف لي ان اعرف على وجه اليقين؟

عند منح الوصول إلى الطابعة أو الكاميرا أو الميكروفون أو نظام تحديد المواقع العالمي (GPS) أو حتى عدد قليل من ملفات تعريف WebBluetooth GATT المضمنة مثل مراقبة معدل ضربات القلب ، يكون هذا السؤال واضحًا نسبيًا ويركز على المحتوى أو الإجراء بدلاً من الجهاز . هناك فهم واضح لما هي المعلومات التي أريدها من الجهاز المحيطي أو الإجراء الذي أريد القيام به باستخدامه ، ويتوسط وكيل المستخدم ويتأكد من التعامل مع هذا الإجراء المعين.

USB عام

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

لذلك ، على عكس حالات الطابعة ونظام تحديد المواقع العالمي والكاميرا ، لا يمكنني التفكير في مطالبة من شأنها إبلاغ المستخدم بما يسمح به منح إذن الصفحة للاتصال بجهاز باستخدام WebUSB في مجال المحتوى ، دون فهم عميق لـ جهاز معين وتدقيق الكود الذي يصل إليه.

حادثة يوبيكى والتخفيف

مثال جيد منذ وقت ليس ببعيد هو حادثة Yubikey ، حيث تم استخدام WebUSB من Chrome لتصيد البيانات من جهاز مصادقة يعمل بنظام USB.

نظرًا لأن هذه مشكلة أمنية يُقال أنه تم حلها ، فقد كنت مهتمًا بالغوص في جهود التخفيف من Chrome في Chrome 67 ، والتي تتضمن حظر مجموعة محددة من الأجهزة ومجموعة محددة من الفئات.

فئة / قائمة حظر الجهاز

لذا فإن دفاع Chrome الفعلي ضد عمليات استغلال WebUSB التي حدثت في البرية ، بالإضافة إلى مطالبة الإذن العامة جدًا حاليًا ، كان حظر أجهزة وفئات أجهزة معينة.

قد يكون هذا حلاً مباشرًا لتقنية أو تجربة جديدة ، ولكن سيصبح تحقيقه أصعب وأصعب عندما (وإذا) أصبح WebUSB أكثر شيوعًا.

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

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

الأمان مقابل الميزات

تعتبر نظرية تجاور النظام الأساسي ، في بعض النواحي ، القدرات والأمان لعبة محصلتها صفر ، وأن كونك متحفظًا للغاية بشأن مخاوف الأمان والخصوصية من شأنه أن يتسبب في فقدان الأنظمة الأساسية لأهميتها.

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

ما الذي يجعل WebUSB مختلفًا عن الأجهزة الطرفية الأخرى

في المتصفحات ، هناك تمييز واضح بين تفاعلات المستخدم والتفاعلات التركيبية (التفاعلات التي يتم إنشاء مثيل لها بواسطة صفحة الويب).

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

لذلك حتى مع مواصفات WebUSB الحالية ، يمكن للأجهزة أن تختار تنفيذ عدة واجهات ، على سبيل المثال تصحيح أخطاء adb و HID لإدخال المؤشر ، واستخدام كود ضار يستفيد من ADB ، يصبح راصد لوحة مفاتيح ويتصفح مواقع الويب نيابة عن المستخدم ، بالنظر إلى آلية وميض البرامج الثابتة القابلة للاستغلال الصحيحة.

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

الموافقة المستنيرة والمحتوى

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

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

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

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

النماذج الأولية مقابل المنتج

أستطيع أن أرى استثناء محتمل لهذا. إذا كانت فرضية WebUSB والمشروع الآخر Fugu APIs هي دعم النماذج الأولية بدلاً من الأجهزة على مستوى المنتج ، فإن المطالبات العامة الشاملة يمكن أن تكون منطقية.

ولجعل ذلك قابلاً للتطبيق ، أعتقد أن ما يلي يجب أن يحدث:

1. استخدم لغة في المواصفات التي تحدد التوقعات حول هذا الموضوع للنماذج الأولية ؛
2. اجعل واجهات برمجة التطبيقات هذه متاحة فقط بعد بعض إيماءات الاشتراك ، مثل جعل المستخدم يمكّنها يدويًا في إعدادات المتصفح ؛
3. احصل على مطالبات إذن "مخيفة" ، مثل تلك الخاصة بشهادات SSL غير الصالحة.

عدم وجود ما سبق يجعلني أعتقد أن واجهات برمجة التطبيقات هذه مخصصة لمنتجات حقيقية وليست نماذج أولية ، وعلى هذا النحو ، فإن التعليقات تحمل.

اقتراح بديل

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

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

مباشر وموجه تم التحقق منه

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

مثال الطابعة ثلاثية الأبعاد

في مواصفات WebUSB ، يتم إحضار الطابعات ثلاثية الأبعاد كمثال ، لذلك سأستخدمها هنا.

عند تطوير تطبيق WebUSB لطابعة ثلاثية الأبعاد ، أريد من المتصفح / نظام التشغيل أن يسألني شيئًا ما على غرار السماح لـ AutoDesk 3ds-mask بطباعة نموذج على طابعة CreatBot 3D الخاصة بك؟ ، يتم عرض مربع حوار مستعرض / نظام تشغيل مع بعض معلمات الطباعة ، مثل التحسين والسمك وأبعاد الإخراج ، ومعاينة لما سيتم طباعته. يجب التحقق من جميع هذه المعلمات بواسطة وكيل مستخدم موثوق به ، وليس عن طريق صفحة ويب من محرك الأقراص.

حاليًا ، لا يعرف المستعرض الطابعة ، ويمكنه التحقق فقط من بعض المطالبات في الموجه:

• يحتوي المجال الطالب على شهادة مسجلة في AutoDesk ، لذلك هناك بعض اليقين بأن هذا هو AutoDesk Inc ؛
• الطرفية المطلوبة تسمي نفسها "طابعة CreatBot ثلاثية الأبعاد" ؛
• لم يتم العثور على هذا الجهاز وفئة الجهاز والمجال في قوائم الحظر بالمتصفح ؛
• أجاب المستخدم بـ "نعم" أو "لا" على سؤال عام تم طرحه عليه.

ولكن لإظهار موجه حقيقي ومحاورة مع التفاصيل المذكورة أعلاه ، سيتعين على المتصفح أيضًا التحقق مما يلي:

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

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

بالإضافة إلى ذلك ، فإن إمكانية الطباعة ثلاثية الأبعاد المتخيلة على الويب كاملة الحجم ستفعل أكثر بكثير مما يمكن أن يوفره WebUSB - على سبيل المثال ، التخزين المؤقت وطلبات الطباعة المختلفة في قائمة الانتظار. كيف سيتم التعامل مع ذلك إذا تم إغلاق نافذة المتصفح؟ لم أقم بالبحث في جميع حالات استخدام WebUSB الطرفية المحتملة ، لكنني أعتقد أنه عند النظر إليها من منظور المحتوى / الإجراء ، سيحتاج معظمهم إلى أكثر من وصول USB.

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

الاقتراح: سلطة تدقيق السائقين

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

ولكن ماذا لو كان هناك جزء مدقق من التعليمات البرمجية ، برنامج تشغيل ، استخدم واجهة برمجة تطبيقات WebUSB داخليًا وقام بما يلي:

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

يمكن أن يتأكد تدقيق برنامج تشغيل مثل هذا من أن ما يفعله يرقى إلى مستوى "الطباعة" ، وأنه يحترم المعلمات ، وأنه يُظهر معاينة الطباعة.

أرى أن هذا يشبه المراجع المصدقة ، وهي جزء مهم في نظام الويب البيئي منفصل إلى حد ما عن بائعي المستعرضات.

نقابة السائقين

لا يلزم تدقيق برامج التشغيل بواسطة Google / Apple ، على الرغم من أن بائع المتصفح / نظام التشغيل يمكنه اختيار تدقيق برامج التشغيل من تلقاء نفسه. يمكن أن تعمل مثل سلطات شهادة SSL - المُصدر هو مؤسسة موثوقة للغاية ؛ على سبيل المثال ، الشركة المصنعة لجهاز طرفي معين أو مؤسسة تصادق على العديد من السائقين ، أو منصة مثل Arduino. (أتخيل ظهور مؤسسات مشابهة لـ Let's Encrypt.)

قد يكون كافيًا أن نقول للمستخدمين: "يثق Arduino في أن هذا الرمز سوف يضيء Uno الخاص بك باستخدام هذا البرنامج الثابت" (مع معاينة البرنامج الثابت).

تحفظات

هذا بالطبع لا يخلو من المشاكل المحتملة:

• يمكن أن يكون السائق نفسه عربات التي تجرها الدواب أو ضار. لكن على الأقل تم تدقيقها ؛
• إنه أقل "webby" ويولد عبئًا تنمويًا إضافيًا ؛
• إنه غير موجود اليوم ، ولا يمكن حله من خلال الابتكار الداخلي في محركات المتصفح.

بدائل أخرى

قد تكون البدائل الأخرى هي توحيد وتحسين واجهة برمجة تطبيقات Web Extensions عبر المستعرضات ، وجعل متاجر الوظائف الإضافية للمتصفح الحالية مثل Chrome Web Store إلى حد ما بمثابة سلطة تدقيق للسائق ، والتوسط بين طلبات المستخدم والوصول المحيطي.

ملخص الرأي

إن الجهود الجريئة التي يبذلها المؤلف وجوجل وشركاؤهم لإبقاء شبكة الويب المفتوحة وثيقة الصلة من خلال تعزيز قدراتها هي جهود ملهمة.

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

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

من أجل دعم أشياء مثل إمكانات الأجهزة المفتوحة إلى حد ما في مشروع Fugu ، وعلى وجه التحديد WebUSB ، يحتاج نموذج الثقة للويب إلى التطور إلى ما بعد مطالبات الأذونات وقوائم حظر المجال / الجهاز ، واستلهام الإلهام من الأنظمة البيئية للثقة مثل شهادات المراجع والسلطات توزيعات الطرد.

مزيد من القراءة على SmashingMag:

• كيف يمكن أن يساعد تحسين أداء موقع الويب في إنقاذ الكوكب
• نحو شبكة ويب خالية من الإعلانات: تنويع الاقتصاد عبر الإنترنت
• هل هناك مستقبل بعد كتابة كود رائع؟
• استخدام الأخلاق في تصميم المواقع