Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simple Tab Groups Breaks Multi-Account Containers (tabs escaped containers, https lost) #2453

Closed
2 tasks done
influential-eliot opened this issue Nov 22, 2022 · 9 comments
Closed
2 tasks done
Labels
bug Something is broken! Status: Addon Compatibility Issues related to compatibility issues with other addons

Comments

@influential-eliot
Copy link

influential-eliot commented Nov 22, 2022

Before submitting a bug report

  • I updated to the latest version of Multi-Account Container and tested if I can reproduce the issue
  • I searched for existing reports to see if it hasn't already been reported

Step to reproduce

  1. Install Multi-Account-Containers (MAC)
  2. Install (Mozilla recommended) Simple Tab Groups (STG)
  3. Ensure that some tabs automatically open in specific MAC, ensure that some are preferred to open in MAC
  4. Create a few STG with all MAC tabs, and open them in different Windows (one window per STG)
  5. Close one of the STG windows
  6. Open the STG window from right click on STG

Alternatively you can close FireFox (CTRL+Q / Menu->Exit) and re-open.

Actual behavior

When the STG window opens it will open all the correct tabs, but it won't open them in the MAC that they were previously in. Here is a view from a 'bad STG+MAC tab' that I opened manually into the correct MAC:

Further more, HTTPS connection is broken, note the bad padlock in this view from the 'bad STG+MAC tab' perspective:

Expected behavior

When a STG window is opened, the tabs that were previously in MAC should reopen in their MAC.

Additional informations

This has been attempted on a Win 11 machine (latest) on Nightly (latest) with STG (last few versions to latest) and MAC (last few versions to latest).

Here's the issue raised with STG on their GitHub page:
Drive4ik/simple-tab-groups#990

EDIT - 30th Nov 2022
I should note, I'm not raising this for 'addon compatibility' ... I'm raising that an addon has circumvented how MAC should function, and will cause security issues for users.

Provide a copy of Troubleshooting Information page (optional)

No response

@dannycolin dannycolin added bug Something is broken! Status: Addon Compatibility Issues related to compatibility issues with other addons labels Nov 22, 2022
@dannycolin
Copy link
Collaborator

When a STG window is opened, the tabs that were previously in MAC should reopen in their MAC.

Do you mean that you assigned a website to a specific container with "Always open in" in Multi-Account Containers and STG doesn't respect the assignment or override it?

@mc0e
Copy link

mc0e commented Jan 10, 2023

I'm not currently familiar with STG, but have come here because it's been raised in #1670 (comment) , which I'm concerned about. I also haven't yet done any investigation on the questions below. So I'm light on knowledge to contribute here, but maybe these questions are useful.

I haven't really thought through the requirements in order to maintain the isolation or sharing of containers that existed prior to a window or browser being closed. Hopefully someone has thought that through and documented the strategy MAC takes? Is there a version of that documentation that's targetted to developers of related browser add-ons, documenting what they need to get right, and the demarcation of responsibility that MAC expects wrt other add-ons?

Is there scope for MAC to limit what other add-ons can do so MAC can provide better guarantees?

What would a testing suite look like for this, to pick up problems before new/updated add-ons get shipped to users? That could be used by other add-on developers and/or published by the MAC project.

Can MAC monitor within browsers whether other add-ons are behaving safely, and warn the user and/or send data to developers?

@achernyakevich-sc
Copy link

I use STG+MAC for years (after STG was created after Firefox Quantum). Never have experienced something similar. :) I have some idea that it would be misconfiguration of add-ons. STG provides possibility to stick a tab group to some MAC container - so any tab open in this group/window will automatically open in dedicated MAC container.

@mc0e Could you provide setting of STG's group that you try to open in new window and that produce a problem?

@mc0e
Copy link

mc0e commented Jan 10, 2023

I use STG+MAC for years (after STG was created after Firefox Quantum). Never have experienced something similar. :) I have some idea that it would be misconfiguration of add-ons. STG provides possibility to stick a tab group to some MAC container - so any tab open in this group/window will automatically open in dedicated MAC container.

@mc0e Could you provide setting of STG's group that you try to open in new window and that produce a problem?

That's one for @influential-eliot. I use MAC with Temporary Containers, but haven't yet used STG. It caught my interest when someone suggested That MAC and STG might be useful as a solution to #1670, but I want to see where this issue goes before trying STG.

The info you ask for is likely to be helpful for tracking down the problem, but It seems to me that it should not be possible to (mis-)configure STG such that it breaks MACs isolation of content, or at least not without some warnings being raised.

@dannycolin
Copy link
Collaborator

dannycolin commented Jan 10, 2023

