Security/Contextual Identity Project/Containers: Difference between revisions

Jump to navigation Jump to search

Security/Contextual Identity Project/Containers (view source)

Revision as of 22:47, 5 August 2015

45 bytes added ,  5 August 2015
Refactoring site-specific containers + moving it to end or wiki
(Reworking the description. Updating and adding to Use Cases.)
(Refactoring site-specific containers + moving it to end or wiki)
Line 41: Line 41:
* They can test a learning management system (e.g. Moodle) by having three containers: teacher, student, admin.
* They can test a learning management system (e.g. Moodle) by having three containers: teacher, student, admin.
* User Story: 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.
* User Story: 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.
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 site-specific 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==
==Purpose-specific Containers==
Line 117: Line 99:
* New button in the URL bar in the webdev edition (aurora)
* New button in the URL bar in the webdev edition (aurora)
* Detect users logging in and out of a service like Twitter that doesn't have support for multiple logins, and offer the feature to them.
* Detect users logging in and out of a service like Twitter that doesn't have support for multiple logins, and offer the feature to them.
==Alternative Features==
===Site-specific Containers===
Site-specific containers could be used to pin a container to a specific origin. Users could specify that a container only be used for a specific first-party.
For example the user may want to define a "Facebook Container" which is only used for isolating Facebook from the rest of the user's browsing. When the user types "facebook.com" into the address bar, they would receive a result which allows them to open their Facebook Container. The browser could also prevent or prompt the user from navigating to other sites within that container.
The browser could also take steps to prevent the user from browsing a specific site outside of its container. For example, 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.
When we link containers to a specific origin (i.e Facebook Container), we may be able to offer some additional features to users. For example, we can clear all non-Facebook cookies from that container each time the users finishes a session in the Facebook Container.
Site-specific containers raise some issues and questions:
* 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?
* Some sites may require that the user interact with multiple top-level origins during a session, or may require cookies from multiple origins.


==Related work==
==Related work==
Englehardt
Confirmed users
25

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/1088585"

Navigation menu