Web Donanım Yeteneklerini Ortaya Çıkarmalı mı?

Son zamanlarda, farklı tarayıcı satıcıları arasındaki web'in geleceği hakkındaki görüş farklılıklarıyla - özellikle web platformu özelliklerini Chromium'un Project Fugu'su gibi yerel platformlara yakınlaştırmaya yönelik çeşitli çabalarla ilgilendim.

Ana pozisyonlar şu şekilde özetlenebilir:

• Google (Intel, Microsoft ve Samsung gibi ortaklarla birlikte) Fugu'dakiler gibi çok sayıda yeni API ile agresif bir şekilde ilerliyor ve yenilikler yapıyor ve bunları Chromium'da gönderiyor;
• Apple, daha muhafazakar bir yaklaşımla geri adım atıyor ve yeni API'lerin çoğunu güvenlik ve gizlilik endişelerini artırıyor olarak işaretliyor;
• Bu (Apple'ın iOS'ta tarayıcı seçimine getirdiği kısıtlamalarla birlikte), Apple'ın web'in ilerlemesini yavaşlattığını iddia ederken Safari'yi yeni IE olarak etiketleyen bir duruş yarattı;
• Mozilla bu konuda Apple'a Google'dan daha yakın görünüyor.

Bu makaledeki amacım, Google ile tanımlanan iddialara, özellikle Project Fugu lideri Alex Russell'ın Platform Bitişik Teorisi'ndeki iddialara bakmak, bu iddialarda sunulan kanıtlara bakmak ve belki de kendi sonucuma ulaşmaktır.

Spesifik olarak, WebUSB'ye (Project Fugu'dan tartışmalı bir API) dalmayı, aleyhindeki güvenlik iddialarının haklı olup olmadığını kontrol etmeyi ve bir alternatifin ortaya çıkıp çıkmadığını görmeye çalışmayı planlıyorum.

Platform Bitişikliği Teorisi

Yukarıda belirtilen teori aşağıdaki iddialarda bulunur:

• Yazılım, bilgi işlemin daha iyi bir sürümü olduğu için web'e taşınıyor;
• Web bir meta-platformdur — işletim sisteminden soyutlanmış bir platformdur;
• Bir meta-platformun başarısı, çoğu bilgisayarın yapmasını beklediğimiz şeyleri başarmasına dayanır;
• Yerel platformlardaki aynı güvenlik sorunlarını göz ardı ederken, güvenlik gerekçesiyle web meta platformuna bitişik yetenekler eklemeyi reddetmek, sonunda web'i giderek daha az alakalı hale getirecektir;
• Apple ve Mozilla tam olarak bunu yapıyor - web'e bitişik bilgi işlem yetenekleri eklemeyi reddediyor ve böylece "web'i kehribar rengine dönüştürüyor".

Yazarın açık web'i alakalı tutma tutkusuyla ve web'i yeni özelliklerle geliştirme konusunda çok yavaş ilerlemenin onu alakasız kılacağı endişesiyle ilgiliyim. Bu, uygulama mağazalarından ve diğer duvarlı bahçelerden hoşlanmamamla daha da arttı. Ancak bir kullanıcı olarak karşıt bakış açısıyla ilişki kurabilirim - bazen hangi web sitelerine göz attığımı bilmediğimde başım dönüyor ve platform kısıtlamalarını ve denetlemeyi rahatlatıcı buluyorum.

Meta-Platformlar

"Meta-platform" terimini anlamak için, teorinin bu adı ne için kullandığına baktım - Java ve Flash, her ikisi de milenyumun dönüşünün ürünleri.

Java veya Flash'ı web ile karşılaştırmayı kafa karıştırıcı buluyorum. Hem Java hem de Flash, teoride bahsedildiği gibi, o zamanlar tarayıcı eklentileri aracılığıyla geniş çapta dağıtıldı ve bu da onları tarayıcı platformunun üzerine binen alternatif bir çalışma zamanı haline getirdi. Bugün Java esas olarak sunucuda ve Android platformunun bir parçası olarak kullanılmaktadır ve her ikisi de dil dışında pek bir ortak noktayı paylaşmıyor.

Bugün sunucu tarafı Java belki bir meta platformdur ve node.js ayrıca sunucu tarafı meta platformuna iyi bir örnektir. Bir dizi API, bir platformlar arası çalışma zamanı ve bir paket ekosistemidir. Gerçekten de node.js, daha önce yalnızca bir platformun parçası olarak mümkün olan her zaman daha fazla yetenek ekliyor.

İstemci tarafında, C++ tabanlı bir çapraz platform çerçevesi olan Qt, ayrı bir çalışma zamanı ile gelmez, yalnızca UI geliştirme için (iyi!) bir çapraz platform kitaplığıdır.

Aynısı Rust için de geçerlidir - bu bir dil ve paket yöneticisidir, ancak önceden yüklenmiş çalışma zamanlarına bağlı değildir.

