Multi-account-containers: Allow custom proxy settings per containers

[PedroArvela]

The rationale is simple. My college institution provides a web proxy I can use to browse using my university's network, which allows me to use the perks associated to it.

Having proxies per containers would then mean I could use my university's proxy only when I am on tabs which I want and need to browse for that use case in specific.

[samuel-allan]

Any thoughts? I would very much like to work on this if everyone is in agreement

[groovecoder]

I agree it would be a cool feature. It seems quite complicated though?

In any case, we won't merge it into this core add-on. If you work on it, you should start a new add-on specifically for this feature.

[jonathanKingston]

I agree given the complexity this shouldn't be a default to start with. Successful features might end up merging in eventually into the bigger picture much like other addons have in the past.

I know there is a new proxy API however I haven't played with it to say if it is suitable here. I'm happy to help advise etc too.

[onionjake]

I used to use foxyproxy so that url's that matched a pattern would go through a specific proxy, but I think containers make much more sense for managing this. Foxyproxy also doesn't have Firefox 57 support (yet)...

Is the container extension written such that I could write a new add-on that manages proxy settings for containers? Or is this something that would need a fork?

[brokoli-mate]

The first thing a wondered after installing - is there such a feature. so it would be great to have this option

[laurento]

I had the same idea at very first moment I tried the add-on. I definitely vote for this feature :)

[tpruzina]

The whole premise without this doesn't make sense to me, actually it would be far more preferable to have entirely different profile for each "container". Probably not _feasible_ from amount of sheer programming required to make that happen and work seamlessly, but hey one can hope.

But it's not even just the fact that this is currently useless, I can't imagine users accepting this from UX perspective.We would need tab groups (formerly panorama) and per domain "profile" tracking for this to be somewhat seamless experience.

As of right now I'm using two browsers, firefox for netflix (and stuff), tor browser for everything else.
Just having per container proxy won't really help tho, tor browser applies bunch of other modifications that make fingerprinting and other stuff harder to exploit.

[MurzNN]

Firefox below 57 have great Proxy Privacy Ruler addon that allow to enable proxy only for private tabs, but it stops working on Firefox 57+. Will be good to implement same function via Firefox Containers to enable proxy only for specific container.

[laurento]

I would use this feature to assign a specific proxy, hosted behind a VPN, for specific browsing category (e.g. banking or shopping) and/or to avoid country specific limitations. That's the use-case I have in mind.

[thewisenerd]

I would like to vote for this :+1:

[doronbehar]

This is not truly a workaround but since I use firefox containers through extensions like google-container, I've found the extension smartProxy to be quite useful.

[samuel-allan]

Apologies for the huge hangup!
I see there are a number of people interested in this - what is the current status of things?
Is someone working on it already? If not I think I will start this week for at least a preliminary version.

EDIT: probably seems reasonable to fork it off and make a test version, so will do

[groovecoder]

If I remember correctly, @bakulf - this requires a platform-level change to isolate preferences by contextual identity?

[onionjake]

I have been able to use a PAC script similar to the proxy-blocker in the webextensions-examples here https://github.com/mdn/webextensions-examples/tree/master/proxy-blocker to get this functionality partially working. I haven't set it up to be configured per container yet, but would it be too hacky for FindProxyForURL to try and figure out which tab/container originated the request and return a configured proxy?

[groovecoder]

I'm not familiar with PAC, but it looks like it's possible in the extension (without needing a platform change):

1. Use browser.proxy.onRequest.addListener
2. Use browser.tabs.get to get the tab object of the request
3. Check if the tab.cookieStoreId is in a map of "proxied Containers"
4. Return the appropriate ProxyInfo object, if any

Note: This will add a new dimension of "assignment" data to the add-on - like the site-assignment data. So it may require significant design thinking to make sure it's right.

[samuel-allan]

