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?
Direct Sockets API in Chrome 131
141–150 of 171 posts
Re: Direct Sockets API in Chrome 131
#142Earlier 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.
Re: Direct Sockets API in Chrome 131
#143Earlier 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.
Re: Direct Sockets API in Chrome 131
#144Earlier 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.
Re: Direct Sockets API in Chrome 131
#145> 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
#146I found this issue indicating a bad idea for end user safety: https://github.com/mozilla/standards-positions/issues/431
[1] https://developer.mozilla.org/en-US/docs/Web/API/USB#browser...
Re: Direct Sockets API in Chrome 131
#147Earlier 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
Any use cases outside that?
If not, it is probably fair to say nobody uses this.
Re: Direct Sockets API in Chrome 131
#148Earlier 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 "?"
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
#149Earlier 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?
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
#150Earlier 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…
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.