Slashdot Mirror
Smarter Clients Via ReverseHTTP and WebSockets
igrigorik writes "Most web applications are built with the assumption that the client / browser is 'dumb,' which places all the scalability requirements and load on the server. We've built a number of crutches in the form of Cache headers, ETags, and accelerators, but none has fundamentally solved the problem. As a thought experiment: what if the browser also contained a Web server? A look at some of the emerging trends and solutions: HTML 5 WebSocket API and ReverseHTTP."
A problem that I can see is that web browsers already contain enough security holes, imagine if they contained a web server ;-)
Everything I write is lies, read between the lines.
Ah, but the young 'uns have forgotten that anybody did anything before they came along. So "the network" is synonymous with "the web" and if you want to send any information it better be over HTTP. So bidirectional HTTP means you can communicate in both directions!
Next they're going to figure out that if you move the web app out of the browser you can have a much richer GUI experience.
I actually do think that NATs have been a boon to end-user security, more so than firewalls would have been, because they created a (relatively) consistent ruleset that software developers were then forced to accommodate. Hear me out.
Imagine an alternate universe where IP6 was rolled out before before broadband, and there was never any technical need for NAT. In that case the consumer routers would have all come with firewalls rather than NAT. First off it is very possible that router manufacturers would have shipped these with the firewall off to avoid confusion and misplaced blame: "I can't connect to the internet, this thing must be broken". If they were enabled by default, with common ports opened up, there would still be applications (server and P2P) that would need to have incoming ports manually configured to be open in order to work. Most users wouldn't be able to figure this out, and the common advice between users would become "If it doesn't work disable the firewall".
And the fact of the matter is that requiring a novice user to configure his router just to use an application is not a good approach. There needs to be some sane form of auto-configuration. Even if the firewall tried to implement this internally, you would run into problems with different "smart firewalls" behaving differently, which would create even more headache for application developers.
With NAT you have the same problem in that manually configuring port forwarding is confusing to users. The difference is that there is no option to disable NAT. So it became the application developers' problem by necessity, and this is a good thing, because they are better suited to handle technical problems than the end user is. It was a major pain in the ass, but eventually all the router manufactures all settled on similar heuristics on how to fill the NAT table based on previous traffic, and we learned strategies to initiate P2P traffic that didn't require user intervention.
In end, default behavior of NAT (outgoing traffic always allowed, incoming only in response to outgoing) gave us the auto-configuration ability that we needed, and the result was something much more secure than would have existed if the firewall was optional.