Add support for private windows

citp / news-disinformation-study

A research project on how web users consume, are exposed to, and share news online.

8 stars 2 forks source link

Add support for private windows #45

Closed jonathanmayer closed 4 years ago

jonathanmayer commented 4 years ago

Tentative plan:

Use the spanning manifest value.
Add an option to each study module (default disabled) to measure in private windows.
Require study-specific consent if we're going to measure in private windows.
For the initial news/disinformation study, we won't measure in private windows.

Note that we need private window permissions to track loss of user attention if the user switches to a private window.

jonathanmayer commented 4 years ago

I've finished adding optional private window support to the PageEvents and Navigation modules. @PranayAnchuri, could you please implement similar support for the LinkExposure, SocialMediaAccountExposure, and SocialMediaNewsExposure modules you're developing? And @akohlbre, same for the SocialMediaSharing module? Should be (relatively) easy...

For webRequest functionality, there's an incognito flag in webRequest.RequestFilter.
For contentScripts functionality, see https://github.com/citp/web-science/commit/9b5e00b271cb33aa044b8178421b53f9157c4aa7 for a possible approach.
For tabs and windows functionality, see the mind-numbing event management in PageEvents. You shouldn't have to deal with any of that.

While I don't expect we'll run measurements in private windows anytime soon (if ever), we still need to handle them because PageEvents attention tracking requires the private window permission.

jonathanmayer commented 4 years ago

@biancadanforth, I'd appreciate your thoughts on the approach to private window support for content scripts in https://github.com/citp/web-science/commit/9b5e00b271cb33aa044b8178421b53f9157c4aa7. I'm not thrilled about running unnecessary content scripts in private windows.

An alternative direction that comes to mind is listening for a URL change with tabs.onUpdated, getting the private window status from the tabs.Tab.incognito property, checking if the page matches various criteria (such as having a domain of interest and not being in a private window), and then running the content script with tabs.executeScript. This approach would be essentially identical to what you previously proposed for more efficiently matching multiple content scripts against a URL, with the added step of checking private window status.

Edit: I thought more about this alternative direction, and I'm concerned about a possible race condition. A call to tabs.executeScript attaches a content script based on a tab ID. This leads to an unlikely—but possible—scenario where the page contained in the tab changes between when we decide to attach the content script and when the content script executes. The declarative approach (with contentScripts.register) avoids this issue.

https://bugzilla.mozilla.org/show_bug.cgi?id=1452045 https://bugs.chromium.org/p/chromium/issues/detail?id=374329

akohlbre commented 4 years ago

SocialMediaSharing done in e738bc0

PranayAnchuri commented 4 years ago

Done for LinkExposure, SocialMediaNewsExposure and SocialMediaAccountExposure.