Reviews for Firefox Multi-Account Containers
Firefox Multi-Account Containers by Mozilla Firefox
Review by Amazing Mr. X
Rated 2 out of 5
by Amazing Mr. X, 3 years agoThis has a lot of potential, but it's not quite ready for prime time. There's a few specific problems here:
Firstly, add-ons can't communicate with the content of containers. This breaks functionality in most add-ons in really weird and unexpected ways. It'd be nice if we could whitelist add-ons to have access to relevant containers, but most users would probably want all of their add-ons to have full access to all of their containers by default and wouldn't expect them to be functionally blocked as they are.
Secondly, containers don't nicely handle redirects. A lot of sites, especially corporate ones, will redirect through several different domains and subdomains when performing the login process. Containers set to "Limit to Designated Sites" won't operate correctly with these redirects as the redirect pages are not true web pages and don't allow you to sit on them long enough to click the address bar button to always open them in the specified container. This cannot currently be remedied by having foreknowledge of the complete list of redirect sites, as the "Limit to Designated Sites" list cannot be manually edited or appended outside of the limited address bar button method.
Thirdly, The VPN integration isn't particularly secure in premise. Being a per-container opt-in means that entities snooping on the line will immediately see that there's something suspiciously different in the data packets coming from your protected containers compared to the rest of your typical https encrypted traffic. This makes isolating these packets, on the fly, infuriatingly trivial. Making this a per-container opt-out would all but eliminate this problem, as attackers would have to have foreknowledge of the originating container to do this effectively in all circumstances. It'd also be great to see connection protocol options ( OpenVPN, WireGuard, etc. ) as well as other VPN provider options as that'd make it that much harder to try and figure out what's going on in the encrypted container traffic and would better protect Mozilla VPN itself. Right now it's technically more secure to not use the VPN feature at all.
I think the basic idea here is really excellent, but these problems really do drag it down. Something made and maintained by Mozilla shouldn't have this many problems. I still think this is potentially useful to certain technical professionals trying to isolate their sensitive internal sites from other web apps, but the average user is going to have too many headaches to be able to use this effectively.
If you know what you're doing, keep the above points in-mind and go ahead and give it a try.
Anyone else? Hope Mozilla addresses some of these issues in a future release. I'll update my review if they do.
Firstly, add-ons can't communicate with the content of containers. This breaks functionality in most add-ons in really weird and unexpected ways. It'd be nice if we could whitelist add-ons to have access to relevant containers, but most users would probably want all of their add-ons to have full access to all of their containers by default and wouldn't expect them to be functionally blocked as they are.
Secondly, containers don't nicely handle redirects. A lot of sites, especially corporate ones, will redirect through several different domains and subdomains when performing the login process. Containers set to "Limit to Designated Sites" won't operate correctly with these redirects as the redirect pages are not true web pages and don't allow you to sit on them long enough to click the address bar button to always open them in the specified container. This cannot currently be remedied by having foreknowledge of the complete list of redirect sites, as the "Limit to Designated Sites" list cannot be manually edited or appended outside of the limited address bar button method.
Thirdly, The VPN integration isn't particularly secure in premise. Being a per-container opt-in means that entities snooping on the line will immediately see that there's something suspiciously different in the data packets coming from your protected containers compared to the rest of your typical https encrypted traffic. This makes isolating these packets, on the fly, infuriatingly trivial. Making this a per-container opt-out would all but eliminate this problem, as attackers would have to have foreknowledge of the originating container to do this effectively in all circumstances. It'd also be great to see connection protocol options ( OpenVPN, WireGuard, etc. ) as well as other VPN provider options as that'd make it that much harder to try and figure out what's going on in the encrypted container traffic and would better protect Mozilla VPN itself. Right now it's technically more secure to not use the VPN feature at all.
I think the basic idea here is really excellent, but these problems really do drag it down. Something made and maintained by Mozilla shouldn't have this many problems. I still think this is potentially useful to certain technical professionals trying to isolate their sensitive internal sites from other web apps, but the average user is going to have too many headaches to be able to use this effectively.
If you know what you're doing, keep the above points in-mind and go ahead and give it a try.
Anyone else? Hope Mozilla addresses some of these issues in a future release. I'll update my review if they do.