Consider a tab context menu option to convert a normal tab to a container

[pmac]

I often click a link from an external app and a normal tab opens, but I'm logged into the web app in a container. I'd like to be able to just convert the tab rather than copy the URL, close the original tab, open a new container tab, and paste the URL.

[groovecoder]

Thanks @pmac

[hasanen]

Perhaps it isn't that big of job add a feature to convert tab from container to another within this?

[gwynnarth]

This might be a good enough solution for #325 I think.

[maverick74]

This is a very important feature that will ease job a LOT, from my point of view :).

Thumbs up for this :)

[smichel17]

Privacy-concerned user here. I would prefer that external links not all be opened in the same context. So, I would not consider this a good enough solution for #325.

Would you consider allowing users to specify which container they would like to open each new tab in?

Example interface

First, add a setting akin to the one for downloads, Open external links in with the options of selecting a default container or Always ask me where to open links. Screenshot for reference:

edit after a little discussion: I do not think it is important to be able to choose a default container. The below can be modified to choose between Open external links outside of containers and Ask me which container to open external links in.

If Always ask me where to open links is selected, links get pre-filled into the URL bar with the cursor placed at the end, with drop-down options to open it in either the global namespace or a specific container. Quick pixel art mockup:

[smichel17]

I think there are two related but definitely different questions here: one is about privacy and the other is about convenience.

Privacy

• The problem: It is difficult to keep profiles separate because it is hard to control what container an external link is opened in.
• A solution: Add the ability to choose which container a tab is opened into.
• This is a duplicate of Handle external links that should not be opened in Default context #325.
• Moving a tab to a new container after it has been opened is not a solution; by that point, the separation of containers has been compromised.

A great example of the privacy problem just happened to me: I was in my development container and went to create an account on http://discourse.mozilla-community.org/. I put in my email address and sent a confirmation email, opened my email client, clicked the confirmation link... and confirmed my account outside of a container. Ooops.

Convenience

• The problem: My tabs are unorganized, and I'd like to organize them.
• A solution: Add the ability to move tabs between containers
• The reason it's easy to confuse this and the privacy problem is that tabs coming into the default container causes clutter in addition to the privacy issue. Two problems, same cause.
  • There are other ways tabs can get cluttered besides external links so I think it is still valuable even with the privacy problem resolved with a solution like I proposed above.
• While the wording is a bit confusing, Can't add Open Tab to a Container #317 is talking about this convenience problem -- @aleth's comment about using them for tab management.

I suggest this issue be renamed and focused in on the privacy problem, and discussion about the convenience problem can take place in #317.

[gwynnarth]

Too bad one cannot upvote on a comment. I agree with @smichel17's analysis above.
I would just add to it that tabs opening in a wrong Container might be also a convenience problem, not only privacy problem.

For example: if I try to open a work-related GDocs link in a Default container (where I am logged on my private Google account) it will fail because I am not permitted to do so. I have to reopen the link somehow in the Work container where I am logged to my corporate account. Another example would be a link to something on Facebook (profile, photo... whatever) - I am logged in only in my Facebook container so in Default container I will get login page. In that scenario, where we talk about "semi-trusted" links the result is simply inconvenience because opening in Default container will not yield expected result. For that problem the ability to move tabs between containers post-factum is, in my opinion, good enough.

As for security and privacy I think I personally would like to handle this like that:

• Create a new "Untrusted" container.
• Set it as a default container for external links.
• Configure the container's security rules so that it does not retain any data when container is closed (for that we need to have per-container security settings, something a'la Container security "personas" #314).

At least for me, the above scenario is a perfect balance between convenience (I don't have to choose the target container each time) and security (the "Untrusted" container by definition contains no sensitive information).

[smichel17]

Too bad one cannot upvote on a comment.

"Upvotes" are just thumbs up reactions. Click the smiley in the upper right of a comment.

For that problem the ability to move tabs between containers post-factum is, in my opinion, good enough.

Most of the time, probably. Sometimes when you try to go to a page meant for logged-in users it'll redirect you to a login page without including a redirect back to the page you were on (or it will store that information in a cookie, which won't be transferred when you move that tab into another container). For example, I tried to copy-paste the mozilla discourse link into a new tab in the correct container, but it expired after I followed it the first time, so I had to re-send it.

