Show HN: Cloud browser – headless Chrome and image maps | Hacker News Reader

Show HN: Cloud browser – headless Chrome and image maps

cloudbrowser.website

69 pointsepitactic31 comments

Hello Hacker News, I made this as a quick weekend project after getting inspired by Ian Bicking's _The Firefox Experiments I Would Have Liked To Try_ submission last week, discussed at https://news.ycombinator.com/item?id=19304802. Specifically, the "cloud browser" concept. Also partly inspired by https://html.brow.sh/, but as a text-based browser browsh is much more limited than Cloud Browser.

https://cloudbrowser.website/ runs a headless Google Chrome instance on a VPS, loading a website and taking a screenshot using NodeJS puppeteer. The links are iterated to create an image map, so you can browse (many) websites as normal, but through the cloud. Not all websites work yet, but many do.

Why is this useful? While this is only a simple prototype, it is an experiment in a new way to browse the web which I believe shows promise. Websites have become increasingly complex, heavy on JavaScript and HTML5 features. Cloud Browser pushes this complexity to the cloud, so you can browse websites requiring JavaScript without enabling JavaScript on your end-user browser, for example.

It is still in its incipient stages, but I welcome any feedback/suggestions on how to expand and refine this concept, or better yet, code contributions ;) feel free to fork on GitLab.

Source code: https://gitlab.com/epitactic/cloudbrowser/

Live demo of Cloud Browser loading Hacker News: http://cloudbrowser.website/b/https://news.ycombinator.com/

Static mirror if the VPS is down: https://epitactic.gitlab.io/cloudbrowser/

I made a similar attempt at this a couple years ago, to allow browsing the (JavaScript) web with JavaScript disabled. It works by proxying all traffic through a headless Chrome instance... but a screenshot + an image map is even better.

https://chrome.google.com/webstore/detail/prerendercloud-dis...

https://www.prerender.cloud/

Nice job with prerender.cloud! This looks like about the idea I had, but you took it a lot further, beyond the prototype stage into an actual product.

If you want to borrow the image map idea, feel free :). I'm not planning on developing cloudbrowser.website much further, moving onto other projects, but maybe I'll be a customer.

Wow! When I saw "image map" on the title I thought this can't actually be talking about the HTML image map. Image map reminds me of HTML from the late 90s, and give me a good nostalgia of making personal homepages from that time. With invisible clickable divs, absolute positioning css and what not, it seems like image map has become a thing of the past. I'm guessing the requirement of making it work with no JS took you to the path of using image maps. Neat technique.

I always thought the map element was an underutilized feature. When I was a kid I really enjoyed glorified mazes like the Bone Garden Estate, which inspired me to make my own stateless "games" using MSPaint and HTML.

It didn't really teach me anything about programming, but it seemed like such a novel thing to put hyperlinks on parts of images.

https://web.archive.org/web/20010301200926/http://www.bonega...

Just want to say thanks for bringing this to my attention. I really want to go through it! I was also very surprised the sound effect still works using the <embed> tag!

In retrospect, it's not very good. lol! But when I was 10 years old, the idea of a virtual haunted house(and being able to inspect the HTML) was really cool. I suppose it's one of the things that inspired me to become the web developer I am today.

Indeed, image maps seemed to be the simplest way to implement this, fitting into my goal of reducing the complexity of the content rendered on the web client. I still use CSS, but only in one place (for showing the cached timestamp in the corner). Technically I do use JavaScript, although only for getting the window dimensions, and it is optional.

An absolutely positioned CSS div is an interesting idea, if I recall correctly I actually tried this first, but ran into various problems (with scaling as the page is zoomed in/out, I think) and the image map worked perfectly. area shape="rect" works well as it translates directly from puppeteer's await page $$('a') boundingBox().

This is a fun experiment, but I cannot see the long-term advantage of what you are doing vs VNC (or similar) on the web.

I'm pretty sure it would take less effort and give better results if you just hooked the viewer to something like a guacamole [1] session tethering you to a remote browser.

http://guacamole.apache.org/

This is a good point, honestly I didn't consider it, or know of Guacamole but I agree it could be a better solution.

Looking into it more, maybe noVNC or Guacamole, with VNC or RDP, tethered to a remote browser instance. This would solve the problem of user interaction with the web page, which is currently very limited with Cloud Browser's image maps (hyperlinks only). On the other hand it would increase the end-user browser requirements (image maps date back to HTML 3.2! https://en.wikipedia.org/wiki/Image_map), but still not run the target website's content, so it could be worthwhile and most browsers actively in use now support HTML5.

Firstly: nifty idea, and neat prototype of said idea. :thumbs up:

