Well it was really just a matter of what I started with and what I left in when I re-activated Torbutton. The reason I originally regarded what I did as “cheating” was that my original intent was to apply these settings to a current Tor Browser in order to produce an acceptable basic i2p Browser. Then I realized Torbutton configured most of those by default and removed all but the proxy-setting preferences, and leaving them all explicit seemed like the careful thing to do. I’ve added that back into the script. This is simple enough to maintain and useful to me, so I’m going to keep it maintained, but if I can I’d like to move to modifying the tb-updater to set up a Tor Browser especially for use with a modified proxy(i2p or privoxy, etc), and either modifying or imitating tb-starter to configure and launch it. That way the behavior is consistent and we can sidestep some of the update issues. I’ll just make it so they have a common configuration file with the desired settings.
changelog.txt? Location? In tbb folder on local harddrive? Of regular
Tor Browser or custom i2p Tor Browser?
- the user may not start the former for a long time so the former
changelog.txt can’t be trusted - the latter changelog.txt in custom i2p Tor Browser folder won’t change
since Tor Browser internal updater
Parsing changelog.txt sounds hacky and wrong.
Idk:
It’ll also help me identify whether there are any needed modifications I can’t make in TBB with environment variables, but most of them already seem to be where I need them.
Yea. Environment variables everywhere already. Fore-planed modification
long ago. And where we lack needed environment variables them, we would
add them.
I was thinking just an “–i2p” flag for each of them,
Yes, it could have a flag --i2p which runs a function which then sets
the variables.
Idk:
if I can I’d like to move to modifying the tb-updater to set up a Tor
Browser especially for use with a modified proxy(i2p or privoxy, etc),
Yes.
and either modifying or imitating tb-starter to configure and launch it.
Imitating tb-starter doesn’t sound so great. Modification should be doable.
I thought on it some more & I don’t feel comfortable fucking with Tor Browser’s updater SSL with stunnel. They are probably checking code sigs too but still. Yet another probably impractical solution is to “virtualize” the original TBB. Essentially every time you launch the custom Bundle, the original is copied to the custom folder, a script applies the custom prefs including the SSL blocking, bookmarks and so on. Then on exit the entire custom TBB folder is deleted. The advantage is you are guaranteed to be running the latest TBB version despite internet access blocked, also its way more easier than modifying the Tor downloader script to keep track of versions, perform the updates and then restore our custom settings that disable socks access. The disadvantage is it could be slower to start.
If this too sounds too much then I say we forget about blocking internet access and save everyone’s time. Let’s assume a non-disciplined user is not really our problem.
You forgot to add enforce-blocks 1
that’s what the “enforce-blocks” option is for. If it’s enabled, Privoxy hides the “go there anyway” link. If the user adds the force prefix by hand, it will not be accepted and the circumvention attempt is logged
.
Expected see
However, because the proxy cannot gracefully show the regular “blocked” page with HTTPS, it will just refuse the request. The browser will then display an error like “The proxy server is refusing connections”. This means you won’t be able to bypass the filter (if that option is even enabled).
Couldn’t we just whitelist the updater URL ?
HulaHoop:
I thought on it some more & I don’t feel comfortable fucking with Tor Browser’s updater SSL with stunnel. They are probably checking code sigs too but still. Yet another probably impractical solution is to “virtualize” the original TBB. Essentially every time you launch the custom Bundle, the original is copied to the custom folder, a script applies the custom prefs including the SSL blocking, bookmarks and so on. Then on exit the entire custom TBB folder is deleted. The advantage is you are guaranteed to be running the latest TBB version despite internet access blocked, also its way more easier than modifying the Tor downloader script to keep track of versions, perform the updates and then restore our custom settings that disable socks access. The disadvantage is it could be slower to start.
See bold. Why would the version be up to date? The user would have to
interact with the “virtual” (or call it template?) TBB’s gui internal
updater. Then the user would have to close TBB so the starter could make
a copy of it, modify, and start it.
You were right 
I added:
and it worked while blocking other ssl sites. My first post is now valid again. No need for the complicated workarounds with Tor downloader. Sorry for not doing a more thorough job the first time. Please add the steps in my link to your github. I also added one more thing for ftp proxying since last time.
Great, thanks for testing
I guess trust-info-url would also be handy for telling the user what happened and that he should use the normal TBB
A URL to be displayed in the error page that users will see if access to an untrusted page is denied.
Please Edit the Link to point to the Repo directly ( i changed the name of the file and i’m going to add more by time just to avoid 404’s )
https://github.com/mutedstorm/Whonix-I2P
+1
Done
TBH, it doesn’t actually seem to be that hard to modify tb-updater to download to a custom folder without affecting any other functionality. I’m still testing it to make sure it doesn’t break anything else, and it’s not doing any of the i2p modifications(I’m going to do that by modifying tb-starter instead, as that is where those changes are appropriate) but this change adds that functionality in a basic way at least. I’m pretty sure that’s all I’ll actually “need” to do to the updater.
Hey can somebody make sure I’m not missing something here? There seems to be a problem using an IPC socket by setting the environment variable in the tor-launcher extension. If I set TOR_SOCKS_IPC_PATH, somehow it ends up with extensions.torlauncher.socks_port_use_ipc=false and network.proxy.socks containing the path to the socket. If I switch extensions.torlauncher.socks_ipc_path to the socket and set extensions.torlauncher.socks_port_use_ipc=true and restart the browser, then it works, but I can’t set this with an environment variable(and I’m pretty sure I shouldn’t be able to. It looks like it’s supposed to work with the socks_ipc_path if it’s set and the file exists, the relevant section of code is https://gitweb.torproject.org/tor-launcher.git/tree/src/components/tl-protocol.js#n135). An i2p SOCKS tunnel(without socat) doesn’t seem to work in this context either, which I tried as a workaround. Before I try and modify tor-launcher, does anyone have any advice?
Never mind. I figured it out like an hour after I posted. I need to submit a tiny change to Torbutton.
Merged. And refactored.
https://github.com/Whonix/tb-updater/pull/3#issuecomment-396076138
Could you please check again if it’s still working as expected?
Sorry I was in bed when you did the refactoring. I tried it and ran into an issue where the variables were not available to tb_preparation. Simply moving tb_preparation to after the argument parsing seems to work and doesn’t seem to interfere with anything else. tb_settings_folder is drawn from directories in tb-starter(/etc/torbrowser.d/) which are not hyphenated. In my fork of tb-starter I didn’t hyphenate the /etc/i2pbrowser.d folder, but if that is preferable I will. For now, I changed that so that it would find the right folder. New pull request should address all that.
tb_run_function tb_parse_cmd_options “$@”
tb_run_function tb_preparation
tb_run_function tb_config_folder_parser
Should be:
lowest priority: tb_preparation (fallback values if below does nothing)
normal priority: tb_config_folder_parser
highest priority: tb_parse_cmd_options
Do you think we have that still?
Idk:
Sorry I was in bed when you did the refactoring.
Don’t worry a thing. It’s very cool to have someone check and modify the
code.
tb_settings_folder is drawn from directories in tb-starter(/etc/torbrowser.d/) which are not hyphenated.
No need for hypen.
Unrelated:
Actually less and less sure if the config file /etc/torbrowser.d/ should
belong to tb-starter. It’s shared. Furthermore, the reason for a
separate tb-starter package are probably invalid by now.
(Reasons where: 1] tb-updater on Whonix-Gateway for
https://phabricator.whonix.org/T118 without a starter. But even if so -
there are better solutions - such as just using another package to
config-package-dev hide the starter than a separate package. 2]
tb-updater / tb-starter outside of Whonix used by third parties -
anondist - unlikely to happen.)
So perhaps for Whonix 15 we’d merge tb-starter into tb-updater.
I am almost sure that we do(Still function normally as before, but with additional behavior). Moving that function seemed like a potentially huge difference in how the code would work, so I read it and ran it extensively first. Regardless of when it’s called, tb_preparation sets any empty variables to the default values, but it only sets those values if they are blank or invalid because the configured setting points to a path that doesn’t exist. Because of this, and because tb_parse_cmd_options only does the argument parsing and sets things that aren’t default, as far as I can tell, tb_preparation can be called immediately after tb_parse_cmd_options without changing the behavior. No args downloads to $HOME/.tb still, gives all the same messages, and doesn’t do anything unexpected, then I tried it with various combinations of args, they seemed to work too. If it(tb_preparation) is not done after the arg parsing, it appears that the settings folder variables are set only by tb_preparation and the only settings folder which can be read is /etc/torbrowser.d. I don’t know every use case out there, but I don’t think users should notice this change from a purely behavioral perspective.
@Goldstein, please add this line to /etc/privoxy/config for future zeronet compatibility too:
forward .bit 127.0.0.1:43110
Done.
I don’t know if it fits there though, have you tested Zeronet?
- Could you please also modify the textual strings
torbrowser-updaterandTor Browsertoi2psomething when using--i2p?
Also would be cool to have:
-
/usr/bin/update-i2pbrowser - simply running
update-torbrowser --i2p -
man page
-
debian folder, postinst script: same mechanism as for Tor Browser (but with an additional config setting to opt-in this first)
All of this is completely optional.
New pull request has it use i2p based names when using --i2p for almost everything but wiki documentation, as that would point to dead links and the update-i2pbrowser script. I’ll do the man pages and the postinstall script shortly.