İstemci tarafı uygulamaları geliştirmenin diğer yolları çoğunlukla platforma özgüdür, ancak Flutter ve Xamarin gibi bazı platformlar arası mobil çözümleri de içerir.

Yetenekler ve Zaman

Teorideki ana grafik, meta-platformların 2B yetenekler ve zaman eksenindeki alaka düzeyini gösterir:

Qt, Xamarin, Flutter ve Rust gibi yukarıda bahsedilen platformlar arası geliştirme çerçevelerinden ve ayrıca node.js ve Java/Scala gibi sunucu platformlarından bahsederken yukarıdaki grafiğin ne kadar anlamlı olduğunu görebiliyorum.

Ancak yukarıdakilerin hepsinin web'den önemli bir farkı var.

3. Boyut

Daha önce bahsedilen meta platformlar, yetenek yarışında gerçekten de ana işletim sistemlerine karşı rekabet ediyor, ancak web'den farklı olarak, güven ve dağıtım hakkında fikir sahibi değiller - bence yukarıdaki grafikte eksik olan 3. boyut.

Qt ve Rust, WebAssembly aracılığıyla dağıtılan, doğrudan ana işletim sistemine indirilen ve yüklenen veya Kargo gibi paket yöneticileri veya Ubuntu gibi Linux dağıtımları aracılığıyla yönetilen uygulamalar oluşturmanın iyi yollarıdır. React Native, Flutter ve Xamarin, uygulama mağazaları aracılığıyla dağıtılan uygulamalar oluşturmanın iyi yollarıdır. node.js ve Java hizmetleri genellikle bir liman işçisi konteyneri, bir sanal makine veya başka bir sunucu mekanizması aracılığıyla dağıtılır.

Kullanıcılar çoğunlukla içeriklerini geliştirmek için ne kullanıldığının farkında değiller, ancak bir dereceye kadar nasıl dağıtıldığının farkındalar. Kullanıcılar Xamarin ve node.js'nin ne olduğunu bilmiyorlar ve Swift Uygulaması bir gün bir Flutter Uygulaması ile değiştirilseydi, çoğu kullanıcı bunu umursamazdı ve ideal olarak umursamamalı.

Ancak kullanıcılar web'i biliyorlar - Chrome veya Firefox'ta "taradıklarında" "çevrimiçi" olduklarını ve mutlaka güvenmedikleri içeriğe erişebileceklerini biliyorlar. Yazılım indirmenin ve kurmanın olası bir tehlike olduğunu ve BT yöneticileri tarafından engellenebileceğini biliyorlar. Aslında, kullanıcıların şu anda "web'de gezindiklerini" bilmeleri web platformu için önemlidir. Bu nedenle, örneğin, tam ekran moduna geçiş, kullanıcıya bundan nasıl geri döneceğine ilişkin talimatlarla birlikte net bir istem gösterir.

Web şeffaf olmadığı için başarılı oldu - ancak ana bilgisayar işletim sisteminden açıkça ayrıldı. Rastgele web sitelerini sabit sürücümdeki dosyaları okumaktan uzak tutmak için tarayıcıma güvenemezsem, muhtemelen hiçbir web sitesine gitmezdim.

Kullanıcılar, telefonlarının Android veya iOS tabanlı olup olmadığına ve şu anda bir uygulama kullanıp kullanmadığına (iOS veya Android'de ve bir dereceye kadar Mac OS'de) bilgisayar yazılımlarının “Windows” veya “Mac” olduğunu da bilir. . İşletim sistemi ve dağıtım modeli genellikle kullanıcı tarafından bilinir - kullanıcı işletim sistemlerine ve web'e farklı şeyler yapmak için ve farklı güven derecelerinde güvenir.

Bu nedenle, web, benzersiz dağıtım modeli dikkate alınmadan platformlar arası geliştirme çerçeveleriyle karşılaştırılamaz.

Öte yandan, web teknolojileri, Electron ve Cordova gibi çerçeveler ile platformlar arası geliştirme için de kullanılmaktadır. Ancak bunlar tam olarak “web” değildir. Java veya node.js ile karşılaştırıldığında, "Web" teriminin "Web Teknolojileri" ile değiştirilmesi gerekir. Ve bu şekilde kullanılan “web teknolojileri”nin mutlaka standart tabanlı olması veya birden fazla tarayıcıda çalışması gerekmez. Fugu API'leri hakkındaki konuşma, Electron ve Cordova için biraz teğettir.

Yerel Uygulamalar

Web platformuna yetenekler eklenirken, 3. boyut olan güven ve dağıtım modeli göz ardı edilemez veya hafife alınamaz. Yazar, “Apple ve Mozilla'nın yeni yeteneklerden kaynaklanan riskler hakkında tavır almalarının, kabul edilen mevcut yerel platform riskleri tarafından yalanlandığını” iddia ettiğinde, web ve yerel platformları güven açısından aynı boyuta koyuyor.

