search

foxyproxy / browser-extension

Version 8 and above. Browser extension source code for Firefox, Chrome, and other Chromium-based browsers
GNU General Public License v2.0
202 stars 28 forks source link

Incognito & Container Support #33

Open erosman opened 10 months ago

erosman commented 10 months ago

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.

2. Specific User Interface

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

Implementation

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

Sync and Preferences: Import/Export

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

erosman commented 10 months ago

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 commented 10 months ago

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

erosman commented 10 months ago

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

TriMoon commented 9 months ago

wrt. "Tab Proxy":

It would be nice to have an option "DIRECT" (or "Disabled") in the drop-down list to select as proxy to use for the tab, which would temporarily disable all proxies for the tab :wink:

erosman commented 9 months ago

It would be nice to have an option "DIRECT" (or "Disabled") in the drop-down list to select as proxy to use for the tab, which would temporarily disable all proxies for the tab There are set & unset to enable and disable Tab proxy.

I can look into adding a DIRECT option to Set Tab Proxy which would disable all proxying related to that tab.

Even when you select a tab proxy in the drop-down list and click and "Set Tab Proxy" it is not shown when you re-open the popup or reload the page, which might be a good idea also.

Set Tab Proxy is an independent function and its data is not saved. The page-action icon is set to show if a tab has Tab Proxy or not. It is possible to grab the data but that would involve a number of async processes which have to be performed every time the popup is shown but not applicable 99% of the times.

pmarks-net commented 9 months ago

It is possible to grab the data but that would involve a number of async processes which have to be performed every time the popup is shown but not applicable 99% of the times.

As the developer, you're free to do whatever you want, but if your code isn't doing the hard work to keep track of its own state, then what hope do the users have of understanding what's happening? I notice that the pageAction icon disappears when I reload the page, for example.

erosman commented 9 months ago

As the developer, you're free to do whatever you want, but if your code isn't doing the hard work to keep track of its own state, then what hope do the users have of understanding what's happening?

If there is popular demand for a feature, it will be looked into.

I notice that the pageAction icon disappears when I reload the page, for example.

That shouldn't happen. I will look into it.

pmarks-net commented 9 months ago

If there is popular demand for a feature, it will be looked into.

I'm talking more about a design philosophy. When adding a feature, often the hardest part is making it comprehensible to the user: https://en.wikipedia.org/wiki/The_Design_of_Everyday_Things

erosman commented 9 months ago

The performance also matters.

Add-on Policies: Development Practices Add-ons must not negatively impact the performance or stability of Firefox.

ericjung commented 9 months ago

Set Tab Proxy" it is not shown when you re-open the popup or reload the page, which might be a good idea also.

Is my understanding correct that FP is not displaying the proxy in use when the popup is opened? And doing so would be a significant performance hit? If so, we should probably remove the Set Tab Proxy feature altogether. I hope I misunderstand.

erosman commented 9 months ago

Please note that Tab Proxy is a separate feature than Incognito & Container Proxy and should be discussed in another topic.

TriMoon commented 9 months ago

@erosman excuse me but your argument is flawed wrt to performance penalty for showing the TabProxy in the popup when it is opened, the flaw is that your code would only do the extra work when the popup is opened by the user which doesn't happen that often anyway during normal browsing...

But WHEN the user opens the popup it expects to see ALL relevant info that is applied at that moment...

So we're enthusiastic about the new features you add :+1: But if it is not communicated to the user in a VISUAL way, it will not be noticed nor used, and as you can expect not appreciated either... (I didn't even notice the tiny icon changes etc cause it's just one among the many icons i have)

PS: About "popular demand", trust me if i say that 1 person's feedback here counts as feedback of 1 million silent users who don't even visit here :wink:

erosman commented 9 months ago

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

ntninja commented 7 months ago

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 #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 commented 7 months ago
  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 commented 7 months ago
  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 commented 7 months ago

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

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

erosman commented 7 months ago

@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 commented 7 months ago

@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 commented 7 months ago

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. :+1:

debilin commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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

equeim commented 4 months ago

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 commented 4 months ago

@equeim What does the log show?

equeim commented 4 months ago

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 commented 4 months ago

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 commented 3 months ago

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

erosman commented 3 months ago

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

kunaltyagi commented 3 months ago

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 commented 3 months ago

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