Improve NoScript and Browser integration
- Extract Security Level backend functionality from torbutton and make into separate firefox patch
- Move Security Level UI Patch before the tor-browser split in firefox
- Ensure only depends on strings in the new localization project (see #40924 )
- Update browser threat-model doc
- Determine what functionality we want to expose to the user
- Integrate NoScript as a system extension
- Build some system for NoSript to trigger 'native' browser UI (modals, etc)
- Implement w/e UX Team comes up with
- Allow about:addons intalled NoScript to override system-extension NoScript and disable w/e custom security features we have
Activity
changed milestone to %Sponsor 131 - Phase 2 - Privacy Browser
assigned to @pierov
marked this issue as related to #40924
added Q3 Roadmap::Future labels
marked this issue as related to #40934 (closed)
marked this issue as related to #40952
marked this issue as related to #40953
marked this issue as related to #40954 (closed)
marked this issue as related to #40973
marked this issue as related to #40980
marked this issue as related to #41001 (closed)
added Sponsor 131 label
added Doing label and removed Roadmap::Future label
We should move also 79f6bd71 (or whatever it is at the version we're doing this) when moving 9c472fd0 to base-browser.
As for the latter, the name 'tor' is used only for the preferences (
extensions.torbutton.something, to be more precise), and forTorString.I propose we rename these preferences, and find a way to migrate from the old preferences to the new ones only in Tor Browser. Possibly, we could either create a patch for migrations, to use also for other features, or create a fixup to the usual TorButton integration commit.
For the strings, sadly they currently are in DTD. I think I could do something to move them to a new fluent file, at least temporarily (the idea from #40924 is to have a single branch for base-browser, so possibly only a single fluent file?). They are about 25 strings. Of course, we should coordinate with l10n, but I am not sure of which strings we will need in base browser, yet.
If I understand correctly, 9bdac764 is involved in security level, too. So, if we move everything to tor-browser.git, we'll either need to move it to base-browser, or to get rid of it (of course, I hope for the latter
Speaking of which, if we keep NoScript (which is what I'd do, at least for starters), we may need to review the extension messaging mechanisms in
torbutton/modules/noscript-control.js.Apart from this, in that file we could create a normal observer, without using
bindPreffromresource://torbutton/modules/utils.js(I don't see a real advantage in using that function), and use another mechanism for logs.I think using a normal console logger is more than okay. The old onion alias code had a nice way to create a custom logger, that has a custom tag in the JS console. I liked it so much that I've copied it to my version of onion aliases, too. (Well, that code itself was the copy of some other code from other parts of Firefox).
noscript-control.jsis initialized at startup fromtorbutton/components/startup-observer.js. I'm sure we can find some other point to inject it.The final piece of the backend should be
torbutton/modules/security-prefs.js, if I haven't missed anything. I think everything I wrote fornoscript-control.jsapply also this file.However, after any modernization of these two files, I'd like to see if it makes sense to keep them separate, or see if merging them is better.
From a practical point of view, I think we should branch out torbutton soon, at least for 11.5, and then either start working on master for this (and maybe finally rename it to main), or to branch out for these changes.
Also, I think we could create a new branch in
tor-browser.git, for 12.0a1 (from what I've understood from the calendar, a1 won't be with 102 ESR, but with 91.11/91.12).
marked this issue as related to #32492 (closed)
marked this issue as related to #40424 (closed)