1365019 - Have containers isolate more things, like extensions

Status: NEW

(Core :: DOM: Security, enhancement, P3)

Description

[James Newton]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.81 Safari/537.36

Steps to reproduce:

It would be great if containers could isolate the container from extensions. Make it configurable to allow the user to choose which extensions are allowed.

Comment 1

[James Newton]

And to add on, flipping the disallowing of extensions, make it so proxy extensions (like foxyproxy) can be set to proxy all pages for a given container. I'm sure there are other use cases too.

Comment 2

[Christoph Kerschbaumer [:ckerschb]]

Jonathan, what do you think about that? Is that reasonable? If so, please add it in the backlog. If not, please feel free to WONTFIX this one.

Comment 3

[Daniel Veditz [:dveditz]]

We have exposed container information to web extensions and expect them to handle containered content correctly. The feature was designed to isolate sites from each other not from the browser, and we consider extensions to be extensions of the browser. What is your use-case here for isolating particular sites from an extension you otherwise trust? (If you don't trust an extension you should not install it.)

Comment 4

[Jonathan Kingston [:jkt] he/him]

I think we have a bug for this, needinfoing myself to find.

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/contextualIdentities is the API that we expose that would allow doing container specific changed. A tab can also be queried based upon cookieStoreId too, which is how we isolate containers.

Comment 5

[Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧]

(In reply to Daniel Veditz [:dveditz] from comment #3)
> We have exposed container information to web extensions and expect them to
> handle containered content correctly. The feature was designed to isolate
> sites from each other not from the browser, and we consider extensions to be
> extensions of the browser.

Should we?  XPCOM add-ons have to be trusted at the same level as the browser itself, but WebExtensions can be given more limited permissions, as I understand it.

> What is your use-case here for isolating
> particular sites from an extension you otherwise trust? (If you don't trust
> an extension you should not install it.)

Trusting an extension enough to let it intervene in browsing cat pictures doesn't imply trusting it enough to let it potentially access your banking, for example.

Chrome already has something vaguely like this: you have to opt-in, per extension, to let the extension access Incognito tabs, and then the UI warns you that the extension could record browsing history.  Containers aren't the same thing as Private Browsing, of course, but they're similar in that they can have different levels of concern about privacy/security.


We still might choose not to implement this, but I don't think it's inherently meaningless.

Comment 6

[Jonathan Kingston [:jkt] he/him]

Hey Andy,
I'm aware this won't be a priority for your team however would it be something that you might ever consider?

The separation to me seems like it might not be hard however I'm not exactly sure how you would manage permissions.

My first thought would be:

- extensions could request to manage which extensions can see what with a permission "contextualIdentitiesManagement".
  - this extension could then force a extension-by-extension block on global access to containers content
  - extensions with this permission would never have a block themselves
- other extensions that require URL matching permissions would then only match for the restricted containers they can use

What do you think?

Issues I see are:
- Race conditions on the restriction which I don't see an obvious way to fix.
- New extensions not being managed correctly

bikeshed:

let extensions = await browser.management.getAll();
extensions.forEach((extension) => {
  browser.contextualIdentities.manage.restrict(extension.id, ["firefox-container-1"]);
});

Comment 7

[Andy McKay]

I think there's something that could be done here. There's an interesting overlap with permissions that would possibly get confusing. For example: an extension asks for <all_urls> but then you limit it down by container... 

I would prioritize getting better private browsing over this though.

Comment 8

[Firefox Bug Husbandry Bot]

Bulk change per https://bugzilla.mozilla.org/show_bug.cgi?id=1401020

Comment 9

[Jeff Mitchell]

Chiming in with my use-case:

While some of my extensions (such as a password manager) I do indeed want to have available in all contexts, some other extensions require signing in with an account that I'm trying to limit to a particular container. For example, Pushbullet requires a Google account to log in. I normally have my Google account in my "Personal" container, but I can't tell the Pushbullet extension that -- so I have to log into Google with the default container, authorize Pushbullet, then log out of the default container -- except Pushbullet is still running in the context of the default container, so there's a real leak if information here in multiple places.

Comment 11

[Dan Harkless]

The use-case that got me here was learning of the Honey extension. I wouldn't mind turning this thing on for one or more containers dedicated to online shopping, but I wouldn't be comfortable letting it watch all my web browsing while it looks for places to insert coupon codes.

Comment 12

[online-services]

Just to add, I'm also experiencing the 'Pushbullet' issue. It's something I want to have running but in order to access it you have to log in with either a Google or Facebook account and the extension seems to run in the default/global container-space, hence the cookies are going to be visible for any site that isn't explicitly opened in a defined container.

These are the two sets of cookies I most want to keep locked away in a 'personal' container so to have either of them in the global/default space isn't at all desirable.

I can of course log out of Google in the default space after the Pushbullet extension login has been completed but I am worried that there's still some traceable cookies there (or maybe they are deleted upon logging out, I don't know enough about cookies to say). It'd be great if there was a way to specify that a given extension (Pushbullet in this case) logged in and ran under a specified container ('personal', in this case).

Comment 13

[mozillabugzilla]

Another use case. I have many web accessibility testing addons installed. I keep them disabled until I want to actually use them to test a site solely to not use up RAM but also to keep the browser uncluttered. Being able to have a separate container would save a lot of time enabling/disabling these addons when needed.

Comment 14

[GabrielaS]

For me there are several reasons to allow certain extensions only in specified containers.

Limit "misbehaving" add-on: There's that one add-on SLP (SnapLinksPlus) that I can't do without. It works as a charm everywhere, except for a minor bug it shows on our CMS's site (it drops a small snippet of garbage code into text fields when rightclicking). I already have a separate container for our CMS. It would be great if I could disable this add-on just in this container.

Troubleshoot websites & extensions: Let's say a webpage doesn't work as expected. After contacting their support, they say it must be one of your extensions. So you need a container, in which you can disable one extension after the other to point the culprit. Without affecting other containers you are working with.

Compare "competing" add-ons: Let's say you want to side-by-side compare the behaviour or results of extensions that promise to do the same thing, might that be an ad blocker, script blocker or any greasemonkey-ish extension. With that feature in containers, you could activate AddOn1 in Container1 and AddOn2 in Container2 only.

Environment with no extensions: For everyday surfing you might have several add-ons activated that change the look of a website, by eliminating ads, changing styles and other stuff. But sometimes you'd like to see a page in its original form, without any add-ons enabled.

There are plenty of usecases for optionally activating/deactivating extensions in containers. I'd definitely use that feature if it existed.

Comment 15

[jmozbu]

Not sure it's ok, I'm new here :) but let me add one more use case:

I use a "work" container for, well, work related stuff. I use one password manager for work and another privately. I would like each password manager extension loaded by itself in the work and personal containers so they don't "compete" for auto-fill, etc.

Comment 16

[tom]

(In reply to Andy McKay from comment #7)

I would prioritize getting better private browsing over this though.

Unfortunately ,I don't see private browsing as a convenient enough workaround. I want to be able to use one browser and one profile for both work and personal stuff, and have my history, etc remembered for convenience (of course I can clear it out from time to time if needsbe).

I say work and personal because similar to some folks above, I want a container where I can have all my developer extensions (which need unfettered access to all websites/data) enabled, but disabled in all other containers, so that I don't have to keep switching them on and off to maintain the privacy of my other containers (banking, shopping, personal, etc).

Comment 17

[08xjcec48]

Please add this to the "See Also" field: https://connect.mozilla.org/t5/ideas/restrict-extensions-to-containers-exclude-extensions-from/idi-p/12041

Comment 18

[John Veysey]

Chiming in to up the thread (following since 2018). The use cases remain well-documented here and in the connect.mozilla thread. I evaluate extensions differently in terms of trust and risk when it comes to my banking and my shopping.

With TCP containers are not as important as they once were. This would be a valuable enhancement and a firefox differentiator.

Comment 19

[Mr Beedell, Roke Julian Lockhart [:B.RJL]]

I support this, although the WebExtension access restrictions should be disabled by default. I shall want to restrict my WE access in few containers, as the majority are best served with my standard WE cohort.