Haruskah Web Mengekspos Kemampuan Perangkat Keras?

Baru-baru ini saya tertarik pada perbedaan pendapat antara vendor browser yang berbeda tentang masa depan web — khususnya dalam berbagai upaya untuk mendorong kemampuan platform web lebih dekat ke platform asli, seperti Project Fugu dari Chromium.

Posisi utama dapat diringkas sebagai:

• Google (bersama dengan mitra seperti Intel, Microsoft dan Samsung) secara agresif mendorong maju dan berinovasi dengan sejumlah besar API baru seperti yang ada di Fugu, dan mengirimkannya dalam Chromium;
• Apple mendorong kembali dengan pendekatan yang lebih konservatif, menandai banyak API baru sebagai meningkatkan masalah keamanan & privasi;
• Ini (bersama dengan pembatasan Apple pada pilihan browser di iOS) telah menciptakan pendirian yang melabeli Safari sebagai IE baru sambil mengklaim bahwa Apple memperlambat kemajuan web;
• Mozilla tampaknya lebih dekat ke Apple daripada ke Google dalam hal ini.

Tujuan saya dalam artikel ini adalah untuk melihat klaim yang diidentifikasi dengan Google, khususnya klaim dalam Platform Adjacency Theory oleh pemimpin Project Fugu Alex Russell, melihat bukti yang disajikan dalam klaim tersebut, dan mungkin mencapai kesimpulan saya sendiri.

Secara khusus, saya bermaksud untuk menyelami WebUSB (API kontroversial tertentu dari Project Fugu), memeriksa apakah klaim keamanan terhadapnya layak, dan mencoba untuk melihat apakah alternatif muncul.

Teori Kedekatan Platform

Teori di atas membuat klaim berikut:

• Perangkat lunak berpindah ke web karena merupakan versi komputasi yang lebih baik;
• Web adalah meta-platform — platform yang diabstraksikan dari sistem operasinya;
• Keberhasilan meta-platform didasarkan pada pencapaian hal-hal yang kami harapkan dilakukan oleh sebagian besar komputer;
• Menolak untuk menambahkan kemampuan yang berdekatan ke meta-platform web dengan alasan keamanan, sementara mengabaikan masalah keamanan yang sama di platform asli, pada akhirnya akan membuat web semakin tidak relevan;
• Apple & Mozilla melakukan persis seperti itu — menolak untuk menambahkan kemampuan komputasi yang berdekatan ke web, sehingga "mencetak web dalam warna kuning".

Saya berhubungan dengan semangat penulis untuk menjaga web terbuka tetap relevan, dan dengan kekhawatiran bahwa terlalu lambat dalam menyempurnakan web dengan fitur baru akan membuatnya tidak relevan. Ini ditambah dengan ketidaksukaan saya pada toko aplikasi dan taman bertembok lainnya. Tetapi sebagai pengguna, saya dapat mengaitkannya dengan perspektif yang berlawanan — terkadang saya pusing ketika saya tidak tahu situs web apa yang saya jelajahi mampu atau tidak mampu melakukannya, dan saya menemukan pembatasan platform dan audit untuk menghibur.

Meta-Platform

Untuk memahami istilah “meta-platform”, saya melihat untuk apa teori tersebut menggunakan nama itu — Java dan Flash, keduanya merupakan produk dari pergantian milenium.

Saya merasa bingung untuk membandingkan Java atau Flash dengan web. Baik Java dan Flash, sebagaimana disebutkan dalam teori, didistribusikan secara luas pada saat itu melalui plug-in browser, menjadikannya lebih sebagai runtime alternatif yang berada di atas platform browser. Saat ini, Java digunakan terutama di server dan sebagai bagian dari platform Android, dan keduanya tidak memiliki banyak kesamaan, kecuali bahasa.

Saat ini Java sisi server mungkin merupakan meta-platform, dan node.js juga merupakan contoh yang baik dari meta-platform sisi server. Ini adalah satu set API, runtime lintas platform, dan ekosistem paket. Memang node.js selalu menambahkan lebih banyak kemampuan, yang sebelumnya hanya dimungkinkan sebagai bagian dari platform.

Di sisi klien, Qt, kerangka kerja lintas platform berbasis C++, tidak datang dengan runtime terpisah, itu hanya pustaka lintas platform (bagus!) untuk pengembangan UI.

Hal yang sama berlaku untuk Rust — ini adalah bahasa dan manajer paket, tetapi tidak bergantung pada runtime yang telah diinstal sebelumnya.

Cara lain untuk mengembangkan aplikasi sisi klien sebagian besar adalah khusus platform, tetapi juga mencakup beberapa solusi seluler lintas platform seperti Flutter dan Xamarin.

