To the best of my understanding, no(simply removing them shouldn’t cause problems in and of itself, but I can’t say anything about update problems). tor-launcher.xpi just configures bridges and makes sure that Tor is started. I thought it was confusing to present that at this point. HTTPS everywhere isn’t relevant(yet/anymore) to eepSites but I’m looking into the darknet-everywhere rulesets to determine the future there. The last one is for meek, which isn’t available to i2p to the best of my knowledge. So those should be safe to take out. Also, they don’t modify pages or expose things that can be manipulated with javascript on pages so they aren’t detectable.
I hadn’t thought about the update thing. I’ve been using the bundles I’ve scraped from the download page which hid that from me. My guess is that it would add the plugins back in though. I’ll look into it too.
1 Like
Idk:
@Patrick
That’s something I’m taking into consideration, it’s just a matter of how and where to implement it. I think it’s possible to implement something equivalent through the i2p API’s.
I don’t see how i2p API’s relate to how Tor Browser by default is now
using SocksSocket (unix domain socket file)?
Can’t you redirect Tor Browser’s unix domain socket file
/var/run/anon-ws-disable-stacked-tor/127.0.0.1_9151.sock to
127.0.0.1 port 4444 (or wherever) using socat (for testing) and
later systemd-socket-proxyd / anon-ws-disable-stacked-tor (for
proper implementation)?
(Tor Browser environment variable TOR_CONTROL_IPC_PATH)
Idk:
What are your thoughts on this guy: i2p-browser-for-cheaters/setup-i2p-browser.sh at master · eyedeekay/i2p-browser-for-cheaters · GitHub ? I didn’t have it do any of the renaming files and changing the contents of the desktop shortcuts, wasn’t sure if that was a good idea in this context yet, but it should be easy to incorporate into other shell scripts or invoke from a terminal.
extension_overrides=“$i2pbrowser_directory/Browser/TorBrowser/Data/Browser/profile.default/preferences/extension-overrides.js”
sysprefs_location=“$i2pbrowser_directory/Browser/TorBrowser/Data/Browser/profile.default/prefs.js”
“$i2pbrowser_directory/Browser/TorBrowser/Data/Browser/profile.default/preferences/temp.js”
Are so many file locations required?
Would
“$i2pbrowser_directory/Browser/TorBrowser/Data/Browser/profile.default/i2p-browser.js”
work?
echo “$i2pbrowser_append_extension_overrides” | tee -a
“$extension_overrides”
echo “$i2pbrowser_syspref_js” | tee “$sysprefs_location”
Script may not be idempotent.
Hammer/nail(Availability heuristic) problem on my part. Socat/systemd is how I’ll move forward.
That juggle there, where it uses the $i2pbrowser_directory/Browser/TorBrowser/Data/Browser/profile.default/preferences/temp.js file, is to remove the bridge configuration lines from the extension-overrides.js file. I don’t think it’s necessary. I’ll try it without that and report back the results. I don’t think I know if $i2pbrowser_directory/Browser/TorBrowser/Data/Browser/profile.default/i2p-browser.js will work in the place of prefs.js. I think it will. I’ll just have to try that too.
1 Like
@Patrick I made the changes you suggested, now the i2p-specific preferences are in the same directory as the extension-overrides under the name i2p-browser.js and I no longer remove the bridge configurations from the extension-overrides.js file. It appears that it all works just fine that way. sysprefs_location was renamed to i2pbrowser_preferences to reflect this change.
@Goldstein @HulaHoop The latest version of the script modifies the names of the .desktop file and the script it launches. It still removes torlauncher*.xpi and https-everywhere*.xpi and the meek stuff. I’m about to apply it to an old TBB and see what the update process does to it.
1 Like
I ran it against version 7.5.3 and allowed it to update. It added https-everywhere back in but not torlauncher, probably because https-everywhere had an update but torlauncher didn’t. So I’m going to need to rethink that part. On the bright side, though, the settings are preserved and I think I can sidestep the parts of torlauncher not relevant to i2p by pre-configuring to disable the plugin instead of removing it. I don’t think leaving https-everywhere in will do anything bad, I’m still able to browse eepSites and not seeing any attempt to connect to the Observatory or any other clearnet resource. The meek http helper folder is not added back in by an update.
Edit: I’ve re-incorporated the extensions that I had deleted before, and instead I’ve set them to use custom preferences that won’t interfere with i2p. TorLauncher is configured to not attempt to start tor or use a bridge, and I’ve explicitly disabled automatic ruleset updates and contact with the SSL Observatory in HTTPS-Everywhere just in case. Settings also appear to be preserved across updates here. HTTPS-Everywhere has support for custom proxies, that might be something worth exploring. Besides that they seem to be working and updates have nothing to silently add anymore since it’s been left in and pre-configured.
1 Like
Is there any reason why I wouldn’t want to set it to my own socket by setting extensions.torlauncher.socks_ipc_path, Whonix-wise? I’ve now successfully made it work over a domain socket in that way. The changes are commented out in the TBB modifying script pending pretty much when TBB switches.
Idk:
The meek http helper folder is not added back in by an update.
Updates only change the delta (actual changes, not resending all files).
So this may or may not be the case when meek gets updated.
I don’t see why meek should be deleted - never caused an issue in Whonix.
I think my early impulse was to try and remove Tor-specific features, but since doing that seems pointless(Now that what it produces works) I’d rather not have something added back in by an update without a user knowing. I’ve changed it to leave the meek profile in now.
Idk:
Is there any reason why I wouldn’t want to set it to my own socket by setting extensions.torlauncher.socks_ipc_path, Whonix-wise?
My Whonix development experience lets me conclude, it’s best to keep the
Tor Browser folder unmodified and to use environment variables to
reconfigure Tor Browser to do what it should. Everything else is
unreliable long term. And in the absence of environment variables, work
with Tor Project to get them implemented, possibly submit patches.
Since you’re possibly going to modify tb-starter /usr/bin/torbrowser (
⚓ T795 Customized welcome page and bookmarks for I2P / Alt TBB (keyword: homepage) ), I think modifying the
environment variable would be better.
2 Likes
@Goldstein I checked it and now its working no problem. Seems to be a spooly errata that is now fixed o.O
1 Like
@eyedeekay You guys have made some great progress since I was last here. Thanks for putting your backs into it. IMHO the best way forward, with least maintenance and breakage is to leave Tor Browser extensions and updater alone and do the absolute minimum that gets us up and running as long as they don’t mess with I2P functionality - Which I don’t think they do?
Has anyone tried to update it with our Tor Browser Downloader script and see if the prefs stay set?
Also speaking of updating I think its very important to have Tor Browser Downloader somehow trigger on startup of TBB I2P to check for new versions since this custom version is incapable of connecting to the the internet? Its very important users have the latest fixes for obvious reasons. @Patrick can this be easily done if its the case?
1 Like
Doable. “Define easy.” Submit proposals / code.
1 Like
The easiest solution I can think of is to append a command to run TBB DLer, in the custom TBB menu icon.
for example:
custom torbrowser u% && run TBB DLer
A user would have to go out of their way to not run an update check.
For this to be seamless as possible:
-
TBB Downloader needs to be able to check the version of the locally installed TBB - this can be done because there is a version.js capability implemented in Tor Browser that can be queried IIRC.
EDIT:
Use prefs.js to get installed torbrowser version by nickjwhite · Pull Request #308 · micahflee/torbrowser-launcher · GitHub
Since TBB lacks a metadata file and parsing prefs.js for version info is bad practice, the best way is to read the changelog text file and go from there:
Read the version number from ChangeLog.txt by kraai · Pull Request #307 · micahflee/torbrowser-launcher · GitHub
-
TBB Downloader should run in a background mode and only show a prompt if installed version is less than a newer one.
While testing now: It seems other config settings are persistent, however disabling the socks proxy (to prevent normal internet access) is rolled back after a TBB update. Do you have a suggestion on how to keep it off permanently?
HulaHoop:
The easiest solution I can think of is to append a command to run TBB DLer, in the custom TBB menu icon.
for example:
custom torbrowser u% && run TBB DLer
&& would result in running update-torbrowser when torbrowser
exits 0 only.
Lunch into background.
torbrowser &
update-torbrowser --some-yet-to-be-implemented-switch[s]
A user would have to go out of their way to not run an update check.
For this to be seamless as possible:
- TBB Downloader needs to be able to check the version of the locally installed TBB - this can be done because there is a version.js capability implemented in Tor Browser that can be queried IIRC.
Patches welcome.
re-implement Tor Browser local version number detection
https://phabricator.whonix.org/T400
- TBB Downloader should run in a background mode and only show a prompt if installed version is less than a newer one.
Ticket and patches for new command line option welcome.
1 Like
OK before I open tickets with the proposals, there is another idea:
Have a script that monitors changes to changelog.txt and trigger an 1. overwrite of the custom TBB folder with the updated code if it detects changes in TBB original, 2. Run the I2P pref script to re-apply those settings after the code update.
Which one do you think is better?
1 Like
I think this one is easier to do and it would give us the option to check more things like:
is i2p running,
are tunnels build,
check for I2P Updates,
and so on…
what do you think ?
I’ve been reading through the tb-updater and tb-starter scripts, and I have a pretty good idea of how to make the changes we need to make to make them set up an i2p browser also. I’ll watch the proposals and try and implement them this weekend. 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. I was thinking just an “–i2p” flag for each of them, which would tell tb-updater download the latest TBB to a different path and tell tb-starter to use that TBB and assure i2p-related settings. Unless I’m missing something that should be something I can do by Monday.
2 Likes
Actually these last couple of proposals are a workaround for the fact that we can’t get privoxy’s domain whitelist feature off the ground. This is by far the better solution as we can still update normally but not users visit internet sites by mistake. @Goldstein any luck doing this?
Now @Goldstein add the whitelist instructions to your github page:
In /etc/privoxy/config uncomment the line below and then restart privoxy:
trustfile trust
Edit the newly created file:
kdesudo kwrite /etc/privoxy/trust
Add this rule rules at the end of the file then restart privoxy:
~*.i2p
Now it should block access and display a big red “UNTRUSTED” warning whenever connecting to a non whitelisted domain (with the caveat that you can override it if you press the go there anyway link but I assume the user is not retarded). Tor Browser updater can connect no problem.
N.B. This is not effective for https links. To block those change the setting below in about:config:
network.proxy.ssl;127.0.0.1
network.proxy.ssl_port;8118
Also might as well set privoxy for ftp proxying too.
Now it will say proxy refusing connections. I think @eyedeekay’s choice to set all the protocols (ftp, ssl, http) to 127.0.0.1:8118 was a more sound choice because ‘share settings’ doesn’t seem effective. Can you also add this to github?
There is still hope. To filter ssl we can can use stunnel. Unfortunately squid is not an option because to enable sslbump support we would need to recompile the deb src package since the default binary does not have these options enabled.
This is more complicated than I thought with not much instructions on the web. The closest thing I have is this discussion though its not directly related:
What we want is to MITM SSL connections and pipe the output into privoxy which can then apply its whitelist. Why does it have to be a bitch to configure? I don’t know but we might get there.