10 ms·

Direct Sockets API in Chrome 131

200 points by michaelkrem 2y ago

deleted 2y ago
[deleted]
chocolatkey 2y ago
When reading https://github.com/WICG/direct-sockets/blob/main/docs%2Fexplainer.md https://github.com/WICG/direct-sockets/blob/main/docs%2Fexpl..., it's noted this is part of the "isolated web apps" proposal: https://github.com/WICG/isolated-web-apps/blob/main/README.md https://github.com/WICG/isolated-web-apps/blob/main/README.m... , which is important context because the obvious reaction to this is the security nightmare
- phildenhoff 2y ago
  Interesting — the Firefox team’s response was very negative, but didn’t (in my reading) address use of the API as being part of an otherwise essentially trusted app (as opposed to being an API available to any website). In reading their comments, I also felt the API was a bad idea. Especially when technology like Electron or Tauri exist, which can do those TCP or UDP connections. But IWA serves to displace Electron, I guess
  - nzoschke 2y ago
    I'm hacking on a Tauri web app that needs to bridge to talking UDP protocols literally as we speak. While Tauri seems better than ever for cross platform native apps, it's still a huge step to take to allow my web app access to lower level. Rust toolchain, Tauri plugins, sidecar processes, code gen, JSON RPC, all to let my web app talk to my network. Seems great that Chrome continues to bundle these pieces into the browser engine itself. Direct sockets plus WASM could eat a lot of software...
    - 1oooqooq 2y ago
      with so many multiplatform gui toolkits today, tauri and electron are really bad choices
      - montymintypie 2y ago
        What's your recommendation? I've tried so many multiplatform toolkits (including GTK, Qt, wxWidgets, Iced, egui, imgui, and investigated slint and sciter) and nothing has come close to the speed of dev and small final app size of something like Tauri+Svelte.
        nzoschke 2y ago
        I've also tried Flutter, React Native, Kotlin multiplatform, Wails. I'm landing on Svelte and Tauri too. The other alternative I dabble with is using the Android Studio, XCode to write my own WebView wrappers.
        bpfrh 2y ago
        What did you dislike about kotlin multiplattform?
        1oooqooq 2y ago
        of course dev speed will be better with tauri plus the literal ton of JavaScript transpilers we use today. but for us an inhouse egui pile of helpers allow for fast applications that are closer to native speeds. and flutter for mobile (using neither Cupertino or material)
        montymintypie 2y ago
        Glad to hear that egui is working for you, but in my experience it's not accessible, difficult to render accurate text (including emoji and colours), very frustrating to extend inbuilt widgets, and quite verbose. One of my most recent experiences was making a fairly complex app at work in egui, then migrating to tauri because it was such a slog.
  - chrismorgan 2y ago
    > but didn’t (in my reading) address use of the API as being part of an otherwise essentially trusted app That’s what the Narrower Applicability section is about <https://github.com/mozilla/standards-positions/issues/431#issuecomment-690860040:~:text=Narrower%20Applicability https://github.com/mozilla/standards-positions/issues/431#is...>. It exposes new vulnerabilities because of IP address reuse across networks, and DNS rebinding.
    - mmis1000 2y ago
      - It is possible, if not likely, that an attacker will control name resolution for a chosen name. This allows them to provide an IP address (or a redirect that uses CNAME or similar) that could enable request forgery. This is quite trival, not even possible though. DNS server is quite a simple protocol. Writing a dns that reflect every request from aaa-bbb-ccc-ddd.domain.test to ip aaa.bbb.ccc.ddd won't take you even for a day. And in fact this already existed in the wild.
  - deleted 2y ago
    [deleted]
- crote 2y ago
  That doesn't really make it any better, if you ask me. The entire Isolated Web Apps proposal is a massive breakdown of the well-established boundaries provided by browsers. Every user understands two things about the internet: 1) check the URL before entering any sensitive data, and 2) don't run random stuff you download. The latter is heavily enforced by both Chrome and Windows complaining quite a bit if you're trying to run downloaded executables - especially unsigned ones. If you follow those two basic things, websites cannot hurt your machine. IWA seems to be turning this upside-down. Chrome is essentially completely bypassing all protections the OS has added, and allowing Magically Flagged Websites to do all sorts of dangerous stuff on your computer. No matter what kind of UX they provide, it is going to be nigh-on impossible to explain to people that websites are now suddenly able to do serious harm to your local network. Browsers should not be involved in this. They are intended to run untrusted code. No browser should be allowed to randomly start executing third-party code as if it is trustworthy, that's not what browsers are for. It's like the FDA suddenly allowing rat poison into food products - provided you inform consumers by adding it to the ingredients list of course.
  - apitman 2y ago
    > Every user understands two things about the internet: 1) check the URL before entering any sensitive data, and 2) don't run random stuff you download I think you're severely overestimating the things every user knows.
  - girvo 2y ago
    Unfortunately this is the future. Handing the world wide webs future to Google was a mistake, and the only remedy is likely to come from an (unlikely) antitrust breakup or divestment.
    - bloomingkales 2y ago
      I doubt websites as we know it will be what we’ll be dealing with going forward anyways. What is a browser if we just digest all the HTML and spit out clean text in the long run? We handed over something of some value I guess, once upon a time.
    - 2y ago
