Google brengt Chrome 61 met WebUSB-api's uit

Google heeft versie 61 van zijn Chrome-browser uitgebracht voor Windows, macOS, Linux en Android. De update brengt een aantal fixes naar de browser en daarnaast is onder andere ondersteuning voor de WebUSB- en de WebShare-api's en JavaScript-modules toegevoegd.

De introductie van Chrome 61 voor de desktop gaat gepaard met het verhelpen van 22 kwetsbaarheden, waaronder 6 die als ernstig bestempeld worden. Zo heeft Google een heap buffer overflow-probleem bij WebGL-verwerking opgelost en een https-downgrade-mogelijkheid bij redirects voorkomen.

Daarnaast zijn enkele verbeteringen voor ontwikkelaars doorgevoerd. Zo is er ondersteuning voor JavaScript-modules, met voordelen op het gebied van caching, het voorkomen van duplicaties op pagina's en het verwerken van scripts in de juiste volgorde.

Verder ondersteunt Chrome vanaf versie 61 WebUSB. Hiermee kunnen web-apps na toestemming van de gebruiker bepaalde usb-apparaten benaderen die nu nog niet met api's ondersteund werden. Hiervoor zijn nu geen speciale drivers meer nodig.

Nieuw bij Chrome voor Android is WebShare, waarmee pagina's het menu op een smartphone om tekst en links te delen kunnen oproepen. Verder is op Android de vertaaltoolbar compacter gemaakt en is de manier om afbeeldingen te selecteren om online te zetten, verbeterd.

Reacties (86)

[dehardstyler]

En waarom zou ik willen dat mijn USB apparaten beschikbaar zijn in mijn browser? Ik kan er één bedenken en dat is een security token / wachtwoordkluis op USB. Voor de rest wil ik juist dat het helemaal niet beschikbaar is in mijn browser.

[mstx]

Alle apparaten die niet expliciet aangeven dat ze compatible zijn, zijn niet beschikbaar.

The WebUSB API does not even try to provide a way for a web page to connect to arbitrary USB devices. There are plenty of published attacks against USB devices that makes it unsafe to allow this.

For this reason, a USB device can define a set of origins that are allowed to connect to it. This is similar to the CORS mechanism in HTTP. In other words, WebUSB devices are associated with a web origin and can only be accessed from a page from the same origin.

Hardware manufacturers will have to update the firmware in their USB devices in order to enable WebUSB access to their device via the Platform Capability descriptor. Later a Public Device Registry will be created so that hardware manufacturers can support WebUSB on existing devices.

https://developers.google...ss-usb-devices-on-the-web

[Reactie gewijzigd door mstx op 25 juli 2024 00:33]

[dehardstyler]

Uit die zelfde link: "make USB safer and easier to use by bringing it to the Web."
Hoe wordt iets "safer" van het "naar het Web brengen"?
Kan ik mij niet voorstellen namelijk. Dat het niet onveilig is, oke dan. Maar dat het veiliger wordt, nou nee.
Ik kan mij ook niet voorstellen dat ik hier behoefte aan heb, dus ga liever voor een complete sandbox of is dat zo'n rare gedachte?

[WimBarelds]

Door directe toegang te kunnen geven is het niet meer nodig om third-party software of plugins te gebruiken om die verbinding te maken. Ik zie zelf ook nog niet direct een use-case die voor mij meerwaarde bied, maar dit helpt wel bij de veiligheid voor gevallen waar hardware-integratie gewenst is.

[mstx]

Een use-case is bijvoorbeeld mijn Garmin navigatiesysteem. Die gebruikt nu een browser plugin om verbinding te maken tussen het apparaat en de website, bijvoorbeeld om hem te registreren en te bepalen welke kaart-updates beschikbaar zijn. Door daar WebUSB voor te gebruiken heb je geen plugin meer nodig, wat goedkoper is voor de fabrikant en beter voor de consument, want die kan elk OS en elke browser gebruiken die deze API ondersteunt. En waarschijnlijk is het ook veiliger dan een plugin die misschien nooit geüpdated wordt.

[Z80]

Ik zie behoorlijk wat aannames. Hoezo is de nieuwe oplossing veiliger?
Een website mat daarin een frame van de site: ikwilaljoudata.hack met een vermomde akkoord knop trekt het usb apparaat compleet leeg zonder dat een gebruiker dit doorheeft.

