11 ms·

In protest of the web{*} bulldozer, a response to websocket port scanning

144 points by bjt2n3904 6y ago

kbenson 6y ago
> Firstly, WebSockets seem to be prohibited from accessing 192.168.0.0/16 and 10.0.0.0/8. In Firefox, it raises SecurityError. And 172.16.0.0/12 I hope. I did a little Googling and didn't quickly find a list of sources they are blocking in Firefox (or is it part of the standard?), but I hope that one is included. It's not as common, but it's still a private network and used sometimes.
- pdonis 6y ago
  > And 172.16.0.0/12 I hope Yes, at least on my Firefox (76.0.1 on Ubuntu). However, Chrome will happily open a websocket to addresses in the 192.168., 10., and 172.16. ranges. It fails for 127.0.0.1, but only because it says there's nobody listening (not, as Firefox does, because of a security error accessing that IP in the first place); for localhost it can actually verify that no service is running on that port, whereas for remote hosts in the private ranges it can't.
  - tzs 6y ago
    I don't understand the point of blocking all of 192.168/16, 172.16/12, and 10/8. If the point is to block access to other hosts on your LAN shouldn't it just block the one your LAN actually uses?
    - pferde 6y ago
      What if the my network uses several different local subnets? How would the browser figure that out? No, blocking all these IP ranges is a good idea. After all, these ranges are supposed to not be directly routeable to from the Internet.
      - tzs 6y ago
        > What if the my network uses several different local subnets? How would the browser figure that out? It would look at your computer's routing table. If it is an IP address your computer talks to directly, it is on a LAN your computer is on and would be blocked. If it is an IP address that your computer talks to through a gateway, it is on the internet and would not be blocked. > After all, these ranges are supposed to not be directly routeable to from the Internet. They are supposed to not be directly routeable to/from the public internet. They can be directly routable between non-public parts of the internet. A not uncommon example, especially now, is having a VPN connection between a home network and the internal network of a business, both of which are using addresses in the private ranges.
        pdonis 6y ago
        > If it is an IP address that your computer talks to through a gateway, it is on the internet and would not be blocked. No, this would just make the security problem worse, because now any website could use websockets to scan, not just your personal LAN, but any network you are connected to through a VPN or any other gateway.
        pferde 6y ago
        > They are supposed to not be directly routeable to/from the public internet. They can be directly routable between non-public parts of the internet. Sure, but this is different from a VPN. This would be untrusted code downloaded from a remote website talking to unrelated devices on my local network. Effectively, it would be the remote website having free reign inside my local network, with my web browser acting as a proxy (or as a trojan horse, with a bit of exaggeration).
    - magicalhippo 6y ago
      I use both 192.168/16 and 10/8 on my computer. One is for my regular LAN and the other is for my 10G link to my NAS.
    - pdonis 6y ago
      I don't understand the point of not blocking all of those ranges. Why should the browser bother trying to figure out which ones are actually used on a particular LAN? All of those IP ranges are designated as private, and that in itself should be reason enough for browsers to block websocket connections to them.
- moonbug 6y ago
  Gee, good job no one uses IPv6.
  - gerdesj 6y ago
    Shhh the kids are thinking. They'll work it out eventually. My IPX/SPX and pigeon borne packet transfers are all good. I'm using a dual IPv4/6 stack laptop at home with a dual stack IPv4/6 OpenVPN to the office at the moment, with my default gateways forced down the VPN. Silly me, click (disconnect) Oh, no real change in experience.
  - icedchai 6y ago
    Consider a /64 subnet will take a while, if not forever, to scan.
    - Dylan16807 6y ago
      Unless you know part of the mac address. Or it's bound to :0:0:0:1. And maybe you already know the IP and the firewall is blocking connections from outside the building.
swiley 6y ago
I remember being a little surprised websockets could violate the same origin policy. It was only a matter of time before that was going to be abused. It’s a shame because it meant you could run your own server for eg js/html games.
- deleted 6y ago
  [deleted]
- TazeTSchnitzel 6y ago
  > I remember being a little surprised websockets could violate the same origin policy. It was only a matter of time before that was going to be abused. WebSockets don't have the Same Origin Policy like XMLHttpRequest does, yes, but they are required to tell the server they connect to what origin they came from, so the server can enforce whatever restrictions it likes. WebSockets were also designed with preventing abuse in mind: note the protocol obfuscation and weird headers, which I think are there so you can't confuse non-WebSocket-aware servers and non-HTTP protocols. However, as with XMLHttpRequest and other ways to do an HTTP request, it's not possible for the browser to know if a destination server speaks HTTP without trying to connect to it, and I guess that's why port scanning is possible.