Kemampuan vs. Waktu

Grafik utama dalam teori, menunjukkan relevansi meta-platform pada sumbu 2D kemampuan vs. waktu:

Saya dapat melihat bagaimana grafik di atas masuk akal ketika berbicara tentang kerangka kerja pengembangan lintas platform yang disebutkan di atas seperti Qt, Xamarin, Flutter dan Rust, dan juga ke platform server seperti node.js dan Java/Scala.

Tetapi semua hal di atas memiliki perbedaan utama dari web.

Dimensi ke-3

Meta-platform yang disebutkan sebelumnya memang bersaing dengan OS host mereka dalam perlombaan untuk kemampuan, tetapi tidak seperti web, mereka tidak berpendirian tentang kepercayaan dan distribusi — dimensi ke-3, yang menurut saya tidak ada dalam grafik di atas.

Qt dan Rust adalah cara yang baik untuk membuat aplikasi yang didistribusikan melalui WebAssembly, diunduh dan diinstal langsung di OS host, atau dikelola melalui manajer paket seperti Cargo atau distribusi Linux seperti Ubuntu. React Native, Flutter, dan Xamarin adalah cara yang layak untuk membuat aplikasi yang didistribusikan melalui toko aplikasi. node.js dan layanan Java biasanya didistribusikan melalui wadah buruh pelabuhan, mesin virtual, atau mekanisme server lainnya.

Pengguna sebagian besar tidak menyadari apa yang digunakan untuk mengembangkan konten mereka, tetapi menyadari sampai tingkat tertentu bagaimana konten tersebut didistribusikan. Pengguna tidak tahu apa itu Xamarin dan node.js, dan jika Aplikasi Swift mereka suatu hari nanti digantikan oleh Aplikasi Flutter, sebagian besar pengguna tidak akan dan idealnya tidak mempedulikannya.

Tetapi pengguna mengetahui web — mereka tahu bahwa ketika mereka "menjelajah" di Chrome atau Firefox, mereka "online" dan dapat mengakses konten yang tidak selalu mereka percayai. Mereka tahu bahwa mengunduh perangkat lunak dan menginstalnya adalah kemungkinan bahaya, dan mungkin diblokir oleh administrator TI mereka. Faktanya, penting bagi platform web bahwa pengguna mengetahui bahwa mereka sedang "menjelajahi web". Itu sebabnya, misalnya, beralih ke mode layar penuh menunjukkan perintah yang jelas kepada pengguna, dengan petunjuk cara kembali darinya.

Web menjadi sukses karena tidak transparan — tetapi jelas terpisah dari OS inangnya. Jika saya tidak dapat mempercayai browser saya untuk menjauhkan situs web acak dari membaca file di hard drive saya, saya mungkin tidak akan membuka situs web mana pun.

Pengguna juga mengetahui bahwa perangkat lunak komputer mereka adalah "Windows" atau "Mac", apakah ponsel mereka berbasis Android atau iOS, dan apakah mereka saat ini menggunakan aplikasi (saat menggunakan iOS atau Android, dan di Mac OS sampai taraf tertentu) . OS dan model distribusi umumnya diketahui oleh pengguna — pengguna memercayai OS dan web mereka untuk melakukan hal yang berbeda, dan pada tingkat kepercayaan yang berbeda.

Jadi, web tidak dapat dibandingkan dengan kerangka kerja pengembangan lintas platform, tanpa mempertimbangkan model distribusinya yang unik.

Di sisi lain, teknologi web juga digunakan untuk pengembangan lintas platform, dengan kerangka kerja seperti Electron dan Cordova. Tapi itu bukan "web". Jika dibandingkan dengan Java atau node.js, istilah “Web” perlu diganti dengan “Web Technologies”. Dan "teknologi web" yang digunakan dengan cara ini tidak harus berbasis standar atau bekerja di banyak browser. Percakapan tentang API Fugu agak bersinggungan dengan Electron dan Cordova.

Aplikasi Asli

Saat menambahkan kemampuan ke platform web, dimensi ke-3 — model kepercayaan dan distribusi — tidak dapat diabaikan, atau dianggap enteng. Ketika penulis mengklaim bahwa "Posting Apple dan Mozilla tentang risiko dari kemampuan baru dibantah oleh risiko platform asli yang masih ada" , ia menempatkan web dan platform asli dalam dimensi yang sama dalam hal kepercayaan.

