4 ms·

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

by habyte 6y ago

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.
    - bjt2n3904 6y ago
      This is true -- and it may also be the same for miscellaneous permissions. But that doesn't mean it won't be used as an excuse by the feature developers. Honestly though, this is just me being bitter at web developers.
- usr1106 6y ago
  Right. Firefox is open source. Why is nobody adding prompts for Web Sockets, WebGL, Web Assembly and all the new stuff that a security / privacy concerned user has at least mixed feelings about. Prompts are not a good solution for a wider audience, but at least they satisfy the curiosity of power users and offer the possibility to leave the site if you get the feeling it's too dodgy.
SmallPeePeeMan 6y ago
Native applications.
- LunaSea 6y ago
  Native applications have orders of magnitude more access to your system than a website has.
  - rpastuszak 6y ago
    This isn't a loaded question, but how come people (especially the people here) don't know that?
    - SmallPeePeeMan 6y ago
      the real question is: Why do people write websites to behave more and more like native apps? In order to prevent a client-side install? For applications that want special access to my machine, there SHOULD be a barrier to entry or inconvenience like a client-side installation.
phkahler 6y ago
Native applications? Not everything needs to run in a browser.
- Spivak 6y ago
  But that’s even worse! Native apps have even less (i.e. zero most of the time) sandboxing than the browser. This wouldn’t be a meaningful security improvement for anyone.
  - danieldk 6y ago
    You use a much smaller set of applications than web sites. Moreover, you usually vet your applications and do not run random stuff. Application developers build up trust over time. Even if I want to use the web as hypertext + some Javascript for interactivity, every stupid web site can pull these shenanigans.
    - rpastuszak 6y ago
      A flashlight app asking for your contact list disagrees (don't forget about the FB SDK sitting quietly in the corner)
    - danShumway 6y ago
      You use a much smaller set of applications than websites because websites exist. You're imagining a world where the most popular dev environment goes away, and service providers decide to use HTML forms instead of forcing me to download an app every time I want to order a pizza. That world does not exist. The apps aren't going to go away, and your security model can't be, "people just won't install untrustworthy apps." And put things in perspective here -- we're talking about a security vulnerability that allows port scanning primarily for fingerprinting purposes. A native app can not only port scan, it can literally just make POST requests to those open ports across separate domains. The security risks we're talking about are not even remotely equivocal. Don't get me wrong, stuff like port-scanning should be fixed in web browsers. But even with these vulnerabilities, the web is still unquestionably the safest consumer-accessible application platform that we have today. Moving applications off of the web and back onto native platforms would be setting security back half a decade. When someone comes to me and asks how they make their phone more secure and more private, the number one piece of advice I give them, every single time, is "avoid native apps and use websites instead. Don't install Facebook, use the website. Don't install random clicker games, browse them online instead." The web has been a major asset in my quest to get friends and family not to install a bunch of random malware on their devices. Doubly so when you throw kids and younger users into the equation. I am eternally grateful that the web is advanced enough that people can join a Zoom meeting without installing Zoom on their computer.
90minuteAPI 6y ago
Server Sent Events and HTTP? With a modern setup it’s going to be sharing an HTTP/2 pipe anyway. Even handles disconnections gracefully/transparently if you’re clever about it. Can anyone expand on why this technique isn’t more common? I’m so sick of seeing folks reinvent HTTP (poorly) on top of WebSockets. I get if extreme low latency is (allegedly) a requirement.
- iokanuon 6y ago
  From what I remember about SSE, no Microsoft browser supported them. It seems like they've finally added support to Edge this year though.
- pennaMan 6y ago
  SSE have a limit of 6 connections across all browser tabs https://bugzilla.mozilla.org/show_bug.cgi?id=906896 https://bugzilla.mozilla.org/show_bug.cgi?id=906896 https://bugs.chromium.org/p/chromium/issues/detail?id=275955 https://bugs.chromium.org/p/chromium/issues/detail?id=275955
  - anderspitman 6y ago
    If you're using HTTP/2 this problem goes away.
- verandaguy 6y ago
  >Can anyone expand on why this technique isn’t more common? Hard answer: WS has been around for longer, and it's had more "marketing" for lack of a better word -- more people know about it and know how to use it. Retooling existing WS-using code to use HTTP/2 pipes would be a considerable effort with little to no perceived benefit to most users and teams. Speculative answer: most web developers live closer to the application and presentation layers, and there's resistance to learning technologies that involve HTTP connection management e.g. in nginx (not to say that there are none of these, there are just fewer of us). WS was at the right place at the right time with a good high-level interface available to the client, and gained traction because of this.
- nemothekid 6y ago
michaelt 6y ago
Web sockets, but redesigned to only connect to the host shown in the address bar, on port 443.
- derefr 6y ago
  Doesn’t work if www.example.com is just an S3 bucket, with the actual website at api.example.com.
  - michaelt 6y ago
    That sounds like the developer's problem, not the browser's problem. I mean, I could half-ass my work a lot more often if they'd get rid of these burdensome restrictions on cross-origin requests. But they ain't going to.
    - derefr 6y ago
      Domains are never going to be just one origin. If we could force developers (or, more precisely, ops teams) to do this, then CORS would never have needed to exist in the first place, because there would be no need to allow any crossing of origins in the first place. But, at every point in the web’s evolution (including today), there was always been something that needed to live on a different host or port for some reason or another—usually because it’s too leading-edge for load-balancers to understand how to route it correctly. TCP load balancers that can handle long-lived flows with connection stickiness et al, are a very modern invention in the web’s history; and even they still stumble when it comes to e.g. WebRTC’s UDP packets, or QUIC.
- bjt2n3904 6y ago
  This man right here understands things.

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

by 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.
  - bjt2n3904 6y ago
    This is true -- and it may also be the same for miscellaneous permissions. But that doesn't mean it won't be used as an excuse by the feature developers. Honestly though, this is just me being bitter at web developers.
usr1106 6y ago
Right. Firefox is open source. Why is nobody adding prompts for Web Sockets, WebGL, Web Assembly and all the new stuff that a security / privacy concerned user has at least mixed feelings about. Prompts are not a good solution for a wider audience, but at least they satisfy the curiosity of power users and offer the possibility to leave the site if you get the feeling it's too dodgy.

SmallPeePeeMan 6y ago

Native applications.

LunaSea 6y ago
Native applications have orders of magnitude more access to your system than a website has.
- rpastuszak 6y ago
  This isn't a loaded question, but how come people (especially the people here) don't know that?
  - SmallPeePeeMan 6y ago
    the real question is: Why do people write websites to behave more and more like native apps? In order to prevent a client-side install? For applications that want special access to my machine, there SHOULD be a barrier to entry or inconvenience like a client-side installation.

phkahler 6y ago

Native applications? Not everything needs to run in a browser.

Spivak 6y ago
But that’s even worse! Native apps have even less (i.e. zero most of the time) sandboxing than the browser. This wouldn’t be a meaningful security improvement for anyone.
- danieldk 6y ago
  You use a much smaller set of applications than web sites. Moreover, you usually vet your applications and do not run random stuff. Application developers build up trust over time. Even if I want to use the web as hypertext + some Javascript for interactivity, every stupid web site can pull these shenanigans.
  - rpastuszak 6y ago
    A flashlight app asking for your contact list disagrees (don't forget about the FB SDK sitting quietly in the corner)
  - danShumway 6y ago
    You use a much smaller set of applications than websites because websites exist. You're imagining a world where the most popular dev environment goes away, and service providers decide to use HTML forms instead of forcing me to download an app every time I want to order a pizza. That world does not exist. The apps aren't going to go away, and your security model can't be, "people just won't install untrustworthy apps." And put things in perspective here -- we're talking about a security vulnerability that allows port scanning primarily for fingerprinting purposes. A native app can not only port scan, it can literally just make POST requests to those open ports across separate domains. The security risks we're talking about are not even remotely equivocal. Don't get me wrong, stuff like port-scanning should be fixed in web browsers. But even with these vulnerabilities, the web is still unquestionably the safest consumer-accessible application platform that we have today. Moving applications off of the web and back onto native platforms would be setting security back half a decade. When someone comes to me and asks how they make their phone more secure and more private, the number one piece of advice I give them, every single time, is "avoid native apps and use websites instead. Don't install Facebook, use the website. Don't install random clicker games, browse them online instead." The web has been a major asset in my quest to get friends and family not to install a bunch of random malware on their devices. Doubly so when you throw kids and younger users into the equation. I am eternally grateful that the web is advanced enough that people can join a Zoom meeting without installing Zoom on their computer.

90minuteAPI 6y ago

Server Sent Events and HTTP? With a modern setup it’s going to be sharing an HTTP/2 pipe anyway. Even handles disconnections gracefully/transparently if you’re clever about it. Can anyone expand on why this technique isn’t more common? I’m so sick of seeing folks reinvent HTTP (poorly) on top of WebSockets. I get if extreme low latency is (allegedly) a requirement.

iokanuon 6y ago
From what I remember about SSE, no Microsoft browser supported them. It seems like they've finally added support to Edge this year though.
pennaMan 6y ago
SSE have a limit of 6 connections across all browser tabs https://bugzilla.mozilla.org/show_bug.cgi?id=906896 https://bugzilla.mozilla.org/show_bug.cgi?id=906896 https://bugs.chromium.org/p/chromium/issues/detail?id=275955 https://bugs.chromium.org/p/chromium/issues/detail?id=275955
- anderspitman 6y ago
  If you're using HTTP/2 this problem goes away.
verandaguy 6y ago
>Can anyone expand on why this technique isn’t more common? Hard answer: WS has been around for longer, and it's had more "marketing" for lack of a better word -- more people know about it and know how to use it. Retooling existing WS-using code to use HTTP/2 pipes would be a considerable effort with little to no perceived benefit to most users and teams. Speculative answer: most web developers live closer to the application and presentation layers, and there's resistance to learning technologies that involve HTTP connection management e.g. in nginx (not to say that there are none of these, there are just fewer of us). WS was at the right place at the right time with a good high-level interface available to the client, and gained traction because of this.
nemothekid 6y ago

michaelt 6y ago

Web sockets, but redesigned to only connect to the host shown in the address bar, on port 443.

derefr 6y ago
Doesn’t work if www.example.com is just an S3 bucket, with the actual website at api.example.com.
- michaelt 6y ago
  That sounds like the developer's problem, not the browser's problem. I mean, I could half-ass my work a lot more often if they'd get rid of these burdensome restrictions on cross-origin requests. But they ain't going to.
  - derefr 6y ago
    Domains are never going to be just one origin. If we could force developers (or, more precisely, ops teams) to do this, then CORS would never have needed to exist in the first place, because there would be no need to allow any crossing of origins in the first place. But, at every point in the web’s evolution (including today), there was always been something that needed to live on a different host or port for some reason or another—usually because it’s too leading-edge for load-balancers to understand how to route it correctly. TCP load balancers that can handle long-lived flows with connection stickiness et al, are a very modern invention in the web’s history; and even they still stumble when it comes to e.g. WebRTC’s UDP packets, or QUIC.
bjt2n3904 6y ago
This man right here understands things.