133
edits
|  (→Discovering the feature:  Added image and description of way to access container) |  (→Persisting containers:  Added purpose-specific containers section) | ||
| Line 30: | Line 30: | ||
| ** I work at a technology company which primarily  focuses on our website. Being able to view the site with a fresh set of cookies this easily is awesome. We use incognito mode currently, but that has the limitation of each tab/window sharing one set of incognito cookies. | ** I work at a technology company which primarily  focuses on our website. Being able to view the site with a fresh set of cookies this easily is awesome. We use incognito mode currently, but that has the limitation of each tab/window sharing one set of incognito cookies. | ||
| == | ==Site-specific Containers== | ||
| Previously, our idea was to tie persistent containers to bookmarks and have a per-origin container. The way this works is by adding a new setting on the bookmark interface that, when activated, would force the browser to open Twitter in its own container. Internally the container would probably be named after the origin of the site being bookmarked. | |||
| To access this, when you type twitter.com in the URL bar, the bookmark will be picked up and the "contained" bookmark used instead. | |||
| Alternatively, when you navigate to twitter.com, the browser could show a ribbon at the top that says: "hey, you normally open this in a container, would you like to do this now?" with a button to close the tab and open a new container window. | Alternatively, when you navigate to twitter.com, the browser could show a ribbon at the top that says: "hey, you normally open this in a container, would you like to do this now?" with a button to close the tab and open a new container window. | ||
| One nice thing about tying containers to bookmarks is that we know what origin the container is meant for. This means we can clear all non-Twitter cookies for example. We can only do this for containers that are isolated to a site, because for long-term tasks (e.g., shopping for a mortgage) may desire long-lived tracking cookies. | One nice thing about tying containers to bookmarks is that we know what origin the container is meant for. This means we can clear all non-Twitter cookies for example. We can only do this for containers that are isolated to a site, because for long-term tasks (e.g., shopping for a mortgage) may desire long-lived tracking cookies. | ||
| Since then, we recognised a few problems with per-origin containers: | |||
| * When I sign out of a site, will that site-specific container disappear? | |||
| * The website I signed into saves a whole bunch of cookies that are outside of its origin. How will the browser know that these out-of-origin cookies are associated with a specific site container? | |||
| * As written above, some long-term tasks involve tying together multiple services that needed to be connected to each other | |||
| To address this problem, we proposed a very simple model of purpose-specific containers. | |||
| ==Purpose-specific Containers== | |||
| [[File:Containers-start-page.png|900px|frameless]] | |||
| * Firefox comes with a set of containers that, through user research, our users will likely need and benefit from: | |||
|   * Personal (to use at home) | |||
|   * Work (to use at the office) | |||
|   * Banking (for accessing sites with financial or sensitive informations) | |||
|   * Shopping (for accessing ecommerce sites) | |||
|   * Custom (for future versions) | |||
| * Through naming and onboarding, we gently encourage users to use different containers for different purposes, as separation limits tracking and improves security | |||
| * A purpose-specific container can have many sites in it: | |||
|   * The Personal container can be signed into Outlook, Facebook and Twitter. Work can have Outlook, Facebook and Twitter, too. | |||
|   * The Banking container can be signed into your bank, insurance, accounting and investing websites | |||
|   * The Shopping container can be a place for Amazon, Alibaba, and other stores | |||
| ===Behaviors=== | |||
| By creating containers, we also create a notion of sites that exists ''outside'' of a container. This necessitates a few behaviors when you navigate from inside a container: | |||
| Manually-invoked navigation: | |||
| * Right click menu will have two additional options | |||
|   * Open Link in New Tab (this opens the link in the same container) | |||
|   * Open Link Outside of This Container (this opens the link ''outside'' of the container) | |||
|   * In future versions, we’d like the ability to open link in a specific containers | |||
| * Command-clicking a link will open that link in a new tab in the same container | |||
| Site-invoked navigation: | |||
| * window.open always open in the same container as the site that opened it, so as not to break single sign-on | |||
| ==Making containers look different== | ==Making containers look different== | ||
edits