Incognito & Container Support

[erosman]

Incognito & Container Support

Support can be added for Firefox only.
See also: #27

User Interface

Incognito can be supported without any issues. However to support containers as well. there are 2 options for the User Interface:

1. Generic User Interface

Use a generic container list, not knowing or matching the number of containers the user has e.g.

• Incognito
• Container 1
• Container 2
• Container 3
• Container 4

2. Specific User Interface

Get the container list contextualIdentities.query() and create the UI

• contextualIdentities

  To use this API you need to include the "contextualIdentities" and "cookies" permissions in your manifest.json file.

• Adding "contextualIdentities" permission automatically enables containers in Firefox which is undesirable to users who don't want to use containers
• "contextualIdentities" permission is not available as an optional_permissions
• See also: Bug 1386673: Make Contextual Identity extensions be an optional permission

Implementation

• Incognito/Containers can be set to a specific proxy (not patterns or PAC URL)
• Incognito/Container settings will have precedence over other settings (except Tab Proxy)

The checking order would be:

1. Tab Proxy
2. Incognito/Container Proxy
3. Check for "Disable" mode
4. Global Exclude
5. PAC URL
6. Proxy by Patterns or Individual Proxy

To decide

• Should "Disable" disable everything?
• Should Tab Proxy be independent of "Disable" since it has its own independent on/off?
• Should Incognito/Container Proxy be independent of "Disable"?

Sync and Preferences: Import/Export

Container settings may mismatch, if the user has different containers on different browsers.

[erosman]

FoxyProxy v8.1 includes incognito & container support for Firefox only.
The Log is also updated to include incognito & container details.

The feature is still under consideration and development.

[pmarks-net]

The Incognito feature doesn't seem to do anything on Firefox 118. Here's what I tried:

• Copy manifest-firefox.json to manifest.json
• Load manifest.json from about:debugging
• Run in Private Windows > Allow
• Proxies > add 10.2.2.1, SOCKS5, 1080
• Options > Incognito > 10.2.2.1:1080
  
• Open a private window
• https://ifconfig.me/ still shows non-proxied IP address
• Click FoxyProxy icon > 10.2.2.1:1080
• https://ifconfig.me/ shows proxied IP address (but this affects regular tabs too)

[erosman]

