23 ms·

Every time I hear about some shiny new feature being added to a browser, I think... 1) Will I ever actually use this 2) How is this gonna screw me over WebSo

Every time I hear about some shiny new feature being added to a browser, I think... 1) Will I ever actually use this 2) How is this gonna screw me over WebSockets, WebBluetooth, WebAssembly, Web-You-Can-Access-my-Accelerometer-and-Battery, haven't ever wanted to use those. Ever. For anything. For any reason. (Edit 3: Oh yeah, I forgot! WebRTC!) Edit: Fantastic. You can't disable it in Firefox. So what, does Firefox need a freaking iptables implementation now? [1] 1 - https://bugzilla.mozilla.org/show_bug.cgi?id=1091016 https://bugzilla.mozilla.org/show_bug.cgi?id=1091016 "The only theoretical reason for the WebSocket pref these days is the possibility to disable it easily in case there is a security issue found in the protocol itself or so." The protocol itself is the security issue. ALL OF IT. Edit 2: So I don't have the time to investigate every new fad when it comes out. I originally thought WebSockets were raw sockets, but they aren't. Firefox blocks access to port 22 -- I was hoping all privileged ports, but it seems just those. Opening a WebSocket to netcat dumps out a HTTP request, so it seems unlikely that you'd be able to talk with anything that doesn't talk HTTP and WebSockets. Firefox also seemingly blocks access to 192.168/24 and 10/8. This makes me less angry. But what STILL make me angry is that I have to sit and research about some stupid thing that I don't want and can't turn off. Sooner or later, some web dev is gonna argue that all sites should be loaded over WebSockets because his bloated javascript stack performs marginally better, and then WebSockets won't be something I can turn off. Websites will just whitepage. Edit 4: Done researching this now. I went to ebay on Firefox, and wasn't getting websocket scans. But I've got a stack of uBlock and NoScript... maybe that's interfering with it some how? Opened up a stock config for google-chrome -- that's my browser for "some dumb new web tech that isn't working in Firefox" -- not seeing any scans when I open up inspector and click "WS". Regardless, his point still stands. You can totally use WebSockets as a port scanner for localhost, assuming the Content Security Policy allows it. Now I gotta go update my nginx configs...

deleted 6y ago
[deleted]
the8472 6y ago
> So what, does Firefox need a freaking iptables implementation now? umatrix is the layer7 firewall you're looking for, it can block websocket connections, cross-domain ones in particular are quite easy.
- djsumdog 6y ago
  I've had performance issues with umatrix. I tried blocking all JS by default and explicitly enabling scripts. In theory that should make the browser preform better. I suspect there are a bunch of sites that can't run a function or reach a JS resource and then just go into spin loops eating through resources .. either that or the blocking itself is resource intensive.
  - the8472 6y ago
    blocking has non-zero cost, yes. especially if complex whitelists need to be evaluated for every request. but at least for me it still is a net win most of the time. But you can also operate umatrix in a blacklist-based approach, i.e. simply let most requests through except the categories you deem problematic (e.g. cross-site websockets in this case)
  - OJFord 6y ago
    > I suspect there are a bunch of sites that can't run a function or reach a JS resource and then just go into spin loops eating through resources Google Maps.
habyte 6y ago
I'm sorry, what's the alternative for (soft-)real-time applications on frontend if not WebSocket? You probably do want to use it.
- kalium-xyz 6y ago
  Webrtc, plain requests, and side channels involving streams
- jackewiehose 6y ago
  The alternative is to ask the user on a site basis.
  - bjt2n3904 6y ago
    That would be amazing, but it would never happen. Mom and Pop would always click "no" out of fear of the unknown, and my awesome feature wouldn't get used! It has to be enabled by default, they don't know what they're missing!
    - kchr 6y ago
      Surely everybody needs My Feature(TM)!
    - derefr 6y ago
      That’s already how the browser microphone/camera API and notification API work, though. At this point, it’s the expectation/default for new APIs to act this way. The browser makers would just have to be convinced to align the behaviour of these slightly-older APIs to the best-practice UX paradigm for new APIs.
    - gsnedders 6y ago
      That's literally the opposite of the concern with permission prompts: all the evidence from years of SSL/TLS certificate errors is that users will blindly grant permission.
      - 6y ago
