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
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...
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.
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)
It’s not great but there’s just no momentum or resources anywhere to work on native anymore outside platform specific libraries. Few people want to build an app that can only ever run on Mac or Windows.
Many such applications are accessible on the web, often with the exact UI. They may even have a mobile/iPad version. They may be big enough that they have a design system that needs to be applied to in every UI (including company website). Building C++ code on all platforms and running all the tests may be too expensive. The list goes on.
Offering a web app is indeed not trivial. Maybe Qt WebAssembly will be a viable option if I can optimize the binary and users wouldn't mind first long load time (and then the app should be cached for instant load). Or maybe I could build a read-only web app using web technology.
Currently, my focus is building a good native application, and I think most of my users care about that. But in the future, I can see how a web app could be useful for more users. One thing I would like to built is a web browser that could load both QML and HTML files (using regular web engine), so I could simply deploy my app by serving my QML files without the binary over the internet.
That’s what the Narrower Applicability section is about <https://github.com/mozilla/standards-positions/issues/431#is...>. It exposes new vulnerabilities because of IP address reuse across networks, and DNS rebinding.
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.
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.
I think you're severely overestimating the things every user knows.
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.
Nobody handed anything to anyone. They go with the flow. The flow is driven by people who use their products. The browser is how Google delivers their products so it’s kinda difficult to blame them for trying to push the envelope but there are alternatives to Chrome.
The ancient history of just 10-15 years ago shows Google aggressively marketing Chrome across all of its not inconsiderable properties like search and Youtube, and sabotaging other browsers while they were at it: https://archive.is/2019.04.15-165942/https://twitter.com/joh...
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.
I did a search, and most stuff come from a few years ago.
Any use cases outside that?
If not, it is probably fair to say nobody uses this.
It's a minimal amount of extra work and would mean you cross browser isolation in a very controlled manner.
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.
Stopped hanging... then input locks up somehow.
Switched to chrome on win10, same issue: input locks up after a bit.
Talk about getting nerd sniped.
https://gooberdash.winterpixel.io/
tbh the WebRTC performance is basically the same network performance as websockets and was way more complicated to implement. Maybe the webrtc perf is better in other parts of the world or something...
Edit: Very cool game! I love instant loading web games and yours seems very polished and fun to play. Has the web version been profitable, or is most of your revenue from the app stores? I wish I better understood the reasons web games (reportedly) struggle to monetize.
That said, I agree that peer to peer will never be seemless thanks mostly to said abusive isps.
If some ISPs are not currently firewalling all incoming IPv6 connections, it's a major security risk. I hope some security researcher raises boise about that soon, and the firewalls will go closed by default.
Firewalling goes back in the control of the user in most cases - the other day we on IRC told someone how to unblock port 80 on their home router.
It became a problem precisely the moment AWS starting charging for ipv4 addresses.
"IPv4 will cost our company X dollars in 2026, supporting IPv6 by 2026 will cost Y dollars, a Z% saving"
There's now a tangible motivator for various corporate systems to at least support ipv6 everywhere - which was the real ipv6 impediment.
Residential ISP appear to be very capable of moving to v6, there are lots of examples of that happening in their backends, and they've demonstrated already that they're plenty capable of giving end users boxes the just so happen to do ipv6.
Most people are probably using ELB anyway
Try to connect to github.com over IPv6.
https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address...
Most people are probably using ELB anyway.
No NAT, sure, that's great. But no firewalls? That's not great. Lots of misconfigured networks waiting for the right malware to come by...
In fact runtimes like Node, Deno, Cloudflare Workers, Fastly Compute, Bun et al run JS on servers, and will benefit from standardization of such features.
[WICG] aims to provide a space for JavaScript runtimes to collaborate on API interoperability. We focus on documenting and improving interoperability of web platform APIs across runtimes (especially non-browser ones).
So, for instance if I want to connect to an mqtt server from a webpage I have to use a server that supports websocket endpoint. With direct sockets I could connect to any server using any protocol
With direct socket access to TCP/UDP you can build anything! You loose the constraint of JS servers, costly WebRTC server hosting, and lack of listen sockets feature in WebRTC DataChannel.
<self promotion>NAT puncturing is already solved in our lab, even for mobile 4G/5G. This might bring back the cyberpunk dreams of Peer2Peer... In our lab we bought 40+ SIM cards for the big EU 4G/5G networks and got the carrier-grade NAT puncturing working[1]. Demo blends 4G/5G puncturing, TikTok-style streaming, and Bittorrent content backend. Reading the docs, these "isolated" Web Apps can even do SMTP STARTTLS, IMAP STARTTLS and POP STLS. wow!
[0] https://github.com/WICG/direct-sockets/blob/main/docs/explai... [1] https://repository.tudelft.nl/record/uuid:cf27f6d4-ca0b-4e20...
Here's a link to an over-view for my system: https://p2pd.readthedocs.io/en/latest/p2p/connect.html
My system can't handle symmetric --- symmetric. But could in theory handle other types of NATs ---- symmetric. Depending on the exact NAT types and delta types.
...with the help of the birthday paradox. Rather than open 1 port on the hard side and have the easy side try 65,535 possibilities, let’s open, say, 256 ports on the hard side (by having 256 sockets sending to the easy side's ip:port), and have the easy side probe target ports at random.We added specific 4G and 5G mobile features. these carrier-grade boxes have often non-random port allocations. "By relying on provider-aware IPv4 range allocations, provider-aware port prediction heuristics, high bandwidth probing, and the birthday paradox we can successfully bypass even symmetric NATs."
> We utilise parallelism by opening at least 500 Internet datagram sockets on two devices. By relying on provider-aware IPv4 range allocations, provider-aware port prediction heuristics, high bandwidth probing, and the birthday paradox we can successfully bypass even symmetric NATs.
U mad. Love it!
Plus, it only works if you can afford and have access to cell service, and in those cases you or have access to normal Internet stuff.
Unless cell towers are able to route between two phones when their fiber backend goes down. That would make this actually pretty useful in emergencies if a rower could work like a ham repeater, assuming it wasn't too clogged with traffic to have a chance.
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.
https://developer.mozilla.org/en-US/docs/Web/API/WebTranspor...
I haven't tinkered with it yet though.
I ask because I've spent multiple days trying to get a viable non-local WebRTC connection going with no luck.
view-source:https://thelongestyard.link/q3a-demo/?server=Seveja
The code is here: https://github.com/jdarpinian/ioq3 and here: https://github.com/jdarpinian/HumbleNet. For example, here is the file where the RTCPeerConnection is created: https://github.com/jdarpinian/HumbleNet/blob/master/src/humb...
I feel your pain. WebRTC is extremely difficult to use.
It won't work completely offline unfortunately, as the server is required for the connection establishment step in WebRTC. A peer-to-peer protocol for connection establishment on offline LANs would be awesome, but understandably low priority for browsers. The feature set of WebRTC is basically "whatever Google Meet needs" and then maybe a couple other things if you're lucky.
Direct sockets will be amazing for IoT, because it will let you talk directly to devices.
With service workers you can make stuff that works 100% offline other than the initial setup.
Assuming anyone uses it and we don't just all forget it exists, because FF and Safari probably won't support it.
[1] https://developer.mozilla.org/en-US/docs/Web/API/USB#browser...
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/ [2]: https://developer.chrome.com/docs/capabilities/web-apis/file...
There was 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"
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/ uncritically just include this
I am not surprised sites like that include Chrome-only non-standards, they've done this for years claiming impartiality
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#is...
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.
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 standards committee done to replace it? Well, now they suggest using IndexedDB or bringing your own SQLite binary using WASM.
IndexedDB is very low level, which is why almost no one uses it directly. And it also has garbage performance, to the point where it's literally faster for you run SQLite on top of IndexedDB instead: https://jlongster.com/future-sql-web
So ultimately if you want to have any data storage on the web that isn't just key-value, you now have to ship your own SQLite binary or use some custom JS storage library.
So end users now have to download a giant binary blob, that is also completely unauditable. And now that there is no standard storage solution, everybody uses a slew of different libraries to try to emulate SQL/NoSQL storage. And this storage is emulated on top of IndexedDB/LocalStorage so they are all trying to mangle high level data into key-value storage so it ends up being incredibly difficult to inspect as an end-user.
As a reminder: when the standards committee fails to create a good standard, the result is not "everybody doesn't do this because there is no standard", it is "everybody will still do this but they will do it 1 million different ways".
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.
Happened over a decade ago - ChromeOS. It's also the birthplace of other similar tech.. webmidi webusb Bluetooth etc.
I’ll keep my eyes on this one, see where we are in a year
> 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...