Security/Automatic Private Browsing Upgrades

From MozillaWiki
Jump to: navigation, search
Warning signWarning: This is just a draft proposal for a new Firefox feature

Description

Flow

The goal of this feature is to provide a way for website authors to tell Firefox that the site should only be viewed while in Private Browsing.

A bit like HSTS but for local attackers.

Delivery Mechanism

We define a new require-private CSP directive. It can be delivered as an HTTP header:

Content-Security-Policy: require-private

or as a meta tag inside the page's head:

<head>
  <meta http-equiv="content-security-policy" content="require-private">
</head>

Triggers

Notification bar

There are three ways to trigger it:

  • Typing a URL in the address bar and pressing Enter
  • Opening a bookmark
  • Clicking a link

Once triggered, the following happens:

  1. We open the "protected" URL in a new private browsing window and show a notification bar
  2. The original tab is navigated to about:blank (or maybe closed if it doesn't have any history)
  3. We delete the protected URL from the history
  4. We purge all site data (cookies, localStorage, cache, etc.) associated with the protected URL

Automatic-private-browsing-upgrades.gif

Prospective clients

Example websites that might be interested:

Example websites without tutorial on hiding your tracks:

Security / Privacy Considerations

  • Malware sites could abuse this feature to better hide their traces, by essentially clearing the history after getting the user to download malware.
  • Because all sites in a private browsing session share the same cookie jar, third-party tracking (e.g. Google Analytics) is still possible.
  • If a user is using private browsing to separate Facebook from the rest, a site could defeat that protection by getting itself "upgraded" into private browsing without the user's consent and then share data with Facebook via the Like button.
  • A site could use this mechanism to probe whether or not the user is in Private Browsing mode though it would cause some pretty major UX disruptions.
  • This could be a way for sites to bypass the popup blocker.
  • There would be other traces in a user's browser:
    • They used a search engine to find the anti-abuse site and the search result page is still in the cache.
    • They were logged into their Google account when visited the site and it ended up in their account's Web History.

Mitigations

  • Users who regularly investigate malware will have an about:config pref to disable this feature entirely.
  • Third-party tracking is reduced by tracking protection.
  • Private sessions will isolate private browsing sites from each other.

Related