I have uploaded the under-development v8.1 for another issue (#35). Therefore, the incognito & container is not finalised yet.

Update
Found the issue and updated the repo

[erosman]

Please limit the discussion to Incognito & Container Support in this topic.

[ntninja]

Feedback about this new option:

1. It looks like a promising way of consolidating the current “Container Proxy” + “FoxyProxy Standard” setup into just using FoxyProxy!
2. The fact that the UI just shows Container 1 – 4 instead of names really looks like a bug at first glance and the reasoning behind should be explained then and there
3. Unfortunately, we have a setup with more than 4 containers in total and one of the containers that needs to be set up to use a proxy happens to not be configurable using the current UI so using just FoxyProxy is infeasible
   • Assuming FoxyProxy won’t somehow gain the ability to find out the total number of containers maybe some kind of “Add another” link to make the list longer would be very helpful without changing too much
4. If two or more configured proxies share the same hostname and port configuration, selecting any of them as the proxy to use for a container will always result in the first proxy with that hostname/port combination in the list of proxies being applied on “Save” (bug)
   * This occurs specifically because the configuration contains several entries for the local TOR node (localhost:9050) that only differ on the username and password set (cf Suggestion: Replace username/password fields with “Context Identifier” for TOR type proxies #77): Using TOR this way causes the TOR node establish independent network paths (“stream isolation”) for each of them even when visiting the same page from different contexts in the hope that this will make it harder/impossible to detect that these connections originate from the same host. (The sent username/password combination is just used as an identifier for the stream isolation context and has nothing to do with authentication.)

[erosman]

1. Incognito/Container feature is experimental
2. It is explained in the help
3. It is not possible to get any details about the user's containers without the right permission. The “Add" is a possibility that can be looked into.
4. FoxyProxy regularly searches the data to find() the right proxy using hostname:port & PAC URL as the criteria. While having multiple proxies with the same hostname:port are permitted, the search would always return the first one.
   The request requires further investigation & discussion.

[ntninja]

1. I didn’t know that until you pointed it out (it’s not obvious at all) – just adding the beaker-icon from the help to the main view would change that though
2. My first instinct at least is not to consult the help when I’m like “why is this broken?”, doubt most other people feel very differently about this – maybe an explicit pointer to the help then?
   (ie: Incognito/Container proxy (Firefox only, see help for known issues and limitations))
3. Understandable! Maybe also link to the Mozilla bug in the help to make it clear that that is what needs to happen to be able to improve the situation?
4. That explains why this happens from a technical implementation PoV, but it doesn’t mean that it should be this way: It took me quite a bit of time to even figure out that it’s the duplicate username+port combination that triggers this behaviour because the effective UX is “it just changes to something else on save” (with no further explanation) and that is clearly suboptimal.

I get that this should be considered an experimental PoC for now though – just wanted to give some feedback in the hopes that future iterations of this may be improved! 🙂

[erosman]

Understandable! Maybe also link to the Mozilla bug in the help to make it clear that that is what needs to happen to be able to improve the situation?

It is how the "contextualIdentities" API is designed.

contextualIdentities

To use this API you need to include the "contextualIdentities" and "cookies" permissions in your manifest.json file.

Unfortunately, it is not available as optional_permissions

• Bug 1386673: Make Contextual Identity extensions be an optional permission

AFA no 4, #76 has similar issue so the discussion can be continued there.

[erosman]

@ntninja Repo is updated with v8.8 and a workaround for issue no 4.

Please read Help: Proxies for details.

Let me know how it works out.

[ntninja]

@erosman: I had the workaround to use <somename>.localhost for each of those since they all resolve 127.0.0.1 internally but are different hostnames, so in our case another workaround wasn’t necessary – for #76 it wasn’t an option though, I do realize that. I’ll try your workaround once it lands though.

[erosman]

I had the workaround to use <somename>.localhost for each of those since they all resolve 127.0.0.1 internally but are different hostnames, so in our case another workaround wasn’t necessary

@ntninja TBH, using <somename>.localhost is more elegant. 👍

[debilin]

The Firefox extension cookie-autodelete was able to grab information about containers. I don't know how they do it, but we could look at their code and attempt to replicate.

[erosman]

The Firefox extension cookie-autodelete was able to grab information about containers. I don't know how they do it, but we could look at their code and attempt to replicate.

Getting container details is not a problem. Above extension has "contextualIdentities" permission in its manifest.json.

As explained under "2. Specific User Interface", adding "contextualIdentities" permission is fine for people who use containers.
However, for people who don't want to use container, adding "contextualIdentities" permission will automatically enables containers which is undesirable.

At the moment, there is no other option.

[equeim]

Doesn't seem to work for me in Firefox 123 with FoxyProxy 8.9. Proxy is applied for incognito window, but not for containers.

[erosman]

Doesn't seem to work for me in Firefox 123 with FoxyProxy 8.9. Proxy is applied for incognito window, but not for containers.

Are you using containers (enabled via other extensions) and have you set them to a proxy in FoxyProxy Options?

[equeim]

Doesn't seem to work for me in Firefox 123 with FoxyProxy 8.9. Proxy is applied for incognito window, but not for containers.

Are you using containers (enabled via other extensions) and have you set them to a proxy in FoxyProxy Options?

Yes

[erosman]

Can you post your settings (remove/obfuscate any personal data)?

[equeim]

Sure:

{
  "mode": "disable",
  "sync": false,
  "autoBackup": false,
  "passthrough": "",
  "theme": "",
  "container": {
    "incognito": "",
    "container-1": "127.0.0.1:9050",
    "container-2": "",
    "container-3": "",
    "container-4": ""
  },
  "commands": {
    "setProxy": "",
    "setTabProxy": "",
    "quickAdd": ""
  },
  "data": [
    {
      "active": true,
      "title": "TOR",
      "type": "socks5",
      "hostname": "127.0.0.1",
      "port": "9050",
      "username": "",
      "password": "",
      "cc": "",
      "city": "",
      "color": "#8b4513",
      "pac": "",
      "pacString": "",
      "proxyDNS": true,
      "include": [],
      "exclude": []
    }
  ]
}

Tabs in the first container do not use the proxy.

[erosman]

@equeim What does the log show?

[equeim]

The log shows that url in container tab is opened without proxy.

I created a new Firefox profile and it works there. I then tried to disable all extensions except FoxyProxy in my original profile and it still doesn't work. IDK what breaks it. I'm using "Firefox Multi-Account Containers" and it's native proxy feature for now.

[erosman]

I created a new Firefox profile and it works there.

If the feature works in a new profile without any other extensions, then the issue is a conflict with another extension that handles containers e.g. "Firefox Multi-Account Containers".
Furthermore, "Firefox Multi-Account Containers" also has a proxy feature which can conflict with other proxying processes.

If that is the case, there isn't much that can be done.

The only suggestion at the moment is to disable "Firefox Multi-Account Containers" and enable containers by another method (i.e. use Firefox Nightly, Dev version, or another extension which enables containers e.g. FoxyTab).

[kunaltyagi]

Is there any roadmap for adding more containers than just the first containers?

[erosman]

Is there any roadmap for adding more containers than just the first containers?

Do you mean more than the first 4?
If there is a popular demand, it can be done.

However, if Firefox fixes the following, better support can be provided.

Unfortunately, it is not available as optional_permissions

• Bug 1386673: Make Contextual Identity extensions be an optional permission

[kunaltyagi]

Last useful update on that feature request was 4 years ago, so hopes aren't that high. Any reason for not using the permission in non-optional mode?

[erosman]

Last useful update on that feature request was 4 years ago, so hopes aren't that high. Any reason for not using the permission in non-optional mode?

As mentioned ...

• Adding "contextualIdentities" permission automatically enables containers in Firefox which is undesirable to users who don't want to use containers

[ChristianTacke]

Can one improve the UI by allowing to change the proxy for "the current container"? That is, the container of the current tab?

foxyproxy seems to somehow know the proxy for the current tab / container, because it can already show the right badge on the empty page (no website) loaded?

Or would this also require this permission?

[erosman]

I can think of an alternative approach...

• Remove container option from the Options UI (Incognito setting will remain in Options UI)
• Move the container settings to the toolbar popup

PRO

• Container proxy can be set/unset/changed for any current container tab (not only the first 4)

CON

• Users must open a container tab first in order to set/unset/change the container proxy

[ChristianTacke]

Naive question: Can't one use both? Or is this one or the other (due to different, incompiatible APIs?)?

[erosman]

Naive question: Can't one use both? Or is this one or the other (due to different, incompiatible APIs?)?

Do you mean both on Options page & popup?
It would be duplicating the settings (UI bloatware) and can cause more confusion.

[ChristianTacke]

Do you mean both on Options page & popup?

Yeah, that's what I meant.

(I personally like a little UI bloat: The "popup" for more "ad hoc configuration", and the settings page for "dedicated configuration".)

It would be duplicating the settings (UI bloatware) and can cause more confusion.

Understood!

I'd vote for the popup.

The current behaviour on the popup is a little confusing (at least to me): The badge tells me "Using that proxy". While the popup shows "deactivated".

PRO:

• The setting is better connected to the name of the container. Not some random number (you have to know that your work container has number 3.)