Second: If my cloud browser has all of my credentials, do I care that my cloud browser is the process that’s pwned instead of my local browser? I think I don’t, so the main benefit would seem to be something like “view a certain static-ish subset of JS-required websites on a device that can’t/won’t run JS”.

What if this service had been set up that you pay for it and when you do so you get an virtual server instance automatically set up. From a security perspective you are running a own virtual private server isolated from the company that provides the software. From a usability point of view everything is spun up via some clever scripts, so you don't have to go through the hazzle of configuring the VPS.

I've been toying with this configuration and think it might be usable for some opensource projects.

Thanks!

That was essentially my envisioned use case, as well. Not only for devices that won't run JS but those where you might not want to. For example, a lot of news websites are surprisingly JavaScript heavy, slow and buggy, not something I necessarily want to run if I merely want to read what the news is talking about. Public read-only sites. Granted, arguably services like outline.com and archive.is already cover this use case better.

As for sites requiring credentials, the way I see it users could run the cloud browser on their own server. This has benefits even for public sites, adding additional privacy. However it is not something this Cloud Browser really supports yet, since there is no support for forms, text fields, or other interactivity with the exception of hyperlinks.

I'm doing a lot of rather JS-calculation heavy projects. Then again a lot of this is leveraging canvases, how well would this approach with that sort of dynamic content.

I'd try for myself, but as I take it you are not doing this on a production scale the HN effect produces a lot of out error messages so I can't really see for my self.

Seems like both the demo and the static mirror are down or suffering from HN hug

The static mirror https://epitactic.gitlab.io/cloudbrowser/ is just a static HTML page + image hosted on GitLab Pages, so it should always be up, but the links there go back to the online demo which was down.

Unfortunately, I'm only hosting the demo on a quad-core 6GB VPS, which frequently runs out of memory. There is a known issue (https://gitlab.com/epitactic/cloudbrowser/issues/2) where old Chrome processes are not cleaned up for some reason. I've restarted the VPS, should be available again for now, for at least a while.

Interesting. As the next step for automated testing, browsing on the cloud browser images can be automated with the kantu browser extension and its image and text recognition features https://a9t9.com/kantu/docs/xclick

Thanks for the link, this Kantu XClick and XMove image-driven "real user simulation" project opens up some interesting possibilities.

It also points out a significant limitation of Cloud Browser's imagemap-based architecture. Screenshotting the page locks away the text behind an image, inaccessible to screen readers, copy and paste, or other interactions. This doesn't seem easy to solve, since the most the img tag offers for accessibility is an "alt" tag, which does not allow specifying which areas of the image contain what text. Sending the actual text (like html.brow.sh) would solve this problem, but then layout is up to the end-user browser again.

Client-side OCR'ing of the image may be a possible alternative, will look into it thanks!

Doing this via images seems... backwards. It's crazy bandwidth-intensive and almost never suits the client. There are other raster-options (SVG would be lighter on bandwidth) but they still don't scale.

So why not just sanitise the DOM? Embed images. Remove script before sending. Add an event listener to send all events back to your server. User clicks, your server emulates and sends back a DOM diff. You'd need to do more work for things like :hover (et al) but it all seems more sustainable than sending full on rasters.

On the surface this reminds me of Opera Turbo[0], but a lot of the details are different. Opera Turbo still seems to rely on the browser to do a lot of what you're suggesting the server should do.

[0] https://www.opera.com/turbo

Sanitizing the DOM is another option, but the main problem I was trying to avoid by taking screenshots is the arms race between the cloud browser and websites, as also seen with ad blockers. A static screenshot in contrast is "up" a level, agnostic to the complex details of rendering an HTML5 website.

Another inspiration is image boards such as 4chan, where screenshots are a very common means of sharing information, including articles on websites, or even tweets. Even though it may not be technically ideal, and annotated text seems like it would be more efficient, in practice images as the lowest-common-denominator seem to be a reasonably effective format for sharing information.

On the other hand, if someone does come up with a true "browser in browser" implementation like you propose, I would be very interested in trying it out. Could be a promising idea, but a lot of work to get right.

I've often wondered if something like this could be used with older browsers on retro platforms to give a rough approximation of a modern browsing experience (without all the ram and cpu time required).

Yes indeed it could, I haven't tested it but according to Wikipedia, image maps were introduced in HTML 3.2, which was published as a W3C recommendation in 1997 (!), so in principle it should work. Maybe even earlier, there was a supplemental RFC for adding client-side image maps to HTML 2.0 published in 1996: https://tools.ietf.org/html/rfc1980 A Proposed Extension to HTML : Client-Side Image Maps.

