Security/Automatic Private Browsing Upgrades: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Added toolbar indicator)
(→‎Related: link to a new webappsec thread)
 
(6 intermediate revisions by the same user not shown)
Line 3: Line 3:
== Description ==
== Description ==


[[File:User_flow_diagram.png|300px|thumb|right|Flow]]
[[File:User_flow_diagram.png|500px|thumb|right|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.
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.
Line 21: Line 21:
  </head>
  </head>


=== Note on fingerprinting ===
== Triggers ==
 
This is not meant as a way for a site to probe whether or not the user is in Private Browsing mode. It could be used for that, but using it would cause some pretty major UX disruptions.


== Triggers ==
[[File:Automatic-private-browsing-upgrades-toolbar-indicator.png|500px|thumb|right|Notification bar]]


There are three ways to trigger it:
There are three ways to trigger it:
Line 35: Line 33:
Once triggered, the following happens:
Once triggered, the following happens:


# We open the "protected" URL in a new private browsing window
# We open the "protected" URL in a new private browsing window and show a notification bar
  # In this private browsing window, we show a message saying that the user was upgraded because the site owner has asked for it
# The original tab is navigated to <tt>about:blank</tt> (or maybe closed if it doesn't have any history)
# The original tab is navigated to <tt>about:blank</tt> (or maybe closed if it doesn't have any history)
# We delete the protected URL from the history
# We delete the protected URL from the history
Line 42: Line 39:


[[File:Automatic-private-browsing-upgrades.gif]]
[[File:Automatic-private-browsing-upgrades.gif]]
[[File:Automatic-private-browsing-upgrades-toolbar-indicator.png]]


== Prospective clients ==
== Prospective clients ==
Line 56: Line 52:


* https://rainn.org/
* https://rainn.org/
== 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 <tt>about:config</tt> pref to disable this feature entirely.
* Third-party tracking is reduced by [[Security/Tracking_protection|tracking protection]].
* [[Security/Contextual_Identity_Project/Private_Session|Private sessions]] will isolate private browsing sites from each other.


== Related ==
== Related ==
Line 63: Line 76:
* [https://w3c.github.io/webappsec/specs/clear-site-data/ Clear Site data]: new spec to allow sites to clear site data themselves
* [https://w3c.github.io/webappsec/specs/clear-site-data/ Clear Site data]: new spec to allow sites to clear site data themselves
* [http://www.w3.org/TR/upgrade-insecure-requests/ Upgrade insecure requests]: another spec which defines a new CSP directive
* [http://www.w3.org/TR/upgrade-insecure-requests/ Upgrade insecure requests]: another spec which defines a new CSP directive
* [https://lists.w3.org/Archives/Public/public-webappsec/2016Jan/0046.html "_private" browsing context]

Latest revision as of 23:17, 13 January 2016

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

Retrieved from "https://wiki.allizom.org/index.php?title=Security/Automatic_Private_Browsing_Upgrades&oldid=1112629"