Tabii ki, yerel uygulamaların kendi güvenlik sorunları ve zorlukları vardır. Ancak bunun, buradaki gibi daha fazla web yeteneği lehine nasıl bir argüman olduğunu anlamıyorum. Bu bir yanılgıdır - sonuç, işletim sistemi özelliklerine sahip bir alaka yakalama oyununda oldukları için web uygulamaları için güvenliği gevşetmek değil, yerel uygulamalarla güvenlik sorunlarını düzeltmek olmalıdır.

Güven ve dağıtım modelinin 3. boyutu dikkate alınmadan, yerel ve web yetenekler açısından karşılaştırılamaz.

App Store Sınırlamaları

Teoride yerel uygulamalarla ilgili eleştirilerden biri, iOS'ta tarayıcı motoru seçiminin olmamasıdır. Bu, Apple'a karşı yaygın bir eleştiri konusu, ancak buna birden fazla bakış açısı var.

Eleştiri, özellikle Apple'ın uygulama mağazası inceleme yönergelerinin 2.5.6 Maddesi ile ilgilidir:

"Web'de gezinen uygulamalar, uygun WebKit çerçevesini ve WebKit JavaScript'i kullanmalıdır."

Bu, rekabete aykırı görünebilir ve iOS'un ne kadar kısıtlayıcı olduğu konusunda kendi çekincelerim var. Ancak 2.5.6 maddesi, uygulama mağazası inceleme yönergelerinin geri kalanının bağlamı olmadan okunamaz, örneğin Madde 2.3.12:

"Uygulamalar, 'Yenilikler' metinlerinde yeni özellikleri ve ürün değişikliklerini açıkça tanımlamalıdır."

Bir uygulama cihaz erişim izinlerini alabilseydi ve ardından oradaki herhangi bir web sitesinden kod yürütebilecek kendi çerçevesini ekleseydi, uygulama mağazası inceleme yönergelerindeki bu öğeler anlamsız hale gelirdi. Uygulamaların aksine, web siteleri her revizyonda özelliklerini ve ürün değişikliklerini açıklamak zorunda değildir.

Bu, tarayıcılar Fugu projesinde olduğu gibi henüz standart olarak kabul edilmeyen deneysel özellikler gönderdiğinde daha da büyük bir sorun haline gelir. Bir tarayıcının ne olduğunu kim tanımlar? Uygulama mağazası, uygulamaların herhangi bir web çerçevesi göndermesine izin vererek, esasen "uygulamanın" denetlenmemiş herhangi bir kodu çalıştırmasına veya ürünü tamamen değiştirmesine izin vererek mağazanın inceleme sürecini atlatır.

Hem web sitelerinin hem de uygulamaların bir kullanıcısı olarak, her ikisinin de bilgisayar dünyasında yeri olduğunu düşünüyorum, ancak mümkün olduğunca çok şeyin web'e taşınabileceğini umuyorum. Ancak, web standartlarının mevcut durumunu ve Bluetooth ve USB gibi şeylerin etrafındaki güven ve sanal alan boyutunun çözülmekten ne kadar uzak olduğunu düşündüğümde, uygulamaların web'den içeriği özgürce yürütmesine izin vermenin kullanıcılar için nasıl faydalı olacağını anlamıyorum. .

Uygulamanın Peşinde

İlgili başka bir blog gönderisinde, aynı yazar yerel uygulamalardan bahsederken bunlardan bazılarına değiniyor:

"'Uygulama' olmak, yalnızca bir dizi keyfi ve değiştirilebilir işletim sistemi kuralına uymaktır."

"Uygulama" tanımının keyfi olduğu ve tanımının uygulama mağazası politikalarını kim tanımlıyorsa ona bağlı olduğu fikrine katılıyorum. Ancak bugün, aynı şey tarayıcılar için de geçerlidir. Gönderideki web uygulamalarının varsayılan olarak güvenli olduğu iddiası da biraz keyfidir. “Tarayıcı nedir” kumundaki çizgiyi kim çiziyor? Yerleşik bir tarayıcıya sahip Facebook uygulaması bir "tarayıcı" mı?

Bir uygulamanın tanımı keyfidir, ancak aynı zamanda önemlidir. Düşük seviyeli yetenekler kullanan bir uygulamanın her revizyonunun güvenebileceğim biri tarafından, bu biri keyfi olsa bile denetlenmesi, uygulamaları oldukları gibi yapar. Eğer o kişi parasını ödediğim donanımın üreticisiyse, bu daha da az keyfi olur - bilgisayarımı satın aldığım şirket, o bilgisayar için daha düşük yeteneklere sahip tek denetleme yazılımıdır.

Her Şey Bir Tarayıcı Olabilir

Apple uygulama mağazasının esasen yaptığı gibi, “tarayıcı nedir” diye bir satır çizmeden, her uygulama kendi web motorunu gönderebilir, kullanıcıyı uygulama içi tarayıcısını kullanarak herhangi bir web sitesine göz atması için cezbedebilir ve herhangi bir izleme kodunu ekleyebilir. uygulamalar ve web siteleri arasındaki 3. boyut farkını daraltmak istiyor.