Memang, aplikasi asli memiliki masalah dan tantangan keamanannya sendiri. Tapi saya tidak melihat bagaimana itu argumen yang mendukung lebih banyak kemampuan web, seperti di sini. Ini adalah kekeliruan — kesimpulannya harus memperbaiki masalah keamanan dengan aplikasi asli, bukan melonggarkan keamanan untuk aplikasi web karena mereka berada dalam permainan mengejar relevansi dengan kemampuan OS.

Asli dan web tidak dapat dibandingkan dalam hal kemampuan, tanpa mempertimbangkan dimensi ke-3 dari model kepercayaan dan distribusi.

Batasan App Store

Salah satu kritik tentang aplikasi asli dalam teori adalah tentang kurangnya pilihan mesin browser di iOS. Ini adalah kritik umum terhadap Apple, tetapi ada lebih dari satu perspektif untuk ini.

Kritik tersebut secara khusus tentang Item 2.5.6 dari pedoman ulasan toko aplikasi Apple:

“Aplikasi yang menjelajahi web harus menggunakan kerangka kerja WebKit dan JavaScript WebKit yang sesuai.”

Ini mungkin tampak anti-persaingan, dan saya memiliki keberatan sendiri tentang betapa ketatnya iOS. Tetapi item 2.5.6 tidak dapat dibaca tanpa konteks panduan ulasan app-store lainnya, misalnya Item 2.3.12:

“Aplikasi harus dengan jelas menjelaskan fitur baru dan perubahan produk dalam teks 'Yang Baru'."

Jika sebuah aplikasi dapat menerima izin akses perangkat, dan kemudian menyertakan kerangka kerjanya sendiri yang dapat mengeksekusi kode dari situs web mana pun di luar sana, item-item tersebut dalam pedoman ulasan toko aplikasi akan menjadi tidak berarti. Tidak seperti aplikasi, situs web tidak harus menjelaskan fitur dan perubahan produk mereka dengan setiap revisi.

Ini menjadi masalah yang lebih besar ketika browser mengirimkan fitur eksperimental, seperti yang ada di proyek Fugu, yang belum dianggap sebagai standar. Siapa yang mendefinisikan apa itu browser? Dengan mengizinkan aplikasi untuk mengirimkan kerangka kerja web apa pun, toko aplikasi pada dasarnya akan mengizinkan "aplikasi" untuk menjalankan kode yang tidak diaudit, atau mengubah produk sepenuhnya, menghindari proses peninjauan toko.

Sebagai pengguna situs web dan aplikasi, saya pikir keduanya memiliki ruang di dunia komputasi, meskipun saya berharap sebanyak mungkin bisa pindah ke web. Tetapi ketika mempertimbangkan keadaan standar web saat ini, dan bagaimana dimensi kepercayaan dan kotak pasir di sekitar hal-hal seperti Bluetooth dan USB masih jauh dari penyelesaian, saya tidak melihat bagaimana mengizinkan aplikasi untuk secara bebas mengeksekusi konten dari web akan bermanfaat bagi pengguna. .

Pengejaran Appiness

Dalam posting blog terkait lainnya, penulis yang sama membahas beberapa hal ini, ketika berbicara tentang aplikasi asli:

"Menjadi 'aplikasi' hanyalah memenuhi serangkaian konvensi OS yang berubah-ubah dan berubah-ubah."

Saya setuju dengan gagasan bahwa definisi "aplikasi" adalah arbitrer, dan definisinya bergantung pada siapa pun yang mendefinisikan kebijakan toko aplikasi. Tapi hari ini, hal yang sama berlaku untuk browser. Klaim dari posting bahwa aplikasi web aman secara default juga agak sewenang-wenang. Siapa yang menarik garis di pasir "apa itu browser"? Apakah aplikasi Facebook dengan browser bawaan adalah "browser"?

Definisi aplikasi adalah arbitrer, tetapi juga penting. Fakta bahwa setiap revisi aplikasi yang menggunakan kemampuan tingkat rendah diaudit oleh seseorang yang mungkin saya percayai, bahkan jika seseorang itu sewenang-wenang, membuat aplikasi seperti apa adanya. Jika seseorang itu adalah produsen perangkat keras yang saya bayar, itu membuatnya semakin tidak sewenang-wenang — perusahaan tempat saya membeli komputer saya adalah satu-satunya perangkat lunak audit dengan kemampuan lebih rendah untuk komputer itu.

Semuanya Bisa Menjadi Peramban

Tanpa menggambar garis "apa itu browser", yang pada dasarnya dilakukan oleh toko aplikasi Apple, setiap aplikasi dapat mengirimkan mesin webnya sendiri, memikat pengguna untuk menelusuri situs web apa pun menggunakan browser dalam aplikasinya, dan menambahkan kode pelacakan apa pun diinginkannya, meruntuhkan perbedaan dimensi ke-3 antara aplikasi dan situs web.

