5 ms·
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
by peterwwillis 10y ago
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.
- poop_cicle 10y agoNaivety here is appalling.
- benaadams 10y agoMore like TCP/IP is not good for data where only the current state is relevant and old state can be discarded: live video, games, stock prices... 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)
- fulafel 10y agoSince the P2P feature set is a superset of the client-server feature set, it would only increase complexity in the browser to add another protocol for the client-server feature set.
- dragonshed 10y agoObjectRTC? That's a new one..
- geofft 10y agoThe browser is a much better multi-user operating system than the actual operating systems people tend to use. 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, defeating the entire point of memory protection. If the game and the tax app are in a browser (or in a mobile OS, to their credit), this isn't so. 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.
- grumpynumpy 10y agoA 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 What? No...
- richardwhiuk 10y agoNot the in process memory, but yes to the stored data, which is arguably as bad.
- skissane 10y agoOn Linux, generally speaking yes to reading the in-process memory too. 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...)
- felixgallo 10y agoWhat? No...
- ReverseCold 10y agoMany games on Windows even ask for administrator to run (or update), so that's already game over from a security perspective.
- fulafel 10y agoDebugging APIs.
- AnthonyMouse 10y agoDesktop operating systems have the capacity to do this; "server operating systems" (which are just desktop operating systems configured differently) already do 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.