I'm raising that an addon has circumvented how MAC should function, and will cause security issues for users.

  1. You can't change the cookie store of a container through the webextension API
  2. STG doesn't copy the cookies from one store to another one meaning I haven't seen any cookies.get or cookies.set in the codebase.
  3. When first-party isolation is enabled in Firefox, the extension is forced to respect it or else the API call will fail. This means that if the cookie were to be copied in some way, you'd still be protected by Total Cookie Protection

In other words, the isolation isn't broken because cookies are never shared between two containers. If the "Always open in" is failing, that's another issue unrelated to the isolation itself. There's no immediate security risk from an API/addon perspective with the issue reported.

I do agree that if the assignment aren't respected the user could accidentally re-login to a website without immediately realizing they aren't in the right container. However, this can happen outside of this scenario if the user doesn't make sure they're in the right container by looking at the container indicator in the address bar an the tabbar.

Is there scope for MAC to limit what other add-ons can do so MAC can provide better guarantees? Can MAC monitor within browsers whether other add-ons are behaving safely, and warn the user and/or send data to developers?

No, addons are completely isolated from each others. We can't dictate what another of them can or can't do or vice-versa.

@influential-eliot
Copy link
Author

influential-eliot commented Jan 10, 2023

Hi, @dannycolin, thanks for the responses! :)

Adhoc Tabs

Before diving in, I should note that there's perhaps something that I didn't touch on, and that is the nature of using MACs in an 'adhoc' fashion.

Not all tabs opened in a MAC are in the list of sites that are supposed to be opened in that MAC. Sometimes a tab is open in a MAC on an adhoc basis, or in relation to a piece of work, or a login that is relevant for what's going on with the other tabs open.

I'll come back to this, later. 👍


Always Open In

With regard to this question:

Do you mean that you assigned a website to a specific container with "Always open in" in Multi-Account Containers and STG doesn't respect the assignment or override it?
I apologise, I thought I'd covered this adequately, but I'd not worded it sufficiently. Again, apologies.

This piece of text that I wrote:

Ensure that some tabs automatically open in specific MAC, ensure that some are preferred to open in MAC
That was intended to indicate that some sites are configured to always open in a specific MAC, and some sites are set to open in specific MAC, but the additional step of checking the 'Remember my decision for this site' has not been checked.

This (for example) allows me to open sites such as the Azure or AAD portals nominally in my main tenant, but still easily open them in others (for the MS tenancies are many and varied).

So, yes, on all of the sites in question the 'Always open in' has been checked, and yes, STG does not only not respect it, it simply loads a blank tab page with the URL in the address bar.


Cookies / Privacy

I appreciate the below, and thanks for letting me know. It does bleed into my other need with FireFox in general to allow us to be more prescriptively involved with our cookie management. I've not been introduced (yet) to a solution that allows me decent control over this, but I do appreciate that it's a multi-layered, complex, beast, and here is not the place. 👍

I'm raising that an addon has circumvented how MAC should function, and will cause security issues for users.

champion cookies chatter 👍

In other words, the isolation isn't broken because cookies are never shared between two containers. If the "Always open in" is failing, that's another issue unrelated to the isolation itself. There's no immediate security risk from an API/addon perspective with the issue reported.

Seriously, thanks for that insight. 🙂

Essentially, though, the following quote does basically touch on the level at which I'm talking about, here. Although with many MACs provisioned and reigniting an old STG to get back to work on it could mean that plenty of tabs that were not in their 'default' tab group on purpose, or were opened ad-hoc (as per my intro) the user may not have the context clues to ably necessitate this.

I do agree that if the assignment aren't respected the user could accidentally re-login to a website without immediately realizing they aren't in the right container. However, this can happen outside of this scenario if the user doesn't make sure they're in the right container by looking at the container indicator in the address bar an the tabbar.

But, yes, essentially MOST security issues can be worked around with decent user knowledge, and I'm not raising this as a hair's on fire kind of doom-saying thing. Purely that it is a concern, since it is happening, and beyond that is potentially (I've seen tens of tabs and whole windows full not reload correctly) a royal PitA for anyone that has to figure out how to reopen each and every MAC tab properly.

Again, though, the very fact that it has happened indicates that something isn't right, I'm just not knowledgeable enough to figure out where. 😞 (sorry)

I do agree that if the assignment aren't respected the user could accidentally re-login to a website without immediately realizing they aren't in the right container. However, this can happen outside of this scenario if the user doesn't make sure they're in the right container by looking at the container indicator in the address bar an the tabbar.


Restricting Access

Not to wind into opinion territory, but this seems like a bad road to travel down, and I'm glad from what @dannycolin said here that it's not limited ... but also that it's not spying. 👍

Is there scope for MAC to limit what other add-ons can do so MAC can provide better guarantees? Can MAC monitor within browsers whether other add-ons are behaving safely, and warn the user and/or send data to developers?

No, addons are completely isolated from each others. We can't dictate what another of them can or can't do or vice-versa.


More Data For STG Ticket

With regard to @achernyakevich-sc's requests here, I'm glad that you've not experienced the issue, achemyakevich-sc. It means that you've definitely had an easier usage of the add-on than I. 🙌

I use STG+MAC for years (after STG was created after Firefox Quantum). Never have experienced something similar. :) I have some idea that it would be misconfiguration of add-ons. STG provides possibility to stick a tab group to some MAC container - so any tab open in this group/window will automatically open in dedicated MAC container.