- rty32 2y ago
  Have isolated web apps/web bundle gained any traction over the past few years? I just realized that this thing existed and there were some discussions around it -- I almost completely forgot this. I did a search, and most stuff come from a few years ago.
  - meiraleal 2y ago
    It is used by chromeOS
    - rty32 2y ago
      You means apps written by Google as "native apps"? Any use cases outside that? If not, it is probably fair to say nobody uses this.
      - meiraleal 2y ago
        A PWA is a IWA so lots of people are using it besides Google
  - angra_mainyu 2y ago
    It makes much more sense to bundle a binary + web extension (w/ native messaging) to handle bridging the browser isolation in a sensible manner. It's a minimal amount of extra work and would mean you cross browser isolation in a very controlled manner.
parweb 2y ago
[flagged]
- deleted 2y ago
  [deleted]
- potwinkle 2y ago
  Please don't paste unedited AI output as a comment to a discussion.
- zzo38computer 2y ago
  I also think direct sockets can be helpful. (Note: I did not read the article because it does not work on my computer.) Another use would be for extensions (rather than web pages) to implement other protocols (which is related to item 2 in your list, but different). However, I think that many of these things shouldn't need to use a web browser at all. A web browser is a complicated software and using other software would be better if you are able to do so. This includes ping, traceroute, etc, which can already be handled by other programs (and can be used even if you do not have a web browser installed); but these things may be useful on Chromebook, perhaps; or if you have Chrome 131 but cannot use other software for some reason. For example, a service could be available by some other protocols (e.g. IRC), but also provide a web interface; this can then be one of the implementations of the protocol, so that if the web interface is compatible with your computer but the other provided implementations are not compatible (e.g. because you do not have a suitable operating system, or because you don't want to install extra software but you already have Chrome, etc), then it provides an additional interoperability, without needing too much additional complexity. Handling security is necessary, although there are ways to make it securely: Ask the user first to allow it, and allow the user to configure proxies and restrictions on the use (e.g. if it can only access specific addresses or cannot access specific addresses, or to allow or disallow specific port numbers, etc). (If a SOCKS proxy with localhost can be configured, then the user can use separate software to handle this; the web browser will just need to ensure that it is possible to be configured to not block anything, in case the user is configuring it like this in order to implement their own blocking rules.) A server's web pages should ideally include documentation as well, which allows you to find documentation and use other software (or write your own), if you do not have a compatible web browser or if you do not wish to use the web interface. So, I think that it is helpful, although there are some considerations. (The one about documentation is not really one that the authors of web browsers could easily enforce, and is the kind of problem that many web pages already have anyways, and this can't help.)
modeless 2y ago
I think a lot of people don't realize it's possible to use UDP in browsers today with WebRTC DataChannel. I have a demo of multiplayer Quake III using peer-to-peer UDP here: https://thelongestyard.link/ https://thelongestyard.link/ Direct sockets will have their uses for compatibility with existing applications, but it's possible to do almost any kind of networking you want on the web if you control both sides of the connection.
- winrid 2y ago
  Runs smoother than the Android home screen. :)
- mhitza 2y ago
  Longest Yard is my favorite Q3 map, but for some reason I cannot use my mouse (?) in your version of the Quake 3 demo.
  - modeless 2y ago
    Interesting, what browser and OS?
    - mhitza 2y ago
      Brave browser (Chromium via Flatpak) on the Steam Deck (Arch Linux) in Desktop mode with bluetooth connected mouse/keyboard.
      - topspin 2y ago
        Same browser on win10. Mouse works after you click in the window and it goes full screen. However, it hangs after a few seconds of game play. Stopped hanging... then input locks up somehow. Switched to chrome on win10, same issue: input locks up after a bit.
        modeless 2y ago
        Yeah that issue I have seen, but unfortunately haven't been able to debug yet as it isn't very reproducible and usually stops happening under a debugger.