[bauke1994]

Een browser draait in een sandbox, het installeren van software kan allerlei malware/addware met zich meenemen.

Niet zomaar iedere website kan toegang krijgen tot ieder USB apparaat, het apparaat zelf moet aangeven welke domeinen toegang tot het apparaat kunnen hebben.
Tot slot moet de gebruiker toegang verlenen voor de USB API's, dit gaat via een vergelijkbare melding als die van de notificatie API, dus niet via één of andere vermomde akkoord knop maar via een native browser melding.

-edit-
De aanname dat het veiliger is kan ik me in vinden, een lek in de browser plugin(van bv. Garmin) zal niet zo snel worden gedicht als een lek in de USB API.

[Reactie gewijzigd door bauke1994 op 25 juli 2024 00:33]

[sHELL]

Interessante inkijk, zou het dan ook mogelijk zijn om een bvb navigatie apparaat te updaten via een chrome book?

[edwinjm]

Goed voorbeeld. Maar bijvoorbeeld ook aan de fitness trackers die veel mensen gebruiken. Juist iets technisch mogelijk maken kan voor ontwikkelingen zorgen waar we nu nog geen weet van hebben.

[Reactie gewijzigd door edwinjm op 25 juli 2024 00:33]

[TommieW]

Ik kan me voorstellen dat misschien zo'n E.dentifier van de ABN-Amro via USB beter kan werken met een dergelijke API.

[Reactie gewijzigd door TommieW op 25 juli 2024 00:33]

[TrekVogel]

Wordt dat nog ondersteund via USB dan? Ik dacht dat ze daar mee gestopt waren.

Niettemin zou dat een goede toepassing zijn.

[Dreamvoid]

De user case is ChromeOS.

[tagican]

Ik ken wel apparatuur dat wordt gebruikt van het flashen van bepaalde hardware. De aansturing gebeurt via een webportal, maar het vereist nu nog een aparte plugin. Wellicht dat deze WebUSB implementatie dit makkelijker maakt. Ik ga er wel vanuit dat er wel eerst toestemming moet worden gegeven, gezien het anders wel vrij gevoelig is voor misbruik.

[dehardstyler]

Ook dat snap ik dus totaal niet! Waarom zou je in godsnaam hardware flashen via internet? Dat is toch vragen om ellende met malware? Ook al is het gesigned, dat kan prima offline neem ik aan?

[edwinjm]

Met CD-ROM's bedoel je? Die zijn al een tijdje geen gemeengoed meer.

[dehardstyler]

Je kunt geen mogelijkheden bedenken die tussen het gebruik van een CD-ROM en het gebruik van Internet liggen? Ik neem aan dat je je source-code prima offline kunt hebben en dus ook prima offline kunt flashen. Of ken je geen USB kabels?

[edwinjm]

Je hebt toch een medium nodig om aan de firmware te komen. Als dat per se offline moet, dan kom je op CD-ROM's of USB-sticks uit.

Via een browser flashen is juist veel veiliger. Sommige fabrikanten bieden wel de firmware aan, maar het programma om te flashen moet je op internet zoeken. Dan moet je maar hopen dat daar niets malafide bij zit. Als je vanuit Chrome, direct vanaf de website van de fabrikant naar je device flashed, dan kan je er toch best zeker van zijn dat het goed zit.

[dehardstyler]

Via een browser flashen is juist veel veiliger.

Het is denk ik gewoon even wennen voor mij dan, maar in mijn ogen moet je alles wat via je webbrowser gebeurt juist als onveilig aanmerken. Als ik moet flashen, download ik het liever en check de source lokaal als het open is. Dan hang je het te flashen apparaat via USB / Serial aan de PC, of zet het inderdaad op een USB stick die ik vertrouw en ga dan flashen. In plaats van direct aan internet hangen en maar gewoon flashen via een of andere API die Google beheerd.

Maar wil je eens uitweiden waarom via een browser flashen "veel veiliger" is?

[curry684]

Het is denk ik gewoon even wennen voor mij dan, maar in mijn ogen moet je alles wat via je webbrowser gebeurt juist als onveilig aanmerken.