As for security and privacy I think I personally would like to handle this like that:

-snip-

I will point out, the "Untrusted" container could actually just be no container (the default context), and you could configure it not to accept cookies, retain history, run js, etc. So I guess I should revised my comment above to say "A solution" instead of "The solution." (Although, I personally prefer my solution to (or in addition to) the "secure default container" one.)

[gwynnarth]

Thanks @smichel17 for the hint about upvoting! :)

While of course I could configure Default container to behave like you described that wouldn't save me from creating a 'Trusted' or 'Private' (or 'Whatever' really) container that would override these settings - because I do want my cookies retained for most websites. At the moment I treat Default container as my 'Private' container where I am logged in to all my non-work-related site (this is of course just one way to use it).

All in all I think it is easier to create one 'Untrusted' container and configure it like I described above than override the default browser policy for X other containers. Mozilla could even preconfigure such Untrusted container to make it easier for non-power-users to adopt such scenario.

Both scenarios can and should coexist if your proposed solution gets implemented - and everyone would be able to pick their favorite :)

PS. In my ideal world I would be able to alternate easily between the two scenarios - by default links are opened in Untrusted container and if I alt-click it then it allows me to choose which container to use. Or the other way around. Unfortunately that's not going to be possible since it requires OS support or third-party app support. Not going to happen :(

[MurzNN]

IMHO most of users use containers not for serious security reasons, but for easy switch profiles in services (for example, corporate and home logins in Google and Facebook). And errors when you open wrong container happens very often - you see wrong login and want to switch it. So ability to switch container of already opened tab will do this in more comfortable way.

P.S. Maybe at first we can solve this issue via separate extension - is this possible? If any want, it can install it, by default behavior will keep like now - without ability to change container of already open tab.

[Stis]

OP's title. I really need this simplicity, and i use it lots of times per day with Multifox right now.

I understand some may be concerned by security, but since I use Multifox a lot, i'm already used to pay attention to which profile/container my external will open. Losing simplicity I have right now for security... no, I prefer to stay vigilant. It's a good rule.

[jonathanKingston]

@smichel17 you talk about "Add the ability to choose which container a tab is opened into." which is a sound solution for the privacy problem. However it comes at the cost of harming convenience, if every link a user had to choose a container they are likely to suffer from "alert blindness" and just click any rather than making a good decision. I think once you can assign a URL to a container and you don't have cookies in a different containers we could make this simpler. For example:

• Open example.com in a work container.
• Example.com links to shopping-site.com.
• Browser shows a list of options to choose the container to go into before opening the link.
• User selects shopping and the new tab is opened as shopping.
• User visits another site linking to shopping-site.com and browser would choose shopping by default
• If a user right clicks and chooses a different container for shopping-site.com the browser would always show the choice screen when there are multiple the user has viewed the site in.

This would give users the privacy but also keep the convenience for less frequently used sites.

"Always ask me where to open links" is an option I would get behind certainly.

@MurzNN yes most of the containers work that has happened will be possible in an extension when the API changes we needed hit stable: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/contextualIdentities

[smichel17]

@jonathanKingston agreed on all counts. Choosing which container to open a tab into is one solution of several to the privacy issue. If it were chosen, it should come along with a preference to be disabled and always open into the default container.

[neclimdul]

"Essentially you turn containers into a organisational tool rather than a privacy one. "

This is actually exactly the opposite of the reason I want to move containers.

Lets follow the process:

1. Click a link in email.
2. "Oh, I'm not logged in to application X... right not the correct context. "

No there are two options

1. I copy the url, open a new tab in the container, paste the url and go, close the old tab. This just bypasses the privacy concern but it also makes me angry because I had to grab my mouse and do a bunch of stuff.
2. I log in. This not only bypasses the privacy, it messes up all the privacy on my hole un-associate container. Also, again I'm angry because containers didn't work for me.