Saat saya menggunakan aplikasi di iOS, saya tahu tindakan saya saat ini diekspos ke dua pemain: Apple & produsen aplikasi yang teridentifikasi. Saat saya menggunakan situs web di Safari atau di Safari WebView, tindakan saya diekspos ke Apple & ke pemilik domain tingkat atas dari situs web yang sedang saya lihat. Saat saya menggunakan browser dalam aplikasi dengan mesin yang tidak dikenal, saya dihadapkan pada Apple, produsen aplikasi, dan pemilik domain tingkat atas. Ini dapat membuat pelanggaran asal yang sama yang dapat dihindari, seperti pemilik aplikasi yang melacak semua klik saya di situs web asing.

Saya setuju bahwa mungkin garis di pasir "Hanya WebKit" terlalu keras. Apa definisi alternatif dari browser yang tidak akan membuat pintu belakang untuk melacak penjelajahan pengguna?

Kritik Lain Tentang Apple

Teori tersebut mengklaim bahwa penolakan Apple untuk mengimplementasikan fitur tidak terbatas pada masalah privasi/keamanan. Ini termasuk tautan, yang memang menunjukkan banyak fitur yang diterapkan di Chrome dan bukan di Safari. Namun, saat menggulir ke bawah, itu juga mencantumkan sejumlah besar fitur lain yang diterapkan di Safari dan bukan di Chrome.

Kedua proyek browser tersebut memiliki prioritas yang berbeda, tetapi jauh dari pernyataan kategoris "Permainan menjadi jelas saat memperkecil" dan dari kritik keras tentang Apple yang mencoba membuat web menjadi kuning.

Juga, tautan berjudul sulit dan kami tidak ingin mencoba mengarah pada pernyataan Apple bahwa mereka akan menerapkan fitur jika masalah keamanan/privasi terpenuhi. Saya merasa bahwa menempatkan tautan ini dengan judul-judul itu menyesatkan.

Saya setuju dengan pernyataan yang lebih seimbang, bahwa Google jauh lebih optimis daripada Apple tentang penerapan fitur dan kemajuan web.

Permintaan Izin

Google menempuh cara-cara inovatif yang panjang dalam dimensi ke-3, mengembangkan cara-cara baru untuk memperantarai kepercayaan antara pengguna, pengembang, dan platform, terkadang dengan sukses besar, seperti dalam kasus Aktivitas Web Tepercaya.

Tapi tetap saja, sebagian besar pekerjaan di dimensi ke-3 yang berkaitan dengan API perangkat difokuskan pada permintaan izin dan membuatnya lebih menakutkan, atau hal-hal seperti pemberian izin kotak waktu, dan domain yang terdaftar diblokir.

Permintaan "Menakutkan", seperti yang ada dalam contoh ini yang kita lihat dari waktu ke waktu, sepertinya dimaksudkan untuk mencegah orang membuka halaman yang tampaknya berpotensi berbahaya. Karena sangat mencolok, peringatan tersebut mendorong pengembang untuk beralih ke API yang lebih aman dan memperbarui sertifikat mereka.

Saya berharap bahwa untuk kemampuan akses perangkat, kami dapat memberikan petunjuk yang mendorong keterlibatan dan memastikan bahwa keterlibatan itu aman, daripada mencegahnya dan mengalihkan tanggung jawab kepada pengguna, tanpa perbaikan yang tersedia untuk pengembang web. Lebih lanjut tentang itu nanti.

Saya setuju dengan argumen bahwa Mozilla & Apple setidaknya harus mencoba berinovasi di ruang itu daripada "menolak untuk mengimplementasikan". Tapi mungkinkah mereka? Saya pikir isLoggedIn dari Apple, misalnya, adalah proposal yang menarik dan relevan dalam dimensi ke-3 yang dapat dibangun oleh API perangkat masa depan — misalnya, API perangkat yang rawan sidik jari dapat tersedia saat situs web saat ini sudah mengetahui identitas pengguna.

WebUSB

Di bagian selanjutnya saya akan membahas WebUSB, memeriksa apa yang diizinkannya, dan bagaimana penanganannya di dimensi ke-3 — apa model kepercayaan dan distribusinya? Apakah itu cukup? Apa saja alternatifnya?

Premis

WebUSB API memungkinkan akses penuh ke protokol USB untuk kelas perangkat yang tidak diblokir.

Itu dapat mencapai hal-hal yang kuat seperti menghubungkan ke papan Arduino atau men-debug ponsel Android.

