I would like to propose moving the Privacy Settings checkboxes to the about:preferences#privacy page. That means removing them from torbutton and adding them to tor-browser.git
Here is my reasoning:
The security slider can be separated from the privacy settings. The privacy checkboxes are dangerous, because the default (all checked) offers maximum privacy, and unchecking any of the checkboxes substantially reduces privacy. Whereas the security slider has low security by default, and moving the slider always increases security. So I think it's better to encourage use of the security slider and discourage use of the privacy checkboxes.
We unify the privacy user interface, which hopefully simplifies it for users. There are already privacy settings for Firefox on the about:preferences#privacy page, so it seems natural to move them there. Also the "Always Use Private Browsing Mode" checkbox on that page is more or less equivalent to torbutton's "Don't record browsing history" checkbox. And then we don't have to duplicate the "restart" prompt associated with that checkbox.
Hopefully we can uplift to mainline Firefox, one of our SponsorU goals, thereby exposing our great privacy features (first party isolation, fingerprinting resistance, etc.) to Firefox users in the privacy UI.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items ...
Show closed items
Linked items 0
Link issues together to show that they're related.
Learn more.
Note that the last torbutton patch adds an overlay so that the our translated checkbox labels can be temporarily applied to the about:preferences page. If Mozilla uplifts these to Firefox and translates the labels themselves, then we won't need this overlay any more.
I've written patches for this, because it's going to make the problems I encountered in #18093 (moved) much easier to solve.
yay :)
There are 6 patches here (in which I remove checkboxes one by one and then clean up the UI):
https://github.com/arthuredelstein/torbutton/commits/20244
And rename "Privacy and Security Settings..." menu item?
and 2 patches here (where I add two checkboxes to the about:preferences#privacy page):
https://github.com/arthuredelstein/tor-browser/commits/20244
"Restrict third party..." has "strange" relations with FF's "Third party cookies" option, so the layout should reflect the dependencies.
And what about "Custom settings" instead of "Never"? Would it be default or both would be good (after bugfixing)?
Note that the last torbutton patch adds an overlay so that the our translated checkbox labels can be temporarily applied to the about:preferences page. If Mozilla uplifts these to Firefox and translates the labels themselves, then we won't need this overlay any more.
It's good to get this upsteamed while Mozilla is in mozilla52: behind a pref as resistFingerprinting and first-party isolation, but also Mozillians could make suggestions about naming, layout, hints, etc in the FF's UI.
There is a typo in the commit message for 38f3653b89ce3790d75b8652316f7381158d0af3 ("Bug Bug").
You sometimes treat privacy.thirdparty.isolate as a Boolean pref, which does not seem correct.
When I clicked the button in about:plugins to enable plugins, no warning prompt was displayed. Possibly related, there is no default value for plugins.disable which caused this to appear on the browser console:
16:26:17.523 NS_ERROR_UNEXPECTED: Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getBoolPref]1 torbutton.js:2323:0
Please remove the following from src/defaults/preferences/preferences.js:
Can we reduce the height of the preferences window? I cannot remember how the height is determined, but on OSX there is now a lot of extra space below the slider. Or maybe it is just remembering an old height that I set by resizing.
Note that the last torbutton patch adds an overlay so that the our translated checkbox labels can be temporarily applied to the about:preferences page. If Mozilla uplifts these to Firefox and translates the labels themselves, then we won't need this overlay any more.
In the tor-browser patches, should we use the same labels as we have in src/chrome/locale/en/torbutton.dtd? Or did you intentionally make them different to verify that the overlay was working?
Should we include the access keys in the overlay so they can be localized?
I've written patches for this, because it's going to make the problems I encountered in #18093 (moved) much easier to solve.
Kathy and I reviewed and ran with all of the patches. Nice work! Comments below.
Thanks for the review!
There is a typo in the commit message for 38f3653b89ce3790d75b8652316f7381158d0af3 ("Bug Bug").
Fixed.
You sometimes treat privacy.thirdparty.isolate as a Boolean pref, which does not seem correct.
Oops, good catch. Fixed.
When I clicked the button in about:plugins to enable plugins, no warning prompt was displayed. Possibly related, there is no default value for plugins.disable which caused this to appear on the browser console:
{{{
16:26:17.523 NS_ERROR_UNEXPECTED: Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getBoolPref]1 torbutton.js:2323:0
}}}
Turns out I had consistently mistyped "plugin.disable" as "plugins.disable". Fixed.
Please remove the following from src/defaults/preferences/preferences.js:
{{{
extensions.torbutton.resist_fingerprinting
extensions.torbutton.restrict_thirdparty
}}}
Done. I have now also removed "extensions.torbutton.block_disk" in patch 20244.1 and use the "browser.privatebrowsing.autostart" pref instead.
Can we reduce the height of the preferences window? I cannot remember how the height is determined, but on OSX there is now a lot of extra space below the slider. Or maybe it is just remembering an old height that I set by resizing.
I added maxwidth and maxheight properties to stop it from getting too big.
In the tor-browser patches, should we use the same labels as we have in src/chrome/locale/en/torbutton.dtd? Or did you intentionally make them different to verify that the overlay was working?
I did, but now I have made them the same.
Should we include the access keys in the overlay so they can be localized?