jackewiehose 6y ago
There is media.peerconnection.enabled in about:config. When set to false, WebRTC doesn't work but I'm not sure if there isn't anything left active. Also uBlock has an option "Prevent WebRTC from leaking IP adresses". WebRTC should be disabled by default or firefox should ask explicitly like with webcam-access. There have already been reports where sites use your browser as a peer in a P2P-network (without your consent). This can be really problematic depending on where you live.
- jimmaswell 6y ago
  > Prevent WebRTC from leaking IP adresses A local IP?
  - Reelin 6y ago
    Yes, oddly enough. It can be used by a website you visit to gain information about your local network which turns out to be incredibly effective for fingerprinting.
    - fr2null 6y ago
      WebRTC can also leak your IP when you're hiding behind a VPN.
      - hanniabu 6y ago
        Any way to stop that?
        mirimir 6y ago
        The best solution is running the VPN client in your router. That way, your machine can't see its ISP-assigned public IP address. If you're using a workspace VM, you can run the VPN client in a pfSense VM, which is functionally equivalent. If you're not using a workspace VM, and can't run the VPN client in a router, you can run the VPN client in a pfSense VM. You bridge the WAN interface of the pfSense VM to the host LAN adapter. So then the host can't use it. And you configure the LAN interface of the pfSense VM as host-only. So now the host machine (your workspace) can reach the Internet only through the VPN client in the pfSense VM. Or you can just make sure that WebRTC is disabled.
djsumdog 6y ago
Websockets are nice for some things. I hack on Mastodon and it uses WSS for streams and they're very helpful. But WebBluetooth, ASM, etc are all fairly insane. WebRTC feels like a massive security issue (I've seen a demo of someone using WebRTC to find computers on an internal network at a security conference years ago. Even if that hole is fixed, it's still a hacky solution to video streaming behind NAT). I agree; most of this stuff needs to have ways to disable it, in the base configuration screen of the browser (not hidden somewhere in about:config).
- Reelin 6y ago
  > Even if that hole is fixed ... Last I checked (> 1 year ago) it was WONTFIX because of some very idiotic (IMO) reasoning. I keep it permanently disabled and have never missed it (media.peerconnection.enabled in Firefox btw).
  - rhizome 6y ago
    No doubt like canvas, font, audio, etc. fingerprinting, it will eventually be required to use Google apps like Maps and Messages for Web (to cite two recent discoveries). "If you're not paying, you're the product" has its own form of economic inflation.
- klodolph 6y ago
  Why is ASM insane? Are you talking about WASM? That’s got the same security model as JavaScript.
  - garmaine 6y ago
    Which is where the trouble started.
  - neurostimulant 6y ago
    WASM is great peace of tech but I can't help to think it would be abused a lot in the future. For example, right now we can use ad blocker to block ads and analytics by blocking its js from loading. Imagine when wasm gains mainstream popularity and ad companies begin to ship their ads and analytics product as a libaries to be linked at compile time. How do we block something like that? Sure the adblocker can hide the relevant dom contents, but the code is still run and doing whatever it want on your browser.
louis_pasteur 6y ago
We need a simple browser implementation for the masses. Is there any such browser in existence?
- mcherm 6y ago
  There are no simple browsers, thus certainly no simple browser for the masses.
  - folmar 6y ago
    If you are on mobile there is Firefox Klar/Focus.
- mard 6y ago
  Netscape.
- Sargos 6y ago
  DOS is simpler than Linux. Lets go back to that.
- kchr 6y ago
  Qutebrowser.
- wronex 6y ago
  Agreed. Firefox99, latest Firefox but party like it's 1999. Web* disabled. Canvas disabled. LocalStorage disabled. DRM-content disabled. Anything else we don't need?
  - travisporter 6y ago
    You've inpsired me! In Firefox: LocalStorage - about:config Dom.storage.enabled Canvas - block JS via noscript DRM - Preferences->Disable DRM content checkbox WebRTC - about:config media.peerconnection.enabled; As a side note, noscript has been an eye-opener for how many things are loaded when I open anywebsite! It's been fast, but I've been getting annoyed by guessing what to enable to move past a blank webpage. And WTF is newrelic and why does half of my internet browsing use it?
lqet 6y ago
> Opening a WebSocket to netcat dumps out a HTTP request, so it seems unlikely that you'd be able to talk with anything that doesn't talk HTTP and WebSockets. AFAIK this is only partly true, if the web server does not support the websocket protocol, you cannot connect to it [0]. So if I am understanding this correctly, WebSockets only support a small subset of HTTP and it should therefore not be possible to use them to connect to "classic" HTTP servers or to send GET or POST requests to it. [0] https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_...
- jwandborg 6y ago
  WebSocket connections are initialized by sending an HTTP request.