Sangat menarik untuk melihat video Suz Hinton tentang bagaimana API ini dapat membantu mencapai hal-hal yang sebelumnya sangat mahal untuk dicapai.

Saya benar-benar berharap platform menemukan cara untuk menjadi lebih terbuka dan memungkinkan iterasi cepat pada proyek perangkat keras/perangkat lunak pendidikan, sebagai contoh.

Perasaan lucu

Tapi tetap saja, saya merasa lucu ketika saya melihat apa yang memungkinkan WebUSB, dan masalah keamanan yang ada dengan USB secara umum.

USB terasa terlalu kuat sebagai protokol yang diekspos ke web, bahkan dengan permintaan izin.

Jadi saya sudah meneliti lebih lanjut.

Tampilan Resmi Mozilla

Saya mulai dengan membaca apa yang dikatakan David Baron tentang mengapa Mozilla akhirnya menolak WebUSB, dalam posisi standar resmi Mozilla:

“Karena banyak perangkat USB tidak dirancang untuk menangani interaksi yang berpotensi berbahaya melalui protokol USB dan karena perangkat tersebut dapat memiliki efek signifikan pada komputer yang terhubung, kami percaya bahwa risiko keamanan dari memaparkan perangkat USB ke Web terlalu luas untuk risiko mengekspos pengguna kepada mereka atau untuk menjelaskan dengan benar kepada pengguna akhir untuk mendapatkan persetujuan yang berarti.”

Permintaan Izin Saat Ini

Seperti inilah tampilan permintaan izin WebUSB Chrome pada saat memublikasikan pos ini:

Domain tertentu Foo ingin terhubung ke Bar perangkat tertentu. Melakukan apa? dan bagaimana saya bisa tahu pasti?

Saat memberikan akses ke printer, kamera, mikrofon, GPS, atau bahkan beberapa profil GATT WebBluetooth yang lebih berisi seperti pemantauan detak jantung, pertanyaan ini relatif jelas, dan berfokus pada konten atau tindakan daripada pada perangkat . Ada pemahaman yang jelas tentang informasi apa yang saya inginkan dari periferal atau tindakan apa yang ingin saya lakukan dengannya, dan agen pengguna menengahi dan memastikan bahwa tindakan khusus ini ditangani.

USB Adalah Generik

Tidak seperti perangkat yang disebutkan di atas yang diekspos melalui API khusus, USB tidak spesifik konten. Seperti disebutkan dalam intro spesifikasi, WebUSB melangkah lebih jauh dan sengaja dirancang untuk jenis perangkat yang tidak diketahui atau belum ditemukan, bukan untuk kelas perangkat terkenal seperti keyboard atau drive eksternal.

Jadi, tidak seperti kasus printer, GPS, dan kamera, saya tidak dapat memikirkan prompt yang akan memberi tahu pengguna tentang apa yang memungkinkan pemberian izin halaman untuk terhubung ke perangkat dengan WebUSB di ranah konten, tanpa pemahaman mendalam tentang perangkat tertentu dan mengaudit kode yang mengaksesnya.

Insiden dan Mitigasi Yubikey

Contoh yang baik dari beberapa waktu yang lalu adalah insiden Yubikey, di mana WebUSB Chrome digunakan untuk mem-phishing data dari perangkat autentikasi yang didukung USB.

Karena ini adalah masalah keamanan yang dikatakan telah diselesaikan, saya penasaran untuk menyelami upaya mitigasi Chrome di Chrome 67, yang mencakup pemblokiran perangkat tertentu dan kelas tertentu.

Daftar Blok Kelas/Perangkat

Jadi pertahanan Chrome yang sebenarnya terhadap eksploitasi WebUSB yang terjadi di alam liar, selain permintaan izin yang saat ini sangat umum, adalah untuk memblokir perangkat dan kelas perangkat tertentu.

Ini mungkin solusi langsung untuk teknologi atau eksperimen baru, tetapi akan menjadi semakin sulit untuk dicapai ketika (dan jika) WebUSB menjadi lebih populer.

Saya khawatir orang yang berinovasi pada perangkat pendidikan melalui WebUSB mungkin mencapai situasi yang sulit. Pada saat mereka selesai membuat prototipe, mereka mungkin menghadapi serangkaian daftar blokir non-standar yang selalu berubah, yang hanya diperbarui bersama dengan versi browser, berdasarkan masalah keamanan yang tidak ada hubungannya dengan mereka.