saagarjha 6y ago
All the new web standards are a bit tiresome, to be honest, and some of them have the flimsiest justification. I remember someone pushing the Ambient Light Sensor API on Twitter at some point and the example they gave was "you can offer dark mode to your users if the brightness you detect is low". Like, really? There are actual browser APIs for this, and they offer a better signal of user intent than brightness levels could ever do. Can you please just think these through?
- hoten 6y ago
  Extrapolating the reasons behind a particular standard being created from a random Tweet is a bit disingenuous. Here are the examples that the standard proposal cites: https://w3c.github.io/ambient-light/#usecases-requirements https://w3c.github.io/ambient-light/#usecases-requirements The camera one especially seems convincing to me.
  - gruez 6y ago
    None of the examples they've listed sound convincing. >A Web application provides input for a smart home system to control lighting. Why would you need ambient light level to control lighting? Do you need a phone to calibrate the room's brightness or something? >A Web aplication checks whether light level at work space is sufficient. Can't think of a reason why an app would need to do this >A Web application calculates settings for a camera with manual controls (apperture, shutter speed, ISO). Seems contrived to me. It might make sense for an analog camera, but every digital camera has a lightmeter, which is what you'd want anyways rather than the light sensor on your phone with unknown accuracy and viewing angle. >A Web application monitors light level changes produced by hovering hand user gesture and interprets them to control a game character. Wouldn't that be better served by using the front facing camera? You can even implement different hand gestures that way.
  - Rantenki 6y ago
    They left some out: - Monitor room light level for fluctuations that correspond to advertising broadcasts for advertising proximity fingerprinting, or location fingerprinting, ie: the illuminance profile for a video broadcast is moderately unique, and can identify the fact that it's playing on a screen near the user - Side channel for data exfiltration attacks (we require permission to use the microphone for more reasons than just listening for people talking) - Monitoring for in/out of pocket/purse state for the phone - Probably a ton of other nefarious stuff that I am not devious enough to think of.
_bxg1 6y ago
The web already has a user-facing permissions system; it wouldn't be hard to add many of these under that umbrella (USB, Bluetooth, and Sensors stand out as obvious candidates that should've been behind that barrier from the beginning). Battery Status definitely seems pointless overall. But I don't agree with the overall thesis, that the web fundamentally should not get features like these. Though, obviously, some of these "standards" have been rushed through and poorly executed. I think for this we can blame Chromium's dominance. As the author said, many of these features were probably motivated by Chrome OS. And the devil's bargain of letting Chromium take such complete control over the web is that Google can strongarm whichever new "standards" they like into the Web. The standards committee doesn't want WebBatteryStatus? Fine, we'll implement it anyway and now Chrome desktop/mobile, Chromebooks, and Edge will all have it. Sites that want to use it will probably just use it and throw up a "Use Chrome" notification for Firefox and Safari.
- chipperyman573 6y ago
  I own a business and recently had to change all the pictures on my website from webp to png because safari both refuses to render webp and pretends to accept them. I hate it so much and see very real costs in increased bandwith (every image is around 3-4x bigger) but I have no choice because I want people with iphones to be able to buy things from me. Safari is honestly just as bad as chrome but for different reasons (ios safari was arguably the single biggest cause of the death of flash, for example). I also had to go through and fix a few other pseudo css classes that only safari didn't support which was really annoying, what a waste of time. I don't think many people would consider "Don't use safari" banners a valid option unless the website was somehow really focused on non-apple users or not trying to sell something.
  - _bxg1 6y ago
    I use Roll20, a popular web app for playing tabletop games with others over the internet. It doesn't work in Firefox or Safari; it's the only reason I keep Chromium on my machine.
    - 6y ago
mindslight 6y ago
The problem is that these APIs have been developed with little concern paid to security. Compounding this, Mozilla hasn't even tweaked the implementation details to retain what security they could. This is seemingly due to a mistaken idea that sandbox escape is the only security property that matters, allowing these APIs to leak identifying information like sieves. For example, AFAICT the common wisdom for mitigating Location with user.js is to set it to Ask for every site instead of a blanket Deny, because the latter actually turns out to be more fingerprintable. Whereas Deny should be indistinguishable from Ask with a negative response.
qeternity 6y ago
I’m a bit surprised that anyone with a remotely techie background has been unaware of websockets until now.
- qorrect 6y ago
  Yeah his intro turned me off immediately. Why would I want to read this guys uninformed opinion ?
- bjt2n3904 6y ago
  I generally do embedded and radio things. :) I'm not gonna lie, I can't follow web stuff with the speed at which it changes.
