Restrict extensions to containers / Exclude extensions from containers

[Zocker1999NET]

Extensions (or add-ons) are great to enhance the web experience, but entrusting them with access to the content of all websites I visit (if the features of those require it) is a little bit too much. Some extensions can already solve that: Extensions which only want to modify e.g. YouTube do not need "Access [to] your data for all websites". But other extensions should be possible to use on all webpages, e.g. extensions replacing/blocking "bad words", translating extensions or extensions, which should work with self-hostable instances of services (GitLab, Phabricator, Nitter, …). They cannot easily restrict themselves to some domains (e.g. the official variants) because that would also restrict their use. But, most of the time, such extensions cannot & should not be able to see my whole history or access data when I'm using online banking.

Using different Firefox profiles is a way to solve that problem, but it is not easily usable because switching between these sessions is not easy. However, it is easy & user-friendly & automatable to work with containers, e.g. I can assign certain domains to certain containers so visiting them automatically switches to or suggests  the assigned container. And already are containers used to enhance security & privacy. By allowing users to restrict extensions to certain containers, I can easily configure which extensions should be able to modify which website(s), either special selected ones or I can easily switch to a certain container to enable more not-so-trusted extensions if I need to. And by allowing to exclude some or not explicitly selected extensions from certain containers, I can increase the security of online shopping / banking services because fewer extensions would have access to the data of those.

This would make it easier for users to trust extensions which need the "Access your data for all websites" permission because I would not be required to give them access to all unconditionally.

[aaj]

I would also like to have this feature -- specifically so that I can run certain password managers only on my work container, while my personal container uses a different manager.

[DesertBaron]

Feature Request: Allow container specfic extensions.

I would like to request the ability to enable extensions on a per-container basis rather than applying them globally. Currently, extensions are tied to the overall environment, which limits flexibility when working with multiple containers that serve different purposes.

Allowing container-specific extensions would provide several benefits:

• Isolation of functionality: Developers could tailor extensions to the unique requirements of each container without introducing unnecessary overhead or conflicts in others.

• Improved performance: Containers would only load the extensions they actually need, reducing resource usage and startup times.

• Enhanced maintainability: Teams could better manage dependencies by keeping extensions scoped to the container they are relevant to, simplifying troubleshooting and updates.

• Greater flexibility: This would support diverse workflows, such as running lightweight containers for testing while maintaining fully equipped containers for development. 

This feature would make containerized environments more efficient, customizable, and aligned with real-world development practices. I'm sure it has been requested before, im not a browser developer so im not sure if its even possible. If it isn't possible i do apologize.

Thanks for reading! 😃

[Jon]

(Note: similar ideas have been merged into this thread)

[alaskacanyon]

Running Extensions in Isolated Containers: A Security-First Approach

The idea of executing browser extensions inside isolated containers represents a major leap forward in user security and system integrity. Traditionally, extensions run within the browser's process space, often with broad access to tabs, cookies, local storage, and even system resources. While convenient, this model exposes users to significant risks—especially when extensions are poorly maintained, vulnerable, or malicious.

By shifting extension execution into lightweight containers, each extension becomes a self-contained process with tightly scoped permissions. These containers can be spun up only when needed—activated alongside specific browser sessions or tasks—and automatically shut down when no longer in use. This ephemeral lifecycle dramatically reduces the attack surface.
🔐 Security Benefits

Isolation by Design: Containers provide process-level separation, preventing extensions from accessing browser internals or other extensions.
Granular Resource Control: Using container runtimes like Docker or Firecracker, developers can restrict CPU, memory, and network access per extension.
Zero Persistence: Once the container shuts down, all volatile data is wiped—eliminating lingering threats or data leaks.
Dynamic Trust Boundaries: Extensions can be sandboxed based on origin, behavior, or user-defined policies, allowing for adaptive security.
Defense Against Supply Chain Attacks: Even if an extension is compromised, its containerized environment limits the blast radius.

This model aligns with modern security principles like zero trust and least privilege, offering users peace of mind without sacrificing functionality. It also opens the door to new extension architectures—where extensions can be written in any language, run in isolated environments, and communicate with the browser via secure APIs.

In short, containerized extensions could redefine how we think about browser customization—making it safer, smarter, and more resilient.

[Jon]

(Note: similar ideas have been merged into this thread)