Jiahang 2y ago
nice！
xenator 2y ago
Can't wait to see it working.
- revskill 2y ago
  Why waiting ? What can you do with it ? Can't wait to wait for you.
bloomingkales 2y ago
Can a browser run a web server with this?
- apitman 2y ago
  I assume they would limit it to clients.
- melchizedek6809 2y ago
  Since it allows for accepting incoming TCP connections, this should allow for HTTP servers to run within the browser, although running directly on port 80/443 might not be supported everywhere (can't see it mentioned in the spec, but from what I remember on most *nix systems only root can listen on ports below 1024, though I might be mistaken since it's been a while)
  - deleted 2y ago
    [deleted]
deleted 2y ago
[deleted]
fhdsgbbcaA 2y ago
Great fingerprinting vector. Expect nothing less from Google.
Spivak 2y ago
Anything that moves the web closer to its natural end state— the J(S)VM is a win in my book. Making web apps a formally separate thing from pages might do some good for the web overall. We could start thinking about taking away features from the page side.
- remram 2y ago
  This is beyond that, it's more a move to remove the VM than make JS a generic VM.
mlhpdx 2y ago
I’m excited, and anticipate some interesting innovation once browser applications can “talk UDP”. It’s a long time in the making. Gaming isn’t the end of it — being able to communicate with local network services (hardware) without involving an API intervening is very attractive.
- immibis 2y ago
  Indeed. I'll finally be able to connect to your router and change your wifi password, all through your browser.
  - lazyasciiart 2y ago
    Shhh, you’re giving my parents unrealistic expectations of how much remote tech support I can do.
chrisvenum 2y ago
I found this issue indicating a bad idea for end user safety: https://github.com/mozilla/standards-positions/issues/431 https://github.com/mozilla/standards-positions/issues/431
- hoherd 2y ago
  Mozilla won't even support webusb[1][2][3] due to security reasons, so there's no way they'd support raw sockets. [1] https://developer.mozilla.org/en-US/docs/Web/API/USB#browser_compatibility https://developer.mozilla.org/en-US/docs/Web/API/USB#browser... [2] https://wiki.mozilla.org/WebAPI/Security/WebUSB https://wiki.mozilla.org/WebAPI/Security/WebUSB [3] https://mozilla.github.io/standards-positions/#webusb https://mozilla.github.io/standards-positions/#webusb
jeswin 2y ago
I prefer web apps to native apps any day. However, web apps are limited by what they can do. But what they can do is not consistent - for example, it can take your picture and listen to your microphone if you give permissions; but it can't open a socket. Another example: Chrome came out with an File System Access API [2] in August; it's fantastic (I am using it) and it allows a class of native apps to be replaced by Web Apps. As a user, I don't mind having to jump through hoops (as a user) and giant warning screens to accept that permission - but I want this ability on the Web Platform. For Web Apps to be able to complete with native apps, we need more flexibility Mozilla. [1] [1]: https://mozilla.github.io/standards-positions/ https://mozilla.github.io/standards-positions/ [2]: https://developer.chrome.com/docs/capabilities/web-apis/file-system-access https://developer.chrome.com/docs/capabilities/web-apis/file...
- 1oooqooq 2y ago
  nah. we need even less. i rather webapps because of the limitations. much less to worry about
deleted 2y ago
[deleted]
kureikain 2y ago
This means that we can finally do gRPC directly from browser.
hipadev23 2y ago
What about WebTransport? I thought that was the http/3 upgrade to WebSockets that supported unreliable and out-of-order messaging
- mmis1000 2y ago
  I think WebRTC data channels will be a good alternative if you want peer to peer connection. WebTransport is strictly for Client-Server architecture only.
tjoff 2y ago
Great, so now a mis-click and your browser will have a field day infecting your printer, coffee machine and all the other crap that was previously shielded by NAT and/or a firewall.
- jeroenhd 2y ago
  As long as they don't change the spec, this will only be available to special locally installed apps in enterprise ChromeOS environments. I don't think their latest weird app format is going to make it to other browsers, so this will remain one of those weird Chrome only APIs that nobody uses.
  - fensgrim 2y ago
    > special locally installed apps in enterprise ChromeOS environments There was https://developer.chrome.com/docs/apps/overview https://developer.chrome.com/docs/apps/overview though, so this seems to be a kind of planned feature creep after deprecating former one? "Yeah our enterprise partners now totally need this, you see, no reasoning needed"