@mc0e Could you provide setting of STG's group that you try to open in new window and that produce a problem?

I would kindly perhaps suggest that your concerns and requirements might better serve the issue from the STG perspective, rather than this thread here, which is for the MAC issue. This ticket is (speaking from a broad ITIL mindset) less about the specific add-on that caused this incident, and thinking about how an add-on might have caused a problem that has (as yet) gone unnoticed. At least that's how I intended it with the raising of the ticket, however I appreciate that there may be some person ID involved in me thinking that it must be a deeper thing, because I'm somehow special. 😅 Either way, it's a very new OS build that had very little on it, W11, latest FF, and updates applied to both add-ons with the issue showing either side of the updates.

That said, I (painfully) disabled all other add-ons other than these two whilst testing this at the time ( I'm not going to again 😅 ) and ensured that nothing was colouring it. All the same, I can't exactly remember, but I may have seen it happen with a STG set to open in a specific MAC, if that feature was available at the time. Either way, with the chance that tabs were adhoc (I can't automate my whole life, no matter how I try) I'd say it's perhaps somewhat moot. But definitely worth mentioning in the STG ticket, I think, perhaps. 🙂

@influential-eliot
Copy link
Author

influential-eliot commented Feb 22, 2023

I think I may have identified a repeat of whatever is causing this without STG involved, this could be unique to the current build of Nightly that I'm on, though.

Current Nightly Version: 112.0a1 (2023-02-17) (64-bit)

In this update of Nightly, when I reopen the browser and it reloads tabs, it will not just reload them in the groups they were in prior to closing. I will try to test this again after the next update applies, but I've got a bit on, so it'll be open for a while.

I'm not necessarily suggesting that this is an issue, but this doesn't feel like the right UX / UI choice if it's 'working as designed' ... 🤔

I say this because if I'm closing the browser with a few different workflows in situ, then I will want to re-open it there.

Currently, if I have 6 tabs in one window (and a few in another) setup like this:

  1. CompanyGroup 1 MAC - Site: Azure Portal
  2. CompanyGroup 1 MAC - Site: Power Automate
  3. CompanyGroup 2 MAC - Site: Azure Portal
  4. CompanyGroup 2 MAC - Site: Power Automate
  5. CompanyGroup 2 MAC - Site: SharePoint Site
  6. CompanyGroup 2 MAC - Site: YouTube

... and my setup is:

  • Site: Azure Portal defaults to the CompanyGroup 2 MAC ('Remember' tick not enabled)
  • Site: Power Automate defaults to the CompanyGroup 1 MAC ('Remember' tick not enabled)

Then when I reopen the browser, and switch to:

  • Tab Add readme #1 - It opens a new tab asking me if I meant to open it in the CompanyGroup 2 MAC
  • Tab add initial acceptance criteria #4 - It opens a new tab asking me if I meant to open it in the CompanyGroup 2 MAC
  • Tabs 2,3,5,6 - All open in their previous MAC groups no issues

... then I have to close the original tab, obviously.

As I say, I might be gloriously misjudging how this should work, however it seems incongruous to do this for tabs that were previously opened, which makes me think it is possibly related to whatever underlying cause affects the STG issue this is raised as.


I have also noticed that it's ignoring 'Limit to designated sites' ... it literally just opened one on a middle-click.

@influential-eliot
Copy link
Author

influential-eliot commented Mar 2, 2023

Pertinent update, the Add-on creator has shown that this is not add-on related, but a bug in the browser:

https://bugzilla.mozilla.org/show_bug.cgi?id=1819794

@dannycolin
Copy link
Collaborator

Good catch and thanks for sharing the upstream bug report! I'll close this as a duplicate of #1719 on our side since they are caused by the same issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something is broken! Status: Addon Compatibility Issues related to compatibility issues with other addons
Projects
None yet
Development

No branches or pull requests

4 participants