
Show HN: Cloud browser – headless Chrome and image maps - epitactic
https://cloudbrowser.website/
======
epitactic
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](https://news.ycombinator.com/item?id=19304802).
Specifically, the "cloud browser" concept. Also partly inspired by
[https://html.brow.sh/](https://html.brow.sh/), but as a text-based browser
browsh is much more limited than Cloud Browser.

[https://cloudbrowser.website/](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/](https://gitlab.com/epitactic/cloudbrowser/)

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

Static mirror if the VPS is down:
[https://epitactic.gitlab.io/cloudbrowser/](https://epitactic.gitlab.io/cloudbrowser/)

~~~
godot
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.

~~~
ravenstine
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...](https://web.archive.org/web/20010301200926/http://www.bonegarden.com/)

~~~
petercooper
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!

~~~
ravenstine
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.

------
oliwarner
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.

~~~
epitactic
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.

------
jamesu
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).

~~~
epitactic
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](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](https://gitlab.com/epitactic/cloudbrowser/issues).

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

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

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

------
ficklepickle
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.

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

~~~
epitactic
Thanks for this, found a review of Authentic8 Silo:
[https://uk.pcmag.com/password-
managers/3921/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](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.

------
sansnomme
Another one:
[https://news.ycombinator.com/item?id=18929245](https://news.ycombinator.com/item?id=18929245)

~~~
epitactic
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](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.)

------
andridk
Does this bypass all known forms of browser fingerprinting?

~~~
epitactic
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](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-...](https://nakedsecurity.sophos.com/2019/03/08/firefox-browser-
picks-up-advertiser-dodging-tech-from-tor/)

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.