josteink 6y ago
> Each brings the browser closer and closer to my desktop, and seems solely driven by ChromeBook developers. Yes. So let’s reject them all. Let sane desktop browsers tell the web that these APIs don’t exist in a meaningful way, and that building applications that rely on them is a waste of time. Mozilla, Microsoft and Apple? Pretty please?
TazeTSchnitzel 6y ago
> Web{Assembly}: Enables binary executables to run in your browser “Binary executables” makes it sound like it's machine code, but WebAssembly is more like a bytecode for JavaScript.
- TeMPOraL 6y ago
  I'm of two minds about it. On the one hand, JS should've been compiled in the first place; that we spent some two decades making computers parse increasingly complex scripts repeatedly is a sad waste, and it spawned what's probably the biggest hack ever to become a standard practice: minifying code. On the other hand, WebASM webapps will be an order of magnitude less inspectable.
  - TazeTSchnitzel 6y ago
    Why will WebAssembly applications be less inspectable? JS applications are already aggressively minified multi-megabyte blobs.
    - TeMPOraL 6y ago
      I can take a look at a minified piece of JS after reformatting, and quickly guess what many of the functions do just by their shape. I won't be able to do that anywhere as easily with a piece of decompiled bytecode, especially if it went through an optimization pass.
      - derefr 6y ago
        The re-prettification of the minified code doesn't have identifiers, except for the calls to the browser runtime. Unless you use a source map, in which case it does. The decompiled WASM doesn't have identifiers, except for the calls to the browser runtime. Unless you use a source map, in which case it does. Not really seeing the difference. Minified/"uglified" JS—and especially obfuscated JS (where "minification" and "obfuscation" are frequently aligned interests, so most libraries incidentally do both)—is already "a bytecode for the browser virtual machine", just a highly-redundant encoding of one.
bijection 6y ago
> Unlike the rest of the technologies, [Websockets] seems to have somewhat of a purpose — even if it’s been made redundant by things like HTTP/2 streams. ... Give it a few months, and there will be some NodeJS fad where everyone wants to re-implement HTTP with WebSockets, and load every asset for their website through JavaScript to save a tenth of a microsecond in some edge case involving tech buzzword bingo. ... Once this happens, disabling WebSockets breaks the internet. To be fair to Websockets, they've been around for almost a decade, pre-dating http/2 by a few years, and the duplex communication they offer is a fundamental building block for all kinds of stuff, from games to trading websites to chat systems. Although the Battery API is a different story, the author's point about Websockets seems to be based on somehow having overlooked them for quite a while.
- TazeTSchnitzel 6y ago
  Yes, and WebSockets are a clean and fast replacement for horrible hacks that preceded them. Nobody liked having to constantly poll the server one way or another, or god forbid, use Flash.
  - Thorrez 6y ago
    One alternative to repeated polling or Flash is hanging GETs. But yes, that's a pretty weird hack.
    - cygx 6y ago
      That's called 'long polling'. You can also leverage HTTP 1.1 chunked transfers. Cf https://en.wikipedia.org/wiki/Comet_(programming) https://en.wikipedia.org/wiki/Comet_(programming)
    - arantius 6y ago
      That's unidirectional. Websockets allow fully stateful bidirectional data transfer (just like a regular socket). They're wonderful when that's what you need.
      - 6y ago
vbezhenar 6y ago
One website can use resources from other website using img, script, link tags. That was since WWW invented. User agent will retrieve related resources from other websites. Those port scanners abuse that feature. <img href="https://website-resolving-to-127-0-0-1.com:1234"> https://website-resolving-to-127-0-0-1.com:1234"> is a legitimate code and browser is expect to establish TLS connection to 127.0.0.1:1234. Trying to patch that fundamental behaviour is hard. Websockets are not enemy here. They are just convenient tool. It could be implemented without websockets. Imagine that google.com added <img src=yourpoorwebsite.com> into their main page. Now you've got billions of requests and your website is DDoSed. Who's bad here? Browser which allows requests from google.com to yourpoorwebsite.com? Or Google who decided to kill your website?
- cygx 6y ago
  Trying to patch that fundamental behaviour is hard. There's prior art for this, though: https://web.archive.org/web/20121001002815/http://my.opera.com/securitygroup/blog/2012/07/03/operas-cross-network-protection https://web.archive.org/web/20121001002815/http://my.opera.c...
- EE84M3i 6y ago
  "One website can use resources from other website using img, script, link tags." Interestingly, you can't do this for web fonts, because they require CORS, which was only added to make type foundries happier by making hotlinking fonts not possible.
  - deleted 6y ago
    [deleted]
- cookiengineer 6y ago
  This reminds me of the DDoS service that was using adverts on various ad networks to abuse firefox’s ftp:// url support in exactly the same manner, because ftp protocol didn’t have any limitations, so there were 65k connections spawned simultaneously per client/bot.