iOS'ta bir uygulama kullandığımda, eylemlerimin şu anda iki oyuncuya maruz kaldığını biliyorum: Apple ve tanımlanan uygulama üreticisi. Safari'de veya Safari Web Görünümü'nde bir web sitesi kullandığımda, eylemlerim Apple'a ve o anda görüntülediğim web sitesinin üst düzey alan adının sahibine açık oluyor. Tanımlanamayan bir motora sahip bir uygulama içi tarayıcı kullandığımda, uygulamanın üreticisi Apple'a ve üst düzey etki alanının sahibine maruz kalıyorum. Bu, uygulama sahibinin yabancı web sitelerindeki tüm tıklamalarımı izlemesi gibi önlenebilir aynı kaynaklı ihlaller oluşturabilir.

Belki de “Only WebKit” in kumdaki çizgisinin çok sert olduğuna katılıyorum. Kullanıcı taramasını izlemek için bir arka kapı oluşturmayan alternatif bir tarayıcı tanımı ne olabilir?

Apple Hakkındaki Diğer Eleştiriler

Teori, Apple'ın özellikleri uygulamayı reddetmesinin gizlilik/güvenlik endişeleriyle sınırlı olmadığını iddia ediyor. Safari'de değil, Chrome'da uygulanan birçok özelliği gerçekten gösteren bir bağlantı içerir. Bununla birlikte, aşağı kaydırırken, Chrome'da değil Safari'de uygulanan çok sayıda başka özelliği de listeler.

Bu iki tarayıcı projesinin farklı öncelikleri var, ancak “Oyun uzaklaştırırken netleşiyor” şeklindeki kategorik ifadeden ve Apple'ın web'i kehribar renginde yayınlamaya çalışmasına yönelik sert eleştirilerden uzak.

Ayrıca, zor ve denemek istemiyoruz başlıklı bağlantılar, Apple'ın güvenlik/gizlilik endişeleri karşılanırsa özellikleri uygulayacaklarına dair açıklamalarına yol açmak istemiyor. Bu bağlantıları bu başlıklarla koymanın yanıltıcı olduğunu hissediyorum.

Google'ın özellikleri uygulama ve web'i ilerletme konusunda Apple'dan çok daha iyimser olduğuna dair daha dengeli bir ifadeye katılıyorum.

İzin İstemi

Google, 3. boyutta uzun süre yenilikçi yollar izleyerek kullanıcı, geliştirici ve platform arasında güven sağlamak için yeni yollar geliştirerek, bazen Güvenilir Web Etkinlikleri örneğinde olduğu gibi büyük bir başarı elde eder.

Ancak yine de, cihaz API'leriyle ilgili olarak 3. boyuttaki çalışmaların çoğu, izin istemlerine ve onları daha korkutucu hale getirmeye veya zaman kutusu izinleri ve blok listelenmiş etki alanları gibi şeylere odaklanır.

"Korkutucu" istemler, zaman zaman gördüğümüz bu örnekte olduğu gibi, insanları potansiyel olarak kötü niyetli görünen sayfalara gitmekten caydırmak için tasarlanmış gibi görünüyor. Çok bariz oldukları için bu uyarılar geliştiricileri daha güvenli API'lere geçmeye ve sertifikalarını yenilemeye teşvik ediyor.

Cihaz erişim yetenekleri için, web geliştiricisi için herhangi bir düzeltme olmaksızın, katılımı caydırmak ve sorumluluğu kullanıcıya devretmek yerine, katılımı teşvik eden ve katılımın güvenli olmasını sağlayan istemler bulabilmeyi diliyorum. Daha sonra bunun hakkında.

Mozilla & Apple'ın “uygulamayı reddetmek” yerine en azından bu alanda yenilik yapmaya çalışması gerektiği argümanına katılıyorum. Ama belki onlar? Örneğin, Apple'dan isLoggedIn'in gelecekteki cihaz API'lerinin üzerine inşa edebileceği 3. boyutta ilginç ve alakalı bir teklif olduğunu düşünüyorum - örneğin, mevcut web sitesi kimliğini zaten bildiğinde parmak izine yatkın cihaz API'leri kullanılabilir hale getirilebilir. Kullanıcı.

WebUSB

Bir sonraki bölümde WebUSB'ye dalacağım, neye izin verdiğini ve 3. boyutta nasıl ele alındığını kontrol edeceğim - güven ve dağıtım modeli nedir? yeterli mi? Alternatifler nelerdir?

öncül

WebUSB API'si, engelleme listesinde olmayan cihaz sınıfları için USB protokolüne tam erişim sağlar.

Bir Arduino kartına bağlanmak veya bir Android telefonda hata ayıklamak gibi güçlü şeyler başarabilir.

Suz Hinton'un bu API'nin daha önce elde edilmesi çok pahalı olan şeyleri başarmaya nasıl yardımcı olabileceğine dair videolarını görmek heyecan verici.

