A draft proposal for #28044 (Integrate Tor Launcher into tor-browser) is attached. Your feedback is welcome and appreciated!
On Tue, 29 Jan 2019, Mark Smith wrote:
3.1 Source Code Integration
Prior to building the browser, the Tor Launcher code will be placed under browser/extensions/tor-launcher/. To avoid the problems associated with git submodules, this will be done using a nested git repository. Specifically, we want to facilitate nightly and developer builds that require that the Tor Launcher code be referred to by a branch or symbolic name rather than a git hash. We will need to make TO-BE-DETERMINED changes to the firefox project within tor-browser-build to put the Tor Launcher code in the correct place within the tor-browser source tree, and to keep it up to date. The tor-launcher RBM project will be removed from tor-browser-build.
This sounds good. However, I think we should not remove completly the tor-launcher project from tor-browser-build but do something like this: - modify the tor-launcher project to create a tar from the sources, instead of an xpi file - remove the tor-launcher dependency from projects/tor-browser and add it to projects/firefox. - in projects/firefox/build extract the tor-launcher tarball under browser/extensions/tor-launcher/.
Nicolas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2/1/19 9:27 AM, Nicolas Vigier wrote:
On Tue, 29 Jan 2019, Mark Smith wrote:
3.1 Source Code Integration
Prior to building the browser, the Tor Launcher code will be placed under browser/extensions/tor-launcher/. To avoid the problems associated with git submodules, this will be done using a nested git repository. Specifically, we want to facilitate nightly and developer builds that require that the Tor Launcher code be referred to by a branch or symbolic name rather than a git hash. We will need to make TO-BE-DETERMINED changes to the firefox project within tor-browser-build to put the Tor Launcher code in the correct place within the tor-browser source tree, and to keep it up to date. The tor-launcher RBM project will be removed from tor-browser-build.
This sounds good. However, I think we should not remove completly the tor-launcher project from tor-browser-build but do something like this: - modify the tor-launcher project to create a tar from the sources, instead of an xpi file - remove the tor-launcher dependency from projects/tor-browser and add it to projects/firefox. - in projects/firefox/build extract the tor-launcher tarball under browser/extensions/tor-launcher/.
Thanks! That sounds like a good plan, and so I added it to the proposal. An updated draft is attached. The only changes compared to the 29-Jan-2019 version are in section 3.1.
Kathy and will start implementing this next week.
- -- Mark Smith Pearl Crescent, LLC http://pearlcrescent.com/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2/7/19 11:07 AM, Mark Smith wrote:
... An updated draft is attached. The only changes compared to the 29-Jan-2019 version are in section 3.1.
I just noticed that there were two sections numbered 3.2. Oops. Please use the draft attached to this message instead of the previous one.
- -- Mark Smith Pearl Crescent, LLC http://pearlcrescent.com/
Mark Smith:
On 2/7/19 11:07 AM, Mark Smith wrote:
... An updated draft is attached. The only changes compared to the 29-Jan-2019 version are in section 3.1.
I just noticed that there were two sections numbered 3.2. Oops. Please use the draft attached to this message instead of the previous one.
Thanks! Commit b5cd3d78f4e118642731a55ec8019fa3c4382f1a in the tor-browser-spec repo has the proposal included now.
Georg
Hi,
Filename: NNN-integrate-tor-launcher-into-tor-browser.txt Title: Integration of Tor Launcher into Tor Browser Core Author: Mark Smith and Kathleen Brade Created: 22-Jan-2019 Updated: 7-Feb-2019 Status: Draft Ticket: #28044
Sorry for the delay: we were busy with preparing our major 3.12 release when this proposal came up, and I've just come back from holiday.
R3. Allow users and projects such as Tails to disable Tor Launcher at runtime via environment variables and hidden preferences as is possible today.
Thanks a lot for including Tails in your considerations, much appreciated :)
R5. Continue to maintain a separate git repository for Tor Launcher. This will allow development of Tor Launcher to proceed outside of core browser development and will also facilitate continued use of Tor Launcher as a XUL/XPCOM extension by those projects that have that requirement, e.g., TorBirdy.
OK. I understand this will allow Tails to:
- Build and ship a Tor Launcher extension (disabled in our main Tor Browser profile, as per R3).
- Run Tor Launcher just like we currently do, until we switch to 68esr in October. Once we're based on 68esr, we won't be able to run Tor Launcher as a XUL/XPCOM extension anymore, and we'll need to replace it with another tool.
If I got it wrong, please let me know.
4.1 TL_LOGO and pkg-prepare
Tails uses Tor Launcher for their Tor network configuration UI. To avoid confusion, they include the Tails logo in their copy of Tor Launcher, replacing the Tor Browser logo. This replacement is handled by the pkg-prepare Makefile target. We will need to find a different way to handle the logo override.
Tails sets TOR_HIDE_BROWSER_LOGO=1 (#14122). It would be nice to keep it. Since it's a runtime setting, and not a build-time thing, I assume it's not too much trouble to keep support for it? If it's too much trouble, drop it. This would cause a minor usability regression in Tails but given the timeline, I'd rather use your "being nice to Tails" time on longer-term issues such as #27466 and #10760, rather than on a tool that we'll need to drop in 8 months anyway.
However, we do *not* replace it with a custom logo (#12451) and have never done so. I think there's some confusion because of the way proper introduced themselves "as a user of Tails and a maintainer of Whonix" on these tickets. By the way, IIRC Whonix has replaced Tor Launcher with their own thing a while ago, so perhaps they don't need any of this anymore and TL_LOGO could go away?
4.3 UI For Access To The Tor Network Settings
Currently, the Torbutton toolbar menu contains a "Tor Network Settings" menu item which causes Tor Launcher to open its Network Settings dialog. As plans for incorporating the Torbutton functionality into the core browser proceed, we may need to provide a new method for users to access the network settings. Tentatively, we plan to eliminate the Torbutton toolbar item and its associated menu, which means new UI will need to be added to provide access to Tor Launcher's Network Settings dialog.
I think Tails will need some way to hide this new UI (otherwise user experience will be poor as Tor Browser in Tails is not actually allowed to change such settings). If we can do this in our profile config, with something like userChrome.css, that would be good enough considering we'll need to replace Tor Launcher in October.
Cheers,
On 2/8/19 10:39 AM, intrigeri wrote:
Hi,
Filename: NNN-integrate-tor-launcher-into-tor-browser.txt Title: Integration of Tor Launcher into Tor Browser Core Author: Mark Smith and Kathleen Brade Created: 22-Jan-2019 Updated: 7-Feb-2019 Status: Draft Ticket: #28044
Sorry for the delay: we were busy with preparing our major 3.12 release when this proposal came up, and I've just come back from holiday.
No worries; thank you for your input.
R5. Continue to maintain a separate git repository for Tor Launcher. This will allow development of Tor Launcher to proceed outside of core browser development and will also facilitate continued use of Tor Launcher as a XUL/XPCOM extension by those projects that have that requirement, e.g., TorBirdy.
OK. I understand this will allow Tails to:
Build and ship a Tor Launcher extension (disabled in our main Tor Browser profile, as per R3).
Run Tor Launcher just like we currently do, until we switch to 68esr in October. Once we're based on 68esr, we won't be able to run Tor Launcher as a XUL/XPCOM extension anymore, and we'll need to replace it with another tool.
Tails uses -app today, correct? Has that been removed from Firefox now?
4.1 TL_LOGO and pkg-prepare
Tails uses Tor Launcher for their Tor network configuration UI. To avoid confusion, they include the Tails logo in their copy of Tor Launcher, replacing the Tor Browser logo. This replacement is handled by the pkg-prepare Makefile target. We will need to find a different way to handle the logo override.
Tails sets TOR_HIDE_BROWSER_LOGO=1 (#14122). It would be nice to keep it. Since it's a runtime setting, and not a build-time thing, I assume it's not too much trouble to keep support for it? If it's too much trouble, drop it. This would cause a minor usability regression in Tails but given the timeline, I'd rather use your "being nice to Tails" time on longer-term issues such as #27466 and #10760, rather than on a tool that we'll need to drop in 8 months anyway.
We do not plan to remove support for TOR_HIDE_BROWSER_LOGO=1. Honestly, I forgot it was there... but our goal is to not break anything unless we need to do so due to Firefox changes, etc.
However, we do *not* replace it with a custom logo (#12451) and have never done so. I think there's some confusion because of the way proper introduced themselves "as a user of Tails and a maintainer of Whonix" on these tickets. By the way, IIRC Whonix has replaced Tor Launcher with their own thing a while ago, so perhaps they don't need any of this anymore and TL_LOGO could go away?
Yes, that was Tails vs. Whonix confusion on our part. And I think you are correct: we can just drop the TL_LOGO build-time option.
4.3 UI For Access To The Tor Network Settings
Currently, the Torbutton toolbar menu contains a "Tor Network Settings" menu item which causes Tor Launcher to open its Network Settings dialog. As plans for incorporating the Torbutton functionality into the core browser proceed, we may need to provide a new method for users to access the network settings. Tentatively, we plan to eliminate the Torbutton toolbar item and its associated menu, which means new UI will need to be added to provide access to Tor Launcher's Network Settings dialog.
I think Tails will need some way to hide this new UI (otherwise user experience will be poor as Tor Browser in Tails is not actually allowed to change such settings). If we can do this in our profile config, with something like userChrome.css, that would be good enough considering we'll need to replace Tor Launcher in October.
We will keep this requirement in mind as we move forward. Thanks for bringing it to our attention.
Hi again,
Mark Smith:
On 2/8/19 10:39 AM, intrigeri wrote:
OK. I understand this will allow Tails to:
Build and ship a Tor Launcher extension (disabled in our main Tor Browser profile, as per R3).
Run Tor Launcher just like we currently do, until we switch to 68esr in October. Once we're based on 68esr, we won't be able to run Tor Launcher as a XUL/XPCOM extension anymore, and we'll need to replace it with another tool.
Tails uses -app today, correct?
Yes, we do this:
exec_unconfined_firefox \ -app "${TOR_LAUNCHER_INSTALL}/application.ini" \ -profile "${PROFILE}"
… with a custom application.ini that contains (in Tails 3.12):
[App] Vendor=TorProject Name=TorLauncher Version=0.2.16.6 BuildID=20190128 ID=tor-launcher@torproject.org
[Gecko] MinVersion=60.5.0 MaxVersion=*.*.*
[Shell]
Has that been removed from Firefox now?
Apparently not. With Firefox 65 on Debian, I've extracted tor-launcher@torproject.org.xpi from current stable Tor Browser, added the aforementioned application.ini in the same directory, and run "firefox -app /tmp/blah/application.ini". Then I see a Tor Launcher "Unable to start Tor" dialog and once I click through it, the "Connect to Tor" one.
Does this mean it'll still work in Firefox 68esr?
We do not plan to remove support for TOR_HIDE_BROWSER_LOGO=1. […] And I think you are correct: we can just drop the TL_LOGO build-time option.
:)
4.3 UI For Access To The Tor Network Settings
Currently, the Torbutton toolbar menu contains a "Tor Network Settings" menu item which causes Tor Launcher to open its Network Settings dialog. As plans for incorporating the Torbutton functionality into the core browser proceed, we may need to provide a new method for users to access the network settings. Tentatively, we plan to eliminate the Torbutton toolbar item and its associated menu, which means new UI will need to be added to provide access to Tor Launcher's Network Settings dialog.
I think Tails will need some way to hide this new UI (otherwise user experience will be poor as Tor Browser in Tails is not actually allowed to change such settings). If we can do this in our profile config, with something like userChrome.css, that would be good enough considering we'll need to replace Tor Launcher in October.
We will keep this requirement in mind as we move forward. Thanks for bringing it to our attention.
Excellent!
Cheers,
Hi,
(Mark asked me on #10760 whether "the standalone XUL app feature will still be available in Firefox 68" so I figured I would reply in this thread, that has more context.)
intrigeri:
Mark Smith:
On 2/8/19 10:39 AM, intrigeri wrote:
OK. I understand this will allow Tails to:
Build and ship a Tor Launcher extension (disabled in our main Tor Browser profile, as per R3).
Run Tor Launcher just like we currently do, until we switch to 68esr in October. Once we're based on 68esr, we won't be able to run Tor Launcher as a XUL/XPCOM extension anymore, and we'll need to replace it with another tool.
Tails uses -app today, correct?
Yes, we do this:
exec_unconfined_firefox \ -app "${TOR_LAUNCHER_INSTALL}/application.ini" \ -profile "${PROFILE}"
… with a custom application.ini that contains (in Tails 3.12):
[App] Vendor=TorProject Name=TorLauncher Version=0.2.16.6 BuildID=20190128 ID=tor-launcher@torproject.org
[Gecko] MinVersion=60.5.0 MaxVersion=*.*.*
[Shell]
Has that been removed from Firefox now?
Apparently not. With Firefox 65 on Debian, I've extracted tor-launcher@torproject.org.xpi from current stable Tor Browser, added the aforementioned application.ini in the same directory, and run "firefox -app /tmp/blah/application.ini". Then I see a Tor Launcher "Unable to start Tor" dialog and once I click through it, the "Connect to Tor" one.
Does this mean it'll still work in Firefox 68esr?
I did the same test as above with Firefox 68.0a1 and it still works, so apparently the standalone XUL app feature is still available. Of course, that does not guarantee it will still be there is 68esr.
Does anyone know where Mozilla tracks the removal of this feature? If not, I'll fall back to asking my Firefox release manager friends.
Cheers,
-
Georg Koppen -
intrigeri -
Mark Smith -
Nicolas Vigier