Allow PB to be active in Incognito windows (Was: Respect private browsing mode)

[diracdeltas]

During Private Browsing mode, we should probably keep a separate store that gets cleared when the private browsing session ends.

[garrettr]

That's what Lightbeam does as well. The connections within that private browsing window can be visualized, but are not stored. They also pop up an alert to explain what's going on to the user. Code.

[garrettr]

Jetpack has a Private Browsing API.

[garrettr]

After a conversation with @diracdeltas and @pde today, here's what we ideally want:

Privacy Badger runs in private browsing windows. We need a separate data store for private browsing that is identical to the main data store, but stores all interactions (observed domains, heuristic blocklist updates, and per-host user settings) from private browsing. When the private browsing session ends (no more private browsing windows are open), this data store is cleared.

Slightly tricky: keeping the private data store updated as changes to the main data store occur (since users may have both a private session and non-private session concurrently).

We can use sdk/private-browsing to determine if a window/tab is private with isPrivate, and we can detect when the private browsing session is over (last private browsing window closed) by listening for the system event last-pb-context-exited.

IMHO the best way to implement this is to abstract all of the storage into a single object, which can maintain the non-private (persisted) and private data structures transparently. I think we'll need to pass it the window whenever we use it so it can determine whether we're in a private context. It can also listen for last-pb-context-exited and clear the private data stores transparently.

A quick skim of the code shows that this isn't too hard. Most of the places where we update storage have or are near the relevant window object, so we should be able to provide it with minimal refactoring. Requiring another parameter is a little clunky, but seems necessary. I'm open to other ideas.

[diracdeltas]

What happens if users have multiple private browsing sessions open at once?

[pde]

Probably it's good enough to treat all private browsing sessions as the same thing for now. Private browsing is not designed to be useful against remote tracking attackers.

Having said that, if there's a very easy way to make the state be kept per-session, we might as well do that.

[garrettr]

What happens if users have multiple private browsing sessions open at once?

All open private browsing windows share the same state, so I don't think it's possible to have multiple private browsing sessions open at once. Basically, as soon as one private browsing window is opened, a temporary set of state is created, and is maintained and shared across all private browsing windows as long as at least one private browsing window is open. When the last window is closed, this temporary state is cleared.

[diracdeltas]

Decided that this should be punted to a later release.

[diracdeltas]

For the record, in 0.1, Privacy Badger simply ignores private browsing windows. See https://developer.mozilla.org/en-US/Add-ons/SDK/High-Level_APIs/private-browsing.

[diracdeltas]

Note that we are also not active if user chooses "Never remember history".

[garrettr]

"Never remember history" is basically "every session is a private browsing session, but with the normal UI" (confusing)

[diracdeltas]

It makes sense to use the state of Privacy Badger from a user's normal browsing session as the initial state of Privacy Badger during Private Browsing sessions, but user feedback has shown that many frustrated people are on Private Browsing by default or set "never remember history".

I would like to have a working solution for them in the next release, and it should even be good enough for Tor Browser Bundle users. Here's a proposal:

1. During a private browsing session, store userset and heuristic-set blocking state in a separate data structure that gets deleted when the session ends.
2. When the session starts, seed blockedOrigins with a hardcoded list of "well-known" trackers. @pde suggested generating this based on selenium crawls or data voluntarily collected from actual Privacy Badger users, but perhaps it's good enough for now to just fork the Disconnect list (which was generated from a crawl IIRC, though it may have been a while ago): https://github.com/disconnectme/disconnect/blob/HEAD/firefox/content/disconnect.safariextension/opera/chrome/data/services.json

[diracdeltas]

On second thought, it might be fine to persist blockedOrigins between normal and private sessions. It only stores eTLD+1's that are commonly-used enough to track you on 3 or more 1st parties. Seems unlikely to leak sensitive browsing history information this way.

originFrequency, however, should not be persisted beyond private browsing sessions because it stores first party origins as well.

So we can do accounting in originFrequency or originFrequencyPrivate depending on the window's privacy state. Then if (Object.keys(storage.originFrequency[origin]).length + Object.keys(storage.originFrequencyPrivate[origin]).length)) >= 3, add origin to blockedOrigins. When the private session ends, delete originFrequencyPrivate.

thoughts?

[diracdeltas]

Another, bigger issue: the nsICookiePermission is window-agnostic, so blocking/allowing a cookie in either session type blocks it in the other. :/