- cygx 6y ago
  But you still have to make sure all programs bound to local ports handle WebSocket requests gracefully. Binding to 127.0.0.1 is a nicely cross-platform way to do inter-process communication (I've done so in the past to mitigate JVM startup/warmup issues). I've never written this code defensively, because if you run programs that throw random shit at locally-bound ports, that's your responsibility. The web community has decided it's a good idea to give arbitrary websites that capability. It's true that the 'random shit' may only take the form of WebSocket requests, but this is only a minor comfort. From my perspective, this needs to be locked down. edit: On second thought, you have always been able to trigger similar requests by e.g. just setting the src attribute of an image: Opera aside, browsers apparently never implemented proper cross-network protections. So from now on, I'll be extra careful to make sure all my servers can handle unexpected, potentially malicious HTTP requests even when bound to 127.0.0.1. That said, I still do think this is something that needs fixing on the browser-side.
datenwolf 6y ago
You forgot WebUSB – I wish I was joking, but I'm not: https://developer.mozilla.org/en-US/docs/Web/API/USB https://developer.mozilla.org/en-US/docs/Web/API/USB
- bjt2n3904 6y ago
  ...we are screwed.
- edoo 6y ago
  I see irony in all this web functionality. Back in the 90's if you wanted an ohms law calculator you had to go download a poorly written program from some random website. Network admins started locking down what you could download, run, and install due to security problems. Flash became a hit and they started piling on features in the browser so you could run things dynamically without having to download something. Fast forward almost 30 years and the browser has become so full featured it is practically a weak OS sandbox that allows you to run just about anything. It was originally being extended to avoid that in the first place, and here we are almost back to square one.
  - abakker 6y ago
    yes, because for most user choosing between security and functionality is not a choice they are prepared to reason about. I'm no expert, but I am computer savvy. My experience is that more security ALWAYS limits functionality that I want. I get around it all with VMs and snapshots. I have totally wide open VMs that have no host access and just reset to the snapshot when I shut them down. the irony is that it is not only harder to choose functionality today, when you want it, but also harder to choose security. The choices are made for you. it is infuriating.
  - wongarsu 6y ago
    The browser is basically the reinvention of the operating system. Its huge advantage is that it's built on the assumption that the user is trusted and the code isn't. In contrast most operating systems are designed on the assumption that code is absolutely trusted, but the user isn't. That's why rights management in Windows is concerned with who's allowed to access which file, while rights management in Firefox is concerned which which website is allowed to access the Webcam. The big disadvantage of the browser is of course that there's huge competitive pressure, and most users prefer usability over security. Keeping things secure without asking the user about their intentions every step is a huge challenge (see also Windows UAC, which struggles with the same problem).
craftinator 6y ago
Whatever happened to a control panel to turn off all of the things you Don't Want? All of these protocols should have triple toggle switches, Enabled, Ask, Disabled. If something on the page doesn't load because that protocol is disabled, it logs to the console so you can turn on what you need for that page. I get that adding lots of user controls makes state management difficult, but there are tried and true ways to do this; users need the browser to work for them, not the other way around.
- jschwartzi 6y ago
  Firefox is open-source, so you could add that. I would really appreciate being able to turn WebUSB WebBluetooth and WebRTC off entirely as those expose a lot of devices that I need not to be exposed to the Internet.
  - michaelt 6y ago
    I'm pretty sure someone at Firefox has decided the settings panel should be 'clean' and 'easy to use' rather than providing maximum control. I mean, there's a lot in about:config that the settings panel doesn't support.
    - folmar 6y ago
      ... and it was around the time when Firefox 3 was introduced.
fxtentacle 6y ago
Web browsers really are the new operating systems. Chrome OS was far ahead of its time, both in its general user hostility and in its excessive resource consumption for seemingly mundane tasks. Like when your roommate's YouTube streaming makes your Excel-like app horribly slow, because your new spreadsheet app needs high-speed internet for no obvious reason. BTW, WebRTC and WebAssembly were great for crypto mining trojans embedded into ads. Before, they had to port their crypto miner to JavaScript by hand. By now, you can just cross-compile it. The progress of technology ... helps only the technology, but not you, the disposable user in front of the screen :p
- giantrobot 6y ago
  Hey, refID af64e30y, get back to looking at ads while your browser mines cryptocoins! We'll be watching!
- typ 6y ago
  Strictly speaking, it is more like the shell of the distributed operating system.
  - Minor49er 6y ago
    Which is also funny because, if I remember correctly, IE was deeply integrated into Windows Explorer and the desktop was essentially rendered by the browser. I remember being able to even change my wallpaper to a custom HTML page in Windows
- TomMarius 6y ago
  You can't cross compile anything other than crypto miners or how does it not help anything else?
  - fxtentacle 6y ago
    Most of the other uses are pointless. I don't need WebRTC for chat, because IRC is still working just fine. I don't need WebRTC for video calls, because Skype is still working just fine. I don't need WebRTC and WebAssembly for online gaming, because I have Steam to install games locally. Plus latency and performance of games emscripten-ed to wasm tends to be atrocious. So the only uses where I have seen the new Web* APIs in my life was obnoxious ads and newspaper websites trying to shove recommendations and notifications into my face. What would you want to cross-compile that couldn't be done much better by building a proper local app?
u801e 6y ago
> Firefox also seemingly blocks access to 192.168/24 and 10/8. What about 172.16.0.0/12?
- pdonis 6y ago
  It blocks that too on my machine.
- m463 6y ago
  I remember when you could have a link to file:///etc/passwd and you could click on it, and the browser would load it.
have_faith 6y ago
I don't think there's anything wrong with any of those things with a sane permissions system attached (strict opt in per site). The web is now a no-install app delivery platform, it makes sense for these things to exist.
thinkmassive 6y ago
The ability to selectively enable those features would be ideal, but I disagree that their presence alone is a net negative. Web browsers are the new cross-platform runtime, better to get used to it.
pdonis 6y ago
> Firefox also seemingly blocks access to 192.168/24 and 10/8 Chrome, OTOH, will happily open a websocket to these IP ranges. Another good reason not to use Chrome.
- kchr 6y ago
  Uh... Why not block all private networks?
  - foobiekr 6y ago
    Probably IoT.
  - ac29 6y ago
    A search seems to suggest Chromecast devices are controlled via websocket, though that information is pretty old.
- deleted 6y ago
  [deleted]
- dragonwriter 6y ago
  > Chrome, OTOH, will happily open a websocket to these IP ranges. Another good reason not to use Chrome. Why is “I can use websockets on a private network” a bad thing?
derefr 6y ago
> WebSockets ... haven’t ever wanted to use those. Ever. For anything. For any reason. You’ve never used a web-app chat client? > WebBluetooth APIs like these don’t exist for the sake of regular unprivileged web-apps. They exist for the sake of browser extensions (or browser “apps”, or apps within a browser-projector like Electron), specifically in order to be used to add driver-like or service-like capabilities to devices like Chromebooks where the browser is the OS.
- bcrosby95 6y ago
  Before websockets webapp chat features would use long polling. Not sure if all current ones require websockets or if they have a fallback mechanism.
  - derefr 6y ago
    Before websockets, webapp chat features—as implemented by your average web-backend programmer—couldn’t pass the C10K challenge. Yes, fundamentally, on a technical level, there’s not much difference between holding open an HTTP connection in long-polling, vs. holding open a websocket connection. But the abstractions presented by webserver gateway interfaces (e.g. CGI, prefork process-per-connection language-module embeds), languages/web frameworks (e.g. Ruby on Rails), and platforms (e.g. Heroku) back then, just didn’t support long polling efficiently. HTTP backends, back then, were all built on an assumption of serialized queuing of HTTP requests—with each web server/web stack/worker thread serving requests one-at-a-time, getting each request out of the way as quickly as possible. There was no concept of IO asynchrony. Web servers were request loops, not event reactors. Libuv didn’t exist yet; nginx didn’t exist yet. The standard web server was Apache, and Apache couldn’t “yield” from a request that was idle. And, as such, providers like Heroku would queue at the load-balancer, and only proxy a single open request to your web backend at a time, under the presumption that it wouldn’t be able to handle concurrent load. So you had to pay for 2x the CPUs (e.g. Heroku “dynos”) if you wanted to be able to hold 2x the connections open! Entire third-party businesses (e.g. https://pusher.com/ https://pusher.com/) were built around the hosting of custom web servers that were written in an event-driven architecture, and so were able to host these pools of long-polling connections. But they were freakin’ expensive, because even they didn’t scale very well. Eventually, it was realized that the just-introduced Node.js could do IO asynchrony pretty well, and people started building explicit “websocket servers” in Node, culminating in the https://socket.io/ https://socket.io/ library. Back then, you couldn’t just put your regular HTTP load-balancer in front of your websocket backend, because your regular HTTP load-balancer almost certainly didn’t support held-open connections. You needed to host socket.io on a separate host/port, directly open to the internet. (This was one of the driving forces of Node’s adoption: as long as you were putting a Node app directly on the Internet, you may as well just put the rest of your HTTP app in there as well, and make the “websocket backend” into your whole backend.) Sure, these days, every backend, load-balancer, and NAT middlebox can handle long-polling just fine. But we got there with a decade of struggle, and “legacy”-but-not-really code that used WebSockets because they guaranteed the semantics that long-polling couldn’t. (I should mention, though, that WebSockets still have some advantages in the modern environment; namely, idle WebSockets are known to be idle at the runtime level, and so, unlike with a long-polling HTTP request, a mobile device can relax its wakeup-timer intervals when the only network connections it’s holding open are idle WebSockets.)
baybal2 6y ago
We are in ActiveX 2.0 era. Can we call it GoogleX?
billme 6y ago
>> “ Edit 4: Done researching this now. I went to ebay on Firefox, and wasn't getting websocket scans.“ ...Just in case you missed it and you’re using Linux, from the article... “I thought it might be because I run Linux, so I created a new Windows VM and sure enough, I saw the port scan occurring in the browser tools from the ebay home page”
anon_cow1111 6y ago
>So I don't have the time to investigate every new fad when it comes out I'm finding this to be my main problem. I have a fairly solid computer repair/troubleshooting background but can't keep up with the layers of crap that are pasted on top of modern software. An ongoing list of "features" being added to web browsers and how to get rid of them would be hugely helpful, but I've never found a centralized site for this topic, it's all just scattered around various tech sites.
deleted 6y ago
[deleted]
Wowfunhappy 6y ago
I realize Hacker News isn't a hivemind, but I see these two assertions frequently, and I find the contradiction striking: 1. Why are web browsers becoming application platforms? Web browsers are document readers, and we should treat them as such. 2. Why does Zoom (or Slack, or insert-thing-here) want me to download a native app? I should be able to do it in my web browser! I sympathize with both philosophies, but they cannot co-exist.
- dullgiulio 6y ago
  Nope, this is a strawman argument you're making. Parent is asking for granular access control over these very advanced and double-edged features, which is a perfectly valid request. Having permissions is the norm for native apps on mobile, and it's slowly becoming the norm also on desktop, finally. Browsers are the new OS, they have to implement permissions too without anything enabled by default.
- asveikau 6y ago
  Actually I think there's middle ground or a way to somewhat satisfy both. Does Zoom, Slack, or insert-thing-here need the technical ability to portscan localhost in the manner of this blog post? Well, Zoom had their vulnerability making web requests to their app bound to localhost, but did they need to be able to do it? They could get the job done without that functionality. They already have both an app and a web-only experience. (They try to hide the latter by only presenting the option when the former has evidently failed, but it's still there.) So, it has it both ways by your 1 & 2. Almost as if users should be able to choose.

deleted 6y ago

[deleted]

the8472 6y ago

> So what, does Firefox need a freaking iptables implementation now? umatrix is the layer7 firewall you're looking for, it can block websocket connections, cross-domain ones in particular are quite easy.

djsumdog 6y ago
I've had performance issues with umatrix. I tried blocking all JS by default and explicitly enabling scripts. In theory that should make the browser preform better. I suspect there are a bunch of sites that can't run a function or reach a JS resource and then just go into spin loops eating through resources .. either that or the blocking itself is resource intensive.
- the8472 6y ago
  blocking has non-zero cost, yes. especially if complex whitelists need to be evaluated for every request. but at least for me it still is a net win most of the time. But you can also operate umatrix in a blacklist-based approach, i.e. simply let most requests through except the categories you deem problematic (e.g. cross-site websockets in this case)
- OJFord 6y ago
  > I suspect there are a bunch of sites that can't run a function or reach a JS resource and then just go into spin loops eating through resources Google Maps.

habyte 6y ago

I'm sorry, what's the alternative for (soft-)real-time applications on frontend if not WebSocket? You probably do want to use it.

kalium-xyz 6y ago
Webrtc, plain requests, and side channels involving streams
jackewiehose 6y ago
The alternative is to ask the user on a site basis.
- bjt2n3904 6y ago
  That would be amazing, but it would never happen. Mom and Pop would always click "no" out of fear of the unknown, and my awesome feature wouldn't get used! It has to be enabled by default, they don't know what they're missing!
  - kchr 6y ago
    Surely everybody needs My Feature(TM)!
  - derefr 6y ago
    That’s already how the browser microphone/camera API and notification API work, though. At this point, it’s the expectation/default for new APIs to act this way. The browser makers would just have to be convinced to align the behaviour of these slightly-older APIs to the best-practice UX paradigm for new APIs.
  - gsnedders 6y ago
    That's literally the opposite of the concern with permission prompts: all the evidence from years of SSL/TLS certificate errors is that users will blindly grant permission.
    - 6y ago

jackewiehose 6y ago

There is media.peerconnection.enabled in about:config. When set to false, WebRTC doesn't work but I'm not sure if there isn't anything left active. Also uBlock has an option "Prevent WebRTC from leaking IP adresses". WebRTC should be disabled by default or firefox should ask explicitly like with webcam-access. There have already been reports where sites use your browser as a peer in a P2P-network (without your consent). This can be really problematic depending on where you live.

jimmaswell 6y ago
> Prevent WebRTC from leaking IP adresses A local IP?
- Reelin 6y ago
  Yes, oddly enough. It can be used by a website you visit to gain information about your local network which turns out to be incredibly effective for fingerprinting.
  - fr2null 6y ago
    WebRTC can also leak your IP when you're hiding behind a VPN.
    - hanniabu 6y ago
      Any way to stop that?
      - mirimir 6y ago
        The best solution is running the VPN client in your router. That way, your machine can't see its ISP-assigned public IP address. If you're using a workspace VM, you can run the VPN client in a pfSense VM, which is functionally equivalent. If you're not using a workspace VM, and can't run the VPN client in a router, you can run the VPN client in a pfSense VM. You bridge the WAN interface of the pfSense VM to the host LAN adapter. So then the host can't use it. And you configure the LAN interface of the pfSense VM as host-only. So now the host machine (your workspace) can reach the Internet only through the VPN client in the pfSense VM. Or you can just make sure that WebRTC is disabled.

djsumdog 6y ago

Websockets are nice for some things. I hack on Mastodon and it uses WSS for streams and they're very helpful. But WebBluetooth, ASM, etc are all fairly insane. WebRTC feels like a massive security issue (I've seen a demo of someone using WebRTC to find computers on an internal network at a security conference years ago. Even if that hole is fixed, it's still a hacky solution to video streaming behind NAT). I agree; most of this stuff needs to have ways to disable it, in the base configuration screen of the browser (not hidden somewhere in about:config).

Reelin 6y ago
> Even if that hole is fixed ... Last I checked (> 1 year ago) it was WONTFIX because of some very idiotic (IMO) reasoning. I keep it permanently disabled and have never missed it (media.peerconnection.enabled in Firefox btw).
- rhizome 6y ago
  No doubt like canvas, font, audio, etc. fingerprinting, it will eventually be required to use Google apps like Maps and Messages for Web (to cite two recent discoveries). "If you're not paying, you're the product" has its own form of economic inflation.
klodolph 6y ago
Why is ASM insane? Are you talking about WASM? That’s got the same security model as JavaScript.
- garmaine 6y ago
  Which is where the trouble started.
- neurostimulant 6y ago
  WASM is great peace of tech but I can't help to think it would be abused a lot in the future. For example, right now we can use ad blocker to block ads and analytics by blocking its js from loading. Imagine when wasm gains mainstream popularity and ad companies begin to ship their ads and analytics product as a libaries to be linked at compile time. How do we block something like that? Sure the adblocker can hide the relevant dom contents, but the code is still run and doing whatever it want on your browser.

louis_pasteur 6y ago

We need a simple browser implementation for the masses. Is there any such browser in existence?

mcherm 6y ago
There are no simple browsers, thus certainly no simple browser for the masses.
- folmar 6y ago
  If you are on mobile there is Firefox Klar/Focus.
mard 6y ago
Netscape.
Sargos 6y ago
DOS is simpler than Linux. Lets go back to that.
kchr 6y ago
Qutebrowser.
wronex 6y ago
Agreed. Firefox99, latest Firefox but party like it's 1999. Web* disabled. Canvas disabled. LocalStorage disabled. DRM-content disabled. Anything else we don't need?
- travisporter 6y ago
  You've inpsired me! In Firefox: LocalStorage - about:config Dom.storage.enabled Canvas - block JS via noscript DRM - Preferences->Disable DRM content checkbox WebRTC - about:config media.peerconnection.enabled; As a side note, noscript has been an eye-opener for how many things are loaded when I open anywebsite! It's been fast, but I've been getting annoyed by guessing what to enable to move past a blank webpage. And WTF is newrelic and why does half of my internet browsing use it?

lqet 6y ago

> Opening a WebSocket to netcat dumps out a HTTP request, so it seems unlikely that you'd be able to talk with anything that doesn't talk HTTP and WebSockets. AFAIK this is only partly true, if the web server does not support the websocket protocol, you cannot connect to it [0]. So if I am understanding this correctly, WebSockets only support a small subset of HTTP and it should therefore not be possible to use them to connect to "classic" HTTP servers or to send GET or POST requests to it. [0] https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_...

jwandborg 6y ago
WebSocket connections are initialized by sending an HTTP request.
cygx 6y ago
But you still have to make sure all programs bound to local ports handle WebSocket requests gracefully. Binding to 127.0.0.1 is a nicely cross-platform way to do inter-process communication (I've done so in the past to mitigate JVM startup/warmup issues). I've never written this code defensively, because if you run programs that throw random shit at locally-bound ports, that's your responsibility. The web community has decided it's a good idea to give arbitrary websites that capability. It's true that the 'random shit' may only take the form of WebSocket requests, but this is only a minor comfort. From my perspective, this needs to be locked down. edit: On second thought, you have always been able to trigger similar requests by e.g. just setting the src attribute of an image: Opera aside, browsers apparently never implemented proper cross-network protections. So from now on, I'll be extra careful to make sure all my servers can handle unexpected, potentially malicious HTTP requests even when bound to 127.0.0.1. That said, I still do think this is something that needs fixing on the browser-side.

datenwolf 6y ago

You forgot WebUSB – I wish I was joking, but I'm not: https://developer.mozilla.org/en-US/docs/Web/API/USB https://developer.mozilla.org/en-US/docs/Web/API/USB

bjt2n3904 6y ago
...we are screwed.
edoo 6y ago
I see irony in all this web functionality. Back in the 90's if you wanted an ohms law calculator you had to go download a poorly written program from some random website. Network admins started locking down what you could download, run, and install due to security problems. Flash became a hit and they started piling on features in the browser so you could run things dynamically without having to download something. Fast forward almost 30 years and the browser has become so full featured it is practically a weak OS sandbox that allows you to run just about anything. It was originally being extended to avoid that in the first place, and here we are almost back to square one.
- abakker 6y ago
  yes, because for most user choosing between security and functionality is not a choice they are prepared to reason about. I'm no expert, but I am computer savvy. My experience is that more security ALWAYS limits functionality that I want. I get around it all with VMs and snapshots. I have totally wide open VMs that have no host access and just reset to the snapshot when I shut them down. the irony is that it is not only harder to choose functionality today, when you want it, but also harder to choose security. The choices are made for you. it is infuriating.
- wongarsu 6y ago
  The browser is basically the reinvention of the operating system. Its huge advantage is that it's built on the assumption that the user is trusted and the code isn't. In contrast most operating systems are designed on the assumption that code is absolutely trusted, but the user isn't. That's why rights management in Windows is concerned with who's allowed to access which file, while rights management in Firefox is concerned which which website is allowed to access the Webcam. The big disadvantage of the browser is of course that there's huge competitive pressure, and most users prefer usability over security. Keeping things secure without asking the user about their intentions every step is a huge challenge (see also Windows UAC, which struggles with the same problem).

craftinator 6y ago

Whatever happened to a control panel to turn off all of the things you Don't Want? All of these protocols should have triple toggle switches, Enabled, Ask, Disabled. If something on the page doesn't load because that protocol is disabled, it logs to the console so you can turn on what you need for that page. I get that adding lots of user controls makes state management difficult, but there are tried and true ways to do this; users need the browser to work for them, not the other way around.

jschwartzi 6y ago
Firefox is open-source, so you could add that. I would really appreciate being able to turn WebUSB WebBluetooth and WebRTC off entirely as those expose a lot of devices that I need not to be exposed to the Internet.
- michaelt 6y ago
  I'm pretty sure someone at Firefox has decided the settings panel should be 'clean' and 'easy to use' rather than providing maximum control. I mean, there's a lot in about:config that the settings panel doesn't support.
  - folmar 6y ago
    ... and it was around the time when Firefox 3 was introduced.

fxtentacle 6y ago

Web browsers really are the new operating systems. Chrome OS was far ahead of its time, both in its general user hostility and in its excessive resource consumption for seemingly mundane tasks. Like when your roommate's YouTube streaming makes your Excel-like app horribly slow, because your new spreadsheet app needs high-speed internet for no obvious reason. BTW, WebRTC and WebAssembly were great for crypto mining trojans embedded into ads. Before, they had to port their crypto miner to JavaScript by hand. By now, you can just cross-compile it. The progress of technology ... helps only the technology, but not you, the disposable user in front of the screen :p

giantrobot 6y ago
Hey, refID af64e30y, get back to looking at ads while your browser mines cryptocoins! We'll be watching!
typ 6y ago
Strictly speaking, it is more like the shell of the distributed operating system.
- Minor49er 6y ago
  Which is also funny because, if I remember correctly, IE was deeply integrated into Windows Explorer and the desktop was essentially rendered by the browser. I remember being able to even change my wallpaper to a custom HTML page in Windows
TomMarius 6y ago
You can't cross compile anything other than crypto miners or how does it not help anything else?
- fxtentacle 6y ago
  Most of the other uses are pointless. I don't need WebRTC for chat, because IRC is still working just fine. I don't need WebRTC for video calls, because Skype is still working just fine. I don't need WebRTC and WebAssembly for online gaming, because I have Steam to install games locally. Plus latency and performance of games emscripten-ed to wasm tends to be atrocious. So the only uses where I have seen the new Web* APIs in my life was obnoxious ads and newspaper websites trying to shove recommendations and notifications into my face. What would you want to cross-compile that couldn't be done much better by building a proper local app?

u801e 6y ago

> Firefox also seemingly blocks access to 192.168/24 and 10/8. What about 172.16.0.0/12?

pdonis 6y ago
It blocks that too on my machine.
m463 6y ago
I remember when you could have a link to file:///etc/passwd and you could click on it, and the browser would load it.

have_faith 6y ago

I don't think there's anything wrong with any of those things with a sane permissions system attached (strict opt in per site). The web is now a no-install app delivery platform, it makes sense for these things to exist.

thinkmassive 6y ago

The ability to selectively enable those features would be ideal, but I disagree that their presence alone is a net negative. Web browsers are the new cross-platform runtime, better to get used to it.

pdonis 6y ago

> Firefox also seemingly blocks access to 192.168/24 and 10/8 Chrome, OTOH, will happily open a websocket to these IP ranges. Another good reason not to use Chrome.

kchr 6y ago
Uh... Why not block all private networks?
- foobiekr 6y ago
  Probably IoT.
- ac29 6y ago
  A search seems to suggest Chromecast devices are controlled via websocket, though that information is pretty old.
deleted 6y ago
[deleted]
dragonwriter 6y ago
> Chrome, OTOH, will happily open a websocket to these IP ranges. Another good reason not to use Chrome. Why is “I can use websockets on a private network” a bad thing?

derefr 6y ago

> WebSockets ... haven’t ever wanted to use those. Ever. For anything. For any reason. You’ve never used a web-app chat client? > WebBluetooth APIs like these don’t exist for the sake of regular unprivileged web-apps. They exist for the sake of browser extensions (or browser “apps”, or apps within a browser-projector like Electron), specifically in order to be used to add driver-like or service-like capabilities to devices like Chromebooks where the browser is the OS.

bcrosby95 6y ago
Before websockets webapp chat features would use long polling. Not sure if all current ones require websockets or if they have a fallback mechanism.
- derefr 6y ago
  Before websockets, webapp chat features—as implemented by your average web-backend programmer—couldn’t pass the C10K challenge. Yes, fundamentally, on a technical level, there’s not much difference between holding open an HTTP connection in long-polling, vs. holding open a websocket connection. But the abstractions presented by webserver gateway interfaces (e.g. CGI, prefork process-per-connection language-module embeds), languages/web frameworks (e.g. Ruby on Rails), and platforms (e.g. Heroku) back then, just didn’t support long polling efficiently. HTTP backends, back then, were all built on an assumption of serialized queuing of HTTP requests—with each web server/web stack/worker thread serving requests one-at-a-time, getting each request out of the way as quickly as possible. There was no concept of IO asynchrony. Web servers were request loops, not event reactors. Libuv didn’t exist yet; nginx didn’t exist yet. The standard web server was Apache, and Apache couldn’t “yield” from a request that was idle. And, as such, providers like Heroku would queue at the load-balancer, and only proxy a single open request to your web backend at a time, under the presumption that it wouldn’t be able to handle concurrent load. So you had to pay for 2x the CPUs (e.g. Heroku “dynos”) if you wanted to be able to hold 2x the connections open! Entire third-party businesses (e.g. https://pusher.com/ https://pusher.com/) were built around the hosting of custom web servers that were written in an event-driven architecture, and so were able to host these pools of long-polling connections. But they were freakin’ expensive, because even they didn’t scale very well. Eventually, it was realized that the just-introduced Node.js could do IO asynchrony pretty well, and people started building explicit “websocket servers” in Node, culminating in the https://socket.io/ https://socket.io/ library. Back then, you couldn’t just put your regular HTTP load-balancer in front of your websocket backend, because your regular HTTP load-balancer almost certainly didn’t support held-open connections. You needed to host socket.io on a separate host/port, directly open to the internet. (This was one of the driving forces of Node’s adoption: as long as you were putting a Node app directly on the Internet, you may as well just put the rest of your HTTP app in there as well, and make the “websocket backend” into your whole backend.) Sure, these days, every backend, load-balancer, and NAT middlebox can handle long-polling just fine. But we got there with a decade of struggle, and “legacy”-but-not-really code that used WebSockets because they guaranteed the semantics that long-polling couldn’t. (I should mention, though, that WebSockets still have some advantages in the modern environment; namely, idle WebSockets are known to be idle at the runtime level, and so, unlike with a long-polling HTTP request, a mobile device can relax its wakeup-timer intervals when the only network connections it’s holding open are idle WebSockets.)

baybal2 6y ago

We are in ActiveX 2.0 era. Can we call it GoogleX?

billme 6y ago

>> “ Edit 4: Done researching this now. I went to ebay on Firefox, and wasn't getting websocket scans.“ ...Just in case you missed it and you’re using Linux, from the article... “I thought it might be because I run Linux, so I created a new Windows VM and sure enough, I saw the port scan occurring in the browser tools from the ebay home page”

anon_cow1111 6y ago

>So I don't have the time to investigate every new fad when it comes out I'm finding this to be my main problem. I have a fairly solid computer repair/troubleshooting background but can't keep up with the layers of crap that are pasted on top of modern software. An ongoing list of "features" being added to web browsers and how to get rid of them would be hugely helpful, but I've never found a centralized site for this topic, it's all just scattered around various tech sites.

deleted 6y ago

[deleted]

Wowfunhappy 6y ago

I realize Hacker News isn't a hivemind, but I see these two assertions frequently, and I find the contradiction striking: 1. Why are web browsers becoming application platforms? Web browsers are document readers, and we should treat them as such. 2. Why does Zoom (or Slack, or insert-thing-here) want me to download a native app? I should be able to do it in my web browser! I sympathize with both philosophies, but they cannot co-exist.

dullgiulio 6y ago
Nope, this is a strawman argument you're making. Parent is asking for granular access control over these very advanced and double-edged features, which is a perfectly valid request. Having permissions is the norm for native apps on mobile, and it's slowly becoming the norm also on desktop, finally. Browsers are the new OS, they have to implement permissions too without anything enabled by default.
asveikau 6y ago
Actually I think there's middle ground or a way to somewhat satisfy both. Does Zoom, Slack, or insert-thing-here need the technical ability to portscan localhost in the manner of this blog post? Well, Zoom had their vulnerability making web requests to their app bound to localhost, but did they need to be able to do it? They could get the job done without that functionality. They already have both an app and a web-only experience. (They try to hide the latter by only presenting the option when the former has evidently failed, but it's still there.) So, it has it both ways by your 1 & 2. Almost as if users should be able to choose.