Should the Web Expose Hardware Capabilities?(smashingmagazine.com)
smashingmagazine.com
Should the Web Expose Hardware Capabilities?
https://www.smashingmagazine.com/2021/01/web-expose-hardware-capabilities/
74 comments
The problem is that the web browser runs every URL that a user visits and whatever that page links to.
This means that it's a privacy risk.
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.
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.
> Why does the web browser need to make available the list of all fonts on a user's machine?
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.
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.
> The user isn't consenting to that.
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.
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.
People keep mentioning the fingerprinting thing, but why is the web special in that aspect? A desktop app has access to a lot more than what the browser exposes. At least with the browser, if they try to access a file, they can’t. Desktop apps on Windows have pretty much free reign on the file system (see ransomware).
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.
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.
[deleted]
> So how come this gets twisted on its head when it comes to web apps?
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.
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.
Right, there are effectively only two levels of trust for a typical user: None at all, and Unlimited. Do you really like that model?
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.
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.
> 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?
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.
[0] https://stackoverflow.com/a/39569062/
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.
[0] https://stackoverflow.com/a/39569062/
> I don't see why web apps should be handicapped
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.)
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.)
I think the danger lies mostly in apps that both access my data and hardware and the web. For local apps accessing hardware or data, I can often control whether it sends that data elsewhere.
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.
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.
Exactly. But for the savy it's easier to see from network tab in dev tools where your data is sent.
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
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
>> I don't see why web apps should be handicapped compared to their native versions.
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).
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).
Indeed, OSes already have privilege access mechanisms like GPO on Windows and SELinux / AppArmor / Flatpak on Linux to restrict installed binaries.
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.
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.
Yet we are as of right now where even our OS will go behind our back and act like malware to collect data even when we explicitly say no.
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 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.
[deleted]
I agree that it doesn't need to be about security. If web apps had to be installed on browsers similar to the way they are installed on the operating system, they would be acceptable. The current system that they run automatically when you visit a web page is obviously unacceptable, but that could be changed. The lack of standards and GUI features is also not that bad.
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.
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.
> I agree that it doesn't need to be about security
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.
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.
> If it was as easy to download, install, and run native apps, we would be having the same exact conversations in regards to security and portability.
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.
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.
I'm not sure what you mean, a webpage can't just randomly snoop on all your device's keystrokes if you don't have it open AFAIK. Do you have an example of this?
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.
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.
Browsers already expose way too much about hardware. We shouldn't be trying to shove privileged APIs into a web browser for the rest of the world to exploit -- at a very minimum we need abstraction layers that completely isolate web apps from the hardware they run on. We should make hardware work with a browser rather than making it work with the web.
They do, but you don't need exposure of information by default. All of those features should be explicit opt in when prompted, same as phone apps.
But browsers won't remove that data exposure by default because advertising data and captcha systems. Torbrowser gets it right.
But browsers won't remove that data exposure by default because advertising data and captcha systems. Torbrowser gets it right.
I don't think being opt-in is a solution to the problem. Most people will click anything if it lets them read the page they're trying to view, and nefarious actors will take advantage of this. We'll just end up with an internet that doesn't work unless you opt-in.
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.
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.
Yeah, opt-in is an attractive nuisance when deciding things like this. It's a good way to argue that something should be allowed because you did your due diligence and warned the user, but in practice it provides very poor security (for the reason you give). At the end of the day, no amount of purism and theory can ever outweigh the actual effects.
At that point don't have a computer. Don't have software. Native applications do significantly more hardware identification. It's not opt in and you're not told what's collected and for what purpose. People install applications all the time they don't know what they're doing.
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. 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.
That's a defeatist comparison. We treat native applications differently than web browsers because it is useful to assume a default level of trust when we browse the internet. This applies not only to users, but to institutions, OEMs, system integrators, etc.
> 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.
> 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.
"The bad technologies we use don't have to be the way they are"
They're not bad technologies, and you can't just 'replace them' and fix the problem. How do you replace P2P and not have IP exposure or a tech that's exactly the same by a different name? That's physically impossible.
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.
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.
> How do you replace P2P and not have IP exposure or a tech that's exactly the same by a different name? That's physically impossible.
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.
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.
One possibility might be to report to all sites that permission has been granted, but only actually grant permission once the user has specifically chosen to do so.
I was looking at some niche MIDI hardware recently and it had a link to a configuration app - which was just a web page on their site that used WebUSB.
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.
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.
Sure, the WebUSB feature set is nice. Care to address any of the points made in the article?
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.
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.
[deleted]
I was playing with some ancient hardware pretty recently that got configured via serial port. The configuration program was included on a cd-rom (one of those weird miniature ones). I had to find a USB-serial adapter as well as an external USB cd-rom drive in order to make it all work. I also had to install Windows XP into a virtual machine.
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.
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.
I read the article and the hesitation to expose various details through the web, what the article describes as the conservative approach, is absolutely valid. The biggest problem with exposing anything to the current web is complete exposure to anonymous strangers (loss of privacy) and all the security implications that come with that.
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.
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.
I wish browsers would aim to become lighter, not heavier. One already needs a ton of RAM, a fast CPU and a decent graphics card to render smoothly webpages that consist of basically just text and a few images. It’s ridiculous.
But they're not just text and a few images. They're text, a few images, and megabytes of advertising (and often tracking) JS.
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.
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.
Browsers should have an entropy budget of just a tiny number of bits. It’s not ok to know my screen resolution, it’s not ok to render fonts and read back the pixels. Exposing more hardware capabilities would be used a thousand times for fingerprinting for every time it’s used for a legitimate purpose (just like the canvas pixel readout).
You're so right it is messed up !
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.
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.
No discussion about this subject can be complete without mentioning ActiveX. It's the extreme endpoint of this path: a signed ActiveX control had full access not only to hardware capabilities, but also software capabilities. That much access is nowadays widely considered as having been a mistake.
No absolutely not, we don't need more ways for advertisers to destroy people's privacy.
Solve that problem and maybe.
Solve that problem and maybe.
I would trade my privacy for better functionality and/or performance any day.
Ok, but would you make that trade for not just yourself but everyone? Including those who are threatened by physical harm?
That should be an option for everyone to decide.
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.
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.
Very much in favor of standards like the one the article focuses on, WebUSB. Author links Suz Hinton's excellent talk, which goes through a bunch of projects & background & culminates with an Arduino programmer on the web[1]. Sue talks about this as a much friendlier interface than a lot of her other work, with the already excellent avrgrl programming project[2].
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
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
> 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.
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.
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.
And control of a PCIe device (with the usual lazy broken drivers that just ignore IOMMU) means full read and write access to all physical memory adresses, including OS kernel, firmware and NMI RAM areas and all applications. This gives an attacker the capability to compromise the hardware in very permanent ways. Nothing to take lightly or brush off as security absolutism.
The Web has certain properties that it relies on for its existence. This isn't "clawing for absolute security", it's recognition that if you push the Web just a little too far, it's dead. As in, it's not the Web anymore, will gradually become useless for many existing purposes, and will have to be replaced by something else borne out of its ashes.
"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 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.)
Regardless of where anyone thinks the maximas are in software trade-off space, developers are going to experiment shipping software at new points anyway, as markets at known points become saturated and exploration again becomes worthwhile in expectation.
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.
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.
No, the browser can use hardware to accelerate but the web should remain agnostic.
Web? Yes. Browser? No.
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.
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 was thinking about something similar the other day. At the moment, we have 2 webs. One is for websites, and the other one is for apps that happen to run in web. I when apps run in the browser mode (with address bar, tabs, etc.), they should run in sandbox mode, but once you "install" the app (similar to add to home screen on mobile), they should be treated like a native app.
I really like this idea, because it'd enable true per-site permissions for hardware access — currently one has to give the browser access to everything and trust its ability to restrict access as needed and keep sites cordoned off from each other. The browser itself would no longer need exceptional privileges (compared to other types of apps) in order to function as a platform.
When I was younger the "web" used to mean just the parts of the Internet accessed using a web browser.
We're already there with WebAssembly SIMD & WebGPU. I don't know how to interpret it any other way than "exposing hardware" to the browser interface. And I have ANR'd my own machine required hard reboot. What I think could become standard is a modal pop up warning. In the same manner that WebRTC media streams requires explicit permission to access a users web camera. Herein lies dragons, abandon all hope and enter at your peril.
The mad arms race for browser functionality smells a lot like an Embrace and Extend strategy by the big players. If browsers implementations are impossibly complex for anyone other than large companies to implement then the concept of "open standards" doesn't mean what it used to.
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.
[0] - https://tools.ietf.org/html/rfc8890
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.
[0] - https://tools.ietf.org/html/rfc8890
Are you seriously implying that browser functionalities are currently simple enough for entities smaller than "large companies" to implement?
No. The opposite. I'm trying to say that open standards aren't really open if they can't be broadly implemented.
So in order for you to consider a standard "open" it has to be simple? We aren't allowed to have open standards above a certain level of complexity?
Breadth of current standards is more of an issue, I would argue. As the number of browser standards has increased, the number of browser engines (and platforms capable of running those browser engines) has decreased, and the computing power needed for web browsing has increased.
Are you sure your view aligns with the rest of users? I know many people who are happy that the browser has became a very capable app platform - both end users and app vendors. Now the end users are asking for more functionality - I see it daily in my line of work - and that needs new browser features.
With the tiny percentage of Firefox market share, and iDevices worldwide market share, the Web is effectively a synonym for ChromeOS, regardless of how Apple and Mozilla might think about it.
Normally I think rules like Betteridge's Law of Headlines are lazy, but it is strong with this one.
No way. Most of the web is to some extent hostile. Already it wants to know too much about you. Usually, though, it can't do that much to you.
No.
No.
Just No
Without clicking: no
I sense great fear within you.
"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.
"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.I don’t want the web doing cool things. I want the web to be fast, boring, and private. Leave the cool things to native apps.
It sucks, this tension of people that insist the web be the one thing they want, that anyone wanting anything else be unable to get it. I don't know how to deal with conservatives. Never have.
So basically the question is: should corporations keep betraying users by giving away their hardware specs?
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.
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.
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?