banachtarski 6y ago
So much misinformation and FUD in this article. It's immediately suspect that the author had to lookup what websockets even WERE. No mention of the permissions system? This is a super low-quality article to make it to the front page.
- tasteTheAnus 6y ago
  Okay, but you're the one that's wrong. The truth is, we lost control of our own devices that are supposed to work for us, and instead they're used against us. I can't take the battery out of my phone, and it's design is such that it won't work directly from a power cord plugged into a wall socket. This incentivizes the user toward keeping the battery charged at all times, and thus maintaining a device state, such that one can never truly know if the radio, camera and microphone are engaged or not. And whose fault is that? It's a dark pattern, and device manufacturers know it. So too with all of the web* technology that the author highlights. The party line is "You asked for it, you do it to yourself, and you really DO like it, but you just don't know it yet, sam-i-am. Just try the green eggs and ham, friend. It's blisssssssss..." It's not wrong to take exception to this prevailing dismal wind.
- kccqzy 6y ago
  Yeah. Not to mention that WebSockets designers gave considerable thought to its security. Things like adding a mask to client messages look like puzzling inefficiencies, but are actually well designed security measures.
- usr1106 6y ago
  Right, and he didn't try out all sockets to find out what is the blacklist. Did he notice that Firefox is open source and reading the source might give good hints? (On my phone now and not starting to do it myself. But I have run Firefox under gdb before to check how Google Streetview uses WebGL. It's not difficult under Linux at least, even if you like myself know absolutely nothing about the somewhat intimidating code base of Firefox.)
nana- 6y ago
Actually Microsofts work on https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rdperp/ead02bce-64ef-41d6-aa06-8565956b9fe7 https://docs.microsoft.com/en-us/openspecs/windows_protocols...
ximm 6y ago
I am starting to wonder whether we should split the web into "document mode" with only small subset of javascript APIs and "application mode". This could actually spark some innovation because the threshold to build a document-web-browser from scratch would be so much lower and it could have much better security.
- lecarore 6y ago
  I browse the web with js off by default, and turn it on per domain in 2 clicks. That's basically what you are proposing accessible today, with Firefox, on desktop and on Android
  - throwaway_pdp09 6y ago
    Aside: I turn off JS and never allow it on outside a VM (which gets wiped back to a clean state on shutdown). It's definitely not the same thing because a lot of documents simply do not render (here's one I was looking at not 2 minutes ago, at least it has text, but no pics https://vanschneider.com/the-kawaiization-of-product-design https://vanschneider.com/the-kawaiization-of-product-design A Number of sites will render absolutely nothing at all, text or otherwise eg https://www.washingtonpost.com https://www.washingtonpost.com). Nope, he's got a good suggestion IMO.
- throwaway_pdp09 6y ago
  Oh hell yes, I'm all for this. Though with the proviso of NO javasccript for document mode at all. I think this is a great idea.
- eitland 6y ago
  Daniel Janus had written about it here: http://blog.danieljanus.pl/2019/10/07/web-of-documents/ http://blog.danieljanus.pl/2019/10/07/web-of-documents/ I am fairly certain I have written about it as well, here or on my blog somewhere. My ideas are a bit more pragmatic maybe: I hope Mozilla or someone else will make a html version of asm.js - an extremely performant renderer for a subset of html and css. This could solve the bootstrapping dilemma since it would work in every other browser as well - only hopefully even faster in browsers that supports it - and make real headway in as little as a few years while working from day 1. My suggestions: - a meta field in the header indicating html document - a free validation service - if a document signals it is a modern document, send it down the fast path - if the document doesn't follow the rules, restart with ordinary rules - js is forbidden except for a number of vetted common libraries for things like autocomplete
fxtentacle 6y ago
I fully agree. When I open a newspaper website, I want to receive a tiny bit of HTML and CSS and maybe references to some images. Like 50KB+images. Instead, I am bombarded with megabytes of JavaScript and these new APIs so that advertisers can better spy on me. All of that comes at the expense of my bandwidth, my CPU usage and battery power, and my privacy. Soon, we'll need a service that remotely opens those websites for you, then dumps the DOM and only forwards that to you. So basically server-side rendering for other people's delinquent websites.
IshKebab 6y ago
Good list of Web* technologies but he is wrong about them being all on-by-default security risks and wrong about them being useless gimmicks: * WebSockets: On by default but obviously useful and not that different to normal HTTP requests. Can you port scan with XMLHttpRequest? I wouldn't be surprised. * WebBluetooth: Has a permission dialog. This is actually really useful for things like the physical web - you can control nearby one-off devices without needing to install an app or for either device to have internet access. Great for interactive art installations for example. * WebRTC: Enabled by default but very useful for web based games because it allows UDP-like communication. Also obviously useful for video conferencing. * WebAssembly: This doesn't let you do anything that Javascript didn't so he's just being paranoid that it "enables binary executables to run in your browser". * WebGL: This one he has a point on - GPU drivers are full of bugs and weren't designed to run untrusted software. I'm surprised there aren't more exploits of this. * WebUSB: Again, useful for using USB devices without having to install an app. This also has a permission dialog. Most of these are because the web is now an app platform, not just a document store.

