multi-account-containers icon indicating copy to clipboard operation
multi-account-containers copied to clipboard

Assign domains to containers through Firefox policies

Open DamienCassou opened this issue 1 year ago • 3 comments

Before submitting a bug report

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

Step to reproduce

It is possible to specify containers through policies: this is documented at https://mozilla.github.io/policy-templates/#containers and looks like the following in policy.json:

{
  "policies": {
    "Containers": {
      "Default": [
        {
          "name": "My container",
          "icon": "pet",
          "color": "turquoise"
        }
      ]
    }
  }
}

This is great. Unfortunately, there is no way to (pre-)assign domains to these containers. I would like to write something like the following:

{
  "policies": {
    "Containers": {
      "Default": [
        {
          "name": "My container",
          "icon": "pet",
          "color": "turquoise",
          "domains": ["example.org"]
        }
      ]
    }
  }
}

With such a configuration, opening example.org would be automatically done in the "My container" container without requiring manual configuration by each user.

Actual behavior

There is no way to associate a domain to a given container.

Expected behavior

example.org should be attached to "My container" without requiring the user to click "Always open this site in"

Additional informations

This was requested in https://github.com/mozilla/multi-account-containers/issues/2565.

Provide a copy of Troubleshooting Information page (optional)

No response

DamienCassou avatar Nov 21 '23 13:11 DamienCassou

cc @mkaply

I like this idea. However, there are a few things to consider:

  • We have no way from the addon to validate the domain (e.g. PublicSuffixList) and it might create issues in some edge cases.
  • We also don't support wildcards and I'm guessing this is wanted. It can be implemented in a follow-up bug but we need to take it into consideration
  • How do we deal with Sync? AFAIK, Firefox policies are only created on first run of a Firefox profile. If the user log in to their Mozilla Account and they enabled Sync in the addon, it might override the policies default and the administrator who configured the policies might not want this. Do we offer a way to lock them?

There might be other concerns but that's what came to my mind at the moment.

dannycolin avatar Nov 21 '23 23:11 dannycolin

Firefox policies are only created on first run of a Firefox profile

I just experimented with this. I think containers are populated from policies if the containers.json file doesn't exist in the profile directory yet. This is a problem I think: a company should be able to deploy an updated policy with new containers for example.

Another problem I see is that containers.json assign an ID to each container but the policies do not. This is a problem for add-ons which rely on container IDs, e.g., Cookie-AutoDelete.

Is there some room to change how policies affect this add-on or is it forged in stone? I'm thinking about something like this for policies:

{
    "policies": {
        "Containers": {
            "LockCreate": true,
            "LockDelete": true,
            "Default": [
                {
                    "id": 1,
                    "name": "My container",
                    "icon": "pet",
                    "color": "turquoise"
                    "domains": ["example.org"],
                    "lockDomains": true
                }
            ]
        }
    }
}

Changes based on existing policies:

  • "LockCreate" allows a company to prevent the creation of a new container
  • "LockDelete" allows a company to prevent the deletion of a container
  • "id" allows a company to uniquely identify a container (this is useful for add-ons to do dedicated stuff for some containers)
  • "domains" allows a company to pre-assign domains to a container
  • "lockDomains" allows a company to prevent adding/removing domains to a container

I kept the lower case property names in each container (e.g., "name" instead of "Name") but it seems like "Containers" is the only policy not using upper camel case.

DamienCassou avatar Nov 22 '23 08:11 DamienCassou

Until have evidence that lots of companies are using containers, I'm not inclined to put a ton of work into this. The ID and domains make sense if we can do it, but the other changes would be quite a bit of work.

mkaply avatar Nov 22 '23 13:11 mkaply