Your web browser running remotely in Cloudflare's cloud. That's it. That's the story Network services giant Cloudflare wants to host your web browser in the cloud so it can send you only safe content. On Thursday, the biz invited customers to sign up for the beta release of its Browser Isolation service, a third component in its evolving Cloudflare for Teams offering that came from S2 Systems, a Kirkland, …
Hmm, yes I agree wholeheartedly with that sentiment.
However, arguably this is slightly different. Open to discussion on this, but as I see it, all the content that comes from outside the LAN perimeter: if it can come through the CloudFlare Browser, then that would be good if CloudFlare acts as gatekeeper. CloudFlare have a vested interest in doing things properly. If there's an outage, either in the cloud or in the WAN connection, then there's no change to what would have happened anyway because the underlying remote site goes through the same channels, with the exception of the final mile at the source end, the bit that goes between the site and CloudFlare. But seeing as a large, and increasing number of sites rely on CloudFlare, that risk is minimal.
The category of browser traffic that will be affected is stuff that doesn't go through the normal channels to be rendered on the local browser, and that is things like local mail servers, NAS boxes and intranet servers.
Perhaps the biggest issue here is session preservation. Is it possible that halfway through a transaction a different session is connected to and data is not served in the correct chronological order? This can cause corruption. But that is an issue regardless of Remote Browser usage anyway, I suppose.
This just seems to be a very very complicated way to essentially implement a dodgy/malware sites blocklist and a (boo, hiss) not allowed by your employer blocklist? Flash and other potentially dodgy browser plugins are all but dead now. All this disassembling the page and rebuilding it, Frankenstein-monster-like, seems an awful lot of hassle, when just blocking the dodgy sites in the first place would surely achieve the same effect more easily?
drawing primitives that are then rendered locally is more X-terminal than VT terminal
The 3270 Model 3279 had GDDM support for host graphics rendered locally in 1979. It supported GKS and PHIGS. Then in 1985 IBM came out with the PC-3270/G, which similarly supported GDDM.
If memory serves, the earliest X terminals came out in 1988, with X11R3.
Of course, there are various differences between GDDM and X, such as the latter's openness and availability from multiple sources. In many ways these "hosted browsers" are more similar to X terminals than they are to the 3270 graphics terminals.
And then there were Sun NeWS and Adobe Display Postscript (both based on Postscript but developed independently). Wikipedia gives 1986 for NeWS and 1987 for DPS.
I assume there were other "graphics terminal" protocols in the late '70s and '80s, though none are coming to mind right now.
Ren: Hey! What is this thing? (tries to pull it off his head) Get it off of me!
Stimpy: It's the Happy Helmet, Ren. Now you'll always be happy! And this is the remote control. And I use this dial to control how happy you are!
Ren: Youuu SICK little monkey! Why I oughta- !
[Stimpy pushes a button on the remote control and Ren freezes as a buzzing sound is heard. His mouth curves into a smile and he tries to fight it. "Flight Of The Bumblebee" plays]
Stimpy: Hey, it works! *pushes the button again.*
Ren: HEY! WHAT'S- HAPPENING- TO ME?!
No, it converts the output of the layout engine into a serialized display list for the renderer, and sends that over the network.
Whether that's a good idea is a separate question (I'm not a fan), and as discussed above it's hardly a new idea, but it is considerably different from sending HTML.
I can see where is could be more useful for those annoying website just don't work if JavaScript is disabled in Noscript. If the JavaScript is running on Cloudflares remote browser and all you are seeing is the rendered output then this allows you to use the website, but still keep your local browser with Noscript enabled. Sinces the JScript is running on the remote machine not your local device.
Even before XMLHttpRequest (AJAX) became a thing around 2000, people had been using techniques like hidden iframes and the like to shovel stuff between the client and server without the hassle of full-page reloads. Naturally, this evolved into 'everything runs client-side' over time. And this naturally evolved into 'all exploits also run client-side' over time.
When JavaScript can be used to spy on what happens in other tabs, or even in the CPU's caches, one has to realise that the 'JavaScript sandbox' is so leaky that there's not a single grain of sand left in it any more.
So what's the solution? Render it server-side, of course!
At least it creates more jobs, I guess?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