Cloud Browser does use a few modern features, a bit of CSS and (optional) JS, but not for anything strictly essential. Again I haven't tested it on any old browsers, but if anyone does I welcome bug reports/patches at https://gitlab.com/epitactic/cloudbrowser/issues.

(I wonder if it would work on NCSA Mosaic? https://news.ycombinator.com/item?id=18428682 - well, Mosaic added the img tag, but not sure if imagemap was yet available.)

I've used browserling[1] in the past for similar purposes.

[1]: https://www.browserling.com

What an interesting concept!

What if it sent a DOM string instead of a picture?

The client would need some js, but mostly just click and input handlers. All the heavy JS runs server-side.

One could use v-dom diffing and only send updates to the client to reduce bandwidth.

But that is getting complicated. I really appreciate the simplicity and elegance of using image maps.

Authentic8 Silo is something like this as a commercial product but it is based on Firefox I think.

Thanks for this, found a review of Authentic8 Silo: https://uk.pcmag.com/password-managers/3921/authentic8-silo

Looks like they have been around a while (5+ years), and from their website https://www.authentic8.com, they are focused on the improved endpoint security aspect:

"The Browser for a Zero Trust Web"

> Traditional browsers run on blind trust. Silo assumes zero trust by running the browser in the cloud.

> Web code can’t be trusted. Organizations know that every page view means risk to the business. Silo restores your trust in the web through isolation, control and audit of the browser.

> Isolate: Silo executes all web code on our servers. Nothing touches your endpoint, and untrusted endpoints can’t corrupt your environment or your data.

> Mitigate risk: Shift your attack surface area off your network and devices to disposable, anonymous cloud infrastructure.

I am intrigued, wonder how well they are doing, and how well it works. Somewhat expensive, I've heard $10/month and $100/year for individuals. No online live free demo, but available on request.

With the Epitactic Cloud Browser, I'm only running the VPS temporarily as a demo, the way I envision it end-users can run their own instance either on a home server or virtual server, maintaining control and privacy.

Another one: https://news.ycombinator.com/item?id=18929245

Deepstream.live, sounded like it was neat, unfortunately, seems to now be down. The same poster also posted about webautomation.guru: https://news.ycombinator.com/item?id=18951821 titled "Show HN: Use Chrome Headless in the Cloud from the Browser", similar to mine, but it too is down for me. Looked a lot more advanced than cloudbrowser.website, though!

These remote browser services seem to be difficult to keep running... (expensive if not profitable, I assume. My VPS is good for a few more weeks.)

Does this bypass all known forms of browser fingerprinting?

In the sense that it proxies traffic through the cloud, almost. The target websites won't see your IP address (although I could add a X-Forwarded-For header passing the origin address like archive.is does: http://archive.is/faq - cloudbrowser.website does not currently do this), or other details of your web browser environment.

Almost all metadata is not transferred through. There are two exceptions I can think of:

1) Browser window size. This is actually a significant fingerprinting leak, since desktop users can resize the dimensions of their browser down to the pixel.Cloud Browser uses it to generate an appropriately-sized image, matching the Chrome instance in the cloud to the end-user's browser. Less of a problem with mobile devices where the browser window is fixed, but could help fingerprint the device type.

If you want to avoid this, disabling JavaScript will prevent Cloud Browser from using window.innerWidth, innerHeight, and devicePixelRatio, and it will default to 800x600x1. This may not match your device. The best way to solve this is probably to run your own Cloud Browser instance, configured for what you will browse it from.

Interestingly, Firefox is implementing a "letterboxing" feature, from TorBrowser, to reduce fingerprinting from this technique: https://nakedsecurity.sophos.com/2019/03/08/firefox-browser-...

2) Time of access. The time Cloud Browser accesses a website will be shortly after the end-user accesses the website, as you would expect from a proxy. Could allow some forms of fingerprinting, e.g. work hours, depending your browsing habits, or correlating with other non-cloud website accesses.

If you are concerned about this, Cloud Browser makes it very easy to share the cached pages offline, in a time-independent manner. That is, you can access the files in cache/ offline as needed. The online browser will try to load from the cache first, but automatically refresh with a live version when it is available. But you could setup a cron job to fetch the websites you commonly visit on a fixed schedule, then only browse through the cache while offline, and then websites wouldn't be able to see when you read them.

I've thought about developing this feature further, it could lead to a better user experience, and avoid some of the problems with running Cloud Browser on a VPS. The VPS would be needed for running headless Chrome, but it could upload the static HTML and images as plain files to any static hosting website, for quick and easy browsing. You would need to "subscribe" to the websites you want to visit, and they would have to be periodically refreshed, however.

Reply on news.ycombinator.com