144 points by bjt2n3904 6y ago

> Firstly, WebSockets seem to be prohibited from accessing 192.168.0.0/16 and 10.0.0.0/8. In Firefox, it raises SecurityError. And 172.16.0.0/12 I hope. I did a little Googling and didn't quickly find a list of sources they are blocking in Firefox (or is it part of the standard?), but I hope that one is included. It's not as common, but it's still a private network and used sometimes.

pdonis 6y ago
> And 172.16.0.0/12 I hope Yes, at least on my Firefox (76.0.1 on Ubuntu). However, Chrome will happily open a websocket to addresses in the 192.168., 10., and 172.16. ranges. It fails for 127.0.0.1, but only because it says there's nobody listening (not, as Firefox does, because of a security error accessing that IP in the first place); for localhost it can actually verify that no service is running on that port, whereas for remote hosts in the private ranges it can't.
- tzs 6y ago
  I don't understand the point of blocking all of 192.168/16, 172.16/12, and 10/8. If the point is to block access to other hosts on your LAN shouldn't it just block the one your LAN actually uses?
  - pferde 6y ago
    What if the my network uses several different local subnets? How would the browser figure that out? No, blocking all these IP ranges is a good idea. After all, these ranges are supposed to not be directly routeable to from the Internet.
    - tzs 6y ago
      > What if the my network uses several different local subnets? How would the browser figure that out? It would look at your computer's routing table. If it is an IP address your computer talks to directly, it is on a LAN your computer is on and would be blocked. If it is an IP address that your computer talks to through a gateway, it is on the internet and would not be blocked. > After all, these ranges are supposed to not be directly routeable to from the Internet. They are supposed to not be directly routeable to/from the public internet. They can be directly routable between non-public parts of the internet. A not uncommon example, especially now, is having a VPN connection between a home network and the internal network of a business, both of which are using addresses in the private ranges.
      - pdonis 6y ago
        > If it is an IP address that your computer talks to through a gateway, it is on the internet and would not be blocked. No, this would just make the security problem worse, because now any website could use websockets to scan, not just your personal LAN, but any network you are connected to through a VPN or any other gateway.
      - pferde 6y ago
        > They are supposed to not be directly routeable to/from the public internet. They can be directly routable between non-public parts of the internet. Sure, but this is different from a VPN. This would be untrusted code downloaded from a remote website talking to unrelated devices on my local network. Effectively, it would be the remote website having free reign inside my local network, with my web browser acting as a proxy (or as a trojan horse, with a bit of exaggeration).
  - magicalhippo 6y ago
    I use both 192.168/16 and 10/8 on my computer. One is for my regular LAN and the other is for my 10G link to my NAS.
  - pdonis 6y ago
    I don't understand the point of not blocking all of those ranges. Why should the browser bother trying to figure out which ones are actually used on a particular LAN? All of those IP ranges are designated as private, and that in itself should be reason enough for browsers to block websocket connections to them.
moonbug 6y ago
Gee, good job no one uses IPv6.
- gerdesj 6y ago
  Shhh the kids are thinking. They'll work it out eventually. My IPX/SPX and pigeon borne packet transfers are all good. I'm using a dual IPv4/6 stack laptop at home with a dual stack IPv4/6 OpenVPN to the office at the moment, with my default gateways forced down the VPN. Silly me, click (disconnect) Oh, no real change in experience.
- icedchai 6y ago
  Consider a /64 subnet will take a while, if not forever, to scan.
  - Dylan16807 6y ago
    Unless you know part of the mac address. Or it's bound to :0:0:0:1. And maybe you already know the IP and the firewall is blocking connections from outside the building.

swiley 6y ago

I remember being a little surprised websockets could violate the same origin policy. It was only a matter of time before that was going to be abused. It’s a shame because it meant you could run your own server for eg js/html games.

deleted 6y ago
[deleted]
TazeTSchnitzel 6y ago
> I remember being a little surprised websockets could violate the same origin policy. It was only a matter of time before that was going to be abused. WebSockets don't have the Same Origin Policy like XMLHttpRequest does, yes, but they are required to tell the server they connect to what origin they came from, so the server can enforce whatever restrictions it likes. WebSockets were also designed with preventing abuse in mind: note the protocol obfuscation and weird headers, which I think are there so you can't confuse non-WebSocket-aware servers and non-HTTP protocols. However, as with XMLHttpRequest and other ways to do an HTTP request, it's not possible for the browser to know if a destination server speaks HTTP without trying to connect to it, and I guess that's why port scanning is possible.

saagarjha 6y ago

