Rechercher dans l’assistance

Évitez les escroqueries à l’assistance. Nous ne vous demanderons jamais d’appeler ou d’envoyer un SMS à un numéro de téléphone ou de partager des informations personnelles. Veuillez signaler toute activité suspecte en utilisant l’option « Signaler un abus ».

En savoir plus

How to access the actual Multi-Account Containers per-container site bindings/associations/etc; Are these hiding anywhere?

  • 5 réponses
  • 1 a ce problème
  • 6 vues
  • Dernière réponse par paoletto

more options

How to access the actual Multi-Account Containers per-container site bindings/associations/etc; Are these hiding anywhere?

I'm wondering if these are stored anywhere that I can hack directly? Maybe in XML or JSON somewhere? I've done some searching, haven't found anything.

TIA

How to access the actual Multi-Account Containers per-container site bindings/associations/etc; Are these hiding anywhere? I'm wondering if these are stored anywhere that I can hack directly? Maybe in XML or JSON somewhere? I've done some searching, haven't found anything. TIA

Solution choisie

The MAC extension stores the subdomain, so you can have support.mozilla.org automatically open in a different MAC than www.mozilla.org, for example.

As for your main goal of automatically setting the MAC extension to distinguish between two different Gmail accounts, it's not possible at this time. Since there's no differences between the URL for one Gmail inbox compared to the other, it wouldn't be possible, even if the MAC extension allowed you to set rules for specific pages on a website. There's no way for the extension to tell the difference.

Lire cette réponse dans son contexte 👍 1

Toutes les réponses (5)

more options

Is there a particular reason that you want to "hack" this type of information? Generally, the raw access to that type of stored data is pretty rough to read.

You can see the data that the Multi-Account Containers (MAC) extension (and any other extension, really) is saving. They just use Firefox's builtin system for saving extension storage. This can be done by going to the about:debugging page, selecting This Firefox on the sidebar and pressing the Inspect button next to the extension you want to view.

That opens the developer tools for that extension. You can press the Storage tab and typically see all of the raw extension data that's saved under the Extension Storage section.

In the case of the MAC extension, saved sites are saved using the siteContainerMap@@_SITENAME key, with information saved in there. Each key has a identityMacAddonUUID value that matches the macAddonUUID value of a container, each of which are stored as a identitiesState@@_CONTAINER key.

However, I wouldn't generally recommend directly manipulating an extension's storage area. It can cause the extension to break or lose important information. If you have some issue with the extension, there's generally a better and safer way to fix the problem that you are having, especially if you have minimal technical knowledge or background.

more options

Wesley, thank you very much for the great explanation. I'm fairly new to MAC and already using it extensively. To answer your question, my motivations: 1) Twice now I've installed / later uninstalled other tab-related extensions that seemed to bork MAC's bindings. I was hoping to be able to at least back them up for safekeeping. 2) I find the MAC's user interface somewhat clunky, and thought it would be great if I could just manage the associations all in one list, rather than the blind, one-by-one, several click per, manual procedure. 3) I'm curious how much of a given URI is used in the associations. Just the TLD? Subdomains? Parameters? One example is I keep separate containers for each of my gmail accounts and want to figure out a way to differentiate them from MAC's perspective. Actually, if you know of an elegant way, I'd appreciate your input, as well as the URI question. Anyways, I did a little scanning of the local storage and, as you suggested, haven't been able to grok anything useful, certainly not in any user-friendly way. Thanks again and best regards.

more options

Solution choisie

The MAC extension stores the subdomain, so you can have support.mozilla.org automatically open in a different MAC than www.mozilla.org, for example.

As for your main goal of automatically setting the MAC extension to distinguish between two different Gmail accounts, it's not possible at this time. Since there's no differences between the URL for one Gmail inbox compared to the other, it wouldn't be possible, even if the MAC extension allowed you to set rules for specific pages on a website. There's no way for the extension to tell the difference.

more options

Understood. I have found some URL-ish identifiers for gmail, e.g. https://mail.google.com/mail/u/[email protected] But it redirects before getting the chance to add to a specific MAC container.

I tried to modify one of the siteContainerMap@@_SITENAME keys but it won't let me change it. Or add a new one. I didn't spend too much time at it.

Anyways, I do appreciate the dialogue! And you taught me a few things. Best regards.

more options

Thank you wesley for your reply.

This is actually needed in case of using MAC together with CAD. unfortunately, after decades, firefox sync is still able to get truly basic things wrong. In this specific case, it gets the indices of the containers wrong across devices. The result is that CAD rules exported from one machine and imported into another will be screwed.

Alternately one can manually copy the containers.json into the new profile. This works EXCEPT for the site associations, that, if synced, are then all wrong.

Very sad to see this is even a mozilla-created extension. Unsure if these kind of things are the results or the reason of mozilla difficulties lately.