huqedato 2y ago
Just now, when I have only recently switched permanently to Firefox...
troupo 2y ago
Status of specification: "It is not a W3C Standard nor is it on the W3C Standards Track." Status in Chrome: shipping in 131 Expect people claiming this is a vital standard that Apple is not implementing because they don't want web apps to compete with App Store. Also expect sites like https://whatpwacando.today/ https://whatpwacando.today/ uncritically just include this
- meiraleal 2y ago
  Expect Apple claiming this is a not vital standard and Apple is not implementing because they don't want web apps to compete with App Store. Also expect sites like https://whatpwacando.today/ https://whatpwacando.today/ to obviously just include this
  - troupo 2y ago
    Which part of "is not a w3c standard and not any standards track" do you not understand? I am not surprised sites like that include Chrome-only non-standards, they've done this for years claiming impartiality
    - meiraleal 2y ago
      Cry me a river. Apple doesn't need you to defend their strategic and intentional PWA boycott.
      - troupo 2y ago
        Which part of "is not a w3c standard and not any standards track" do you not understand? Do you understand that for something to become a standard, it needs two independent implementations? And a consensus on API? Do you understand that "not on any standards track" means it's Chrome and only Chrome pushing this? That Firefox isn't interested in this either? Do you understand that blaming Apple for everything is borderline psychotic? And that Chrome implementing something at neck-breaking pace doesn't make it a standard? Here's Mozilla's extensive analysis and conclusion "harmful" that Google sycophants and Apple haters couldn't care less about: https://github.com/mozilla/standards-positions/issues/431#issuecomment-690860040 https://github.com/mozilla/standards-positions/issues/431#is...
pjmlp 2y ago
Yet another small step into ChromeOS take over.
arzig 2y ago
The inner platform effect intensifies.
Asmod4n 2y ago
Thank god they plan to limit this to electron type apps.
sabbaticaldev 2y ago
so with this I would be able to create a server in my desktop web app and sync all my devices using webrtc
tonetheman 2y ago
[dead]
Uptrenda 2y ago
I saw this proposal years ago now and was initially excited about it. But seeing how people envisioned the APIs, usage, etc, made me realize that it was already too locked down. Being able to have something that ran on any browser is the core benefit here. I get that there are security concerns but unfortunately everyone who worked on this was too paranoid and dismissive to design something open (yet secure.) And that's where the proposal is today. A niche feature that might as well just be regular sockets on the desktop. 0/10
hexo 2y ago
Game over for security.
revskill 2y ago
That means we can connect directly to remote Postgres server from web browser ?
- zamadatix 2y ago
  So long as you do it from an isolated web app rather than normal page.
deleted 2y ago
[deleted]
FpUser 2y ago
All nice and welcome. At what point browser becomes full blown OS with the same functionality and associated vulnerabilities yet still less performant as it sites on top of other OS and goes through more layers. And of course ran and driven by one of the largest privacy invader and spammer of the world
- anilgulecha 2y ago
  > At what point browser becomes full blown OS. Happened over a decade ago - ChromeOS. It's also the birthplace of other similar tech.. webmidi webusb Bluetooth etc.
badgersnake 2y ago
It’s pretty clear Google are building an operating system, not a browser.
- pjmlp 2y ago
  It is called ChromeOS, and its spread is helped by everyone that keeps pushing Electron all of the place.
grishka 2y ago
Can we please stop this feature creep in browsers already?
demarq 2y ago
Something tells me this is more to do with a product Google wants to launch rather than a genuine attempt to further the web. I’ll keep my eyes on this one, see where we are in a year
westurner 2y ago
From "Chrome 130: Direct Sockets API" (2024-09) https://news.ycombinator.com/item?id=41418718 https://news.ycombinator.com/item?id=41418718 : > I can understand FF's position on Direct Sockets [...] Without support for Direct Sockets in Firefox, developers have JSONP, HTTP, WebSockets, and WebRTC. > Typically today, a user must agree to install a package that uses L3 sockets before they're using sockets other than DNS, HTTP, and mDNS. HTTP Signed Exchanges is one way to sign webapps. But HTTP Signed Exchanges is cancelled, so arbitrary code with sockets if one ad network? ... > Mozilla's position is that Direct Sockets would be unsafe and inconsiderate given existing cross-origin expectations FWIU: https://github.com/mozilla/standards-positions/issues/431 https://github.com/mozilla/standards-positions/issues/431 > Direct Sockets API > Permissions Policy: https://wicg.github.io/direct-sockets/#permissions-policy https://wicg.github.io/direct-sockets/#permissions-policy > docs/explainer.md >> Security Considerations : https://github.com/WICG/direct-sockets/blob/main/docs/explainer.md#security-considerations https://github.com/WICG/direct-sockets/blob/main/docs/explai...
deleted 2y ago
[deleted]

