Security/Automatic Private Browsing Upgrades
From MozillaWiki
< Security
Contents
Description
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
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:
- We open the "protected" URL in a new private browsing window and show a notification bar
- The original tab is navigated to about:blank (or maybe closed if it doesn't have any history)
- We delete the protected URL from the history
- We purge all site data (cookies, localStorage, cache, etc.) associated with the protected URL
Prospective clients
Example websites that might be interested:
- https://womensrefuge.org.nz/WR/Legal/Internet-Safety
- http://shakti-international.org/how-to-hide-my-visit/
- http://www.kidshelpphone.ca/Teens/AboutUs/How-to-Keep-it-Private.aspx
- http://www.childline.org.uk/explore/onlinesafety/pages/covertracks.aspx
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
- Initial idea (W3C Privacy Interest Group)
- Blushproof: detecting when private browsing should be used and prompting users
- Clear Site data: new spec to allow sites to clear site data themselves
- Upgrade insecure requests: another spec which defines a new CSP directive
- "_private" browsing context