spohl (cc-ed) let me know that he's going to be reverting https://bugzilla.mozilla.org/show_bug.cgi?id=967970 and landing https://bugzilla.mozilla.org/show_bug.cgi?id=1405577 to address issues like https://bugzilla.mozilla.org/show_bug.cgi?id=1418903
In particular, reverting the first issue prevent window title disk leaks, but the new patch should still address that need.
-tom
Tom Ritter:
spohl (cc-ed) let me know that he's going to be reverting https://bugzilla.mozilla.org/show_bug.cgi?id=967970 and landing https://bugzilla.mozilla.org/show_bug.cgi?id=1405577 to address issues like https://bugzilla.mozilla.org/show_bug.cgi?id=1418903
In particular, reverting the first issue prevent window title disk leaks, but the new patch should still address that need.
What does "should" mean? Looking over the commit it seems there is no test that actually makes sure this assumption still holds. Or am I missing something?
Georg
On 12/1/17 3:01 AM, Georg Koppen wrote:
Tom Ritter:
spohl (cc-ed) let me know that he's going to be reverting https://bugzilla.mozilla.org/show_bug.cgi?id=967970 and landing https://bugzilla.mozilla.org/show_bug.cgi?id=1405577 to address issues like https://bugzilla.mozilla.org/show_bug.cgi?id=1418903
In particular, reverting the first issue prevent window title disk leaks, but the new patch should still address that need.
What does "should" mean? Looking over the commit it seems there is no test that actually makes sure this assumption still holds. Or am I missing something?
I'll try to answer this: Previously, we relied on an undocumented plist key to prevent the OS from writing anything to disk in the ~/Library/Saved Application State directory. Although this commit makes it so that the OS writes data to this directory, we now deliberately don't write window titles to disk via a documented API when in private browsing mode (which should always be the case for Tor). There was never a guarantee or test that the plist key would continue to work as expected. I'm exploring adding a test for the window titles, but since it is the OS that writes this data to disk, a test wouldn't catch anything else privacy-sensitive that the OS may be writing to disk in the future.
Tor may choose to continue using the undocumented plist key to prevent the OS from writing data to this directory. However, bear in mind that this may stop working at any time and it will come with downsides that have plagued Firefox up until now. These include an inability to open fullscreen browser windows in several different spaces. Popups may also not work correctly when one browser window is in fullscreen mode. See https://bugzilla.mozilla.org/show_bug.cgi?id=1405577 and dependent bugs. These issues were all caused by the undocumented plist key.
-Stephen
Stephen A Pohl:
On 12/1/17 3:01 AM, Georg Koppen wrote:
Tom Ritter:
spohl (cc-ed) let me know that he's going to be reverting https://bugzilla.mozilla.org/show_bug.cgi?id=967970 and landing https://bugzilla.mozilla.org/show_bug.cgi?id=1405577 to address issues like https://bugzilla.mozilla.org/show_bug.cgi?id=1418903
In particular, reverting the first issue prevent window title disk leaks, but the new patch should still address that need.
What does "should" mean? Looking over the commit it seems there is no test that actually makes sure this assumption still holds. Or am I missing something?
I'll try to answer this: Previously, we relied on an undocumented plist key to prevent the OS from writing anything to disk in the ~/Library/Saved Application State directory. Although this commit makes it so that the OS writes data to this directory, we now deliberately don't write window titles to disk via a documented API when in private browsing mode (which should always be the case for Tor). There was never a guarantee or test that the plist key would continue to work as expected. I'm exploring adding a test for the window titles, but since it is the OS that writes this data to disk, a test wouldn't catch anything else privacy-sensitive that the OS may be writing to disk in the future.
Tor may choose to continue using the undocumented plist key to prevent the OS from writing data to this directory. However, bear in mind that this may stop working at any time and it will come with downsides that have plagued Firefox up until now. These include an inability to open fullscreen browser windows in several different spaces. Popups may also not work correctly when one browser window is in fullscreen mode. See https://bugzilla.mozilla.org/show_bug.cgi?id=1405577 and dependent bugs. These issues were all caused by the undocumented plist key.
Okay, this makes sense. Thanks for the explanation.
Georg
On 11/29/17 12:24 PM, Tom Ritter wrote:
spohl (cc-ed) let me know that he's going to be reverting https://bugzilla.mozilla.org/show_bug.cgi?id=967970 and landing https://bugzilla.mozilla.org/show_bug.cgi?id=1405577 to address issues like https://bugzilla.mozilla.org/show_bug.cgi?id=1418903
In particular, reverting the first issue prevent window title disk leaks, but the new patch should still address that need.
-tom
Quick update: We have decided to call the documented API for all windows to prevent window titles from being written to disk, not just for private browsing windows. There is more detail in https://bugzilla.mozilla.org/show_bug.cgi?id=1405577 but the tl;dr is that until we start integrating with macOS' resume feature, there is no benefit in having macOS write window titles to disk.
-spohl
-
Georg Koppen -
Stephen A Pohl -
Tom Ritter