200 points by michaelkrem 2y ago

deleted 2y ago

[deleted]

When reading https://github.com/WICG/direct-sockets/blob/main/docs%2Fexplainer.md https://github.com/WICG/direct-sockets/blob/main/docs%2Fexpl..., it's noted this is part of the "isolated web apps" proposal: https://github.com/WICG/isolated-web-apps/blob/main/README.md https://github.com/WICG/isolated-web-apps/blob/main/README.m... , which is important context because the obvious reaction to this is the security nightmare

phildenhoff 2y ago
Interesting — the Firefox team’s response was very negative, but didn’t (in my reading) address use of the API as being part of an otherwise essentially trusted app (as opposed to being an API available to any website). In reading their comments, I also felt the API was a bad idea. Especially when technology like Electron or Tauri exist, which can do those TCP or UDP connections. But IWA serves to displace Electron, I guess
- nzoschke 2y ago
  I'm hacking on a Tauri web app that needs to bridge to talking UDP protocols literally as we speak. While Tauri seems better than ever for cross platform native apps, it's still a huge step to take to allow my web app access to lower level. Rust toolchain, Tauri plugins, sidecar processes, code gen, JSON RPC, all to let my web app talk to my network. Seems great that Chrome continues to bundle these pieces into the browser engine itself. Direct sockets plus WASM could eat a lot of software...
  - 1oooqooq 2y ago
    with so many multiplatform gui toolkits today, tauri and electron are really bad choices
    - montymintypie 2y ago
      What's your recommendation? I've tried so many multiplatform toolkits (including GTK, Qt, wxWidgets, Iced, egui, imgui, and investigated slint and sciter) and nothing has come close to the speed of dev and small final app size of something like Tauri+Svelte.
      - nzoschke 2y ago
        I've also tried Flutter, React Native, Kotlin multiplatform, Wails. I'm landing on Svelte and Tauri too. The other alternative I dabble with is using the Android Studio, XCode to write my own WebView wrappers.
        bpfrh 2y ago
        What did you dislike about kotlin multiplattform?
      - 1oooqooq 2y ago
        of course dev speed will be better with tauri plus the literal ton of JavaScript transpilers we use today. but for us an inhouse egui pile of helpers allow for fast applications that are closer to native speeds. and flutter for mobile (using neither Cupertino or material)
        montymintypie 2y ago
        Glad to hear that egui is working for you, but in my experience it's not accessible, difficult to render accurate text (including emoji and colours), very frustrating to extend inbuilt widgets, and quite verbose. One of my most recent experiences was making a fairly complex app at work in egui, then migrating to tauri because it was such a slog.
- chrismorgan 2y ago
  > but didn’t (in my reading) address use of the API as being part of an otherwise essentially trusted app That’s what the Narrower Applicability section is about <https://github.com/mozilla/standards-positions/issues/431#issuecomment-690860040:~:text=Narrower%20Applicability https://github.com/mozilla/standards-positions/issues/431#is...>. It exposes new vulnerabilities because of IP address reuse across networks, and DNS rebinding.
  - mmis1000 2y ago
    - It is possible, if not likely, that an attacker will control name resolution for a chosen name. This allows them to provide an IP address (or a redirect that uses CNAME or similar) that could enable request forgery. This is quite trival, not even possible though. DNS server is quite a simple protocol. Writing a dns that reflect every request from aaa-bbb-ccc-ddd.domain.test to ip aaa.bbb.ccc.ddd won't take you even for a day. And in fact this already existed in the wild.
- deleted 2y ago
  [deleted]
crote 2y ago
That doesn't really make it any better, if you ask me. The entire Isolated Web Apps proposal is a massive breakdown of the well-established boundaries provided by browsers. Every user understands two things about the internet: 1) check the URL before entering any sensitive data, and 2) don't run random stuff you download. The latter is heavily enforced by both Chrome and Windows complaining quite a bit if you're trying to run downloaded executables - especially unsigned ones. If you follow those two basic things, websites cannot hurt your machine. IWA seems to be turning this upside-down. Chrome is essentially completely bypassing all protections the OS has added, and allowing Magically Flagged Websites to do all sorts of dangerous stuff on your computer. No matter what kind of UX they provide, it is going to be nigh-on impossible to explain to people that websites are now suddenly able to do serious harm to your local network. Browsers should not be involved in this. They are intended to run untrusted code. No browser should be allowed to randomly start executing third-party code as if it is trustworthy, that's not what browsers are for. It's like the FDA suddenly allowing rat poison into food products - provided you inform consumers by adding it to the ingredients list of course.
- apitman 2y ago
  > Every user understands two things about the internet: 1) check the URL before entering any sensitive data, and 2) don't run random stuff you download I think you're severely overestimating the things every user knows.
