Live data from Hacker News

Direct Sockets API in Chrome 131

chromestatus.com

141–150 of 171 posts

Re: Direct Sockets API in Chrome 131

#141
post #101

Earlier quoted context omitted.

Not happening for 55%. Try to connect to github.com over IPv6.

It doesn't work now so it's never going to work?

If it doesn't work for a website as large as technically forward as GitHub in 2024, the odds are not looking good.

Re: Direct Sockets API in Chrome 131

#142
post #38

Earlier quoted context omitted.

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 tryi…

> If you follow those two basic things, websites cannot hurt your machine. Oh yes they can. Quite a bunch of "helper" apps - printer drivers are a bit notorious IME - open up local HTTP servers, and not all of them enforce CORS properly. Add some RCE or privilege escalation vulnerability in that helper app and you got yourself an 0wn-from-the-browser exploit chain.

How often does that actually happen?

Re: Direct Sockets API in Chrome 131

#143
post #73

Earlier quoted context omitted.

What do you mean not going to happen? It's already happening. It's about 45% of internet packets.

Not happening for 55%. Try to connect to github.com over IPv6.

Yes, that's one of the rare exceptions of a company trying to obsolete itself. It's actually one reason a bunch of people are moving away from Github.

Re: Direct Sockets API in Chrome 131

#144
post #38

Earlier quoted context omitted.

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 tryi…

The last time I used Chrome was about 3 years ago. You have a choice.

Only kind of. If you are on Mac you can use Safari. On Windows your options are Firefox or other versions of Chrome (Edge, Opera, Brave, etc), and Firefox will not work right enough, and it'll drive you to a version of Chrome.

Re: Direct Sockets API in Chrome 131

#145
From "Chrome 130: Direct Sockets API" (2024-09) 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

> Direct Sockets API > Permissions Policy: https://wicg.github.io/direct-sockets/#permissions-policy

> docs/explainer.md >> Security Considerations : https://github.com/WICG/direct-sockets/blob/main/docs/explai...

Re: Direct Sockets API in Chrome 131

#146

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

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...

[2] https://wiki.mozilla.org/WebAPI/Security/WebUSB

[3] https://mozilla.github.io/standards-positions/#webusb

Re: Direct Sockets API in Chrome 131

#147
post #98

Earlier quoted context omitted.

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.

It is used by chromeOS

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.

Re: Direct Sockets API in Chrome 131

#148
post #95

Earlier quoted context omitted.

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 borde…

What part of "cry me a river" you didn't understand? Don't go crazy because at least one of the browsers propose things that move the web forward. Geez, you should take a break from the internet. So many "?"

> Don't go crazy because at least one of the browsers propose things that move the web forward.

No, they shape the web in an image that is beneficial to Google, and Google only.

> Geez, you should take a break from the internet. So many "?"

Indeed, so may "?" because, as you showed, Google sycophants cannot understand why these questions are important.

Re: Direct Sockets API in Chrome 131

#149
post #66

Earlier quoted context omitted.

You can also use WebTransport with streams for tcp and datagramms for udp https://developer.mozilla.org/en-US/docs/Web/API/WebTranspor...

Not peer to peer though presumably?

There was some traction & interest in https://github.com/w3c/p2p-webtransport but haven't seen any activity in a while now.

I'm pretty cocksure certain a whole industry of p2p enthusiasts would spring up building cool new protocols and systems on the web in rapid time if this ever showed up.

Re: Direct Sockets API in Chrome 131

#150
post #95

Earlier quoted context omitted.

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 borde…

There are a lot of reasons why people have such extreme differing opinions on this. I for one, am still salty about the death of WebSQL due to "needing independent implementations". Frankly put, I think that rule is entirely BS and needs to be completely removed. Sure, there is only one implementation of WebSQL (SQLite) but it is extremely well audited, documented and understood. Now that WebSQL is gone, what has the…

> Frankly put, I think that rule is entirely BS and needs to be completely removed.

That's what Google is essentially doing: they put up a "spec", and then just ship their own implementation, all others be damned.

Here's the most egregious example: WebHID https://github.com/mozilla/standards-positions/issues/459

--- start quote ---

- Asked for position on Dec 1, 2020

- One month later, on Jan 4, 2021, received input: this is not even close to being even a draft for a standard

- Two months later, on March 9, 2021, enabled by default and shipped in Chrome 89, and advertised it as fait accompli on web.dev

- Two more months later: added 2669 lines of text, "hey, there's this "standard" that we enabled by default, so we won't be able to change it since people probably already depend on it, why don't you take a look at it?"

--- end quote ---

The requirement to have at least two independent implementations is there to try and prevent this thing exactly: the barreling through of single-vendor or vendor-specific implementations.

Another good example: Constructible Stylesheets https://github.com/WICG/construct-stylesheets/issues/45

Even though several implementations existed, the API was still in flux, and the spec had a trivially reproduced race condition. Despite that, Google said that their own project needed it and shipped it as is, and they wouldn't revert it.

Of course over the course of several years since then they changed/updated the API to reflect consensus, and fixed the race condition.

Again, the process is supposed to make such behavior rare.

What we have instead is Google shitting all over standards processes and people cheering them on because "moving the web forward" or something.

---

As for WebSQL: I'm also sad it didn't become a standard, but ultimately I came to understand and support Mozilla's position. Short version here: https://hacks.mozilla.org/2010/06/beyond-html5-database-apis... Long story here: https://nolanlawson.com/2014/04/26/web-sql-database-in-memor...

There's no actual specification for SQLite. You could say "fuck it, we ship SQLite", but then... which version? Which features would you have enabled? What would be your upgrade path alongside SQLite? etc.

Post reply on HN