Örnek olarak, platformların daha açık olmanın ve eğitim donanım/yazılım projelerinde hızlı yinelemelere izin vermenin yollarını bulmasını gerçekten diliyorum.

komik duygu

Ama yine de, WebUSB'nin neler sağladığına ve genel olarak USB ile ilgili mevcut güvenlik sorunlarına baktığımda komik bir his alıyorum.

USB, izin istemlerinde bile web'e maruz kalan bir protokol olarak çok güçlü hissediyor.

Bu yüzden daha fazla araştırdım.

Mozilla'nın Resmi Görünümü

Mozilla'nın resmi standartlar pozisyonunda, Mozilla'nın WebUSB'yi neden reddettiği hakkında David Baron'un söylediklerini okuyarak başladım:

“Birçok USB cihazı, USB protokolleri üzerinden potansiyel olarak zararlı etkileşimleri işlemek üzere tasarlanmadığından ve bu cihazların bağlı oldukları bilgisayar üzerinde önemli etkileri olabileceğinden, USB cihazlarını Web'e maruz bırakmanın güvenlik risklerinin çok yüksek olduğuna inanıyoruz. Kullanıcıları onlara maruz bırakma riskini veya son kullanıcılara anlamlı bilgilendirilmiş onay almak için uygun şekilde açıklamayı içerecek şekilde geniş. ”

Mevcut İzin İstemi

Bu gönderi yayınlanırken Chrome'un WebUSB izin istemi şu şekilde görünür:

Belirli etki alanı Foo, belirli aygıt Çubuğuna bağlanmak istiyor. Ne yapacağını? ve nasıl emin olabilirim?

Yazıcıya, kameraya, mikrofona, GPS'e ve hatta kalp atış hızı izleme gibi daha kapsamlı WebBluetooth GATT profillerinden birkaçına erişim izni verirken, bu soru nispeten açıktır ve cihazdan çok içeriğe veya eyleme odaklanır. Çevre biriminden hangi bilgileri istediğime veya onunla hangi eylemi gerçekleştirmek istediğime dair net bir anlayış var ve kullanıcı aracısı bu özel eylemin işlenmesine aracılık ediyor ve emin olmasını sağlıyor.

USB Geneldir

Yukarıda belirtilen ve özel API'ler aracılığıyla kullanıma sunulan cihazların aksine, USB içeriğe özgü değildir. Spesifikasyonun girişinde belirtildiği gibi, WebUSB daha da ileri gider ve klavyeler veya harici sürücüler gibi iyi bilinen cihaz sınıfları için değil, bilinmeyen veya henüz icat edilmemiş cihaz türleri için kasıtlı olarak tasarlanmıştır.

Bu nedenle, yazıcı, GPS ve kamera durumlarından farklı olarak, kullanıcıyı WebUSB ile bir cihaza bağlanmak için bir sayfa izni vermenin içerik alanında, derin bir anlayışa sahip olmadan neye izin vereceği konusunda bilgilendirecek bir istem düşünemiyorum. belirli bir cihaz ve ona erişen kodu denetleme.

Yubikey Olayı ve Azaltma

Çok uzun olmayan bir zamana iyi bir örnek, Chrome'un WebUSB'sinin USB ile çalışan bir kimlik doğrulama cihazından gelen verileri kimlik avı yapmak için kullanıldığı Yubikey olayıdır.

Bu, çözüldüğü söylenen bir güvenlik sorunu olduğundan, Chrome'un Chrome 67'deki belirli bir cihaz grubunu ve belirli bir sınıf kümesini engellemeyi içeren azaltma çabalarına dalmayı merak ettim.

Sınıf/Cihaz Engelleme Listesi

Dolayısıyla, şu anda çok genel izin istemine ek olarak, Chrome'un vahşi doğada meydana gelen WebUSB istismarlarına karşı asıl savunması, belirli cihazları ve cihaz sınıflarını engellemekti.

Bu, yeni bir teknoloji veya deney için basit bir çözüm olabilir, ancak WebUSB daha popüler hale geldiğinde (ve eğer) başarılması giderek zorlaşacaktır.

WebUSB üzerinden eğitim cihazlarında yenilik yapanların zor duruma düşmelerinden korkuyorum. Prototiplemeyi tamamladıklarında, onlarla hiçbir ilgisi olmayan güvenlik sorunlarına dayalı olarak yalnızca tarayıcı sürümleriyle birlikte güncellenen, sürekli değişen bir dizi standart olmayan engelleme listesiyle karşı karşıya kalabilirler.

Bu API'yi buna değinmeden standartlaştırmanın, ona güvenen geliştiricilere ters etki yapacağını düşünüyorum. Örneğin, birisi hareket dedektörleri için bir WebUSB uygulaması geliştirmek için döngüler harcayabilir, ancak daha sonra hareket dedektörlerinin ya güvenlik nedeniyle ya da işletim sisteminin bunları ele almaya karar vermesi nedeniyle hareket dedektörlerinin engellenen bir sınıf haline geldiğini ve tüm WebUSB çabalarının gitmesine neden olduğunu öğrenmek için harcayabilir. boşa harcamak.

