Changes

We target Private Browsing was initially designed as to 3 privacy goals; in a way for Private Browsing session, FirefoxDoesn’t save the user to browse websites without having those websites show up browsing history or display it in the information saved by Firefox UIPrevents the session's data from writing to the persistent storage, and/or later be displayed in Protects the session's data from online trackingThe first 2 goals focus on a local adversary - someone with direct access to Firefox UI. A secondary incidental use case Private Browsing was discovered which allowed users to to log initially designed with just these two goals in to two instances of a website at the same time using different credentialsmind. The initial design concentrated on isolating Private Browsing mode from regular browsing mode.

The section below highlights the important aspectsResearch [[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.

=== Local privacy ===Any data containing details such as the full or partial address of the pages visited by the userIn 2015, 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 we added [[Services/TrackingProtection|Tracking Protection]] to the user either through the Firefox UI, or through the typical OS-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 permittedhelp protect users from online adversaries. HoweverIn 2018, we officially added the scope of 3rd goal to Private Browsing does not include protecting against scenarios such as attacking the disk-based page file used by the OS, or forensic analysis. This means that the OS is not prevented from caching the sensitive information in memory to the disk, and there is no protection against probes inspecting the process memory at runtime, as such topics are outside of the design scope of this feature's intended threat model.

For UX reasonsTo achieve all these goals, in some specific cases we decided that we can interpret a user's action as a request to persist something specific about the websiteconcentrate on: local privacy, session isolation, and we therefore permit writing such information to the disksite isolation. For example, we take bookmarking as an explicit request from the user for We highlight these aspects in the website to be remembered, so we save bookmarks from private windowsgoal descriptions below. (Note, however, that we save it as an unvisited bookmarka by-product of these protections allowed users to sign into a website with 2 accounts.) As another example, we choose to allow saving permissions from private window in A feature now better accomplished with the page info dialog[https://addons.mozilla.org/firefox/addon/multi-account-containers/ Multi-Account Containers] add-on.)

=== Isolation Firefox UI ===Two instances of the same website (one running We should not write any full or partial addresses or site data from Private Browsing page visits in a normal window and the other in a private window) must be isolated from each other, and thus unable to exchange information via the browser. This is the technical reason why we originally had to isolate the cookies for such instances, since a session cookie set by a private window could be picked up by a non-private instance of the same site and be persisted 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 shows them in the disk is to make them unable to communicate, and ensure that Gecko treats them as independentlocal regular Firefox UI.

The additional use case 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 simultaneous logins data from the sites the user visited. There is a byproduct some mismatch between the user's mental model of individual private windows and this design decisionimplementation. (e.g., [https://bugzilla.mozilla.org/show_bug.cgi?id=1197159 Bug 1197159])

=== Stealth Persistent Storage ===The browser We should make it difficult for not write any full or partial addresses or site data from Private Browsing page visits in a website way that shows them to tell if it is in a private window'''local''' OS disk mechanisms. Without This means writing this level of protection, the websites in the example in the above section could communicate with each other and leak information through their common server - the website to a custom file or a SQLite database in the private window can transmit the sensitive information, and the other instance could retrieve it at a later time. Ideally, the server should have a difficult time determining if one of these instances user's profile is using private browsing mode. There are also UX reasons why users may not want the websites that they are visiting in private mode to be aware of that factpermitted.

From '''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 purely technical standpoint, there are website running in a few weak spots normal window from itself running in the platform that a private window. We make it impossible unable to block this effectivelyshare data between the 2 modes via the browser. E.g. Also, over 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 years[https://addons.mozilla.org/firefox/addon/multi-account-containers/ Multi-Account Containers] add-on.) By default, it has become more difficult we also block connections to fix everything 3rd-party trackers in private windows. [https://disconnect.me/ Disconnect.me] maintains the platform according to this rulelist of 3rd-party trackers. At For more information, see the present, this is probably a lost cause in practice[[Services/TrackingProtection|Tracking Protection]] page.

* Is network level privacy a goal? Should private browsing use an anonymizing proxy?** Experience Research suggests that users believe that expect private browsing implies some amount of provides network level privacy, but from . From a technical standpoint this is a challenging problem of its own , so we have decided to not tackle it for now. It may make sense to look into doing this in the future, but there are also reasons why it would be a bad idea. * Does this mean no network level privacy feature should ever be included?!** No. Again, we know that users expect it, so implemented it would be valuable to try and meet expectationsyet.

** At a technical levelBy default, because of the extensive access that Firefox add-ons have to our internal APIs, and because they are not sandboxed, there is nothing that we can do. However, where appropriate, we have been trying to make it easier to use our APIs in a way that does the right thing by default in order to address some of the issue. On the policy side, we have modified the "[https://developer.mozilla.org/en-US/Add-ons/AMOWebExtensions/manifest.json/incognito spanning]" access to Private Browsing. There is [https://Policybugzilla.mozilla.org/Reviews#Private_Browsing_Mode AMO add-on review guidelinesshow_bug.cgi?id=1380809 a bug] to require support all "incogito" key values, including "not_allowed". For add-ons to adhere to our guidelines distributed on AMO, reviewers look for supporting proper use and treatment of private browsing mode.

** Most likely yes, but if you think you can make a case against it that needs to be discussed. Otherwise, it is appreciated if you - 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.