Saya pikir menstandardisasi API ini tanpa menangani ini akan menjadi kontraproduktif bagi pengembang yang mengandalkannya. Misalnya, seseorang dapat menghabiskan beberapa siklus untuk mengembangkan aplikasi WebUSB untuk pendeteksi gerakan, hanya untuk mengetahui kemudian bahwa pendeteksi gerakan menjadi kelas yang diblokir, baik karena alasan keamanan atau karena OS memutuskan untuk menanganinya, menyebabkan seluruh upaya WebUSB mereka pergi ke limbah.

Keamanan vs. Fitur

Teori kedekatan platform, dalam beberapa hal, menganggap kemampuan dan keamanan sebagai permainan zero-sum, dan terlalu konservatif dalam masalah keamanan & privasi akan menyebabkan platform kehilangan relevansinya.

Mari kita ambil Arduino sebagai contoh. Komunikasi Arduino dimungkinkan dengan WebUSB dan merupakan kasus penggunaan utama. Seseorang yang mengembangkan perangkat Arduino sekarang harus mempertimbangkan skenario ancaman baru, di mana sebuah situs mencoba mengakses perangkat mereka menggunakan WebUSB (dengan beberapa izin pengguna). Sesuai spesifikasi, produsen perangkat ini sekarang harus "mendesain perangkat mereka untuk hanya menerima firmware yang ditandatangani". Hal ini dapat menambah beban bagi pengembang firmware, dan meningkatkan biaya pengembangan, sedangkan seluruh tujuan spesifikasi adalah untuk melakukan yang sebaliknya.

Apa yang Membuat WebUSB Berbeda Dari Periferal Lain

Di browser, ada perbedaan yang jelas antara interaksi pengguna dan interaksi sintetis (interaksi yang dibuat oleh halaman web).

Misalnya, halaman web tidak dapat memutuskan sendiri untuk mengklik tautan atau membangunkan CPU/tampilan. Tetapi perangkat eksternal dapat — misalnya, perangkat mouse dapat mengklik tautan atas nama pengguna dan hampir semua perangkat USB dapat mengaktifkan CPU, tergantung pada OS.

Jadi bahkan dengan spesifikasi WebUSB saat ini, perangkat dapat memilih untuk mengimplementasikan beberapa antarmuka, misalnya debug untuk adb dan HID untuk input pointer, dan menggunakan kode berbahaya yang memanfaatkan ADB, menjadi keylogger dan menelusuri situs web atas nama pengguna, mengingat mekanisme flashing firmware yang dapat dieksploitasi dengan benar.

Menambahkan perangkat tersebut ke daftar blokir akan terlambat untuk perangkat dengan firmware yang disusupi menggunakan ADB atau bentuk flashing lain yang diizinkan, dan akan membuat produsen perangkat lebih bergantung daripada sebelumnya pada versi browser untuk perbaikan keamanan yang terkait dengan perangkat mereka.

Persetujuan & Konten yang Diinformasikan

Masalah dengan persetujuan dan USB, seperti yang disebutkan sebelumnya, adalah bahwa USB (khususnya dalam kasus penggunaan WebUSB ekstra-generik) tidak spesifik konten. Pengguna tahu apa itu printer, apa itu kamera, tetapi "USB" bagi sebagian besar pengguna hanyalah kabel (atau soket) — sarana untuk mencapai tujuan — sangat sedikit pengguna yang tahu bahwa USB adalah protokol dan apa yang memungkinkannya antar situs web dan perangkat berarti.

Satu saran adalah untuk memiliki prompt "menakutkan", sesuatu di sepanjang baris "Izinkan halaman web ini mengambil alih perangkat" (yang merupakan peningkatan dari "ingin terhubung" yang tampaknya tidak berbahaya).

Tetapi seseram yang diminta, mereka tidak dapat menjelaskan luasnya kemungkinan hal yang dapat dilakukan dengan akses mentah ke periferal USB yang tidak diketahui secara dekat oleh browser, dan jika mereka melakukannya, tidak ada pengguna waras yang akan mengklik "Ya ”, kecuali jika itu adalah perangkat yang sepenuhnya mereka percayai bebas bug dan situs web yang benar-benar mereka percayai sebagai yang terbaru dan tidak berbahaya.

Kemungkinan prompt seperti itu akan berbunyi "Izinkan halaman web ini berpotensi mengambil alih komputer Anda". Saya tidak berpikir bahwa prompt menakutkan seperti ini akan bermanfaat bagi komunitas WebUSB, dan perubahan terus-menerus pada dialog ini akan membuat komunitas bingung.

Prototipe vs. Produk

Saya dapat melihat kemungkinan pengecualian untuk ini. Jika premis WebUSB dan proyek Fugu API lainnya adalah untuk mendukung pembuatan prototipe daripada perangkat tingkat produk, permintaan umum yang mencakup semua bisa masuk akal.