All the new web standards are a bit tiresome, to be honest, and some of them have the flimsiest justification. I remember someone pushing the Ambient Light Sensor API on Twitter at some point and the example they gave was "you can offer dark mode to your users if the brightness you detect is low". Like, really? There are actual browser APIs for this, and they offer a better signal of user intent than brightness levels could ever do. Can you please just think these through?

hoten 6y ago
Extrapolating the reasons behind a particular standard being created from a random Tweet is a bit disingenuous. Here are the examples that the standard proposal cites: https://w3c.github.io/ambient-light/#usecases-requirements https://w3c.github.io/ambient-light/#usecases-requirements The camera one especially seems convincing to me.
- gruez 6y ago
  None of the examples they've listed sound convincing. >A Web application provides input for a smart home system to control lighting. Why would you need ambient light level to control lighting? Do you need a phone to calibrate the room's brightness or something? >A Web aplication checks whether light level at work space is sufficient. Can't think of a reason why an app would need to do this >A Web application calculates settings for a camera with manual controls (apperture, shutter speed, ISO). Seems contrived to me. It might make sense for an analog camera, but every digital camera has a lightmeter, which is what you'd want anyways rather than the light sensor on your phone with unknown accuracy and viewing angle. >A Web application monitors light level changes produced by hovering hand user gesture and interprets them to control a game character. Wouldn't that be better served by using the front facing camera? You can even implement different hand gestures that way.
- Rantenki 6y ago
  They left some out: - Monitor room light level for fluctuations that correspond to advertising broadcasts for advertising proximity fingerprinting, or location fingerprinting, ie: the illuminance profile for a video broadcast is moderately unique, and can identify the fact that it's playing on a screen near the user - Side channel for data exfiltration attacks (we require permission to use the microphone for more reasons than just listening for people talking) - Monitoring for in/out of pocket/purse state for the phone - Probably a ton of other nefarious stuff that I am not devious enough to think of.

_bxg1 6y ago

The web already has a user-facing permissions system; it wouldn't be hard to add many of these under that umbrella (USB, Bluetooth, and Sensors stand out as obvious candidates that should've been behind that barrier from the beginning). Battery Status definitely seems pointless overall. But I don't agree with the overall thesis, that the web fundamentally should not get features like these. Though, obviously, some of these "standards" have been rushed through and poorly executed. I think for this we can blame Chromium's dominance. As the author said, many of these features were probably motivated by Chrome OS. And the devil's bargain of letting Chromium take such complete control over the web is that Google can strongarm whichever new "standards" they like into the Web. The standards committee doesn't want WebBatteryStatus? Fine, we'll implement it anyway and now Chrome desktop/mobile, Chromebooks, and Edge will all have it. Sites that want to use it will probably just use it and throw up a "Use Chrome" notification for Firefox and Safari.

chipperyman573 6y ago
I own a business and recently had to change all the pictures on my website from webp to png because safari both refuses to render webp and pretends to accept them. I hate it so much and see very real costs in increased bandwith (every image is around 3-4x bigger) but I have no choice because I want people with iphones to be able to buy things from me. Safari is honestly just as bad as chrome but for different reasons (ios safari was arguably the single biggest cause of the death of flash, for example). I also had to go through and fix a few other pseudo css classes that only safari didn't support which was really annoying, what a waste of time. I don't think many people would consider "Don't use safari" banners a valid option unless the website was somehow really focused on non-apple users or not trying to sell something.
- _bxg1 6y ago
  I use Roll20, a popular web app for playing tabletop games with others over the internet. It doesn't work in Firefox or Safari; it's the only reason I keep Chromium on my machine.
  - 6y ago

mindslight 6y ago

The problem is that these APIs have been developed with little concern paid to security. Compounding this, Mozilla hasn't even tweaked the implementation details to retain what security they could. This is seemingly due to a mistaken idea that sandbox escape is the only security property that matters, allowing these APIs to leak identifying information like sieves. For example, AFAICT the common wisdom for mitigating Location with user.js is to set it to Ask for every site instead of a blanket Deny, because the latter actually turns out to be more fingerprintable. Whereas Deny should be indistinguishable from Ask with a negative response.

qeternity 6y ago

I’m a bit surprised that anyone with a remotely techie background has been unaware of websockets until now.

qorrect 6y ago
Yeah his intro turned me off immediately. Why would I want to read this guys uninformed opinion ?
bjt2n3904 6y ago
I generally do embedded and radio things. :) I'm not gonna lie, I can't follow web stuff with the speed at which it changes.

josteink 6y ago

> Each brings the browser closer and closer to my desktop, and seems solely driven by ChromeBook developers. Yes. So let’s reject them all. Let sane desktop browsers tell the web that these APIs don’t exist in a meaningful way, and that building applications that rely on them is a waste of time. Mozilla, Microsoft and Apple? Pretty please?

TazeTSchnitzel 6y ago

