Consider making relatedTab not abide to current tab container

[jonathanKingston]

Now that we have assignment users of Google who wish to be tracked could assign it to said profile.

Can we consider making the default non containers as this is the best for leaking of data.

STR.

1. In a work container
2. Select some text
3. Right click, search in....
4. Work search is opened

Essentially all links and whatever should move to default tabs instead of in the current container.

See issue: Bug 1355433

[nkestrel]

I implemented this in Bug 1325014 and I think there is a strong argument for not letting searches implicitly leak into the default container.

• Such behavior needs to be very explicit about what container is going to be used and should preferably be optional, the user may not notice otherwise and end up visiting many pages in the wrong container.
• Doing a search in a work container should use your work google account with work seach history by default.
• You also have to consider the case of dragging text into the tab strip which performs a search using the current container.
• You can't assume the default container is safe for all searches, containers may be used for sensitive topics that should be kept separate.
• It should be expected that leaving a container takes some extra effort.

[jonathanKingston]

@nkestrel there is a strong argument either way, I would argue yours is more usability and mine is more privacy. I was actually pretty shocked this even landed into platform, especially as the bugs title and very little text mentions that was in the change.

Usability:

• "Doing a search in a work container should use your work google account with work search history by default."
  • The history will still exist in browser history, users can assign Google to work if they want it to be in their Google account.
• "You also have to consider the case of dragging text into the tab strip which performs a search using the current container."
  • Not sure if this is related, dragging text is pretty explicit into the same container. Other than it should ignore the assignment feature probably.
• "It should be expected that leaving a container takes some extra effort."
  • The harder it is to leave a container, the more users are likely to want "Reload in a different container" functionality, which is basically "tab management" and not containers.
  • I often ctrl+click or select search and leak into another page in the same container.

Privacy:

• "Such behaviour needs to be very explicit about what container is going to be used and should preferably be optional, the user may not notice otherwise and end up visiting many pages in the wrong container."
  • Opening a new tab for a search term just leaked website address and search term to the authenticated search provider; this currently isn't explicit or private.
• "You can't assume the default container is safe for all searches, containers may be used for sensitive topics that should be kept separate."
  • It's far easier to assume the default tab is used regularly as they are far easier to create.
  • Due to their increased usage it's also fair to say users shouldn't ever authenticate into them.
  • This is why I also propose that they are private/first party isolated by default when containers are enabled.

Users should be given the ability to protect themselves shooting their own foot off, even if they have to opt into that protection. I'm also pretty hard to allow user to change the accel+click behaviour for the same reason, again even if this can't be the default because of usability.

If you could please share how you use containers here this will give us a better idea of how you use them.

Thanks

[jonathanKingston]

I also raised Bug 1355433 so that the experiment can allow users the ability to turn off said functionality.

[nkestrel]

Bug 1325014 only covers the creation of related tabs through the new tab button, view source (Bug 1347604) and selection search. It builds on Bug 1276880 which covers the main case of inheritance:

If I have a link in a particular container tab, and open it in a new tab / window / whatever, I would still expect this to be using the same container. If I want to open it somewhere else (different container / no container), that should be the non-default / additional menu option.

https://bugzilla.mozilla.org/show_bug.cgi?id=1276880#c11

My original thinking was to make same-origin links open in the same container, while links that point to different domains should open elsewhere. But this gets complex. For example, what if the domain being opened has been opened before in the other container?

Following the Private Browsing behaviour makes it somewhat easier to think about. All links open in the same container by default, and if I want it to open in a different container (including the default container), I need to right-click and select which container I’d like to open it with.

https://bugzilla.mozilla.org/show_bug.cgi?id=1276880#c16

For the sake of consistency, either all related tabs should inherit the same container or they should all fall back to the default container. There should be no exception just for selection search since that is unexpected and effectively behaves as a leak.

Being able to do a selection search in a different container is a welcome feature but with the current inheritance approach the user needs to be given an explicit choice which container they want to use and if there is a default it should be the same container.

[jonathanKingston]

For the record: Bug 1355433 is literally allowing a pref to wrap all these, so it should be consistent across all the "new tab" behaviour the user does. Let me know if I am missing something here. This means links clicked in the page would still be in the same container as per Bug 1276880 and only ctrl/middle click opening in default based on the pref. We can always add in another pref to change Bug 1276880's behaviour too.

[ArchangeGabriel]

Hi there, I’m new to containers and really enjoy the feature. Search was one of my most complicate decision, especially with regards to the new “Always Open in This Container” feature.

I think I’d like all my search with DuckDuckGo to be in the default container (so not in the current tab container as it is now), but all my searches trough Google (either directly through their search engine or through a !g/i/… search in DuckDuckGo) to be in another isolated container (and if possible isolated from the one with my Google account logged in).

Would such a workflow be possible?

[linostar]

How about giving the user the choice which behavior he desires (new child tab is default container vs current container) by changing a value in about:config? Or add it to the containers window/panel.

And speaking of the default container (for new tabs that aren't created by clicking on a link), I very much like to see an ability to change it, similarly to the ability to change the browser default page. This could be done UX-wise by adding a menuitem called 'Make this container the default' in the container options panel. One example to illustrate the usefulness of this is when someone is at work and wants all his tabs to open in the work container, then he returns home and wants his new tabs to open in the home container, without having to choose the container each time he opens a new tab or presses Ctrl+T.

[tmottabr]

I think the best approach for this, from an usability perspective, is to be an option that can be set for each individual container.

One should be able to configure each container to open new tabs in the same container, in the default container, or maybe even not only in the default container but in any other container configured.

[practik]

Quoting @jonathanKingston from above:

We can always add in another pref to change Bug 1276880's behaviour too.

I would love to see this added. I could imagine it in the Container Preferences overlay, right under Icon and Color, but an about:config option would be fine too.

I'm also adding details on my specific use case at #428 as requested.

[grahamperrin]

From opening post https://github.com/mozilla/multi-account-containers/issues/434#issue-219990108:

See issue: Bug 1355433

– for search and other purposes:

1355433 - Add preference to disable "related tab" code opening in the same container

---

If I imagine one word struck through (correct me please, if this is a misunderstanding)

… all links and whatever should move to default tabs instead of in the current container. …

– then it's an upvote from me in the OP as well as in Bugzilla.

---

From a privacy perspective, the 'non-contained' experience (i.e. tabs that are in neither a named container nor a private window) can be excellent with strict enhanced tracking protection (ETP) in Firefox 86 and greater …

[grahamperrin]

Consider making relatedTab not abide to current tab container

– technically correct, however for vote and other purposes, it might not aid discovery.

@jonathanKingston maybe change the title?

Thanks

---

For what it's worth: this feels (to me) like an issue that could be pinned (but my sense could be way off – hundreds of other enhancement issues, some of which I have not read).