Confirm
657
edits
Changes
no edit summary
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 =====
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.
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.
=== Session isolation ===
From a user's standpoint, their private session with a website is done when they close their private window. In order to support this, we clear our in-memory caches containing details about the sites that the user has visited when the last private window is closed. The reason behind the <i>last</i> part is the technical feasibility of this.
== FAQ ==
* Is network level privacy a goal? Should private browsing use an anonymizing proxy?
** Experience suggests that users perceive some amount of network level privacy, but from a technical standpoint, that 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, but there are also reasons why that would be a bad idea.
* Does this mean no network level privacy feature should ever be included?!
** No. Again, we know that users expect that, so it would be valuable to try to do better in that space.
* What about add-ons?
** At a technical level, because of the extensive access that add-ons have to our internal APIs, and because they are non-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/AMO/Policy/Reviews#Private_Browsing_Mode AMO add-on review guidelines] to require add-ons to adhere to our guidelines for supporting private browsing mode.
* Can my feature be exempted from adhering to private browsing?
** Probably not, but if you think you can make a case for it, that needs to be discussed. Otherwise, it is appreciated if you consider private browsing when designing and implementing your features!