- girvo 2y ago
  Unfortunately this is the future. Handing the world wide webs future to Google was a mistake, and the only remedy is likely to come from an (unlikely) antitrust breakup or divestment.
  - bloomingkales 2y ago
    I doubt websites as we know it will be what we’ll be dealing with going forward anyways. What is a browser if we just digest all the HTML and spit out clean text in the long run? We handed over something of some value I guess, once upon a time.
  - 2y ago
rty32 2y ago
Have isolated web apps/web bundle gained any traction over the past few years? I just realized that this thing existed and there were some discussions around it -- I almost completely forgot this. I did a search, and most stuff come from a few years ago.
- meiraleal 2y ago
  It is used by chromeOS
  - rty32 2y ago
    You means apps written by Google as "native apps"? Any use cases outside that? If not, it is probably fair to say nobody uses this.
    - meiraleal 2y ago
      A PWA is a IWA so lots of people are using it besides Google
- angra_mainyu 2y ago
  It makes much more sense to bundle a binary + web extension (w/ native messaging) to handle bridging the browser isolation in a sensible manner. It's a minimal amount of extra work and would mean you cross browser isolation in a very controlled manner.

parweb 2y ago

[flagged]

deleted 2y ago
[deleted]
potwinkle 2y ago
Please don't paste unedited AI output as a comment to a discussion.
zzo38computer 2y ago
I also think direct sockets can be helpful. (Note: I did not read the article because it does not work on my computer.) Another use would be for extensions (rather than web pages) to implement other protocols (which is related to item 2 in your list, but different). However, I think that many of these things shouldn't need to use a web browser at all. A web browser is a complicated software and using other software would be better if you are able to do so. This includes ping, traceroute, etc, which can already be handled by other programs (and can be used even if you do not have a web browser installed); but these things may be useful on Chromebook, perhaps; or if you have Chrome 131 but cannot use other software for some reason. For example, a service could be available by some other protocols (e.g. IRC), but also provide a web interface; this can then be one of the implementations of the protocol, so that if the web interface is compatible with your computer but the other provided implementations are not compatible (e.g. because you do not have a suitable operating system, or because you don't want to install extra software but you already have Chrome, etc), then it provides an additional interoperability, without needing too much additional complexity. Handling security is necessary, although there are ways to make it securely: Ask the user first to allow it, and allow the user to configure proxies and restrictions on the use (e.g. if it can only access specific addresses or cannot access specific addresses, or to allow or disallow specific port numbers, etc). (If a SOCKS proxy with localhost can be configured, then the user can use separate software to handle this; the web browser will just need to ensure that it is possible to be configured to not block anything, in case the user is configuring it like this in order to implement their own blocking rules.) A server's web pages should ideally include documentation as well, which allows you to find documentation and use other software (or write your own), if you do not have a compatible web browser or if you do not wish to use the web interface. So, I think that it is helpful, although there are some considerations. (The one about documentation is not really one that the authors of web browsers could easily enforce, and is the kind of problem that many web pages already have anyways, and this can't help.)

modeless 2y ago

I think a lot of people don't realize it's possible to use UDP in browsers today with WebRTC DataChannel. I have a demo of multiplayer Quake III using peer-to-peer UDP here: https://thelongestyard.link/ https://thelongestyard.link/ Direct sockets will have their uses for compatibility with existing applications, but it's possible to do almost any kind of networking you want on the web if you control both sides of the connection.

winrid 2y ago
Runs smoother than the Android home screen. :)
mhitza 2y ago
Longest Yard is my favorite Q3 map, but for some reason I cannot use my mouse (?) in your version of the Quake 3 demo.
- modeless 2y ago
  Interesting, what browser and OS?
  - mhitza 2y ago
    Brave browser (Chromium via Flatpak) on the Steam Deck (Arch Linux) in Desktop mode with bluetooth connected mouse/keyboard.
    - topspin 2y ago
      Same browser on win10. Mouse works after you click in the window and it goes full screen. However, it hangs after a few seconds of game play. Stopped hanging... then input locks up somehow. Switched to chrome on win10, same issue: input locks up after a bit.
      - modeless 2y ago
        Yeah that issue I have seen, but unfortunately haven't been able to debug yet as it isn't very reproducible and usually stops happening under a debugger.

Jiahang 2y ago

