Extension leaks private browsing data

[hlieberman]

trafficstars

Though the extension appears to be disabled in private browsing mode (the icon is not visible in the toolbar, nor can it be enabled), the extension continues to run in private browsing -- even if there are no open non-private windows. Images containing gps data opened in private browsing mode will appear in the list of images scanned, as long as a non-private browsing window is opened before closing the private browsing window.

This effect occurs even if the private browsing window has navigated to another page without the image on it.

[allanlw]

Argh. This is really complicated, so I'll record the waist-deep shit I just waded through to figure out a maybe-solution to this for future generations trawling through search results. The first question is, how can the extension get enough information to do something different with private browsing requests than non-private browsing requests.

gps-detect registers observers for a handful of events using the nsIObserverService service. This includes http-on-examine-response, http-on-examine-cached-response and http-on-examine-merged-response. When the response comes through, the addon registers an nsIStreamListener on the nsITraceableChannel of the http response, and then handles data chunks via the stream listener's onDataAvailable method.

This is a very low level API, and the add-on effectively gets alerted to all HTTP responses that get handled by the browser. There's no obvious way to correlate them with having originated via "private" or "non-private" tabs, but there is apparently a way to do it that is very poorly documented, and a good example of another addon that uses that way is HTTPSEverywhere, although they're actually listening on the http-on-modify-request event instead.

They have a very complex method of getting the browser XUL element for an nsIChannel. They take a "bottom up" approach. They even describe their method as "rather magical" and "opaque", but it does seem to work and is e10s compatible.

The source for their code (which has now developed further to support e10s) is apparently this help article, which has 3(!!) different ways of doing this, one of which is definitely out of date as it doesn't use nsILoadContext.

Open questions:

• Is this method applicable to http-on-examine-response as well?
• Is it sufficient to rip off the MDN code (which is Public Domain if it's new enough, or at least a permissive license) or am I going to have to rip out the HTTPS-Everywhere code, which is GPLv2+? I'd rather not get infected.
• What the hell do I do with the XUL browser object once I get a hold of it? How do I determine if it's private or not?

Of course this doesn't begin to tackle the more important question of:

• What is the correct behavior of private browsing? It seems as though that would be the most important time to get alerted of compromising EXIF information, but probably it shouldn't share the history space with the regular mode browsing.

[allanlw]

Now that this is a webextension, the previous post is irrelevant and this is blocking on firefox supporting incognito: split in manifest.json https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/incognito

[allanlw]

This could also be implemented by getting the tabId from the details object on the request listener and then seeing if this was an incognito tab via the tabs API. That's a bit roundabout though, and I definitely don't care enough to fix that myself, but I will accept patches.