Update: I added an option in the HTML of 'edit containers', just to see how this looks (you can see it in my fork: https://github.com/samuel-allan/multi-account-containers), of course it is not stylistically perfect (or even near that), but should suffice for testing. I think I figured out the relevant parts of the code to edit (very clear and clean code) to introduce the actual logic to handle proxies.

Screenshot:

[samuel-allan]

Latest Update: I have implemented the system which associates cookieStoreIds (container identifiers) with their associated HTTP proxies (with support for authentication, and ip:port, e.t.c.). You can see the latest progress here. The file in particular which handles this more design-related step is proxified-containers.js.

[samuel-allan]

@groovecoder Do you think I can wisely proceed with the final stage (actually using the addListener in the background logic javascript) considering the current state of the add-on? Let me know what you think of the current changes I made

[groovecoder]

@samuel-allan looks like you're on the right track, but instead of storing the proxy-container mapping(s) in background window object, can you change that code to more closely match what we do with site assigments in assignManager.js? At the very least, I think you'll need to use browser.storage.local for the proxy assignments in order to preserve the data between browser restarts.

[samuel-crypto]

@groovecoder Hmm, actually I am using browser.storage.local.. Perhaps I posted the wrong code I will check now

[samuel-crypto]

@groovecoder Could you possibly clarify what you mean? Sorry I'm a bit confused - I think I am actually using browser.storage.local in the code I posted (windows.proxifiedContainers is only an object with functions for more convinient use across multiple files - nothing is stored in the window object)

[groovecoder]

Ah, I see now - sorry I over-looked that at first. Yes the code you have so far looks okay to add the webRequest listener in the backgroundLogic.

[samuel-crypto]

@groovecoder Ok perfect, I have completed integration of proxies here. Now comes the cleanup and debugging process which will undoubtedly reveal a lot of flaws, but as far as trivial functionality (using a proxy) it appears to work now. Testers are very welcome!

Edit: excuse me for not mentioning, I am using a different account as my original account is suffering from overbloat (hence the repo would be different now: samuel-crypto/... instead of samuel-allan/...)

[laurento]

Thanks for your work Samuel, I'll be glad to test it and report back.

[laurento]

Except the fact _lint:js_ screams if you try to pack it, but I also believe it is expected, the extension just works good for me :)

Reviewing your code, I was a bit fooled by that const DEFAULT_PROXY = {type: "direct"};. I had the feeling you were defaulting to type: "direct" regardless the FF current proxy configuration, but I empirically tested that it actually works as expected: the extension inherits the _global_ proxy configuration if the new proxy-container setting is blank.

[samuel-crypto]

Thank you very much @laurento for testing!
The code is far from perfect, and it has a long list of confusing things which I will try to fix.
I fixed lint.js's screams (it still is producing warnings about todos but what can I do).

Here are some interesting problems I've discovered:

• Seemingly unrelated tests seem to fail, such as the Always open in feature
• I am not sure what to do in the catch() callbacks in case some weird storage.local error does occur. Currently it is just printing it to console but that is not very performance efficient

Anyway, I'm probably going to submit a pull request and we will see what happens from there :)

[samuel-allan]

Oops apparently I broke the code with some lint fixes. Will check properly
today

On Tue 9 Oct 2018 12:45 PM samuel-crypto [e-mail] wrote:

Thank you very much @laurento https://github.com/laurento for testing!
The code is far from perfect, and it has a long list of confusing things
which I will try to fix.
I fixed lint.js's screams (it still is producing warnings about todos but
what can I do).

Here are some interesting problems I've discovered:

• Seemingly unrelated tests seem to fail, such as the Always open in
  feature
• I am not sure what to do in the catch() callbacks in case some weird
  storage.local error does occur. Currently it is just printing it to console
  but that is not very performance efficient

Anyway, I'm probably going to submit a pull request and we will see what
happens from there :)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mozilla/multi-account-containers/issues/313#issuecomment-428265436,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF9Y9MRp2tInkES2KsNt2hh4IShwXZp6ks5ujNKWgaJpZM4MRXed
.

[xavier83]

would be great if foxyproxy implemented such a feature.

[samuel-crypto]

Alright I fixed these issues and the code is working (proxies are) both when editing and creating new containers, however, some tests seem to be failing (unrelated to the code I wrote), I am not quite sure why... Help is greatly appreciated. The PR can be viewed here: #1284

[brokoli-mate]

Alright I fixed these issues and the code is working (proxies are) both when editing and creating new containers, however, some tests seem to be failing (unrelated to the code I wrote), I am not quite sure why... Help is greatly appreciated. The PR can be viewed here: #1284

Great work you have done this. As I understood it's only for http. What about SOCKS?

[samuel-crypto]

Alright I fixed these issues and the code is working (proxies are) both when editing and creating new containers, however, some tests seem to be failing (unrelated to the code I wrote), I am not quite sure why... Help is greatly appreciated. The PR can be viewed here: #1284

Great work you have done this. As I understood it's only for http. What about SOCKS?

Interestingly enough SOCKS4/5 appears to be supported by proxy.onRequest. So it is possible to add these also. Of course I'm not sure how to do this GUI/wise, or maybe just test for what kind of proxy it is somehow? Either way lets see how this PR goes first

