Multi-account-containers: Password Protect Containers

[budhajeewa]

Would it be possible to protect Containers with passwords?

[andreicristianpetcu]

This is such a cool idea! :D :D

[jonathanKingston]

It depends... What are you trying to protect?

[budhajeewa]

@jonathanKingston

It depends... What are you trying to protect?

Here's an example: In my work PC, I've setup a separate container for my personal browsing. I want to protect that container with a password, so other people who have access to my PC can't access the container.

[jonathanKingston]

This comes always back to thread models really:

1. Are you trying to prevent access to current tabs you have hidden?
2. Are you concerned about history?
3. Are you trying to lock all data?

These are related issues to this problem:

• History is shared between all containers
• Storage (cookies, indexedDB) is unique to a container however protecting them at a browser level across containers isn't in scope at all.

1. Preventing access to current tabs you have hidden

This would be quite simple, as the containers are hidden the URLs are locked to a certain password.

2. Preventing access to history

History could be auto cleared quite easily for a container, however encrypting it is out of scope for the browser.

The extension could encrypt this and insert it back perhaps, however this is likely going to be leaky and also slow: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/history/addUrl

3. Preventing access to data

If you are concerned about storage, simply preventing the tab from opening wouldn't be good in an extension for these reasons:

• An extension that restricted access could be easily removed
• Storage in the browser is using the same databases etc (technical users can easily open the databases etc)

Possible extension model

The only feasible way to do this in an extension would be to:

• Auto clear history for this container
• Capture all data from a container
  
  
  
  • Insert into a database encrypted with the container password
  
  
• Encrypt it with the users password
• Delete all normal data stores

When the user wants to use this container again:

• Decrypt the data
• Place it all back into the websites stores

Limitations to this model include:

1. There are not APIs for all storages like IndexedDB
2. Querying and clearing by container storages is limited currently
   
   
   
   • There is only an API for cookies currently
   
   
   • There isn't an easy way other than history to find out what a container contains
   
   
3. This would likely be super slow

For 1. and 2. Are the biggest limitations here, however there bugs on file for that and storage access improvements.
For 3. Addressing the speed would also be possibly not so hard if you blocked a website loading whilst you restored the data it had.

Closing notes

This model wouldn't protect against attacks by other extensions stealing your password, loss of data when the user forgets their password and also against the OS itself.
Sharing a machine always is a risk, physical access to a machine is basically game over in terms of security to the highest level. This is mostly why browsers don't try and spend too much time protecting against this risk model.