Should the Web Expose Hardware Capabilities?
smashingmagazine.com
smashingmagazine.com
So how come this gets twisted on its head when it comes to web apps? The user should be allowed to do what they want, right? So why shouldn't I be allowed to use web apps that interact with bluetooth or USB devices? Why should your philosophical arguments on which software on what platform is allowed to do get in the way of my very real productivity and desire to use my computer the way I want to? Why should I _have_ to use native apps if I don't want to? As a web developer, why do I need to learn Qt or GTK or whatever to ship something useful to end users, when I already know HTML and JS and could easily deliver my product if the right native API was exposed?
And for all the arguments about performance: I never see anyone complaining about un-optimized native apps even though we have all used them before. Remember splash screens? Random freezes? Running out of RAM because some random app in the background decided to malloc 80GB for some godforsaken reason? How is that a better experience than a web app running in a sandboxed tab you could easily kill whenever you want?
A web app almost by definition uses the network, so if I give it access to my camera or my file system then it’s very hard to know exactly if or where that data is sent.
This isn’t perfect for native either, the dialog to accept network usage is basically a blanket grant to connect anywhere or send anything.
No such luck with native apps. I don't almost never use wireshark to figure out what my native apps are doing.
Also. The entire argument falls apart when you factor in the ability to proxy data. E.g google.com -> bit-shady-site.com -> for-sure-shady-site.com
It's the Windows 95 security model:
Some things I trust, and I'm happy giving nigh-unlimited power, so I run them natively.
Other things I don't trust, and I want them in a sandbox where they can't mess things up. That sandbox is the browser, and having it be very secure is a high priority for me.
Poking more and more holes in the sandbox, together with a philosophical belief that the inside of the sandbox should be no more restrictive than the outside of the sandbox, is not compatible with that philosophy.
That model doesn't work too well for me, I'll give you an example. I want to be able to buy a fun USB gadget (like a fitness tracker) and not have to think about the security implications, but that is difficult right now. I have two choices, I can install the manufacturers sync software, giving it unlimited access to my computer or not use it at all. I trust the manufacturer to access the device they sold me...but I don't really want to give them access to my SSH keys, so my only option is to not use it.
The idea that WebUSB will allow me to visit gadgetvendor.com, grant access to one specific device, and not have to worry about any consequences is really appealing to me. They will have no access to my computer other than to the the device they sold me.
I think the concerns I've read mostly boil down to "what if a website tricks me into granting access to a device I shouldn't have?". It's certainly true we need security UX experts to make sure this is not confusing, but I don't really see how that is any different than a website tricking you into running an EXE.
Mobile platforms have invested in restricting apps by ability. There's no such way to exert this control over web apps with current browsers.
For instance, how to you stop a page from snooping your keystrokes? At best you can disable javascript entirely.
The browser really, really, really needs to adopt the sandbox model used by the rest of the operating system for this to make any sense, and right now the browser is more of a gaping hole in your wall than a sandbox.
> The user should be allowed to do what they want, right?
You'd need to do a hell of a lot of footwork to actually enable users to make decent decisions about random code found on the internet. I don't trust anyone technical I know to do this, much less people who don't understand what's going on.
Browsers already use a sandbox + permission model very similar to mobile. A webpage can't just silently obtain your location data, for example, it has to ask permission first. Any hypothetical hardware API will probably use the same permission flow.
Look at this site which looks at the fingerprintable bits of data that is available from a web browser: https://amiunique.org/fp
The web browser leaks a lot of specific information about the user. Which can then be combined with other information to uniquely track a user on the internet.
Why does the web browser need to make available the list of all fonts on a user's machine? Installing any combination of extra fonts makes you significantly more unique.
Same with GPU model.
The article talks about WebUSB. And how it was used to phish people's Yubikeys:
https://www.wired.com/story/chrome-yubikey-phishing-webusb/
The user isn't consenting to that.
In many cases I think the question is more "what functionality would the web browser need to break to prevent pages detecting X, and is that worth it?".
I remember doing this kind of detection years ago for an (entirely benign) chart authoring webapp; you don't want to offer a font for client-side rendering if the client doesn't have it. You can generally assume that the `monospace` and `serif` fallbacks are different, so if you have one layout box with text in `font-family:FontToDetect,monospace` and another with the same text but `font-family:FontToDetect,serif` and they both come out the same width, it's good odds that the user has that font. [EDIT: originally got that backwards due to brainfart]
Nowadays the existence of `@font-face` makes that particular problem mostly obsolete, but the same general principle applies all over.
AFAIK webUSB was always behind a consent dialog. That attack was based on getting consent, and the authors seems to say so at a talk about it (or a similar attack): https://www.youtube.com/watch?v=pUa6nWWTO4o
It's still very bad, but not nearly as bad as you say it is.
Sure, drive by ad tracking is easier with the web, but fingerprinting through desktop apps does exist.
Basically, why should I be forced to download a program that gets more access than a web app gets? Just so privacy advocates feel better about averting another privacy leak that can be prevented by browser permissions (like the webcam is)?
And as a developer, why should I be forced to learn Qt/GTK so I can do something like USB? And if I use Electron, I’m skewered by other developers for writing a bloated mess because I had no choice.
For me it's more about pricing and freedom. Server and computing costs force most web apps to be subscription-based and I'm extremely picky about subscriptions. First, there is often data lock in, of course, and it's often very deliberate with no viable export options. That's unacceptable to any reasonable person both on desktops and with web-based apps. Second, subscription-based applications are universally too expensive. If I turned all desktop software I currently use into equivalent subscriptions my monthly bill would be insanely high, an additional 200 to 500 euro per month. To most people including me that's just not affordable. It just doesn't add up. There is no market where people buy 20 different apps at $15/month each.
Almost everyone uses free desktop apps and a few paid ones.
This.
You're litterally using a personal computer with at least personal data on it, passwords in a password manager, passwords in your browsers, website account sessions (!) all on your drives and folders. Everything accessible by ALL programs you execute.
The more info Javascript has and therefore the server, the more attack vectors open up to just inject code into your browser and leverage code execution on host (recent CVE on firefox and Chrome !).
Or into your slack electron's chrome. Or any spyware app.
All your keystrokes accessible also !
Consider using a virtual machine or container to isolate the apps from your data so that they can't access it. If needed, mount a folder between host and guest for purpose-only sharing.
Or at least think about it or other measures.
For starters, native apps have too many permissions already.
Second, if you run a native app it should require explicit permission for internet access (perhaps at install time) so you have some idea if local data is going somewhere. Web apps are implicitly assumed to have internet access.
This should be fairly obvious, and the notion of granting more local access to arbitrary outsiders should be distressing. The fact that google and web sites feel entitled to everything on and about you computer says a lot about them. If they were humans with that lack of boundaries and sense that what's yours is theirs, we'd label then narcissists or psychopaths (not sure which).
Then all that goes out the window when the 100 MiB gorilla named /usr/bin/browser wants access to everything anyway, connects all that privileged information to other people's computers, and then implements its own entirely separate privilege access mechanisms in userspace to make that secure.
The native apps are also all trending to online first and cache offline.
I don't understand how a native app going behind your back and asking only for internet connection permission (and not hardware) is viewed as more secure. Why do we trust these native apps more?
Arbitrary psychopathic outsiders have already been here for quite a while. Even if you're running super paranoid homebrew linux distro.
The web needs to be secure against untrusted code, so it makes sense that there might be things you can do in a native application that you can't do in the browser.
> Why should I _have_ to use native apps if I don't want to?
It's not an affront on your freedoms to impose sensible restrictions on browsers' capabilities.
> As a web developer, why do I need to learn Qt or GTK or whatever to ship something useful to end users, when I already know HTML and JS and could easily deliver my product if the right native API was exposed?
If you want to use your web-dev skills to build native applications, there are various frameworks that let you do exactly that. You can call C/C++ functions from Electron. [0] Of course, you also have the option of learning and using C++ for your own GUI code, with frameworks like Qt.
> Remember splash screens? Random freezes? Running out of RAM because some random app in the background decided to malloc 80GB for some godforsaken reason? How is that a better experience than a web app running in a sandboxed tab you could easily kill whenever you want?
This is a straw-man. The people you are caricaturing are just people who want technically excellent software. This includes (but is not limited to) the efficient use of computational resources. No-one is pining for the instability of Windows 98.
The evidence overwhelmingly shows that given an exhortation to adhere to the principle of least authority, developers opt to pursue their apparent belief in their manifest destiny to control ever more resources on the user's machine and relying on that level of control even when it's not called for regarding the application at hand. It doesn't make sense to repeat the experiment by opening the floodgates in all the browsers and seeing if it'll turn out differently this time. It's also not as if there's a dearth of opportunities for developers to fulfil their desires elsewhere. The Web meanwhile is pretty much the only one doing what it is, and it's not like we can just roll things back when devs unsurprisingly do end up misbehaving in the way they are wont to.
> So why shouldn't I be allowed to use web apps that interact with bluetooth or USB devices? Why should your philosophical arguments on which software on what platform is allowed to do get in the way of my very real productivity and desire to use my computer the way I want to?
This doesn't accurately describe the circumstance we're in. There are no concrete barriers here hindering your productivity by total control over your own machine. Your user agent is just another native app, after all, which you have the freedom to select and run how you see fit. Use one that supports Bluetooth, Dat, or heck, one that gives you script access to directly write to your bootsector if you want. This is a power that has been exercised for years by everyone from end users to IT departments (cf continued use of Internet Explorer). The only real limit you have is in the scenario where you are a Web app author and you're hindered by other people's choice of browser, which is a very different situation from the "my computer" argument you're using. (If you want to cite iOS here, then it's Apple and the App Store model that you have the problem with; there are multiple levels of irony in this.)
But browsers won't remove that data exposure by default because advertising data and captcha systems. Torbrowser gets it right.
I think the solution is: if you can't add the functionality in a way that doesn't expose information about the user's system, don't add it.
You're not going to get browsers behind the idea of burning the ground they walk on. Many of the features that end up used for tracking are things people very much like having. Threading, webgl, webrtc, etc.
No doubt some sites will create barrages of opt in notifications - don't use these sites. Walmart, facebook, amazon, etc, are not going to make you complete opt in for everything to proceed. Even if they do - you know it exists and can spoof that data with your browser if you want.
> You're not going to get browsers behind the idea of burning the ground they walk on.
Maybe not Google, but Mozilla and Apple seem to consider privacy before they implement new potential holes into their browsers.
> Many of the features that end up used for tracking are things people very much like having. Threading, webgl, webrtc, etc.
The cat is already out of the bag with these already-implemented features. My point is that we 1) shouldn't make it worse, and 2) should work to replace these with better options. Users don't care whether their chat app uses webrtc or not -- they just want their application to work. The bad technologies we use don't have to be the way they are. Once upon a time the internet relied on ActiveX controls, Java Applets, and Flash, but we've all since moved past those bad technologies as well.
> No doubt some sites will create barrages of opt in notifications - don't use these sites.
Honestly, this is not a solution. We shouldn't ignore momentum, because when designing global standards, the problem is more than just about you or me, it's about the architecture and expectations that are being created. To use my ActiveX example above -- in some places, for a period of time, it was impossible to do online banking without using IE because every bank used ActiveX controls.
How do you replace webgl without identifying information on shader support and GPU model? You don't, that information is given by shader compilation itself.
These technologies are nowhere the same as activex, flash or java. All of those technologies were not built to be safe. They were built to give functionality browsers lacked. Now we have far safer methods of doing this thanks to better features.
Users want their stuff to work, for that to happen you have to have the features necessary for it. Those features are why you can listen to spotify or join voice calls on a browser instead of installing everyones native application which has access to everything.
If you don't want a browser capable of that then use a fork of torbrowser or similar. We will not change anything by trying to reverse the market without actual proof of harm. Instead we can advocate for opt ins to the information these features have given by default.
Who said we need to "replace P2P"? WebRTC's security issues are not predicated on it being a P2P technology.
> How do you replace webgl without identifying information on shader support and GPU model?
There are already ways to draw things in browsers that don't require this information to be leaked. The simple answer to your question is "abstraction".
> These technologies are nowhere the same as activex, flash or java. All of those technologies were not built to be safe. They were built to give functionality browsers lacked.
This statement will, one day be just as true about webRTC and webGL as it is today regarding ActiveX, Java, and Flash.
While I don't have a time machine, I do have full confidence that new technologies will be created that solve today's problems.
> Users want their stuff to work, for that to happen you have to have the features necessary for it.
Before Javascript and Canvas this is literally why ActiveX, Java, and Flash were used. But since we have those better alternatives now, we use them instead.
That's exactly what I want out of web apps - no install, secure, cross platform, immediately useful, and importantly - accessible to the providers.
The configuration page is Chrome only for now, which sucks, but hopefully Apple and Mozilla will come around.
There's a reason why security and features are in constant tension; it doesn't really work to just ignore security when it happens to be features that you want.
You'd better hope that your niche hardware isn't reprogrammable via USB to become an ethernet device that snoops all of your network traffic and injects attacks. It's pretty safe to assume that there is no such attack now. But if it ever happens at any point in the future, then either you'll get hacked, or your device will be blocked and the configuration app will stop working.
No idea if a simple web page using WebUSB would have worked better for me, the original manufacturer seems to have folded up over 10 years ago and their website no longer resolves.
It doesn't have to be that way. The crux of the web is HTTP, which exposes a pseudo-anonymous session-less client-server model. I am working on an application that inverts HTTP to a non-anonymous session-oriented server-client model exposing a GUI in the browser.
The goal isn't privacy, but exposing new capabilities that only make sense in a private environment. There are numerous things people are willing to do on their desktop that would be absurd to do over the web. For example: there is no reason cross-platform file transfer should be challenging. Simply expose a slice of the file system to the net on a computer you own to somebody you trust and they can get what ever files they need at their convenience and discretion, like copy/paste from one folder to another folder except those folders are on different computers. The way the web currently works this isn't practical. The closest thing is a shared storage space in the cloud, like DropBox.
Other potential capabilities include remote application access, remote hardware access, built-in media sharing (think non-proprietary video conferences/presentations), and synchronizing things between your various personal devices.
The site creators will argue, with some merit, that the crap is necessary to provide income in order for them to create and maintain the site.
You can make the browsers lighter, but they wouldn't browse today's Web. Which is fine; I'm all for getting away from the shitshow that is today's Web, but simply making browsers lighter weight would not be a winning Jenga move.
Some services even refuse to serve if one changes the UA, which is only one tracking capability. Though a blank or custom UA is worse, everyone should spoof the one in the onion browser.
User agent switch is currently "not available" on android Firefox.
Solve that problem and maybe.
Just an example. Right now if two websites want to use https://ajax.googleapis.com/ajax/libs/jquery/3.5.1/jquery.mi... they'll download it twice because of "privacy". That's nonsense and I'd turn off that misfeature if I could.
in contrast, the author presents Mozilla's view,
> “Because many USB devices are not designed to handle potentially-malicious interactions over the USB protocols and because those devices can have significant effects on the computer they’re connected to, we believe that the security risks of exposing USB devices to the Web are too broad to risk exposing users to them or to explain properly to end users to obtain meaningful informed consent.”
while i do not disagree with the risks, i for one think this clawing for absolute security, this idea that the web must only allow a narrow enough path that nothing ever goes wrong, is death. there is indeed great cause for Fear Uncertainty and Doubt (FUD)[3], but we have to do it anyways.
and frankly, most usb devices are pretty boring & isolated. yes you can hurt a usb flash drive if you do the wrong things to it, you can install an autorun.inf nasty malware. yes you can play gross sounds or listen on a usb sound card. but few devices are going to do anything to the system. mostly it's a bunch of mice & keyboards.
there's such amazing tension between those who want to secure & lock things down, & those who still have hope, who see the web as one of the few remaining ways to keep doors open, to leave something neutral & available & capable about for humanity to use, without endless gatekeeping rigamarole. nothing comes close to the web for being able to get your idea out there, the web is the epitome of online, and in spite of much danger & scariness, it seems obvious- my soul yearns to amplify & enhance & empower ourselves more with this amazing, unique, utterly special system.
[1] https://www.youtube.com/watch?v=IpfZ8Nj3uiE#t=20m
[2] https://github.com/noopkat/avrgirl
[3] https://en.wikipedia.org/wiki/Fear,_uncertainty,_and_doubt
With Thunderbolt/USB4, a USB device is not only a USB device; it's also a PCIe device. Upgrading its firmware (USB is commonly used for firmware update, but it could also be done through exploits on non-firmare-update endpoints) means the attacker now has control of not only a USB device, but also a PCIe device.
"The Web but without worrying quite as much about its security/privacy characteristics" is simply not the Web. Same as "the Web but without stressing so much about backwards compatibility". It would be a great thing, perhaps, but it's something different and would evolve very differently. (In particular, it would lack some of the core reasons why the Web has competed successfully with native apps.)
The aspect of this collective optimization process that seems particularly helpful and tractable to focus on is ensuring that users know the risks and benefits of their various options.
I'm more interested in seeing web platforms point users to excellent, impartial 3rd party analyses of their options and their associated risks/benefits, rather than stomp out innovation that some people clearly think is worth trying.
It is very convenient to have a standard API for accessing hardware over the internet. But marrying this API with browser will inevitably create security nightmare, as previous decades of web technologies taught us.
As a solution I would propose another API layer, between browsers and the host OS. When a browser requires access to a certain hardware capability it requests the access via this API from the OS. The OS is actually the one where this capability support is implemented and vetted, leaving browsers code much leaner than it is now.
I'm looking forward to the inevitable renaissance of the Open Web which respects the fact that the internet is for end-users[0]. I'm sure there's a million cool things a web page _could_ do but that doesn't mean that's what users want. The web needs more end-user participation, not more functionality. An end-user focused web would focus on security and simplicity over novelty. I'm not sure where this all went so terribly wrong but I'm convinced that it won't always be like this. Disruptive change is something our industry is very good at.
"Fear is the path to the dark side. Fear leads to anger. Anger leads to hate. Hate leads to suffering."
Yes, these capabilities bring will inevitably bring about some down-side, some negatives. But they are 100000% worth it. Endless cool things will spring from this that would be impossible any other way.
Give people power. Give people capabilities. Don't run, don't hide, don't put your head in the sand. Do it. Be brave. Enable better worlds to come.
On the surface it sounds like 'hmm sure why not' then you stop and think about it. It is a security/privacy nightmare waiting to happen. Much like ActiveX and java apps were. I suspect webassembly will end up in the same place.
Frankly it will be used by some small segment of web applications that are cool like you say. At best I fear the majority of the use would be just to fingerprint us more to show us more soap/shoes/drugs to buy. At worst it would end up being a never ending pit of security vulins. We have tried this sort of tech before it worked badly in the end. So a bit of caution is not unwarranted.Why are we asking this question? It should be up to the individual but it’s not - and hasn’t been for years. Virtue signaling.