Per the secreivew[1] we need a list of places where private browsing stops writes happening. [1]https://wiki.mozilla.org/Security/Reviews/Fennec_Private_Browsing

As an addendum; the list of places where private browsing explictly does *NOT* stop something being saved (eg bookmarks, saving something for reader mode)

(In reply to Curtis Koenig [:curtisk] from comment #0) > Per the secreivew[1] we need a list of places where private browsing stops > writes happening. > > [1]https://wiki.mozilla.org/Security/Reviews/Fennec_Private_Browsing Do you need a full list? That is a very big project! ;-) Also, this doesn't need to block bug 794502.

I think finkle can speak better to how granular we need to be (as he was in the secreview) but we do need to cover the usual suspects.

(In reply to comment #3) > I think finkle can speak better to how granular we need to be (as he was in the > secreview) but we do need to cover the usual suspects. Out of curiosity, what was the driving factor for such a list in the security review. I don't recall anything like that coming out of the secreview for the desktop feature...

(In reply to Ehsan Akhgari [:ehsan] from comment #4) > (In reply to comment #3) > > I think finkle can speak better to how granular we need to be (as he was in the > > secreview) but we do need to cover the usual suspects. > > Out of curiosity, what was the driving factor for such a list in the > security review. I don't recall anything like that coming out of the > secreview for the desktop feature... QA and test coverage. We'd like to be able to point to a list of data that _is_ and _is not_ treated a "private".

I should have pointed out that the initial list will be scraped from the dependent bugs on the core PB bugs.

(In reply to comment #5) > (In reply to Ehsan Akhgari [:ehsan] from comment #4) > > (In reply to comment #3) > > > I think finkle can speak better to how granular we need to be (as he was in the > > > secreview) but we do need to cover the usual suspects. > > > > Out of curiosity, what was the driving factor for such a list in the > > security review. I don't recall anything like that coming out of the > > secreview for the desktop feature... > > QA and test coverage. We'd like to be able to point to a list of data that _is_ > and _is not_ treated a "private". In my experience, it's best to get a list of things that should not be considered private (as there's much much fewer of them) and consider everything else as private. One effective bug-finding technique would be to navigate to some websites in a PB tab and to some others in a non-PB tab, then downloading the full profile from the device and grepping its contents for the addresses of websites visited in the PB tab.

(In reply to Ehsan Akhgari [:ehsan] from comment #7) > (In reply to comment #5) > > QA and test coverage. We'd like to be able to point to a list of data that _is_ > > and _is not_ treated a "private". > > In my experience, it's best to get a list of things that should not be > considered private (as there's much much fewer of them) and consider > everything else as private. One effective bug-finding technique would be to > navigate to some websites in a PB tab and to some others in a non-PB tab, > then downloading the full profile from the device and grepping its contents > for the addresses of websites visited in the PB tab. What concerns me about this is that state that could compromise privacy might not necessarily always be greppable: Imagine, for example, if we store a hash of a visited location rather than the location itself; in this case the fact that the location is visited can be determined, but not by grep. Also, consider the example of local storage; the origin is stored in 'scope' in the local storage database, but it's reversed... I'd be happier if we tried a combination of the 2 approaches: 1) We try to enumerate what we know has been worked on - testing these parts is a fairly normal assurance exercise. 2) We use other techniques (analysis of fetched profiles) to see if anything has been missed.

Drive-by comment: how about saving a copy of the profile before and after the PB session and diffing them to identify what changed? There might be some benign changes but it should be easier to spot privacy-leaking changes.

(In reply to Kartikaya Gupta (:kats) from comment #9) > Drive-by comment: how about saving a copy of the profile before and after > the PB session and diffing them to identify what changed? There might be > some benign changes but it should be easier to spot privacy-leaking changes. Yeah, Stefan and I are thinking about ways of doing this - it's not (just) profile changes we care about though; there are android specifics like the bundles with state after OOM kills we may want to consider.

(In reply to comment #8) > What concerns me about this is that state that could compromise privacy might > not necessarily always be greppable: Sure, that's true. > Imagine, for example, if we store a hash of a visited location rather than the > location itself; in this case the fact that the location is visited can be > determined, but not by grep. Hmm, are you worried about rainbow table attacks? I'm not sure if that's worth protecting against. > Also, consider the example of local storage; the origin is stored in 'scope' in > the local storage database, but it's reversed... OK, that's a good example. We do handle DOM storage FWIW, though. > I'd be happier if we tried a combination of the 2 approaches: > 1) We try to enumerate what we know has been worked on - testing these parts is > a fairly normal assurance exercise. > 2) We use other techniques (analysis of fetched profiles) to see if anything > has been missed. That's fine by me. I just wanted to note that number 1 above is a large task, given the vast number of places in the platform where we handle private browsing.

(In reply to comment #10) > Yeah, Stefan and I are thinking about ways of doing this - it's not (just) > profile changes we care about though; there are android specifics like the > bundles with state after OOM kills we may want to consider. That's definitely worth focusing on.

(In reply to Ehsan Akhgari [:ehsan] from comment #11) > > Imagine, for example, if we store a hash of a visited location rather than the > > location itself; in this case the fact that the location is visited can be > > determined, but not by grep. > > Hmm, are you worried about rainbow table attacks? I'm not sure if that's > worth protecting against. Not specifically; more tests against a specific known URL. E.g. Have you been to http://embarassing.example.com/some/resource

(In reply to comment #13) > (In reply to Ehsan Akhgari [:ehsan] from comment #11) > > > Imagine, for example, if we store a hash of a visited location rather than the > > > location itself; in this case the fact that the location is visited can be > > > determined, but not by grep. > > > > Hmm, are you worried about rainbow table attacks? I'm not sure if that's > > worth protecting against. > > Not specifically; more tests against a specific known URL. E.g. Have you been > to http://embarassing.example.com/some/resource OK. However, I'm not aware of any place in our code where we hash URLs.

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.