It's only confusing if you're a technical person -- the sort of person who hears "containers" and thinks "oh, Docker." For laypeople who don't have that association already burned into their brain, it's a simple label that pretty clearly communicates the purpose of the feature -- much less scary-complicated-sounding than "contextual identities."
Yes this, we did some brainstorming and solicited user feedback about names and decided Containers makes sense for a general audience. Docker Containers and 'Contextual Idendities' are kind of inside baseball.
I like persona too, or facade, or anything else that shows this is about what you present to the world... but most users won't think of it that way. Theyll think of it a keeping a bunch of sites in a box. They don't think about how the internet sees them, only how they see the internet.
> Containers describes the implementation, not the user experience or benefit.
This. Sure, "contextual identities" sounds too academic, but who knows, maybe Containers (as a word) will become as ubiquious as Tabs are today (very common word in German today): Hey, dude, open a container ;)
I'd have gone with "facades" or "partitions" personally, because I'm seeing it as the divisions of your identity. But I'm thinking to a user they don't think about how the site sees them, they think about how they see the site, and keep their set of sites in boxes.
In other words, you found that deliberately misleading (and therefore attracting) a public that only knows "containers" as a buzzword was more important than reducing ambiguity in the technical world. Nice. Ya coulda used cans, bottles, flask, vat, pot, vessel, tub, ... etc, etc.
if you're a technical person you don't associate containers with docker. That technology is much older than docker and even with that there're so many alternatives than docker is just one more.
Containers are great. I've been using them for a bit. They definitely need a few things. Like an ability for the "new tab" to be sticky (if I'm in a container - new tab should open in the same container), and the ability to pick which container to open things in when the OS triggers the browser to open a URL. Right now it's very leaky... Say I start a registration process for a site in a container, they send a email confirmation, I click the link and it opens outside of the container, leaking the cookies. Bad for OPSEC.
Agreed. Right now we're pretty hands off about modifying default behaviors, link handling etc. Chalk this up to us wanting to be unopinionated about specific use cases, but there are definitely some optimizations to be made to shore up the situations you describe. Test Pilot is for WIP software, so don't be shy about filing issues.
Would it be possible to have an add-on for this? One that automatically opens each website in a new container? That would allow default behaviour for most people, but for those that want isolation, it would be easy to get it.
It would be great if it could create automatically one container per domain: every site would be neatly separated from all the other ones. If you logged in Facebook the other tabs for other sites wouldn't know about it. Doing that manually every time is almost impossible.
There is a feature called First Party Isolation that (I think) does what you want for normal tabs, and can already be enabled through about:config. (initially developed for the Tor Browser Bundle, their description of it is here https://www.torproject.org/projects/torbrowser/design/#ident... )
Beware that privacy.firstparty.isolate might break some sites that depend on third-party services for login authentication or comment systems. If you find any broken sites, you can report them in Bugzilla and mention this Firefox bug:
I use noscript to by default turn off scripts from 3rd party sites (unless whitelisted). It breaks quite a few sites, but it also makes lots of sites load quicker and doesn't load a bunch of advertising/tracking stuff that I don't really want loaded anyway.
I would pay actual money to help get a feature like that into Chromium or Firefox. Hell, if Firefox added that exact feature I might actually rethink my decision to switch to Chrome once they drop support for all the addons I use.
There is an experimental implementation of that feature, called "First Party Isolation", in Firefox today. You just need to set the `privacy.firstparty.isolate` pref = true in about:config.
With this pref enabled, advertiser X will serve you different cookies on site A and B. They won't be able to track your browsing history from site to site. However, this breaks a lot of sites that depend on third-party services for login authentication or comment systems.
Here is the Firefox bug where you can report broken sites:
uBlock, NoScript, Self Destructing Cookies. Also DisableWebRTC. Firefox would be Opera, Chrome or Vivaldi without them. No particular reason to use it or a random one among the others. Stylish and Greasemonkey are useful too, when sites insist doing the wrong things. I hope all of them survive the switch. Will they?
The following GitHub issue tracks that feature request. It might be cool to ship a default classification list for common banking and shopping sites so they are already "contained".
1. Hello potch!
2. Yes, this is among the most requested features we've seen so far. Containers in Test Pilot will remain in active development for the foreseeable future, so I wouldn't be surprised to see such a feature forthcoming.
The UI/UX for container tabs will be a difficult design challenge. How do you explain to typical users what a contextual identity is and why/when they might want to use one?
I think per-window contextual identities, instead of per-tab, might be a good mental model. It's easy to explain to users that tabs in different windows can't see the same cookies. This is a generalization of Private Browsing window's throwaway context identities today. It's harder to explain that some tabs in the window are in the "Shopping" container and others in the "Personal" container.
Great feedback. A segment of people seem do correlate windows with containers more easily than tabs. We are measuring both window & tab usage in the experiment to get a quantitative sense for it too.
I personally use Tab Groups add-on and associate each of my tab groups with a container, but I also mix my containers in a certain group. E.g., sometimes I'm on hacker news for fun, and sometimes I'm here for work. ;)
Amazing. These types of changes are a step in the right for direction for Mozilla. I abandoned Firefox long ago for Chrome but now with containers, e10s, and Electrolysis I'm planning on moving back.
I realize it's somewhat off-topic, but when on Android, I have found no better browser than Firefox because of extensions. uBlock Origin is indispensable if you don't want to root your device.
I spent years before understanding how shorthands like e10s or i18n (InternationalizatioN) worked, and it was only when I heard about Andreessen Horowitz (a16z) that I understood …
I'm finding the reverse - I'm the last of my co-workers to still use Firefox as a daily driver (theyre all on Chrome) but the performance problems have just about made me give up on it. Too many cases of it freezing up, and Google Maps still makes it crash.
Can you run the "Pulse" experiment and provide feedback on the sites that are slow and/or broken? We will use that data to help debug performance problems - especially the worst ones on popular sites.
This seems like a reimplementation of Profiles, that you can use with `firefox -P`.
The main issue here is one of UI. If you click a link in a PDF, what profile should the link be opened in?
My take is that if you have multiple firefox instances it should ask you, otherwise it should just open on the only one open.
The idea here is to be lighter-weight than profiles, or the similar feature in Chrome. I've got three different containers going right now, side-by-side in one browser window. In addition to the per-tab basis, providing separation within a profile also means you don't have to set your preferences, addons, etc. independently each time.
For example, one of the major use cases for this sort of separation is being able to use multiple accounts on a site like Twitter or Facebook (which don't support multi-account) or Gmail (which does, but it's a bit rough). There's no reason I should have to have separate windows or separate addons for each of those accounts.
Just to be clear, this is NOT just a simple UI version of profiles. Containers only separate Cookies, localStorage, indexedDB, HTTP data cache, Image Cache (bug in progress), and other areas supported by originAttributes (See https://wiki.mozilla.org/Security/Contextual_Identity_Projec...)
I.e., Containers do NOT protect against some lower-level privacy vulnerabilities like plugin enumeration or history-sniffing that are mitigated more by using entirely separate profiles.
Is autocomplete also handled per container? There's an awful lot of privacy sensitive info that can be gleaned from there but it's not listed as being covered.
Firefox's autocomplete implementation doesn't insert values until the user sets focus on the input element, so Firefox wasn't vulnerable to the "sniff user info by autocompleting hidden forms" problem that Chrome was.
I am not worried about anything I was just pointing out that there is still a potential problem. I understand that for knowledgeable users like average joe on hacker news is probably common sense to disable such features if he wants "full privacy".
Anyways; it's not safe by default which should preferably be.
Firefox can autofill password fields if you choose to remember them yeah. There is a platform bug filed for making these container specific or choosing not to auto populate when they were saved in a container.
The test pilot experiment is really to help us to figure out how people are using containers.
IMO it would be awesome if we could configure a few privacy-related settings per container. For example, enabling first-party isolation for Shopping would be great. And creating a container that forgets cookies after a very short timeout (kind of like private browsing) would be nice, too.
Independent of Containers in test pilot, we are planning to do a shield study with variations of privacy-related settings toggled for users, then measure and ask users how their web experience worked. The goal is to find improved privacy related settings that don't break the web for people.
The section "How does the Test Pilot experiment differ from Containers in Nightly?" isn't really clear. It doesn't explain what Nightly (and Developer Edition) users should expect to what they use (if they're not willing to jump to Test Pilot).
Are container tabs are being moved out of the browser core to the Test Pilot walled-garden extension store? Or Test Pilot extension is just enabler and all the stuff is still in the core? Or core is becoming chromeless/API-only and extension does the UI? Or both systems are going to be developed in parallel (or maybe Test Pilot is fast-ring and built-in stuff is a snapshot of whatever looks stable at relase time)? Or is it something else?
All of the machinery is in core, and will stay there (much of it is also depended on by the Tor uplift project's first party isolation features). This Test Pilot experiment is predominately about iterating on the UI.
Test Pilot isn't a "walled garden extension store." It's just a bunch of normal Firefox add-ons that are authored by Mozilla and happen to be explicitly experimental / ephemeral.
Yeah Test Pilot just is there to help us gather more data on how people use Containers so we can shape it's future. Lots of people are asking for features and we would like to concentrate on the ones that users would like.
Containers are indeed internal to the browser using origin attributes which are a platform feature. We have opened this up to extension authors also in WebExtensions so they can play with ideas also.
Telemetry isn't an issue. If anything, it can be fully disabled. And yours is done right - all the data sent is properly described and observable. (Although it would be cool if there'd be a helper "let me decide later" mode when I can let browser collect data for a short while, get notified to review it, and then decide whenever it contains anything I consider sensitive or not...)
Maybe this is silly and irrational, but... While it's all your work (and thank you for this!) and decision, it just somehow doesn't feel right that an locally-installed software - no matter how experimental - is ephemeral, almost like it's not a software but a service. With normal AMO addons - even the experimental ones - I can browse the version history and roll back if something's not right. Test Pilot feels like end-user is completely out of control of whatever happens (unless they don't participate and just install from Git repos).
You're right. We keep control over the experiments so that we know the consistency of the data we're measuring.
A problem with using our full release channel Telemetry is that so many users have so many variables it's hard to compare apples to apples. E.g., was their performance issue caused by a setting, an add-on, the site they were on, or Firefox itself?
Test Pilot experiments give us some controls and parameters on the experience so we have a clearer idea of what's causing what.
The only main difference I can see besides the better UI/UX, is that you can create (and edit) containers, which you can't do in the Nightly version (or at least there is no UI for doing so). For instance you can create a 'Facebook' container, and then leave FB running in that, and not let FB track you across your life, cause that's just wrong. Before I kept FB in it's own Browser, which was annoying.
One surely can edit containers in Nightly. I did this for myself long time ago, when I've first learned about container tabs, as the default set was almost useless to me.
There's a setting, privacy.userContext.ui.enabled than enables management UI in the "privacy" section of "options" system (about:preferences#containers)
Is there any chance those could be synced with KDE Plasma's Activities (which implements a quite similar concept on the DE level)?
The biggest issue with using Activities has always been that browsers know nothing about them, so when clicking a link in any application, it was opened in the most recently active browser window - no matter which activity it was on.
So ideally there'd be a way to have Firefox simply inherit KDE Plasma's Activities as Containers, so one wouldn't have to maintain and somehow map Activities/Containers for both at the same time.
Containers are per-tab and isolate only tracking-related data (not bookmarks or history, for now). Also containers don't require that you open multiple instances of Firefox.
> How will users know what context they are operating in?
I find that themes are great for knowing what context I'm in, like the Totem mechanism in Inception. I'm not sure if we can have a different theme for each container though.
I am reading this name also on other places, surprised Mozilla sticked with "containers":
* https://blog.mozilla.org/tanvi/2016/06/16/contextual-identit...
* https://wiki.mozilla.org/Security/Contextual_Identity_Projec...
* https://wiki.mozilla.org/Security/Contextual_Identity_Projec...