> Web{Assembly}: Enables binary executables to run in your browser “Binary executables” makes it sound like it's machine code, but WebAssembly is more like a bytecode for JavaScript.

TeMPOraL 6y ago
I'm of two minds about it. On the one hand, JS should've been compiled in the first place; that we spent some two decades making computers parse increasingly complex scripts repeatedly is a sad waste, and it spawned what's probably the biggest hack ever to become a standard practice: minifying code. On the other hand, WebASM webapps will be an order of magnitude less inspectable.
- TazeTSchnitzel 6y ago
  Why will WebAssembly applications be less inspectable? JS applications are already aggressively minified multi-megabyte blobs.
  - TeMPOraL 6y ago
    I can take a look at a minified piece of JS after reformatting, and quickly guess what many of the functions do just by their shape. I won't be able to do that anywhere as easily with a piece of decompiled bytecode, especially if it went through an optimization pass.
    - derefr 6y ago
      The re-prettification of the minified code doesn't have identifiers, except for the calls to the browser runtime. Unless you use a source map, in which case it does. The decompiled WASM doesn't have identifiers, except for the calls to the browser runtime. Unless you use a source map, in which case it does. Not really seeing the difference. Minified/"uglified" JS—and especially obfuscated JS (where "minification" and "obfuscation" are frequently aligned interests, so most libraries incidentally do both)—is already "a bytecode for the browser virtual machine", just a highly-redundant encoding of one.

bijection 6y ago

> Unlike the rest of the technologies, [Websockets] seems to have somewhat of a purpose — even if it’s been made redundant by things like HTTP/2 streams. ... Give it a few months, and there will be some NodeJS fad where everyone wants to re-implement HTTP with WebSockets, and load every asset for their website through JavaScript to save a tenth of a microsecond in some edge case involving tech buzzword bingo. ... Once this happens, disabling WebSockets breaks the internet. To be fair to Websockets, they've been around for almost a decade, pre-dating http/2 by a few years, and the duplex communication they offer is a fundamental building block for all kinds of stuff, from games to trading websites to chat systems. Although the Battery API is a different story, the author's point about Websockets seems to be based on somehow having overlooked them for quite a while.

TazeTSchnitzel 6y ago
Yes, and WebSockets are a clean and fast replacement for horrible hacks that preceded them. Nobody liked having to constantly poll the server one way or another, or god forbid, use Flash.
- Thorrez 6y ago
  One alternative to repeated polling or Flash is hanging GETs. But yes, that's a pretty weird hack.
  - cygx 6y ago
    That's called 'long polling'. You can also leverage HTTP 1.1 chunked transfers. Cf https://en.wikipedia.org/wiki/Comet_(programming) https://en.wikipedia.org/wiki/Comet_(programming)
  - arantius 6y ago
    That's unidirectional. Websockets allow fully stateful bidirectional data transfer (just like a regular socket). They're wonderful when that's what you need.
    - 6y ago

vbezhenar 6y ago

One website can use resources from other website using img, script, link tags. That was since WWW invented. User agent will retrieve related resources from other websites. Those port scanners abuse that feature. <img href="https://website-resolving-to-127-0-0-1.com:1234"> https://website-resolving-to-127-0-0-1.com:1234"> is a legitimate code and browser is expect to establish TLS connection to 127.0.0.1:1234. Trying to patch that fundamental behaviour is hard. Websockets are not enemy here. They are just convenient tool. It could be implemented without websockets. Imagine that google.com added <img src=yourpoorwebsite.com> into their main page. Now you've got billions of requests and your website is DDoSed. Who's bad here? Browser which allows requests from google.com to yourpoorwebsite.com? Or Google who decided to kill your website?

cygx 6y ago
Trying to patch that fundamental behaviour is hard. There's prior art for this, though: https://web.archive.org/web/20121001002815/http://my.opera.com/securitygroup/blog/2012/07/03/operas-cross-network-protection https://web.archive.org/web/20121001002815/http://my.opera.c...
EE84M3i 6y ago
"One website can use resources from other website using img, script, link tags." Interestingly, you can't do this for web fonts, because they require CORS, which was only added to make type foundries happier by making hotlinking fonts not possible.
- deleted 6y ago
  [deleted]
cookiengineer 6y ago
This reminds me of the DDoS service that was using adverts on various ad networks to abuse firefox’s ftp:// url support in exactly the same manner, because ftp protocol didn’t have any limitations, so there were 65k connections spawned simultaneously per client/bot.

banachtarski 6y ago

So much misinformation and FUD in this article. It's immediately suspect that the author had to lookup what websockets even WERE. No mention of the permissions system? This is a super low-quality article to make it to the front page.