[bdrtsky]

Absolutely must-have feature. I was surprised to found it doesn't exist. Why not to include it by default? You are saying it will never be included? Without it Facebook containers doesn't make any sense.
Is there any chance this to be implemented? Don't really want to switch back to Chromium profiles...

[samuel-crypto]

Indeed. I have 99% of the code, just need time for the brush ups. I will
try to to get it this week.

On Tue 29 Jan 2019 4:55 AM bdrtsk <[email protected] wrote:

Absolutely must-have feature. Without it Facebook containers doesn't make
any sense.
Is there any chance this to be implemented? Don't really want to switch
back to Chromium profiles...

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mozilla/multi-account-containers/issues/313#issuecomment-458478204,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AgBajP0rbEMXY3wdw2zqBTG1JOA7MaJgks5vIBqngaJpZM4MRXed
.

[unrelentingtech]

@samuel-crypto with your patch, will it be possible to have the global (main firefox settings) proxy applied in all containers by default + some containers that have their own proxies + some containers that connect directly (skipping the default proxy)?

[samuel-crypto]

Not at present.
This behavior can be implemented but it is a much more major reconstruction
of the add-on.
The way I would probably suggest is to create a separate setting for the
'Default' container - allowing people to edit all settings that default
tabs get, and in this editor, one could change the proxy, which then
automatically solves the case when you need everything to be proxified.
Following that you could insert a special switch into the container editor
which asks 'inherit Default proxy settings'. I am not at all against this
and thank you for bringing it up, it would be better as two separate issues
on the same page I think, at least it would get better recognition that way.
Have a good day! :)

On Wed, Feb 6, 2019 at 3:55 PM myfreeweb [e-mail] wrote:

@samuel-crypto https://github.com/samuel-crypto with your patch, will
it be possible to have the global (main firefox settings) proxy applied in
all containers by default + some containers that have their own proxies + some
containers that connect directly (skipping the default proxy)?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mozilla/multi-account-containers/issues/313#issuecomment-461183857,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AgBajGt7erQytCC-d5HFojW3MtXnWnVdks5vK0E9gaJpZM4MRXed
.

[fsdjfhadflkjhsd]

Hi Samuel, I just signed up on github, as I found out about your per-tab-proxy allowing plugin. I hope you will release it soon. Have a great day!

[mario-areias]

@samuel-crypto thanks for the work you are putting into that. Really appreciate this. That's a feature I would like very much to have, so let me know if there is anything I can do to help. Test, docs, development whatever.

[yipivan]

I just searched this function online and found the Sidebery plug-in which allows you do this.

[brentahughes]

I just searched this function online and found the Sidebery plug-in which allows you do this.

I've been using this plugin for the proxy feature and it works well. Only issue is that if I close the sidebar the proxied containers stop going through the proxy.

Really hoping to see this natively supported in the multi-account-containers plugin soon

[samuel-crypto]

Thank you everyone!
I apologise greatly for the delay,
I will get to finishing it shortly.

[samuel-crypto]

One more issue to solve (a small technical point) before it can be integrated is the cleanup (as mentioned by @jonathanKingston in the PR) - once this is solved it can be integrated (as far as I can see).

[furai]

This is something I'm looking forward to. Amazing feature to have. I've just found myself in work situation where I have to access some internal pages over other network. This would be perfect to have.

[samuel-crypto]

Glad you are! Really hoping to get a reply at the PR, haven't heard
anything there yet (one more issue needs to be resolved before it is fully
ready for integration).

On Thu, Aug 15, 2019 at 6:14 PM Lucas Grzegorczyk [e-mail]
wrote:

This is something I'm looking forward to. Amazing feature to have. I've
just found myself in work situation where I have to access some internal
pages over other network. This would be perfect to have.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mozilla/multi-account-containers/issues/313?email_source=notifications&email_token=AIAFVDCEMYUJ4QDNKZ66OYLQEVXERA5CNFSM4DCFO6O2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4MC2AA#issuecomment-521678080,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIAFVDFMS6YFZHHTSGON56DQEVXERANCNFSM4DCFO6OQ
.

[diimpp]

For anybody interested in the feature, while waiting for PR https://github.com/mozilla/multi-account-containers/pull/1284 to be merged, there is this addon, that adds same functionality.

https://addons.mozilla.org/en-US/firefox/addon/container-proxy/
https://github.com/bekh6ex/firefox-container-proxy

[slrslr]

PR #1284 has a conflicting files. Anyone can solve it?

[abitrolly]

@slrslr that's #1903 now. Also conflicting though.