Güvenlik ve Özellikler

Platform bitişiklik teorisi, bazı yönlerden, yetenekleri ve güvenliği sıfır toplamlı bir oyun olarak kabul eder ve güvenlik ve gizlilik endişelerinde çok tutucu olmanın platformların alaka düzeyini kaybetmesine neden olacağını düşünür.

Arduino'yu örnek olarak alalım. Arduino iletişimi WebUSB ile mümkündür ve büyük bir kullanım durumudur. Bir Arduino cihazı geliştiren biri, bir sitenin cihazlarına WebUSB kullanarak (bazı kullanıcı izinleriyle) erişmeye çalıştığı yeni bir tehdit senaryosu düşünmek zorunda kalacak. Spesifikasyona göre, bu cihaz üreticisinin artık "cihazlarını yalnızca imzalı bellenimi kabul edecek şekilde tasarlaması" gerekiyor. Bu, ürün yazılımı geliştiricilerine yük ekleyebilir ve geliştirme maliyetlerini artırabilirken, spesifikasyonun tüm amacı tam tersini yapmaktır.

WebUSB'yi Diğer Çevre Birimlerinden Farklı Kılan Nedir?

Tarayıcılarda, kullanıcı etkileşimleri ile sentetik etkileşimler (web sayfası tarafından başlatılan etkileşimler) arasında açık bir ayrım vardır.

Örneğin, bir web sayfası kendi başına bir bağlantıya tıklamaya veya CPU'yu/ekranı uyandırmaya karar veremez. Ancak harici cihazlar, örneğin, bir fare cihazı kullanıcı adına bir bağlantıya tıklayabilir ve işletim sistemine bağlı olarak hemen hemen her USB cihazı CPU'yu uyandırabilir.

Bu nedenle, mevcut WebUSB spesifikasyonu ile bile, cihazlar birkaç arayüz uygulamayı seçebilir, örneğin adb için hata ayıklama ve işaretçi girişi için HID ve ADB'den yararlanan kötü niyetli kod kullanmak, bir keylogger haline gelmek ve kullanıcı adına web sitelerine göz atmak. doğru sömürülebilir bellenim yanıp sönme mekanizması.

Bu cihazı bir engelleme listesine eklemek, ADB veya izin verilen diğer yanıp sönme biçimleri kullanılarak güvenliği ihlal edilmiş donanım yazılımına sahip cihazlar için çok geç olacak ve cihaz üreticilerini, cihazlarıyla ilişkili güvenlik düzeltmeleri için tarayıcı sürümlerine eskisinden daha fazla bağımlı hale getirecektir.

Bilgilendirilmiş Rıza ve İçerik

Bilgilendirilmiş onay ve USB ile ilgili sorun, daha önce belirtildiği gibi, USB'nin (özellikle ekstra genel WebUSB kullanım durumlarında) içeriğe özgü olmamasıdır. Kullanıcılar yazıcının ne olduğunu, kameranın ne olduğunu bilir, ancak çoğu kullanıcı için "USB" yalnızca bir kablo (veya bir soket) - bir amaca giden yol - çok az kullanıcı USB'nin bir protokol olduğunu ve web siteleri arasında onu neyin etkinleştirdiğini bilir ve cihazlar anlamına gelir.

Bir öneri, "Bu web sayfasının cihazı ele geçirmesine izin ver" satırları boyunca bir "korkutucu" komut istemine sahip olmaktı (bu, görünüşte zararsız "bağlanmak istiyor" üzerinde bir gelişmedir).

Ancak istemler ne kadar ürkütücü olursa olsun, tarayıcının yakından tanımadığı bir USB çevre birimine ham erişimle yapılabilecek olası şeylerin genişliğini açıklayamazlar ve eğer öyleyse, aklı başında hiçbir kullanıcı "Evet" i tıklamazdı. ”, hatasız olduğuna tamamen güvendikleri bir cihaz ve güncel olduğuna ve kötü niyetli olmadığına gerçekten güvendikleri bir web sitesi değilse.

Bunun gibi olası bir istemde "Bu web sayfasının potansiyel olarak bilgisayarınızı ele geçirmesine izin verin" yazacaktır. Bunun gibi korkutucu bir istemin WebUSB topluluğu için faydalı olacağını düşünmüyorum ve bu diyaloglarda sürekli değişiklik yapılması topluluğun kafasını karıştıracaktır.

Prototipleme ve Ürün Karşılaştırması

Bunun olası bir istisnasını görebiliyorum. WebUSB ve diğer proje Fugu API'lerinin amacı, ürün sınıfı cihazlardan ziyade prototiplemeyi desteklemek olsaydı, her şeyi kapsayan genel istemler mantıklı olabilirdi.

Ancak bunu uygulanabilir kılmak için aşağıdakilerin olması gerektiğini düşünüyorum:

1. Prototipleme için bu varlıkla ilgili beklentileri belirleyen özelliklerde dil kullanın;
2. Bu API'leri, kullanıcının tarayıcı ayarlarında manuel olarak etkinleştirmesi gibi bazı kabul hareketlerinden sonra kullanılabilir hale getirin;
3. Geçersiz SSL sertifikaları gibi "korkutucu" izin istemlerine sahip olun.

Yukarıdakilere sahip olmamak, bu API'lerin prototiplerden ziyade gerçek ürünler için olduğunu düşündürüyor ve bu nedenle geri bildirimler geçerli.

Alternatif Bir Teklif

Orijinal blog gönderisinde hemfikir olduğum kısımlardan biri, “hayır” demenin yeterli olmadığıdır - web dünyasında belirli API'leri zararlı oldukları için reddeden büyük oyuncular da hücum etmeli ve bu yeteneklerin önemli olduğu yollar önermeli. kullanıcılara ve geliştiricilere güvenli bir şekilde maruz bırakılabilir. Herhangi bir önemli oyuncuyu temsil etmiyorum, ama mütevazi bir tavır sergileyeceğim.

Bunun cevabının güven ve ilişkinin 3. boyutunda yattığına ve izin istemleri ve engelleme listelerinin dışında olduğuna inanıyorum.

Basit ve Doğrulanmış İstem

Yapacağım ana durum, istemin çevre birimi hakkında değil içerik veya işlem hakkında olması gerektiği ve bilgilendirilmiş onayın belirli bir doğrulanmış parametre seti ile belirli bir basit işlem için verilebileceğidir. bir cihazı "devralmak" veya "bağlanmak" gibi genel eylemler.

3D Yazıcı Örneği

WebUSB spesifikasyonunda 3D yazıcılar örnek olarak getirildi, bu yüzden onu burada kullanacağım.

Bir 3D yazıcı için bir WebUSB uygulaması geliştirirken, tarayıcı/OS isteminin bana AutoDesk 3ds-mask'in CreatBot 3D yazıcınıza bir model yazdırmasına izin ver? , iyileştirme, kalınlık ve çıktı boyutları gibi bazı yazdırma parametreleriyle ve neyin yazdırılacağının bir önizlemesiyle birlikte bir tarayıcı/işletim sistemi iletişim kutusu gösterilir. Bu parametrelerin tümü, bir sürücü web sayfası tarafından değil, güvenilir bir kullanıcı aracısı tarafından doğrulanmalıdır.

Şu anda tarayıcı yazıcıyı tanımıyor ve istemdeki iddiaların yalnızca bazılarını doğrulayabilir:

• Talepte bulunan etki alanı, AutoDesk'e kayıtlı bir sertifikaya sahiptir, dolayısıyla bunun AutoDesk Inc olduğuna dair bir miktar kesinlik vardır;
• İstenen çevre birimi kendisini “CreatBot 3d yazıcı” olarak adlandırıyor;
• Bu cihaz, cihaz sınıfı ve etki alanı, tarayıcının engelleme listelerinde bulunamadı;
• Kullanıcı, kendisine sorulan genel bir soruya “Evet” veya “Hayır” yanıtını verdi.

Ancak, yukarıdaki ayrıntılarla doğru bir istem ve iletişim kutusu göstermek için tarayıcının aşağıdakileri de doğrulaması gerekir:

• İzin verildiğinde, gerçekleştirilen eylem bir 3B model basmak olacaktır ve bundan başka bir şey değildir;
• Seçilen parametrelere (iyileştirme/kalınlık/boyutlar vb.) uyulacaktır;
• Neyin yazdırılacağının doğrulanmış bir ön izlemesi kullanıcıya gösterildi;
• Bazı hassas durumlarda, bunun aslında AutoDesk olduğuna dair ek bir doğrulama, belki de iptal edilebilir kısa ömürlü bir belirteç gibi bir şeyle.

Yukarıdakileri doğrulamadan, bir 3B yazıcıya "bağlanma" veya "devralma" izni verilen bir web sitesi, bir hata (veya bağımlılıklarından birindeki kötü amaçlı kod) nedeniyle büyük 3B modelleri yazdırmaya başlayabilir.

Ayrıca, hayal edilen tam gelişmiş bir web 3D yazdırma özelliği, WebUSB'nin sağlayabileceğinden çok daha fazlasını yapar - örneğin, farklı yazdırma isteklerini biriktirme ve sıraya alma. Tarayıcı penceresi kapatılırsa bu nasıl ele alınır? Tüm olası WebUSB çevresel kullanım durumlarını araştırmadım, ancak tahmin ediyorum ki bunlara içerik/eylem perspektifinden bakıldığında çoğu USB erişiminden daha fazlasına ihtiyaç duyacaktır.