tasteTheAnus 6y ago
Okay, but you're the one that's wrong. The truth is, we lost control of our own devices that are supposed to work for us, and instead they're used against us. I can't take the battery out of my phone, and it's design is such that it won't work directly from a power cord plugged into a wall socket. This incentivizes the user toward keeping the battery charged at all times, and thus maintaining a device state, such that one can never truly know if the radio, camera and microphone are engaged or not. And whose fault is that? It's a dark pattern, and device manufacturers know it. So too with all of the web* technology that the author highlights. The party line is "You asked for it, you do it to yourself, and you really DO like it, but you just don't know it yet, sam-i-am. Just try the green eggs and ham, friend. It's blisssssssss..." It's not wrong to take exception to this prevailing dismal wind.
kccqzy 6y ago
Yeah. Not to mention that WebSockets designers gave considerable thought to its security. Things like adding a mask to client messages look like puzzling inefficiencies, but are actually well designed security measures.
usr1106 6y ago
Right, and he didn't try out all sockets to find out what is the blacklist. Did he notice that Firefox is open source and reading the source might give good hints? (On my phone now and not starting to do it myself. But I have run Firefox under gdb before to check how Google Streetview uses WebGL. It's not difficult under Linux at least, even if you like myself know absolutely nothing about the somewhat intimidating code base of Firefox.)

nana- 6y ago

Actually Microsofts work on https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rdperp/ead02bce-64ef-41d6-aa06-8565956b9fe7 https://docs.microsoft.com/en-us/openspecs/windows_protocols...

ximm 6y ago

I am starting to wonder whether we should split the web into "document mode" with only small subset of javascript APIs and "application mode". This could actually spark some innovation because the threshold to build a document-web-browser from scratch would be so much lower and it could have much better security.

lecarore 6y ago
I browse the web with js off by default, and turn it on per domain in 2 clicks. That's basically what you are proposing accessible today, with Firefox, on desktop and on Android
- throwaway_pdp09 6y ago
  Aside: I turn off JS and never allow it on outside a VM (which gets wiped back to a clean state on shutdown). It's definitely not the same thing because a lot of documents simply do not render (here's one I was looking at not 2 minutes ago, at least it has text, but no pics https://vanschneider.com/the-kawaiization-of-product-design https://vanschneider.com/the-kawaiization-of-product-design A Number of sites will render absolutely nothing at all, text or otherwise eg https://www.washingtonpost.com https://www.washingtonpost.com). Nope, he's got a good suggestion IMO.
throwaway_pdp09 6y ago
Oh hell yes, I'm all for this. Though with the proviso of NO javasccript for document mode at all. I think this is a great idea.
eitland 6y ago
Daniel Janus had written about it here: http://blog.danieljanus.pl/2019/10/07/web-of-documents/ http://blog.danieljanus.pl/2019/10/07/web-of-documents/ I am fairly certain I have written about it as well, here or on my blog somewhere. My ideas are a bit more pragmatic maybe: I hope Mozilla or someone else will make a html version of asm.js - an extremely performant renderer for a subset of html and css. This could solve the bootstrapping dilemma since it would work in every other browser as well - only hopefully even faster in browsers that supports it - and make real headway in as little as a few years while working from day 1. My suggestions: - a meta field in the header indicating html document - a free validation service - if a document signals it is a modern document, send it down the fast path - if the document doesn't follow the rules, restart with ordinary rules - js is forbidden except for a number of vetted common libraries for things like autocomplete

fxtentacle 6y ago

I fully agree. When I open a newspaper website, I want to receive a tiny bit of HTML and CSS and maybe references to some images. Like 50KB+images. Instead, I am bombarded with megabytes of JavaScript and these new APIs so that advertisers can better spy on me. All of that comes at the expense of my bandwidth, my CPU usage and battery power, and my privacy. Soon, we'll need a service that remotely opens those websites for you, then dumps the DOM and only forwards that to you. So basically server-side rendering for other people's delinquent websites.

IshKebab 6y ago

Good list of Web* technologies but he is wrong about them being all on-by-default security risks and wrong about them being useless gimmicks: * WebSockets: On by default but obviously useful and not that different to normal HTTP requests. Can you port scan with XMLHttpRequest? I wouldn't be surprised. * WebBluetooth: Has a permission dialog. This is actually really useful for things like the physical web - you can control nearby one-off devices without needing to install an app or for either device to have internet access. Great for interactive art installations for example. * WebRTC: Enabled by default but very useful for web based games because it allows UDP-like communication. Also obviously useful for video conferencing. * WebAssembly: This doesn't let you do anything that Javascript didn't so he's just being paranoid that it "enables binary executables to run in your browser". * WebGL: This one he has a point on - GPU drivers are full of bugs and weren't designed to run untrusted software. I'm surprised there aren't more exploits of this. * WebUSB: Again, useful for using USB devices without having to install an app. This also has a permission dialog. Most of these are because the web is now an app platform, not just a document store.