Dan kun je ze heden ten dage gewoon beter niet meer gebruiken. De browser is op meer dan 1 manier het nieuwe OS van dit decennium, met je eigen OS (Windows/Mac/Linux) als (extra) virtualisatielaag.

Waar we hard naar onderweg zijn is dat applicaties, van Word Online tot Dropbox tot Gmail tot complete remote oplossingen als Docker Cloud niet meer native op je computer draaien, met veel te veel rechten op je lokale filesystem, maar veilig in de rigide sandbox van een browser, met enkel toegang tot HTML en Javascript. De Chromebook is hier op dit moment het epitoom van, dat het host OS heeft gereduceerd tot een minimaal laagje op een Linuxkernel. Zelfs voor desktopapplicaties is deze beweging al grootschalig bezig. Applicaties als Github Desktop en Slack draaien in Electron, een lokale eigen browser context.

Aan het eind van de dag heb je dus inderdaad veiliger systemen, omdat er 2 lagen met sloten op de deuren zitten - de browser sandbox, en als die horde onverhoopt wordt genomen de kernel van een echt OS. En sneller softwareontwikkeling, omdat webtechnologie de facto portable is. En extra inkadering omdat de webAPI's veel meer rigide worden opgezet dan de generieke native API's die alles moeten kunnen per definitie.

Om binnen het flash voorbeeld te blijven: native applicaties kunnen altijd bij je hardware, en dus kan free_tacos.exe die je moeder download ook je hardware flashen. Een browser doet in dit geval de origin checks voor je, dat het commando alleen mag komen van een HTTPS-enabled strict gedefinieerd domein, en vraagt je daarna ook nog expliciet toestemming voor ie toegang tot de beperktere API geeft. Ja, dat is extreem veel veiliger.

[dehardstyler]

Thanks voor je uitleg, dat maakt het een stuk duidelijker!

[tagican]

Vanuit die denkwijze zou je eigenlijk ook niets meer kunnen downloaden en/of afspelen in je browser. Zolang je toestemming moet geven aan specifieke pagina's (het liefst natuurlijk met SSL ondersteuning - ik weet niet of dat vereist is), dan lijkt mij het niet direct een probleem. Betreft overigens generieke hardware dat vervolgens - legaal - met platform-specifieke firmware kan worden overschreven. Daarbij is het wel handig om zoiets makkelijk toegankelijk te hebben en niet elke keer een apart programma te moeten downloaden en te installeren op je pc.

[dehardstyler]

Ik vind *iets* downloaden iets heel anders als hardware flashen via internet, maar goed. Dat het makkelijk is is uiteraard waar. Ik vind het ook makkelijker om helemaal geen wachtwoord te hoeven intypen bij internetbankieren, maar dat betekend niet dat het een goede en veilige optie is.

[curry684]

het liefst natuurlijk met SSL ondersteuning

Ja natuurlijk, zie https://wicg.github.io/webusb/#security-and-privacy

Secondly, this specification requires that only secure contexts as described in [powerful-features] can access USB devices. This ensures both the authenticity of the code executing on behalf of the origin and that data read from the device may not be intercepted in transit.

[MSalters]

Cryptografie is goed genoeg om malware tegen te houden; elk zichzelf respecterend device checkt de signature van firmware. Gebruiksgemak is dus de doorslaggevende factor, en zeker voor consumentenproducten is offline flashen niet makkelijk.

[dehardstyler]

Ja, dat ging laatst ook zo goed bij Medoc in Oekraïne.
Ow en laten we vooral NetSarang niet vergeten laatst.

[wizzkizz]

Wellicht omdat je dan gemakkelijker gebruik kunt maken van je hardware 2FA/FIDO devices?
Die kun je dan blijkbaar zo instellen dat deze alleen bij het bezoeken van de juiste URI beschikbaar is, wat meteen een beveiliging is tegen phishing/uri encoding attacks.

[dehardstyler]

Ja daar begon ik mee in mijn eerste reactie: " Ik kan er één bedenken en dat is een security token / wachtwoordkluis op USB."
Maar ook die zie ik liever alleen via HID werken.

[Verwijderd]

Medische instanties gebruiken meestal een USB card reader met daarin weer een kaart met cert. Hoe dat nu vaak gaat is dat je via JRT (kots) browser plugin je USB apparaat dan kunt laten uitlezen door de site. Als ik moet kiezen tussen Java en native doorgeven dan weet ik het antwoord wel.