Namun, untuk membuatnya layak, saya pikir hal-hal berikut harus terjadi:

1. Gunakan bahasa dalam spesifikasi yang menetapkan harapan tentang makhluk ini untuk pembuatan prototipe;
2. Sediakan API ini hanya setelah beberapa isyarat keikutsertaan, seperti meminta pengguna mengaktifkannya secara manual di setelan browser;
3. Minta izin "menakutkan", seperti yang untuk sertifikat SSL yang tidak valid.

Tidak memiliki hal di atas membuat saya berpikir bahwa API ini untuk produk nyata daripada untuk prototipe, dan dengan demikian, umpan baliknya berlaku.

Proposal Alternatif

Salah satu bagian dalam posting blog asli yang saya setujui adalah bahwa tidak cukup untuk mengatakan "tidak" — pemain utama di dunia web yang menolak API tertentu karena berbahaya juga harus bermain menyerang dan mengusulkan cara di mana kemampuan ini penting untuk pengguna dan pengembang dapat diekspos dengan aman. Saya tidak mewakili pemain utama mana pun, tetapi saya akan mencobanya dengan rendah hati.

Saya percaya bahwa jawaban untuk ini terletak pada dimensi ke-3 kepercayaan dan hubungan, dan itu di luar kotak permintaan izin dan daftar blokir.

Permintaan Langsung Dan Terverifikasi

Kasus utama yang akan saya buat adalah bahwa prompt harus tentang konten atau tindakan, dan bukan tentang periferal, dan persetujuan yang diinformasikan dapat diberikan untuk tindakan langsung tertentu dengan serangkaian parameter terverifikasi tertentu, bukan untuk tindakan umum seperti "mengambil alih" atau "menghubungkan ke" perangkat.

Contoh Printer 3D

Dalam spesifikasi WebUSB, printer 3D dibawa sebagai contoh, jadi saya akan menggunakannya di sini.

Saat mengembangkan aplikasi WebUSB untuk printer 3D, saya ingin browser/OS meminta saya sesuatu di sepanjang baris Allow AutoDesk 3ds-mask untuk mencetak model ke printer 3D CreatBot Anda? , ditampilkan dialog browser/OS dengan beberapa parameter cetak, seperti penyempurnaan, ketebalan dan dimensi keluaran, dan dengan pratinjau apa yang akan dicetak. Semua parameter ini harus diverifikasi oleh agen pengguna tepercaya, bukan oleh halaman web drive-by.

Saat ini, browser tidak mengetahui printer, dan hanya dapat memverifikasi beberapa klaim di prompt:

• Domain yang meminta memiliki sertifikat yang terdaftar di AutoDesk, jadi ada kepastian bahwa ini adalah AutoDesk Inc;
• Periferal yang diminta menyebut dirinya "Printer CreatBot 3d";
• Perangkat, kelas perangkat, dan domain ini tidak ditemukan di daftar blokir browser;
• Pengguna menjawab "Ya" atau "Tidak" untuk pertanyaan umum yang diajukan kepada mereka.

Tetapi untuk menampilkan prompt dan dialog yang benar dengan detail di atas, browser juga harus memverifikasi yang berikut:

• Ketika izin diberikan, tindakan yang dilakukan akan mencetak model 3D, dan hanya itu;
• Parameter yang dipilih (kehalusan/ketebalan/dimensi dll.) akan dihormati;
• Pratinjau terverifikasi dari apa yang akan dicetak ditampilkan kepada pengguna;
• Dalam kasus sensitif tertentu, verifikasi tambahan bahwa ini sebenarnya adalah AutoDesk, mungkin dengan sesuatu seperti token berumur pendek yang dapat dicabut.

Tanpa memverifikasi hal di atas, situs web yang diberi izin untuk "menghubungkan ke" atau "mengambil alih" printer 3D dapat mulai mencetak model 3D besar karena bug (atau kode berbahaya di salah satu dependensinya).

Selain itu, kemampuan pencetakan 3D web lengkap yang dibayangkan akan melakukan lebih dari apa yang dapat disediakan oleh WebUSB — misalnya, menggulung dan mengantrekan permintaan cetak yang berbeda. Bagaimana itu akan ditangani jika jendela browser ditutup? Saya belum meneliti semua kemungkinan kasus penggunaan perangkat WebUSB, tetapi saya menduga bahwa ketika melihatnya dari perspektif konten/tindakan, sebagian besar akan membutuhkan lebih dari akses USB.