nice！

xenator 2y ago

Can't wait to see it working.

revskill 2y ago
Why waiting ? What can you do with it ? Can't wait to wait for you.

bloomingkales 2y ago

Can a browser run a web server with this?

apitman 2y ago
I assume they would limit it to clients.
melchizedek6809 2y ago
Since it allows for accepting incoming TCP connections, this should allow for HTTP servers to run within the browser, although running directly on port 80/443 might not be supported everywhere (can't see it mentioned in the spec, but from what I remember on most *nix systems only root can listen on ports below 1024, though I might be mistaken since it's been a while)
- deleted 2y ago
  [deleted]

deleted 2y ago

[deleted]

fhdsgbbcaA 2y ago

Great fingerprinting vector. Expect nothing less from Google.

Spivak 2y ago

Anything that moves the web closer to its natural end state— the J(S)VM is a win in my book. Making web apps a formally separate thing from pages might do some good for the web overall. We could start thinking about taking away features from the page side.

remram 2y ago
This is beyond that, it's more a move to remove the VM than make JS a generic VM.

mlhpdx 2y ago

I’m excited, and anticipate some interesting innovation once browser applications can “talk UDP”. It’s a long time in the making. Gaming isn’t the end of it — being able to communicate with local network services (hardware) without involving an API intervening is very attractive.

immibis 2y ago
Indeed. I'll finally be able to connect to your router and change your wifi password, all through your browser.
- lazyasciiart 2y ago
  Shhh, you’re giving my parents unrealistic expectations of how much remote tech support I can do.

chrisvenum 2y ago

I found this issue indicating a bad idea for end user safety: https://github.com/mozilla/standards-positions/issues/431 https://github.com/mozilla/standards-positions/issues/431

hoherd 2y ago
Mozilla won't even support webusb[1][2][3] due to security reasons, so there's no way they'd support raw sockets. [1] https://developer.mozilla.org/en-US/docs/Web/API/USB#browser_compatibility https://developer.mozilla.org/en-US/docs/Web/API/USB#browser... [2] https://wiki.mozilla.org/WebAPI/Security/WebUSB https://wiki.mozilla.org/WebAPI/Security/WebUSB [3] https://mozilla.github.io/standards-positions/#webusb https://mozilla.github.io/standards-positions/#webusb

jeswin 2y ago

I prefer web apps to native apps any day. However, web apps are limited by what they can do. But what they can do is not consistent - for example, it can take your picture and listen to your microphone if you give permissions; but it can't open a socket. Another example: Chrome came out with an File System Access API [2] in August; it's fantastic (I am using it) and it allows a class of native apps to be replaced by Web Apps. As a user, I don't mind having to jump through hoops (as a user) and giant warning screens to accept that permission - but I want this ability on the Web Platform. For Web Apps to be able to complete with native apps, we need more flexibility Mozilla. [1] [1]: https://mozilla.github.io/standards-positions/ https://mozilla.github.io/standards-positions/ [2]: https://developer.chrome.com/docs/capabilities/web-apis/file-system-access https://developer.chrome.com/docs/capabilities/web-apis/file...

1oooqooq 2y ago
nah. we need even less. i rather webapps because of the limitations. much less to worry about

deleted 2y ago

[deleted]

kureikain 2y ago

This means that we can finally do gRPC directly from browser.

hipadev23 2y ago

What about WebTransport? I thought that was the http/3 upgrade to WebSockets that supported unreliable and out-of-order messaging

mmis1000 2y ago
I think WebRTC data channels will be a good alternative if you want peer to peer connection. WebTransport is strictly for Client-Server architecture only.

tjoff 2y ago

Great, so now a mis-click and your browser will have a field day infecting your printer, coffee machine and all the other crap that was previously shielded by NAT and/or a firewall.

jeroenhd 2y ago
As long as they don't change the spec, this will only be available to special locally installed apps in enterprise ChromeOS environments. I don't think their latest weird app format is going to make it to other browsers, so this will remain one of those weird Chrome only APIs that nobody uses.
- fensgrim 2y ago
  > special locally installed apps in enterprise ChromeOS environments There was https://developer.chrome.com/docs/apps/overview https://developer.chrome.com/docs/apps/overview though, so this seems to be a kind of planned feature creep after deprecating former one? "Yeah our enterprise partners now totally need this, you see, no reasoning needed"

huqedato 2y ago

Just now, when I have only recently switched permanently to Firefox...

troupo 2y ago

