Personal tools

Private Browsing Add-on Compatibility Checker

From MozillaWiki

Jump to: navigation, search

Contents

Background

We will be requiring extensions to support the private browsing mode, by not writing any data which can reveal users' browsing history to disk.  The AMO editors will need a tool to help them test extensions in order to make sure that they respect the private browsing mode.  The tool would need to try to automate as much of the process as possible (but of course, it wouldn't be possible to make it 100% automated.)

For the sake of simplicity, the tool will be called checker from this point on.

Use Case

The AMO editors will ideally use a workflow similar to what is outlined below in order to test an extension for Private Browsing compliancy.

  1. Editor selects an option to begin testing.  Checker puts the browser in private browsing mode.
  2. Editor opens a few tabs/windows with a unique web page, which has not been visited in the active Firefox profile.
  3. Editor selects an option finish testing.  Checker closes Firefox, and opens up a report window.  The report window will show which files in the active profile contain the visited domain(s), and which files contain the visited URLs.  If there is any file is found in this report, the test result is FAIL.  Otherwise, it's PASS.

Technical Specification

grepping the active profile directory looking for the URLs and domains visited during the private browsing mode when checker is active.  Checker needs to have the following functionalities in order to make the presented Use Case possible.

UI

It should provide two UI inputs, such as menu items, toolbar buttons, etc.  One of them tells checker that the test is going to start.  The other tells checker that it's going to end.

Implementation

The implementation needs to track the domains and URLs visited when the test is active, and later on close Firefox and start looking through the active profile for signs of those URLs and domains being recorded.  The implementation can be broken into the following three categories:

Starting the test

After the tester tells checker to start the test, it needs to put Firefox into private browsing mode, and start tracking the URLs and domains visited.  It should not output those URLs and domains to the active profile directory, because it defeats the purpose of the test.

Tracking the domains and URLs visited

In this stage, checker need to listen for porgress events on all tabs, and compile a list of domains and URLs that the user has visited during the test period.  It should also prevent the tester from turning the private browsing mode off, because it needs to control when that mode is turned off so that it can start the reporting phase.

Finishing the test and report generation

In this stage, checker needs to turn off the private browsing mode.  Then, it needs to spawn the reporting utility, and quit Firefox to release any possible file locks inside the active profile directory.  The reporter application should wait until Firefox has exited, and then start its job.

In order to use the same set of skills which is required to build the checker extension, and to keep everything portable to all the platforms that we support, it is advised to write the reporting application as a XUL application.  In this case, checker can run the XUL reporter application, and pass it the domains and URLs collected in the second phase as arguments.  In order not to be forced to ship a separate xulrunner runtime, Firefox itself can be used to run the XUL application.  You should however note that you need to specify another profile when running the reporter application, because the entire point behind launching a separate program is to make sure that no file in the active profile directory is being locked.  This can be done by creating a temporary directory and using a command line like this to launch Firefox:

/path/to/firefox -profile /path/to/tmp/dir -app /path/to/reporter/application.ini

The reporter application should enumerate the Firefox active profile directory which was used during testing, and read each file in that directory and look for the each item in the list of domains and URLs inside that file.  If the file contains an item in that list, it should report the file's name and path, as well as the domain/URL found in that file.

See Also

In order to know more about what we're trying to achieve with this tool, see my blog post.