Private Browsing: Difference between revisions

Latest revision as of 00:49, 13 March 2020

Private Browsing

We target Private Browsing to 3 privacy goals; in a Private Browsing session, Firefox:

Doesn’t save the browsing history or display it in the Firefox UI
Prevents the session's data from writing to persistent storage
Protects the session's data from online tracking

The first 2 goals focus on a local adversary - someone with direct access to Firefox. Private Browsing was initially designed with just these two goals in mind. The initial design concentrated on isolating Private Browsing mode from regular browsing mode.

Research [1][2][3] shows that users expect Private Browsing to protect them from online adversaries - e.g., websites, trackers, data brokers etc.

In 2015, we added Tracking Protection to Firefox to help protect users from online adversaries. In 2018, we officially added the 3rd goal to Private Browsing design scope.

To achieve all these goals, we concentrate on: local privacy, session isolation, and site isolation. We highlight these aspects in the goal descriptions below. (Note that a by-product of these protections allowed users to sign into a website with 2 accounts. A feature now better accomplished with the Multi-Account Containers add-on.)

Firefox UI

We should not write any full or partial addresses or site data from Private Browsing page visits in a way that shows them in the local regular Firefox UI.

In the Firefox UI, the user ends their private session with a website when they close ALL their private windows. So, when the user closes the last private browsing window, we clear our in-memory caches of data from the sites the user visited. There is some mismatch between the user's mental model of individual private windows and this implementation. (e.g., Bug 1197159)

Persistent Storage

We should not write any full or partial addresses or site data from Private Browsing page visits in a way that shows them to local OS disk mechanisms. This means writing this information to a custom file or a SQLite database in the user's profile is not permitted.

We do not try to protect against all scenarios - e.g., attacking the disk-based page file used by the OS, or forensic analysis. We allow the OS to cache data from memory to disk, and we don't protect against runtime process memory probes.

We also treat some user actions as requests to persist website data, and write that data to the disk. For example, we save bookmarks from private windows. (Note: we save them as un-visited bookmarks.) We DO NOT save passwords entered into Private Browsing.

Online Tracking

We isolate a website running in a normal window from itself running in a private window. We make it unable to share data between the 2 modes via the browser. E.g., we isolate a website's private cookies from its regular cookies. (Note that a by-product of this protection allows users to sign into a website with 2 accounts - a feature now better accomplished with the Multi-Account Containers add-on.)

By default, we also block connections to 3rd-party trackers in private windows. Disconnect.me maintains the list of 3rd-party trackers. For more information, see the Tracking Protection page.

FAQ

Is network level privacy a goal? Should private browsing use an anonymizing proxy?
- Research suggests users expect private browsing provides network level privacy. From a technical standpoint this is a challenging problem of its own, so we have not implemented it yet.

What about add-ons?
- By default, Firefox add-ons request "spanning" access to Private Browsing but users must explicitly grant access to private windows. There is a bug to support all "incognito" key values, including "not_allowed". For add-ons distributed on AMO, reviewers look for proper use and treatment of private browsing mode.

Does my feature have to respect private browsing?
- Most likely yes - please consider private browsing when designing and implementing your features. If you think your feature does not, please discuss with dev-privacy.

Can an online adversary detect private browsing mode?
- From a purely technical standpoint, there are a few weak spots in the platform that make it impossible to hide private browsing mode effectively. Also, over the years, it has become even more difficult to protect from new threats (e.g., fingerprinting) AND hiding the protections themselves.

@@ Line 1: / Line 1: @@
 == Private Browsing ==