In reality, just sending a URL to a container is the least destructive privacy option and people are going to do it anyway or not use containers so it could at least be easier and done in a way that the extension has the possibility of cleaning up tracking tokens and stuff.

[ArchangeGabriel]

So, I’ve finally found some time to read everything about this issue and I now see what the point is, but my opinion is that this is plainly wrong anyway.

The concern is about privacy leaking when reloading the URL into another container. But not allowing to reload an existing tab into a different container does not solves this, because instead people will just do as they do now, i.e. reloading tabs manually but with the same result regarding privacy! So unless you’re planning to educate users about it (which would by the way be a tad easier if you had a warning about this in the reloading tab in a different container UI), refusing this non-feature makes no sense to me.

So as far as privacy is concerned, I’ve come to realize that there is only one solution: every site is a container, which is a title I’ve seen in my GitHub notifications but have yet to read about. But anything else means you will end up at some point leaking privacy.

Now don’t get me wrong: I’m looking for privacy, not tab management. But it’s not until now and reading everything that I understood the privacy implications of my behaviour. And indeed I don’t want to reload a tab into a different container, at least not blindly (but I think no-one ever thought about blindly reloading, generally we always have good reasons to do so), but I didn’t know that before reading everything here. So that’s my point on educating users: in the current way of doing things, they are no warnings, just something that looks like a missing feature in this add-on.

[cj1985]

Has this issue ever been solved or has it been stonewalled by one or two powerful figures' obsession over privacy?