[Batje4]

Dat is een keuze van de ontwikkelpartij, het is hun keuze om het via Java of andere oplossingen te doen. Er zijn dus alternatieven. Als de markt veilige alternatieven voor JAVA heeft, dan kan dat worden toegevoegd.
In de eerstelijns zorg en ook in ziekenhuizen wordt veel gebruik gemaakt van de UZI-pas met de UZI-card reader dat via USB is gekoppeld. Voor de koppeling met de applicaties is onlangs een nieuwe infrastructuur Zorg-ID in gebruik genomen, zie o.a. https://www.vzvz.nl/page/ICT-leverancier/ZORG-ID.

[Reactie gewijzigd door Batje4 op 25 juli 2024 00:33]

[keesdewit]

Er zijn eigenlijk geen alternatieven om gebruik te maken van certificaten op een usb token via een browser. Het enige wat je kunt doen is Java gebruiken, maar dat werkt bij de meeste browsers niet eens meer. Daarnaast zou een browser specifieke plugin mogelijk ook kunnen werken, maar dan zit je vast aan één browser of heb je een hoop onderhoud aan de diversiteit van plugins voor de verschillende browsers.

[t link]

Ik weet niet zozeer of dat een keuze is van de ontwikkelpartij of gewoon dat er in de zorg heel weinig ruimte is om geld te besteden waardoor er geen incentive is om verder te ontwikkelen. veel instellingen draaien nu al jaren verlies, dan gaan die ook niet investeren in een nieuw systeem dat ze nooit kunnen terugverdienen.

[YopY]

Gamecontrollers. Let ook dat dit voor Google belangrijk is voor Chrome OS, dan hebben ze nog minder afhankelijkheid van het onderliggende OS.

[PPie]

Zijn gamecontrollers niet gewoon HID devices?

[Anonymoussaurus]

