Merged. So far so perfect.
Next optional steps:
- Merge tb-starter into tb-updater.
- Share code to avoid code duplication. Perhaps a common file with shared functions (these which determine variables, parse cmd).
- Add
--i2p
switch to/usr/bin/torbrowser
. -
.desktop
file. - postinst
Hello. I know you have decided against removing features, but a couple of points.
Custom rulesets can be made in HTTPS Everywhere to force connections to eepsites, the same as with onion services. Helps to keep clearnet out of the equation. Example: attempted connections to https://geti2p.net would automatically redirect to http://i2p-projekt.i2p.
I2P uses two transports right now:
NTCP, a Java New I/O (NIO) TCP transport
SSU, or Secure Semireliable UDP
http://i2p-projekt.i2p/en/docs/transport mentions the possibility of pluggable transports and restricted routes (a la guard nodes), but the most recent changes to I2P’s trac tickets were 19 months ago and milestoned at eventually.
Good Point, its not removing features so its fine.
Great, would you like to create this ruleset ?
This isn’t something we should focus on atm, if I2P is blocked we could route it through tor and if tor is blocked I2P will be blocked too with or without pluggable transports.
I can do that. There aren’t too many eepsites with clearnet counterparts, so there aren’t many rules to make. I don’t have any coding experience, but I can paste the extension’s storage.js file with any relevant rulesets… would I aim for any parallel services, or only certain ones?
I know. I wanted to fill in some knowledge for eyedeekay, it wasn’t to imply any need for action on Whonix’s part.
Also, have there been any ideas about how to handle I2P’s (optional) incoming connections at the gateway? Doing that looks to be counter to Whonix’s design policy, but some people (like me) would want to forward them if possible.
great, any parallel service
It should work but i haven’t verified it.
I don’t think it counters Whonix design, but @Patrick probably knows best.
OK, I’ll start compiling the list.
Rulesets can be written as an xml file, but imports/exports are crippled since Firefox’s switch to WebExtension. My idea about Storage.js was no good, hopefully someone knows a way to bring the rules into the browser.
Whonix docs state that opened ports are rarely needed outside of certain use cases, such as relays or onion services. Whonix has mostly been built around Tor at this point, most use cases acting as clients.
AFAIK, Whonix hasn’t incorporated a P2P network into it’s design before this point, so it seems like certain issues haven’t really been experienced yet. I don’t know.
Related wiki page for reference only (no statement for I2P integration):
Opening ports is already easily possible in Whonix-Gateway firewall through config snipped drop-in.
Technically, there are three components here:
- Configuration an open port reachable from Whonix-Gateway side is simple.
- More difficult is how you get the port forwarded from the host to the virtualizer. Virtualizer specific. Undocumented at Whonix. Documented elsewhere for sure.
- Open the port from the - usually NAT router - to the computer running the Whonix-Gateway. Router specific. Undocumented.
Whonix default download version (as it exists at time of writing) shouldn’t ship by default with open ports by default but everything else [*] like opening ports vs not opening ports by opt-in or opt-out is up to the maintainers of this I2P integration.
[*] instructions, helper scripts, packages to install I2P integration, alternative versions [default I2P enabled] or so maybe even downloadable from whonix.org, whatever will be the result of this thread
Good to keep the custom settings in one place IMHO. No haven’t in a while but it is a long term goal on the map.
Alright, 8 eepsite-rulesets have been created. I Started with the rule sets provided by darkweb-everywhere and was able to use some other resources. I’ve (hopefully) accounted for every domain for each ruleset, I2P uses many. Rulesets all verified by HTTPS Everywhere’s ruleset debugger and all syntax should be correct.
rulesets included for:
- I2P, Syndie, and I2P’s official forum
- TheTinHat
- Anoncoin
- (2) Rocksolid BBS member sites
- a Cyrillic-language site called ‘Flibusta’
I disqualified some eepsites for various reasons.
(Forum won’t let me upload the tar.gz archive, how should I share it?)
I am aware of Chris Barry’s darkweb-everywhere rulesets, I just didn’t consider updated https-everywhere rulesets an immediate priority yet. Thanks for taking up this task, I honestly had no idea when I’d be able to get to it.
@Patrick I’ll work on all that this week. I’ve got the basics of /usr/bin/torbrowser --i2p and /usr/bin/i2pbrowser ready to go, but I’ve got to find a way to remove Tor Project related markings and ideally, I’d like to replace about:home with an informational page about how contextual identities work differently in i2p than Tor because of less automatic isolation for http clients. Also in order to do /usr/bin/i2pbrowser I need to set use_nontor_proxy from an environment variable, which might be a hard sell.
Alternatively, and this is a kind of crazy idea, but could I sidestep the need for use_nontor_proxy by implementing domain(destination in the context of i2p) isolation in a way compatible with Torbutton? If I’m understanding things correctly I think that would work? I’ve already got the hardest parts to make of such a system, basically what I would have left to build is a sort of funky control port filter that talks to i2p? It’ll take much more time but I think it might be a better solution.
Why do you need to do that? Maybe you shouldn’t focus much on the cosmetic side of things at this point.
I don’t think there’s any way around use_nontor_proxy. It’s funny you mention destination isolation with Torbutton, because I thought it would be a good idea to send a “stop” command to the HTTP client tunnel and starting a new one when pressing “New identity” on TBB. Of course, that would mean allowing the workstation access to I2P’s router console (I do hope you plan on using the Java router) which isn’t good since the router has awareness of it’s physical IP address.
I should have added that destination isolation isn’t available for I2P, unless the SAM proxy you’ve been working on is successful. Destinations can be made to be time-limited and shut down after a period of disuse, can be manually restarted to generate a new address, or just by waiting for the next router restart.
Not exactly(my application has actually worked OK for a few months). I’ve actually been working on it for quite a while as an out-of-router application. It’s entirely unofficial, but it… works? I’m hesitant, because I don’t consider it ready yet, but per-destination identities are a thing I have, to some extent, successfully automated. GitHub - eyedeekay/si-i2p-plugin: An experimental approach to provide a destination-isolating mechanism for http-over-i2p.. Not even a clear performance hit, and it’ll work with java or c++ i2p. Torbutton compatibility is already a thing I decided I wanted to evaluate, and probably want. Best part is no router console access. All done with the SAM bridge and maybe soon, i2pcontrol.
Edit: just slightly synchronous communication runs a risk of sounding rude when a respondent misses a recent message. If in the conext of your latter comment, my response seems rude, it was unintentional. Battery’s about to die. Back tonight.
The reason I need to remove Tor Project related markings is basically because people are going to use it, and it’s not Tor Browser. It may not be of practical significance to you or me because we’re aware of the differences, but being the same person in every browser tab and on every site is a significant difference in how browsing the networks operates right now. Tor’s an important and useful group of projects and it would be disrespectful and hazardous of me to dilute or misrepresent their work. Also it’s the first thing that came up when I asked them about using TBB to create an i2p browser.
As for the new identity thing, I am fairly sure I could do that, but like you said actually shutting down the in-router http tunnel would at least require using an API that could access sensitive information used by the router console. The SAM bridge, on the other hand, has less access to sensitive information. The reason I mentioned a “funky control port filter that talks to i2p” is that if I put something that acted like a control port into my application, and could translate commands coming from Torbutton into operations inside the application, and do the handshake, then I don’t think there’s any reason we couldn’t be compatible with use_nontor_proxy. But I really don’t want to take that for granted. The application does what it says, if you want to take it for a test and have docker installed, easiest way is ‘make docker-setup browse’ (Default docker configuration uses i2pd), but I need to finish addresshelpers, which I am perennially unsatisfied with, then finish the SOCKS proxy(currently disabled), and hypothetically the Torbutton filter(Not to mention writing a whole bunch of absent tests and generally bringing the code up to a reasonable standard). Which I can do. And it sounds to me like the thing I want to do. But it’s not a thing that gets an i2p browser that works the way i2p browsing works for everybody on widely accepted software that more than one person has tested or manipulated in a serious way.
At some point you might want to create a similar ticket…
permission to install Tor Browser by default in Whonix
Idk:
Also in order to do /usr/bin/i2pbrowser I either need to set use_nontor_proxy from an environment variable, which might be a hard sell.
Not sure I understand?
In case it’s this misconceptions… Environments set by
/usr/bin/i2pbrowser won’t effect neither the global environment
variables nor /usr/bin/torbrowser. /usr/bin/i2pbrowser setting
environment variables might even be better than modifications inside the
file system, since less likely to break on TBB upgrades / when TBB maybe
it’s folder structure in future again.
That’s not the issue exactly, it’s that I need to set use_nontor_proxy explicitly because i2p doesn’t have a way to do per-tab isolation(yet), but there isn’t an existing environment variable to set use_nontor_proxy. I also don’t think the actual change itself(adding in the environment variable) is difficult, it’s a straightforward, 5 line addition to torbutton. My concern is that it might not be the best long-term way to build an i2p browser to do that(1), and if it’s not the best way, then the reason to do it is because it’s the quickest way. I don’t know if I’m wrong about that assessment of the situation.
(1) Deliberately ignoring per-tab isolation being the concern most relevant to Whonix, but platforms where an i2p browser doesn’t necessarily imply an automated way to setup an i2p service, there are other, related differences between i2p and Tor that make things complicated for an i2p-modified Tor browser that’s actually talking directly to i2p.
Now I enabled use_nontor_proxy from an environment variable. · eyedeekay/torbutton@3879775 · GitHub
Why not try to upstream that patch?
Similar tickets for reference:
- add environment variable that causes the "Open Network Settings" menu item to be hidden or disabled (#10632) · Issues · Legacy / Trac · GitLab
- environment variable to skip TorButton control port verification (#13079) · Issues · Legacy / Trac · GitLab
- add environment variable to hide TBB's logo (#14122) · Issues · Legacy / Trac · GitLab
Already decided to(basically gave myself the weekend to consider the options, I haven’t thought of a clear reason not to). They mentioned the domain isolation issue, and that I should remove TPO markings(strings, images, trademarks). I told them I would examine how to remove TPO markings and consider how I would addess domain isolation(Either by documenting the difference on about:home, a tunnel refresh button, or actually doing it being the options I was weighing). I have looked at changing the strings and images, and I can do that while I do the rest this week. They all seem to be a similar process. I’ll also continue to upstream the existing patch.