Karena hal di atas, menggunakan WebUSB untuk pencetakan 3D mungkin akan meretas dan berumur pendek, dan pengembang yang mengandalkannya harus menyediakan driver "nyata" untuk printer mereka di beberapa titik. Misalnya, jika vendor OS memutuskan untuk menambahkan dukungan bawaan untuk printer 3D, semua situs yang menggunakan printer tersebut dengan WebUSB akan berhenti berfungsi.

Proposal: Otoritas Audit Pengemudi

Jadi, izin menyeluruh seperti "mengambil alih periferal" bermasalah, kami tidak memiliki informasi yang cukup untuk menampilkan dialog parameter lengkap dan memverifikasi bahwa hasilnya akan dihormati, dan kami tidak ingin mengirim pengguna dalam perjalanan yang tidak aman untuk mengunduh executable acak dari web.

Tetapi bagaimana jika ada bagian kode yang diaudit , driver, yang menggunakan API WebUSB secara internal dan melakukan hal berikut:

• Menerapkan perintah "cetak";
• Menampilkan dialog cetak di luar halaman;
• Terhubung ke perangkat USB tertentu;
• Melakukan beberapa tindakannya saat halaman berada di latar belakang (misalnya di service worker), atau bahkan saat browser ditutup.

Audit driver seperti ini dapat memastikan bahwa apa yang dilakukannya adalah "mencetak", bahwa ia menghormati parameter, dan menunjukkan pratinjau cetak.

Saya melihat ini mirip dengan otoritas sertifikat, bagian penting dalam ekosistem web yang agak terputus dari vendor browser.

Sindikasi Pengemudi

Driver tidak harus diaudit oleh Google/Apple, meskipun vendor browser/OS dapat memilih untuk mengaudit driver sendiri. Ini dapat bekerja seperti otoritas sertifikat SSL — penerbitnya adalah organisasi yang sangat tepercaya; misalnya, produsen periferal tertentu atau organisasi yang mensertifikasi banyak driver, atau platform seperti Arduino. (Saya membayangkan organisasi bermunculan mirip dengan Let's Encrypt.)

Mungkin cukup untuk mengatakan kepada pengguna: "Arduino percaya bahwa kode ini akan mem-flash Uno Anda dengan firmware ini " (dengan pratinjau firmware).

Peringatan

Hal ini tentu saja tidak lepas dari potensi masalah:

• Pengemudi itu sendiri bisa jadi buggy atau jahat. Tapi setidaknya itu diaudit;
• Ini kurang "webby" dan menghasilkan beban pengembangan tambahan;
• Itu tidak ada hari ini, dan tidak dapat diselesaikan dengan inovasi internal di mesin browser.

Alternatif lain

Alternatif lain adalah dengan entah bagaimana menstandardisasi dan meningkatkan API Ekstensi Web lintas-browser, dan membuat toko add-on browser yang ada seperti Toko Web Chrome menjadi semacam otoritas pengauditan driver, yang menengahi antara permintaan pengguna dan akses periferal.

Ringkasan Opini

Upaya berani penulis, Google, dan mitra untuk menjaga web terbuka tetap relevan dengan meningkatkan kemampuannya sangat menginspirasi.

Ketika saya sampai ke detailnya, saya melihat pandangan Apple dan Mozilla yang lebih konservatif tentang web, dan pendekatan defensif mereka terhadap kemampuan perangkat baru, sebagai membawa keunggulan teknis. Masalah inti dengan persetujuan berdasarkan informasi seputar kemampuan perangkat keras terbuka masih jauh dari penyelesaian.

Apple bisa lebih terbuka dalam diskusi untuk menemukan cara baru untuk mengaktifkan kemampuan perangkat, tetapi saya yakin ini berasal dari perspektif yang berbeda tentang komputasi, sudut pandang yang merupakan bagian dari identitas Apple selama beberapa dekade, bukan dari sudut pandang anti-persaingan.

Untuk mendukung hal-hal seperti kemampuan perangkat keras yang agak terbuka di proyek Fugu, dan khususnya WebUSB, model kepercayaan web perlu berkembang melampaui permintaan izin dan daftar blokir domain/perangkat, mengambil inspirasi dari ekosistem kepercayaan seperti otoritas sertifikat dan distribusi paket.

Bacaan Lebih Lanjut tentang SmashingMag:

• Bagaimana Meningkatkan Kinerja Situs Web Dapat Membantu Menyelamatkan Bumi
• Menuju Web Bebas Iklan: Mendiversifikasi Ekonomi Online
• Apakah Ada Masa Depan Selain Menulis Kode Hebat?
• Menggunakan Etika Dalam Desain Web