Status of specification: "It is not a W3C Standard nor is it on the W3C Standards Track." Status in Chrome: shipping in 131 Expect people claiming this is a vital standard that Apple is not implementing because they don't want web apps to compete with App Store. Also expect sites like https://whatpwacando.today/ https://whatpwacando.today/ uncritically just include this

meiraleal 2y ago
Expect Apple claiming this is a not vital standard and Apple is not implementing because they don't want web apps to compete with App Store. Also expect sites like https://whatpwacando.today/ https://whatpwacando.today/ to obviously just include this
- troupo 2y ago
  Which part of "is not a w3c standard and not any standards track" do you not understand? I am not surprised sites like that include Chrome-only non-standards, they've done this for years claiming impartiality
  - meiraleal 2y ago
    Cry me a river. Apple doesn't need you to defend their strategic and intentional PWA boycott.
    - troupo 2y ago
      Which part of "is not a w3c standard and not any standards track" do you not understand? Do you understand that for something to become a standard, it needs two independent implementations? And a consensus on API? Do you understand that "not on any standards track" means it's Chrome and only Chrome pushing this? That Firefox isn't interested in this either? Do you understand that blaming Apple for everything is borderline psychotic? And that Chrome implementing something at neck-breaking pace doesn't make it a standard? Here's Mozilla's extensive analysis and conclusion "harmful" that Google sycophants and Apple haters couldn't care less about: https://github.com/mozilla/standards-positions/issues/431#issuecomment-690860040 https://github.com/mozilla/standards-positions/issues/431#is...

pjmlp 2y ago

Yet another small step into ChromeOS take over.

arzig 2y ago

The inner platform effect intensifies.

Asmod4n 2y ago

Thank god they plan to limit this to electron type apps.

sabbaticaldev 2y ago

so with this I would be able to create a server in my desktop web app and sync all my devices using webrtc

tonetheman 2y ago

[dead]

Uptrenda 2y ago

I saw this proposal years ago now and was initially excited about it. But seeing how people envisioned the APIs, usage, etc, made me realize that it was already too locked down. Being able to have something that ran on any browser is the core benefit here. I get that there are security concerns but unfortunately everyone who worked on this was too paranoid and dismissive to design something open (yet secure.) And that's where the proposal is today. A niche feature that might as well just be regular sockets on the desktop. 0/10

hexo 2y ago

Game over for security.

revskill 2y ago

That means we can connect directly to remote Postgres server from web browser ?

zamadatix 2y ago
So long as you do it from an isolated web app rather than normal page.

deleted 2y ago

[deleted]

FpUser 2y ago

All nice and welcome. At what point browser becomes full blown OS with the same functionality and associated vulnerabilities yet still less performant as it sites on top of other OS and goes through more layers. And of course ran and driven by one of the largest privacy invader and spammer of the world

anilgulecha 2y ago
> At what point browser becomes full blown OS. Happened over a decade ago - ChromeOS. It's also the birthplace of other similar tech.. webmidi webusb Bluetooth etc.

badgersnake 2y ago

It’s pretty clear Google are building an operating system, not a browser.

pjmlp 2y ago
It is called ChromeOS, and its spread is helped by everyone that keeps pushing Electron all of the place.

grishka 2y ago

Can we please stop this feature creep in browsers already?

demarq 2y ago

Something tells me this is more to do with a product Google wants to launch rather than a genuine attempt to further the web. I’ll keep my eyes on this one, see where we are in a year

westurner 2y ago

From "Chrome 130: Direct Sockets API" (2024-09) https://news.ycombinator.com/item?id=41418718 https://news.ycombinator.com/item?id=41418718 : > I can understand FF's position on Direct Sockets [...] Without support for Direct Sockets in Firefox, developers have JSONP, HTTP, WebSockets, and WebRTC. > Typically today, a user must agree to install a package that uses L3 sockets before they're using sockets other than DNS, HTTP, and mDNS. HTTP Signed Exchanges is one way to sign webapps. But HTTP Signed Exchanges is cancelled, so arbitrary code with sockets if one ad network? ... > Mozilla's position is that Direct Sockets would be unsafe and inconsiderate given existing cross-origin expectations FWIU: https://github.com/mozilla/standards-positions/issues/431 https://github.com/mozilla/standards-positions/issues/431 > Direct Sockets API > Permissions Policy: https://wicg.github.io/direct-sockets/#permissions-policy https://wicg.github.io/direct-sockets/#permissions-policy > docs/explainer.md >> Security Considerations : https://github.com/WICG/direct-sockets/blob/main/docs/explainer.md#security-considerations https://github.com/WICG/direct-sockets/blob/main/docs/explai...

deleted 2y ago

[deleted]