Private Browsing: Difference between revisions
No edit summary |
(Wordsmithing.) |
||
| Line 1: | Line 1: | ||
== Private Browsing == | == 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 | 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 incidental use case was discovered which allowed users to to log in to two instances of a website at the same time using different credentials. | ||
The section below highlights the important aspects. | The section below highlights the important aspects. | ||
=== Local privacy === | === Local privacy === | ||
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 | 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 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 permitted. However, the scope of 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 scope of this feature's intended threat model. | ||
For UX reasons, in some specific cases we decided that we can interpret a user's action as a request to persist something specific about the website, and we therefore 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 from private windows. (Note, however, that we save it as an unvisited bookmark.) As another example, we choose to allow saving permissions from private window in the page info dialog. | |||
=== Isolation === | === Isolation === | ||
Two instances of the same website one running in a normal and | Two instances of the same website (one running 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 the disk is to make them unable to communicate, and ensure that Gecko treats them as independent. | ||
The | The additional use case of simultaneous logins is a byproduct of this design decision. | ||
=== Stealth === | === Stealth === | ||
The browser should make it difficult for | The browser should make it difficult for a website to tell if it is in a private window. Without 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 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 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 fact. | ||
From a | From a purely 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 === | === 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. | 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. This mismatch between the user's mental model and the implementation is a technical limitation of the platform. | ||
== FAQ == | == FAQ == | ||
* Is network level privacy a goal? Should private browsing use an anonymizing proxy? | * Is network level privacy a goal? Should private browsing use an anonymizing proxy? | ||
** Experience suggests that users | ** Experience suggests that users believe that private browsing implies some amount of network level privacy, but 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?! | * Does this mean no network level privacy feature should ever be included?! | ||
** No. Again, we know that users expect | ** No. Again, we know that users expect it, so it would be valuable to try and meet expectations. | ||
* What about add-ons? | * 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 | ** At a technical level, because of the extensive access that 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/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. | ||
* | * Does my feature <i>have</i> to respect private browsing? | ||
** | ** 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 consider private browsing when designing and implementing your features! | ||
== Other resources == | == Other resources == | ||
Revision as of 17:55, 17 July 2015
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 incidental use case was discovered which allowed users to to log in to two instances of a website at the same time using different credentials.
The section below highlights the important aspects.
Local privacy
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 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 permitted. However, the scope of 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 scope of this feature's intended threat model.
For UX reasons, in some specific cases we decided that we can interpret a user's action as a request to persist something specific about the website, and we therefore 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 from private windows. (Note, however, that we save it as an unvisited bookmark.) As another example, we choose to allow saving permissions from private window in the page info dialog.
Isolation
Two instances of the same website (one running 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 the disk is to make them unable to communicate, and ensure that Gecko treats them as independent.
The additional use case of simultaneous logins is a byproduct of this design decision.
Stealth
The browser should make it difficult for a website to tell if it is in a private window. Without 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 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 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 fact.
From a purely 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. This mismatch between the user's mental model and the implementation is a technical limitation of the platform.
FAQ
- Is network level privacy a goal? Should private browsing use an anonymizing proxy?
- Experience suggests that users believe that private browsing implies some amount of network level privacy, but 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 it would be valuable to try and meet expectations.
- 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 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 AMO add-on review guidelines to require add-ons to adhere to our guidelines for supporting private browsing mode.
- Does my feature have to respect private browsing?
- 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 consider private browsing when designing and implementing your features!