Yukarıdakilerden dolayı, 3D baskı için WebUSB'yi kullanmak muhtemelen kısa ömürlü olacak ve buna güvenen geliştiricilerin bir noktada yazıcıları için "gerçek" bir sürücü sağlaması gerekecek. Örneğin, işletim sistemi satıcıları 3D yazıcılar için yerleşik destek eklemeye karar verirse, WebUSB ile bu yazıcıyı kullanan tüm siteler çalışmayı durdurur.

Öneri: Sürücü Denetim Otoritesi

Bu nedenle, "çevre birimini devralmak" gibi kapsamlı izinler sorunludur, tam teşekküllü bir parametre iletişim kutusu göstermek ve sonuçlarına saygı duyulacağını doğrulamak için yeterli bilgiye sahip değiliz ve göndermek istemiyoruz. kullanıcı web'den rastgele bir yürütülebilir dosyayı indirmek için güvenli olmayan bir yolculukta.

Ama ya WebUSB API'sini dahili olarak kullanan ve aşağıdakileri yapan denetlenmiş bir kod parçası, bir sürücü varsa:

• “Yazdır” komutunu uyguladı;
• Sayfa dışı yazdırma iletişim kutusu görüntülendi;
• Belirli bir USB aygıtı grubuna bağlı;
• Eylemlerinden bazılarını sayfa arka plandayken (örn. bir hizmet görevlisinde) veya tarayıcı kapalıyken gerçekleştirdi.

Bunun gibi bir sürücünün denetimi, yaptığının "yazdırma" anlamına geldiğinden, parametrelere uyduğundan ve baskı önizlemesini gösterdiğinden emin olabilir.

Bunu, web ekosisteminde tarayıcı satıcılarından bir şekilde kopuk olan önemli bir parça olan sertifika yetkililerine benzer olarak görüyorum.

Sürücü Sendikasyonu

Tarayıcı/OS satıcısı sürücüleri kendi başına denetlemeyi seçebilse de, sürücülerin Google/Apple tarafından denetlenmesi gerekmez. SSL sertifika yetkilileri gibi çalışabilir - veren kuruluş oldukça güvenilir bir kuruluştur; örneğin, belirli bir çevre biriminin üreticisi veya birçok sürücüyü sertifikalandıran bir kuruluş veya Arduino gibi bir platform. (Let's Encrypt'e benzer kuruluşların ortaya çıktığını hayal ediyorum.)

Kullanıcılara şunu söylemek yeterli olabilir: “Arduino, bu kodun Uno'nuzu bu bellenim ile flaş edeceğine güveniyor” (firmware önizlemesiyle).

uyarılar

Bu elbette potansiyel problemlerden arınmış değildir:

• Sürücünün kendisi hatalı veya kötü niyetli olabilir. Ama en azından denetleniyor;
• Daha az “web”dir ve ek bir geliştirme yükü oluşturur;
• Bugün mevcut değil ve tarayıcı motorlarındaki dahili yeniliklerle çözülemez.

Diğer Alternatifler

Diğer alternatifler, tarayıcılar arası Web Uzantıları API'sini bir şekilde standartlaştırmak ve iyileştirmek ve Chrome Web Mağazası gibi mevcut tarayıcı eklenti mağazalarını, kullanıcı istekleri ile çevresel erişim arasında aracılık ederek bir tür sürücü denetleme yetkilisi haline getirmek olabilir.

Görüş Özeti

Yazar, Google ve ortaklarının yeteneklerini geliştirerek açık web'i alakalı tutmak için cesur çabaları ilham verici.

Ayrıntılara indiğimde, Apple ve Mozilla'nın web'e karşı daha muhafazakar bakış açısını ve yeni cihaz yeteneklerine karşı savunmacı yaklaşımlarını teknik değer taşıdığını görüyorum. Açık uçlu donanım yetenekleriyle ilgili bilgilendirilmiş onayla ilgili temel sorunlar, çözülmekten çok uzaktır.

Apple, cihaz yeteneklerini etkinleştirmenin yeni yollarını bulmak için tartışmada daha açık sözlü olabilir, ancak bunun, rekabet karşıtı bir bakış açısından değil, on yıllardır Apple'ın kimliğinin bir parçası olan bir bakış açısı olan bilgi işlem hakkında farklı bir perspektiften geldiğine inanıyorum.

Fugu projesinde ve özellikle WebUSB'deki biraz açık uçlu donanım yetenekleri gibi şeyleri desteklemek için, web'in güven modelinin izin istemlerinin ve etki alanı/cihaz engelleme listelerinin ötesine geçmesi, sertifika yetkilileri ve benzeri güven ekosistemlerinden ilham alması gerekiyor. paket dağıtımları

SmashingMag'de Daha Fazla Okuma :

• Web Sitesi Performansını Geliştirmek Gezegeni Kurtarmaya Nasıl Yardımcı Olabilir?
• Reklamsız Bir Web'e Doğru: Çevrimiçi Ekonomiyi Çeşitlendirmek
• Harika Kod Yazmanın Ötesinde Bir Gelecek Var mı?
• Web Tasarımında Etik Kullanımı