-Private Browsing was initially designed as a way for the user to browse websites without having those websites show up in the information saved by Firefox to the persistent storage, and/or later be displayed in the Firefox UI.  A secondary use case discovered by the way that people were using the feature was being able to log in to two websites using different authentication information at the same time.
+We target Private Browsing to 3 privacy goals; in a Private Browsing session, Firefox:
-The section below highlights the important aspects.
+* Doesn’t save the browsing history or display it in the Firefox UI
+* Prevents the session's data from writing to persistent storage
+* Protects the session's data from online tracking
-=== Local privacy ===
+The first 2 goals focus on a local adversary - someone with direct access to Firefox. Private Browsing was initially designed with just these two goals in mind. The initial design concentrated on isolating Private Browsing mode from regular browsing mode.
-Any data containing details such as the full or partial address of the pages visited by the user, or information saved on behalf of those sites either by the site or Firefox should not be written to the disk in a way that is exposed to the user either through the Firefox UI, or through the typical OR provided mechanisms for viewing the information on the disk.  This means writing this information to a custom file, or a SQLite database in the user's profile is not permitted.  However, protecting against scenarios such as attacking the disk-based page file used by the OS, or forensic analysis is outside of the scope of Private Browsing.  This means that keeping that information in memory without any specific protection against the page being cached to the disk, or against probes inspecting the memory of the process at runtime is outside of the scope of private browsing.
-==== Exceptions ====
+Research [[https://spreadprivacy.com/is-private-browsing-really-private/ 1]][[https://www.elie.net/blog/privacy/understanding-how-people-use-private-browsing 2]][[https://data.surveygizmo.com/r/28049_59b7e980008742.80492645 3]] shows that users expect Private Browsing to protect them from online adversaries - e.g., websites, trackers, data brokers etc.
-In some specific cases, we decided that for UX reasons, we can take the user action as a request in order for something specific about the website to be remembered, and permit writing such information to the disk.  For example, we take bookmarking as an explicit request from the user for the website to be remembered, so we save bookmarks in private windows.  (However, we save it as an unvisited bookmark.)  As another example, we don't disable saving permissions in the page info dialog from private windows.
-=== Isolation ===
+In 2015, we added [[Services/TrackingProtection|Tracking Protection]] to Firefox to help protect users from online adversaries. In 2018, we officially added the 3rd goal to Private Browsing design scope.
-Two instances of the same website one running in a normal and one running in a private window must be isolated from each other, and be unable to exchange information through the browser.  This is the technical reason why we originally had to keep the cookies for such websites separate, since a session cookie set by a private window could be picked up by a non-private instance of the same site and be saved to the disk from there.  The only way that we can ensure that information cannot leak from one such site to the other and find its way to the disk is to make them unable to talk to each other, or be treated as the same by Gecko.
-The interesting additional use case of simultaneous logins is a byproduct of this design decision.
+To achieve all these goals, we concentrate on: local privacy, session isolation, and site isolation. We highlight these aspects in the goal descriptions below.
+(Note that a by-product of these protections allowed users to sign into a website with 2 accounts. A feature now better accomplished with the [https://addons.mozilla.org/firefox/addon/multi-account-containers/ Multi-Account Containers] add-on.)
-=== Stealth ===
+=== Firefox UI ===
-The browser should make it difficult for the website to tell if they are in private browsing mode.  Without this level of protection, the websites in the example in the above section could communicate to each other and leak information through their common server by the website in the private window phoning home the information and the other instance picking it up in the next sync or such.  But the server should have a hard time telling if one of these instances is in private browsing mode.  There are also UX reason why users may not want the websites that they are visiting in private mode know that fact.
+We should not write any full or partial addresses or site data from Private Browsing page visits in a way that shows them in the local regular Firefox UI.
-From a pure technical standpoint, there are a few weak spots in the platform that make it impossible to block this effectively.  Also, over the years, it has become more difficult to fix everything in the platform according to this rule.  At the present, this is probably a lost cause in practice.
+In the Firefox UI, the user ends their private session with a website when they close ALL their private windows. So, when the user closes the last private browsing window, we clear our in-memory caches of data from the sites the user visited. There is some mismatch between the user's mental model of individual private windows and this implementation. (e.g., [https://bugzilla.mozilla.org/show_bug.cgi?id=1197159 Bug 1197159])
+=== Persistent Storage ===
+We should not write any full or partial addresses or site data from Private Browsing page visits in a way that shows them to '''local''' OS disk mechanisms. This means writing this information to a custom file or a SQLite database in the user's profile is not permitted.
+'''We do not try to protect against all scenarios''' - e.g., attacking the disk-based page file used by the OS, or forensic analysis. We allow the OS to cache data from memory to disk, and we don't protect against runtime process memory probes.
+We also treat some user actions as requests to persist website data, and write that data to the disk. For example, we save bookmarks from private windows. (Note: we save them as un-visited bookmarks.) We DO NOT save passwords entered into Private Browsing.
+=== Online Tracking ===
+We '''isolate''' a website running in a normal window from itself running in a private window. We make it unable to share data between the 2 modes via the browser. E.g., we isolate a website's private cookies from its regular cookies. (Note that a by-product of this protection allows users to sign into a website with 2 accounts - a feature now better accomplished with the [https://addons.mozilla.org/firefox/addon/multi-account-containers/ Multi-Account Containers] add-on.)
+By default, we also block connections to 3rd-party trackers in private windows. [https://disconnect.me/ Disconnect.me] maintains the list of 3rd-party trackers. For more information, see the [[Services/TrackingProtection|Tracking Protection]] page.
+== FAQ ==
+* Is network level privacy a goal? Should private browsing use an anonymizing proxy?
+** Research suggests users expect private browsing provides network level privacy. From a technical standpoint this is a challenging problem of its own, so we have not implemented it yet.
+* What about add-ons?
+** By default, Firefox add-ons request "[https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/incognito spanning]" access to Private Browsing but users must explicitly grant access to private windows. There is [https://bugzilla.mozilla.org/show_bug.cgi?id=1380809 a bug] to support all "incognito" key values, including "not_allowed". For add-ons distributed on AMO, reviewers look for proper use and treatment of private browsing mode.
+* Does my feature <i>have</i> to respect private browsing?
+** Most likely yes - please consider private browsing when designing and implementing your features. If you think your feature does not, please discuss with [https://lists.mozilla.org/listinfo/dev-privacy dev-privacy].
+* Can an online adversary detect private browsing mode?
+** From a purely technical standpoint, there are a few weak spots in the platform that make it impossible to hide private browsing mode effectively. Also, over the years, it has become even more difficult to protect from new threats (e.g., fingerprinting) AND hiding the protections themselves.
+== Other resources ==
+* [https://developer.mozilla.org/en-US/docs/Supporting_per-window_private_browsing How to support private browsing]
+* [https://support.mozilla.org/en-US/kb/private-browsing-use-firefox-without-history User documentation]
+* [https://wiki.mozilla.org/Per-window_Private_Browsing Feature page (contents outdated)]

Private Browsing: Difference between revisions

Latest revision as of 00:49, 13 March 2020

Contents