0

My understanding of a "browser" as a means of consuming software over the web:

  • Browsers isolate web application execution to an environment which greatly reduces end user vulnerability.
  • Browsers provide an approximately standard environment which developers can target with their software.

My understanding of container technologies:

  • Containers isolate software execution.
  • Containers ensure a standard environment.

My curiosities:

  • Could you build a "contained browser" that runs container images as opposed to bundles of JavaScript, WASM, and whatever else you might think to use to run logic on the client?
  • If this is theoretically possible, does it exist already? If it does not exist, why not?

3 Answers3

4

Note that the premise is somewhat flawed. Originally, browsers were tools to navigate a web of linked documents. It seemed desirable to add dynamic content to web documents, and there have been several approaches, such as Java applets or Shockwave Flash scripts.

Today, JavaScript (however you call it) rules, and WASM looks like an interesting alternative. Both need to present a highly abstracted virtual environment to the software running within the browser.

Containers just don't do that, they provide a certain level of isolation and allow to run different userland binaries, but all software running within the container needs to be compatible with the underlying CPU architecture and OS kernel, so they cannot fulfill the portability requirements of web applications.

3

Yes, it would be theoretically possible to combine a browser and a container runner into one.

No, such a combination would not be as useful as you seem to think.

Containers are not intended to be able to run anywhere, but rather they are tied to a particular platform (OS and processor). A container that contains software compiled for Linux on an ARM processor just will not execute under Windows with an Intel processor.

Next to that, containers do not ensure a standard environment, they create a consistent environment by having most of the tools and libraries that an application needs live within the same container.

0

People are already looking at "creating" container systems out of browser technology: https://kubesphere.io/blogs/will-cloud-native-webassembly-replace-docker_/

The difference between the two is how the sandboxing works.

Browsers use a non-native representation of the code (Javascript, Webassembly) which is then JIT-compiled "safely" into native code that will not access outside the bounds it has been given. Note "will not" not "cannot": the code runs in the browser process, so it is not prevented from accessing things by an external mechanism, it's proven by construction and extra checks inserted into the compiled code.

Docker-style containers use virtualization. They do not run inside the parent process, they run isolated using the hardware memory protection features. This is "heavier" and incurs more overhead, but allows faster fully general native code within the isolation boundary.

pjc50
  • 15,223