Dat klopt, gamecontrollers (m'n XBOX controller en Logitech Driving Force GT) worden ook gewoon gezien als HID devices.

[RangedNeedles]

Hiervoor bestaat al wel een tijdje een API, namelijk de GamePad API

[EJlol]

Zolang de gebruiker eerst toestemming moet geven, zie ik geen probleem. Andere dingen waarbij ik USB toegang zou geven zijn bv firmware updates.

[dehardstyler]

Als de gebruiker ergens toestemming voor kan geven, ligt er potentieel een "attack surface". Ik wil helemaal niet dat er een optie is. Liever gewoon een complete sandbox, en dan de security token / wachtwoordkluis alleen toelaten via HID USB.

[Dreamvoid]

Ik ook, maar sandboxing is al een tijdje lang dood. Niet in naam (iedereen roept dat hij het heeft), maar in de praktijk. Inmiddels hebben browsers toegang tot je camera, USB devices, PCIe devices (gpu acceleratie) en filesystem. En er is een krachtige runtime enviroment (=je JavaScript engine) die ongeverifieerde remote web code draait, die 24/7 vanaf tientallen domeinen tegelijk naar hartelust kan proberen gaten te slaan in je browser. Je kan alleen maar hopen dat al die API's 100% correct zijn geimplementeerd.

Ik ben er nog altijd fel tegen, in mijn ogen moeten we vooruit naar een web 3.0 met HTML5 zonder JavaScript, nul toegang tot filesystems, low-level gpu libraries en randapparatuur. 99% van de web functionaliteit kan je daar ook mee doen, met als enige prijs wat meer page reloads. Maar de trein naar meer en meer attack vectors die vanuit het web bereikbaar zijn, die dendert maar door.

[Reactie gewijzigd door Dreamvoid op 25 juli 2024 00:33]

[gimbal]

Dat maakt de sandbox niet dood - in tegendeel juist. Voorheen via alle externe plugins was de sandbox dood, de gehaatte Java en Flash plugins maakte het mogelijk om de browser sandbox te doorbreken doordat er native code werd geinjecteerd wat direct toegang zou kunnen hebben naar het OS, buiten de security maatregelen van de browser om.

Maar nu is het plugin gedoe eruit en zit de ondersteuning voor dit soort technieken native ingebouwd in de browser waardoor het dus binnen de sandbox van de browser blijft. Dat deel vind ik persoonlijk een enorme verbetering. Maar uiteraard worden browsers door de totale wildgroei aan web api's daardoor complexe monsters en dan neemt het risico op fouten weer sterk toe.

[Dreamvoid]

Een sandbox met DMA, local file access en toegang tot allerlei randapparatuur verdient wat mij betreft net zo min het woord 'sandbox' als elke willekeurig lokale applicatie of runtime environment onder lokale user rechten. Je verschuift de attack vector enkel enkel van de plugin naar de browser.

[Reactie gewijzigd door Dreamvoid op 25 juli 2024 00:33]

[dehardstyler]

Maar de trein naar meer en meer attack vectors die vanuit het web bereikbaar zijn, die dendert maar door.

Dit dus! En dat dan allemaal zodat Pietje zijn Skype camera kan gebruiken, die overigens natuurlijk wel eerst WebUSB API compatible moet zijn...
Wat een ellende.

[curry684]

sandboxing is al een tijdje lang dood

Je begrijpt het concept "sandbox" niet helemaal. Sandboxing is niet bedoeld om te beperken, maar om te controleren. Denk aan een echte zandbak met kinderen, waarom zou je daar geen schaar in kunnen leggen om snoepzakjes mee open te maken als er permanent 20 ouders naast de zandbak staan op te letten en afstraffen bij de eerste niet vooraf goedgekeurde handeling? Het gaat om de gecontroleerde doch vrije toegang en het ingrijpen als er misbruik wordt gemaakt, niet om het beperken van mogelijkheden waardoor wenselijke acties niet meer mogelijk zijn.

De sandbox is juist levendiger dan ooit. De "Docker revolutie" heeft in 3 jaar bereikt dat zelfs serverapplicaties massaal in sandboxes draaien in datacenters. Juist omdat het een goed idee is dat 1 gehackt stuk webserver niet de rest van de server(s) met root-rechten kan infecteren of benaderen.

[Li1quid]

Meer en meer evalueren naar een systeem waarbij de browser belangrijker wordt dan het OS. En stapje per stapje wordt het OS overbodig gemaakt.

[Zapato]

Chrome OS

[84hannes]

offtopic:
Je bedoelt "evolueren"

[SampleUser]

Misschien voor custom toetsenbordhobbyisten? dan kan je heel makkelijk de firmware vanuit een website flashen

[SinergyX]

Waarom zou je al zo'n custom keyboard op je Chrome aansluiten? Niet dat je er bijster veel mee kan doen.

[mschol]

denk aan een webapplicatie die een weegschaal uitleest, deze informatie in een database bij een product zet en eventueel bijvoorbeeld ook een printer aanstuurt om een sticker/etiket uit te printen?

[Vuikie]

Wat jezelf noemt is al een usecase. In de maker community zal dit ook verwelkomt worden nu de Arduino's/maker devices ook in een browser-ide ontwikkeld kan worden én kan downloaden zonder 1 of andere shady driver nodig te hebben.

Ik vraag me dan wel af of dit ook naar ChromeOS komt...

[Reactie gewijzigd door Vuikie op 25 juli 2024 00:33]

[broodplank]

Inderdaad, erg veilig klinkt een WebUSB API zeker niet. En ik denk dat de API ook zeker misbruikt kan gaan worden door hackers.

[edwinjm]

Waarom denk je dat het niet veilig is? Heb je de documentatie gelezen?

[Kafka]

Alles kan misbruikt worden. Moeten we dan maar stoppen en in een hoekje zitten?

[dehardstyler]

Alles kan misbruikt worden, moeten we dan alles maar aan het internet hangen?

[deadlock2k]

Je kan het niet willen maar de wereld beweegt naar CLOUD (dat heeft een autocorrect naar hoofdletters in mijn telefoon) en browser based. Dat maakt het goedkoper en eenvoudiger om nieuwe functionaliteit uit te rollen voor bedrijven.

Je kan het er niet mee eens zijn maar het is een beweging die niet terug te draaien is.

[ViNyL]

Op een Chromebook kun je dan bijvoorbeeld Skype gebruiken?

[bauke1994]

Dat 'zou' met HTML5 allang kunnen. Microfoon en webcam API's bestaan al veel langer en zullen ook veel eenvoudiger in gebruik zijn dan een WebUSB API die direct een webcam of microfoon aanspreekt. Verder zal je dan over een voor Skype geschikte webcam en mic moeten beschikken omdat het USB apparaat bepaalt welke website gebruik mogen maken van de WebUSB API.

[lecrab]

Dat kan al, indien je de playstore installeert. De playstore op Chrome OS maakt het OS echt compleet. Die twee samen is geweldig. Althans, dat vind ik.

[ViNyL]

Ja je hebt gelijk, daarmee wel maar mogelijk dat dit voor webbased meer opties biedt?

[lecrab]

Tja, dat weet ik dan weer niet. Ik gebruik geen skype. De apps die ik wel gebruik onder android in chrome os, zijn uitgebreider dan de webvarianten die chrome os zelf aanbied in de meeste gevallen. Daarnaast draaien ze "los" en niet in een browsertab.

[tim085]

Online arduino IDE bijvoorbeeld, scheelt een hoop, dan hoef ik niet meer manueel software en libraries te gaan installeren, maar staat alles gewoon klaar, en kan ik de code meteen op de arduino compilen.

[Lordfox73]

Nou, een scanner bijvoorbeeld. Als je documenten in wilt scannen om te uploaden naar bijvoorbeeld een zorgverzekeraar. Daar zie ik wel iets in.

[MSalters]

Dat zou beter kunnen via een Device Class API. Deze API is vendor-specifiek, en ik wil m'n zorgkosten niet via Logitech uploaden. Maar op zich is het wel acceptabel dat een Logitech scanner nieuwe firmware kan downloaden van Logitech's site.

[totaalgeenhard]

Zoals in filmpje werd aangegeven je kunt input devices hebben (voor gehandicapten) die je niet volledig kunt gebruiken in een webbrowser.

Het enige wat ik wel verwacht dat het standaard uit staat, ook verwacht ik dat je Chrome aan corporate policies (centraal) kunt houden, zodat je niet een situatie krijgt dat iemand cloud leeg trekt vanaf ze werkplek en het op een USB device stopt. (die zijn te spoofen namelijk)

[Verwijderd]

Texas Instruments biedt zijn IDE voor microcontroller ontwikkeling online aan. Helaas moet ik vooralsnog een driver/plugin installeren als ik mijn ontwikkelde applicatie in mijn lokale microcontroller wil flashen. Met WebUSB hoeft dat dus niet meer!
Voor diegenen die hier nooit iets mee doen, je kan dit makkelijk doortrekken naar andere zaken. Wat dacht je van je telefoon rooten vanaf een website, in plaats van een tool als Odin te moeten downloaden of installeren.
Je lokale Cisco firewall via zijn terminal laten benaderen door Cisco tech support vanuit de webchat.
Je game muis van een nieuwe firmware voorzien door op het knopje "upgrade" te drukken i.p.v. een applicatie ervoor te downloaden.
Ik kan er nog wel een paar verzinnen, maar ik denk dat je zo al een redelijk beeld hebt van mogelijke nuttige/makkelijke functies.

[tweakPiet]

Omdat Chrome geen browser meer is! Google noemt het zelf een applicatie platform. Dat platform kan alleen groeien als het meer kan communiceren dan alleen met web servers.
Het OS van vroeger is eigenlijk de browser van nu aan het worden. Je browser draait web applicaties in plaats van web sites.

[418O2]

Web USB is wel echt een bazen API. Daar gaan leuke dingen mee bedacht worden (sensoren uitlezen bijvoorbeeld).

Valt me vaak tegen dat Tweakers alleen maar lopen te zieken en de negatieve punten willen inzien, maar niet denken in de mogelijkheden denken. Zeiken is natuurlijk ook veel makkelijker

[Verwijderd]

Daar gaan leuke dingen mee bedacht worden (sensoren uitlezen bijvoorbeeld).

Daar zijn applicaties voor... niet webbrowsers.

maar niet denken in de mogelijkheden denken.

Zoals een slechte website die ongevraagd access krijgt tot je hardware ? Ben je nou echt zo blind dat je niet ziet dat de hedendaagse browsers nog steeds BAGGER zijn ?

[418O2]

Waarom geen webapplicaties? Ik zie een toekomst waarin alles een webapplicatie kan zijn.

Die sites krijgen geen ongevraagde toegang. Dit loopt via dezelfde beveiliging als andere Apis (notificaties, camera etc)

[vinno97]

Dat is juist de kracht van WebUSB. Ieder programma wat je installeert heeft vrijwel ongelimiteerde toegang tot je computer als die dat wil. Het moderne web kan veel, maar heeft net als een App toestemming nodig voor iedere functie. Zo zul je dus bijv niet een agendaprogramma hebben dat even fijn toegang heeft tot al je USB-apparaten.

[WokeBroke]

Misschien leuk voor game controllers en VR spul. Maar tot nu toe lijkt het er een beetje op dat game ontwikkelaars HTML5 een beetje links laten liggen.

[Verwijderd]

Zolang performance een issue is zullen ze dat wel blijven doen ook.

[thomasmoors]

Ik las hier al eerder over omdat het mogelijk tijdens mijn onderzoek voor mijn scriptie een probleem op zou kunnen lossen. We probeerden namelijk bestaande software te porten die gehoortoestellen kan uitlezen naar een webapplicatie. Of dit dan ook via deze WebUSB API kan is natuurlijk de vraag alsnog, maar voor webapps een zeer interessante ontwikkelling.

[Verwijderd]

Niet alles moet naar de browser toe. Jou 'probleem' behoort gewoon in een applicatie geschreven te worden... daar zijn ze tenslotte voor.

[thomasmoors]

(Dit keer mag er wel een "w" achter jouw). Maar waarom zouden wij geen webapplicatie mogen maken van een softwarepakket? Dit probleem was een deel van een veel grotere applicatie die veel baat zou hebben om een webapplicatie te worden. Nu is de oplossing een kleine agent / background worker voor windows die de connectie via REST tot stand brengt.

[Martinspire]

Ik vind Javascript Modules de grootste feature. Al is het nog afwachten hoe bruikbaar dit is en of het qua snelheid en performance de concurrentie met de huidige middelen aan kan. Het is in ieder geval wel handig om zaken te debuggen.

[henk1994]

De app 'Android System Webview' op Android wordt gebruik voor het weergeven van webbased apps. Die is ook geupdated naar versie 61. De verbeteringen in Chrome 61 wordt daarmee ook beschikbaar voor Android apps.

De WebUSB functionaliteit kan dus ook gebruikt worden in apps, en daarmee kun je bijvoorbeeld gebruik maken van gecertificeerde usb-tokens in apps door deze aan te sluiten.

Ook het voordeel van de JavaScript modules kan geïmplementeerd worden waardoor je weer snelheidsoptimalisatie hebt en het performance verschil (naar verwachting) minder groot gaat worden.

[bbc]

Ik zou op het werk een soort check-in desk willen, waarbij een bezoeker zichzelf kan in-checken of toch al gedeeltelijk.

- Bezoeker scant de MRZ van zijn ID
- Neem foto.
- Print badge.
- Bezoeker gaat naar receptioniste die ID nakijkt en badge activeert.

Porteus kiosk is erg geschikt voor kiosk toepassingen. Het aansturen van usb devices vanuit een browser is echter moeilijker. Misschien kan dit dus een oplossing bieden voor mijn problemen, in de veronderstelling dat er drivers zijn voor linux natuurlijk.

[Verwijderd]

Dit is echt TE debiel voor woorden. In geen 100 jaar dat mijn browser toegang ga geven om bij mijn externe hardware te kunnen. Snap ook niet waar ze dit vandaan halen.

[vinno97]

Maar wel programma's op je PC gebruiken die ongelimiteerde toegang hebben tot je volledige computer?
Inderdaad.. Een webapplicatie die alleen maar via toegang kan krijgen tot features als deze hiervoor toestemming vraagt, is echt extreem gevaarlijk. Vooral als deze alleen via HTTPS bruikbaar zijn

[Demonitzu]

Edit: Chrome 61 is niet voor Android verschenen ondanks diverse nieuwsvermeldingen

[Reactie gewijzigd door Demonitzu op 25 juli 2024 00:33]

[alexanderjcs]

er zitten BEWUSTE lekken ook in deze versie!!!

[ViNyL]

Wat bedoel je? Waarom in "deze" versie?