Overview
This is a proposal for an approach to make Chrome extensions work while in incognito mode.
Status
Partially implemented.
- Hidden behind the experimental API flag.
- Allows users to enable running an extension in incognito on a per-extension basis.
- No major API changes.
Problem
For the first version of the extension system, we disabled extensions in incognito mode. This was done because it was challenging to come up with a good extension API that would preserve incognito's promise: that incognito browsing history is not persisted to disk. With a naive approach, it would be too easy for extensions to forget to handle the incognito case and end up writing history data to local storage.
Goals
1. Extension settings are accessible from incognito (if the user changes a preference from incognito mode, it should persist).
1b. Extensions can purposely override incognito in order to persist important data.
Rationale: if a user wants to consciously persist data, we shouldn't stop him. Such data might be settings, or bookmarks.
2. Extensions that care about incognito will be aware of what mode they are in, and can react accordingly.
Rationale: some extensions could take advantage of incognito. For example, a Tor extension might augment incognito mode to route incognito traffic through Tor.
3. Make it difficult for extensions to accidentally persist incognito data to disk, but possible to intentionally do so.
Rationale: without some safeguards against this, it will be too easy for extensions to break the incognito promise. Note that "disk" is the key word here - we can't prevent an extension from storing/leaking data remotely, and we will make no attempt to do so.
Note: it's unclear how important this particular goal is, and whether the benefits are worth the costs. For the time being, we will ignore this goal.
Proposal
The proposal is two-fold, with each part being somewhat independent, depending on where the cost-benefit tradeoff lies.
User Control
Enabling an extension in incognito is controllable by the user. It is undecided whether this will be opt-in or opt-out. As of this writing, there is some UI in the extensions management page that allows a user to enable/disable an extension in incognito mode. An additional "incognito" permission in the extension manifest indicates that the extension is "recommended for incognito" - the idea being that a developer will set this permission if he has tested his extension in incognito and promises that nothing OTR is written to disk. This value will serve only as information to the user. If the bit is not set, we can warn the user if he attempts to enable the extension in incognito.
Developer Protection (NOT IMPLEMENTED)
As of this writing, it is up to the developer to test tabs and windows for the 'incognito' bit, and avoid persisting them to disk if it is set. In order to make it harder for developers to accidentally persist incognito data, we can also make some changes to the API.
Instead of simply sending incognito events to an extension's existing event handlers, we can require the extension to explicitly express interest in the incognito version of an event. To do this, we will add an extra parameter to the relevant APIs by which a developer can indicate that he wishes to receive information about incognito contexts.
Sample API calls:
chrome.tabs.onUpdated.addListener(callback); // callback will be called for regular tabs only.
chrome.tabs.onUpdated.addListener(callback, {incognito: true}); // callback will be called for both regular and incognito tabs.
chrome.windows.getAll({incognito: true}, function(windows) {}); // windows will include incognito windows.
