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 Answers 3

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.

2
  • Re: "containers provide a certain level of isolation..." What if you had a container within which your containers would run? Could this serve as a target architecture and OS?
    – lmonninger
    Dec 8, 2021 at 16:57
  • No, the container does not virtualize CPU and kernel, so containers within containers would share the host CPU and kernel. Dec 8, 2021 at 20:50
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.

3
  • Technically, I understand them to be tied to a particular 'kernel', but perhaps that's what you mean by OS here. Most people would consider e.g. Alpine and Ubuntu to be different operating systems.
    – JimmyJames
    Dec 8, 2021 at 16:19
  • I asked this to Hans as well. But, could this not-intended to-be-able-to-run-anywhere problem be resolved if the browser was run in a container itself? Could I enforce a standard environment using container consistency?
    – lmonninger
    Dec 8, 2021 at 17:01
  • @lmonninger, a container does not provide processor emulation, so how do you see my application that is compiled to ARM instructions to run on your Intel processor? Dec 8, 2021 at 20:50
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.

3
  • I think there is a little confusion about what the blog post is talking about - or a confusion about this question on my part. They are not talking about using containers in web browsers. They appear to be talking about using WASM as a technology that containers can use - the dependency in reversed. The container can run WASM code, not "the browser can run containers." Dec 8, 2021 at 16:05
  • Greg is right, but the last two paragraphs are insightful, so I'm not downvoting. Faster and fully general native code is what I'm interested in as the outcome of this kind of technology. "Heavier" is fine, but do you think it would be "too heavy" some how?
    – lmonninger
    Dec 8, 2021 at 17:12
  • To be specific, if you had a VM-style container (required to run fully general native code unmodified), then it would have to be not only in a separate process from the browser and its DOM but also cross that security barrier twice for every DOM call. stackoverflow.com/questions/21887797/… ; this is before you consider additional SPECTRE mitigations and that kind of thing.
    – pjc50
    Dec 9, 2021 at 9:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.