Answer: a browser was for traversing hypertext documents. UDP basically is not good for this.
Now a browser is just an abstracted operating system. So, fuck it, I guess, let's add a second TCP/IP stack.
Now a browser is just an abstracted operating system. So, fuck it, I guess, let's add a second TCP/IP stack.
The browser is used for all these things; why not have a protocol that works for these scenarios?
(Client<->Server; WebRTC and ObjectRTC are p2p orientated and excessively complex due to this as discussed in article)
That desktop OSes happen to be called "desktop OSes" and web browsers happen to be called "web browsers" is fairly irrelevant to what they're actually good at. Desktop OSes make great hardware abstraction layers, just as server OSes make great hardware abstraction layers for virtualization platforms. But they're fundamentally misdesigned for much of anything else.
A video game on the average Windows, Mac, or Linux desktop has full read and write access to the memory of a tax app on the same desktop
I can read /proc/$PID/mem provided my UID = the effective UID of the process.
Or I can also use ptrace(), again if my UID = the effective UID of the process, both to read the processes' memory and even to modify its code at runtime.
(Some LSMs will block this...)
You run each program as a different user account. The HTTP daemon doesn't run as the same user as the DNS daemon even if they're on the same machine.
This is obviously annoying on a desktop because you have to use user switching to use another app. It would be better if desktop operating systems provided native support for it so that user accounts had a sub-account per app and apps automatically ran like that, and then a permission prompt if one app tries to access another app's files, which you can grant as one-time access or permanently.
Then you expect your email program to try to access a document you're attaching to an email, but if a video game tries to read your tax returns you can be appropriately suspicious.
The interface between a web page and the outside world allows it to do things like access its site and not others, request a particular file be opened, send structured messages to other sites that wish to opt in to such access, etc.
The interface between a process and the outside world gives it either TCP sockets on behalf of the machine, or nothing at all; either the ability to open any file as the current user, or nothing at all.
I used to be excited about proposals for desktop operating systems to provide sandboxing via multiple UIDs and native interfaces for passing files around and powerboxes and all of that good stuff. Then I realized that the web platform does all of that and is very widely adopted and well-tested, and there's no hope of the existing platforms catching up.
I used to have two user accounts, one of which was allowed to run the Flash plugin so I could listen to music, and one of which held my important work. Then the web folks figured out how to sandbox the Flash plugin without requiring me to Ctrl-Alt-F8 to pause a song. Then they figured out how to not use a native-code plugin at all.
I don't particularly like this conclusion in an abstract sense, but it's certainly let me get on with getting things done instead of hoping for a future that will never come.