(I love it when those in control think that how they trade-off privacy/safety and convenience is also how everyone in the world should do so. It's like if they prefer vanilla to chocolate, they think that everyone in the world should do so too. No, some of us are actually adults who are capable of deciding if we prefer chocolate to vanilla.)

The only reason I'm using Containers rather than MultiFox is that MultiFox was shut down. I'd much rather still be using MultiFox which was far better, especially because of this one single feature.

If you're obsessed over privacy, a very simple solution is to offer an additional option where Containers users can choose whether they want this feature. I don't know why this hasn't been done yet.

                                 - Just another annoyed user.

[jplatte]

@cj1985 This issue has been solved insofar as there being another addon that adds this feature if you want it: https://addons.mozilla.org/nn-no/firefox/addon/context-plus/

[cj1985]

@jplatte: Thanks, this Context Plus add-on you recommend is certainly an improvement over the status quo. However it still isn't as quick and convenient as MultiFox. Ideally, what I (and I believe many others) would like are these features (which were provided by MultiFox):

Feature A.
Step 1. Click once on Multi-Container button, list of profiles shows up.
Step 2. Click on desired profile, new tab opens with current URL but with selected profile.

(In contrast, the Context Plus add-on requires that I (i) right-click on the tab; (ii) move mouse cursor down to "Move to Context" and wait for further drop-down window to appear; (iii) then "Ctrl+Click" desired profile.)

Feature B. The ability to rapidly open the same URL across multiple profiles. With MultiFox I could just click the MultiFox button, then click-click-click-click across all my different profiles and open up multiple tabs with the same URL, but each with a different selected profile.

(In contrast, the Context Plus add-on closes the earlier drop-down windows and immediately brings me to the new tab once I click on one profile.)

Hopefully someone can modify this add-on to have the above features. (I have also added the above requests as a review to the Context Plus add-on download page.)

[jplatte]

@cj1985 I'm not an addon dev. I'd recommend pitching this to the developer(s) of Context Plus, probably via a GitHub issue (https://github.com/totallymike/contextPlus/issues).

[Karlheinzniebuhr]

+1

[maphew]

I created the wiki page which is perhaps clearer. Happy to answer questions to make it clearer though.

Thanks for the wiki page. It made this long twisting thread understandable. Maybe edit the OP to reference it.

My 2c: "Containers" is an unfortunate choice of word, "Profiles", "Personalities" or at least "Profile containers" would be better. Containers are bins I throw things in to manage them, like with like, cups with glasses, bowls with plates. That's what I want to do most often with my tabs, without concern for privacy, it's all me and they're all mine, in the same kitchen.

Profiles are when I want different personalities and strong divisions between, different kitchens, a.k.a privacy. Using a name that highlights the design purpose might help with the confusion and reduce the 'another annoyed user' occurrences.

[faelin]

Why is this not a high-risk config item that I (the end user) can choose to override? I am mostly using containers for reasons other than tracking privacy, but the ability to quickly "containerize" a tab in-place so that it is added to a container or moved to a different container would save me the currently equivalent right-click -> "Open in New Container Tab" -> close old tab. I can already do this in three clicks, why make me create a macro to allow this? Just let me do this by default!

[reikred]

Honest question: Is it also insecure to open a new tab in the desired container, then copy/paste the URL from the old (wrong) container to the new (correct) container? That is, will this potentially reveal that these two containers are in the same browser instance?

[faelin]

TL;DR: yes, copy/pasting specific (unique) URLs increases your likelihood of being tracked, but you're already at risk of being fingerprinted even if you properly use containers, due to your browser's unique characteristics.

@reikred that somewhat depends on the nature of the URL you are opening. If it contains personalized tracking information in the URL query path (such as a unique user id, share-id, link-id, or other such session tracking parameters) then yes, the web server will potentially correlate the two browser "sessions" (containers) as belonging to the same user.

However, if you were copy something generic, such as say http://www.google.com, then the containers are as isolated as if you opened a private browser session: there are still identifiable features that the server may be able to track (there are many resources for learning more about browser fingerprinting, but I recommend amiunique.org). In other words, even with containers, the average web server may still be able to identify you as a unique user, and correlate your various containers as belonging to you.

[reikred]

@faelin , Great reply. I understand. URL with embedded personalized tracking parameters such as ?share-id=someuniquehexstring are a definite problem.

Going one step further: The OP proposed a function to move a tab to a different container. Suppose the move function removed all URL parameters from that tab (and it's history) URLs before moving the tab. Remove anything of the form ?name=value.

Would that make the move operation no less of a privacy concern than the copy-paste-to-other-tab-within-correct-container?

You can probably see where I am going with this idea...

[faelin]

It is not a safe operation to "blindly" remove tracking parameters from a URL. There are blockers (such as uBlock Origin) which offer options to strip suspected tracking parameters, but there is currently no way to reliably/safely do so automatically. Stripping parameters that look like tracking parameters, may damage your session or retrieve unintended paths. Moreover, most websites use query parameters (i.e. anything of the ?name=value format) for many necessary operations, for example when using a search function.

EDIT: this add-on for Firefox has made an attempt at this exact behavior (although it will not be 100% reliable): https://addons.mozilla.org/en-US/firefox/addon/clearurls/

However, you are correct: there is no greater risk in allowing users a shortcut to "reopen tab in new container" versus the copy-paste-close actions described above. There is no reason to limit this kind of operation aside from an attempt to "idiot-proof" the Containers system (and, as we know, "if you make something idiot-proof, someone will just make a better idiot").

In fact, I have installed the Switch Containers add-on for Firefox, which enables the exact behavior we are requesting. However, the add-on is not monitored for security risk, and so an official addition to the Firefox Containers system that enables this behavior would be far preferable.

[reikred]

@faelin, another great reply. I will try switch-container

[pmac]

I've used this one to move tabs between container contexts for years now and it's worked well https://github.com/totallymike/contextPlus

[reikred]

Sadly, none of the addons suggested thus far preserve the tab history.

switch-container did not work at all for me (functionality not added in any menus AFAICT).

switch-container-plus works but does not copy the tab history

contextPlus github page says it does not copy tab history

I guess the next thing I might look for is an addon that can export and import a tab history...

[faelin]

@reikred you are right, the history isn't preserved. I've grown used to that, but I agree that it's a problem! It would be a huge benefit to have that built natively into the behavior :(

To be blunt, I think that any admin resistance to this feature as a concept is purely due to personal opinion, and not a reasonable security concern. However, I am not a Firefox developer, so I cannot comment on the difficulty of implementation. Perhaps I can attempt to build a fix and send a pull request!