#i2p-dev (irc2p) | 2.7.0-2 | Proposal 168 review Tues. Dec. 3, 8 PM UTC #ls2

anonymousmaybe when is the next meeting of I2P? not shown in the top

anonymousmaybe i2p devs i mean...

eche|on was it tuesdays? 1st feb?

anonymousmaybe i dunno tbh i just see the top bar of the room to see when the next date is

eche|on should be 1srt

eche|on and eyedeekay may correct with a correct time and date

tony Blinded message

tony I'm still not setup properly on docker. Everything I've tried and it says Network Firewalled.

dr|z3d is there a particular reason you're using a docker image vs a normal java install, tony?

polistern Hi everyone! Can somebody help me with my questions about Java Bote?

dr|z3d bote is on life support, polistern, but ask away.

polistern Will the application be supported by the I2P project or is mhatta the only hope now?

dr|z3d mhatta is currently the only person working on bote, and I don't think he's done much lately.

dr|z3d I put some themes together a few years ago, but I haven't looked at the codebase in a couple of years.

dr|z3d what you probably already know is that there's a lot of cruft in the codebase that needs either removal or updating.

polistern In any case need to make changes to the protocol.

polistern Well, I'm trying to keep my Bote client backwards compatible with Java, and I'd like to know if this is justified.

dr|z3d that's a good question, to which there is no easy answer. all depends whether mhatta intends to maintain bote. it's not clear what his intentions are.

eyedeekay In any case if mhatta were to start maintaining bote again, we would need help from us as well

polistern For basic functionality only small edit in the Bote protocol is enough to work with new types of addresses in I2P.

polistern More precisely in the processing of one type of packets.

eyedeekay That I can probably handle, and I guess I have plugin signing keys now...

eyedeekay Which type of packets?

polistern Peer List

polistern Here is the exact change I made: pboted.readthedocs.io/en/latest/bote/v5/packet_types/#315-peer-list

polistern Now if Java Bote first runs on I2P node and get non-DSA key, then it can only send mail and can't recieve.

polistern Because in protocol version 4 I2P addresses can only be of a certain length (384).

polistern But what is interesting, even with all this, there are about 200-250 live nodes in Bote network :)

RN is bote still trying to access Seedless?

eyedeekay I got cut off and had to look at the IRC logs to catch up.

eyedeekay I think I'll be able make the necessary changes but without mhatta I won't be able to release an update to existing Bote's

eyedeekay If I come up with something I'll try to get mhatta's attention and merge it

eyedeekay It would essentially become another life-support fork

anonymousmaybe eyedeekay is not worth to work on Bote while I2P still not yet fixed its stream isolation issue

anonymousmaybe i think i saw a github project called eeproxy which is great

anonymousmaybe but i think is also abandoned since 2 or more years

anonymousmaybe I2P anonymity VS fingerprint is garbage

eyedeekay eeproxy is my project, also httpproxy and multiproxy

eyedeekay multiproxy is the most advanced/responsibly designed version

eyedeekay It most closely emulates Tor's tactic for browsers but it's bad at encrypted leaseSets and it's written in Go, so it won't be straightforward to integrate with i2ptunnel, it would need a full rewrite in Java

eyedeekay It's not **hard**

eyedeekay But it might be a lot of work

eyedeekay Just in terms of quantity

anonymousmaybe eyedeekay yeah but I2Pj or I2Pd should implement it by default

eyedeekay Also it doesn't work with HTTP authentication unless we put it into aggressive mode, which is probably not necessary and maybe counterproductive

eyedeekay pseudonym-isolating HTTP proxies are only useful if you are very sure your user agent is going to be a browser, too, so it might break other things on 4444

eyedeekay If such a thing were to be implemented on the HTTP proxy we use now

anonymousmaybe HTTP tunnel for http asaik

eyedeekay The problem is that it works the same way Tor's SOCKS authentication based isolation works, except in our case repurposes the authentication header as a way to multiplex client tunnels

eyedeekay In aggressive mode it's per-site

eyedeekay In regular mode you get a "global" tunnel and a tunnel for every authentication header that you pass

eyedeekay Aggressive mode breaks lots of things about the HTTP proxy that one might rely on. Regular mode only breaks two things, but one of them isn't fixable AFAICT

anonymousmaybe whonix.org/wiki/I2P#Post-Tor_I2P_Tunnel_Effects

anonymousmaybe check Warning: No Stream-isolation Support

eyedeekay I'm aware, I'm the one who explained that possibility to patrick

eyedeekay I also implemented the actual attack

anonymousmaybe cool then, but shouldnt this first fixed?

eyedeekay Yeah but *how* is important. Is it a new tunnel type? An application launched by i2pbrowser.sh in i2p.firefox? How close to the user agent does this have to be to be effective and not break stuff

eyedeekay Because right now strictly speaking the HTTP proxy is working as-intended, and major things exist on the HTTP proxy that are incompatible with this idea

eyedeekay If it goes into I2PTunnel it's a new tunnel type IMO, it can't be an option on the existing tool

anonymousmaybe An application launched by i2pbrowser.sh in i2p.firefox? <- whats the problem with this concept?

anonymousmaybe TB-Tor doing it the same way no?

eyedeekay Nothing that I know of, the operative part being "That I know of"

eyedeekay Well, the encrypted leaseset support is absolutely lousy but I can fix that

eyedeekay Oh also SAM

eyedeekay I need SAM to use multiproxy

anonymousmaybe having lets say 50 http tunnel, can I2P handle that? (assuming each new website gonna have its own tunnel)

eyedeekay But that's workaround-able

eyedeekay It seems to handle it just fine

anonymousmaybe yeah i read that SAM can handle multiproxy i think either by you or someone was in whonix forum was working on I2P inside whonix

eyedeekay But that's for one client that's not actively browsing all 50 sites, I don't know how such a thing would affect the network if it were widespread

anonymousmaybe i can test things if you like

anonymousmaybe but in my opinion this is way much important than Bote or susimail..etc

eyedeekay I kind of agree, but I see why people wouldn't agree

eyedeekay Right now we operate with a fairly simple assumption, one tunnel pool one destination

eyedeekay for the purposes of treating it like an identity, tunnel pool, one destination, one pseudonym

eyedeekay Hypothetically, it ought to be a relatively easy mental model to tolerate

eyedeekay *one hidden service one tunnel pool one destination, really

anonymousmaybe yeah i think that was good for the old times

anonymousmaybe now things need multi instead of one

eyedeekay I still think the how needs more discussion. An issue thread on i2p.firefox might be the place to do that.

anonymousmaybe how thing need more than one source

anonymousmaybe to read and check

eyedeekay Re: the "abandonment" of eeproxy it's not so much abandoned as "really simple." Rarely needs much change because it's just sticking http proxies on a map and looking up the keys

dr|z3d auto-recycle dests would probably address most of anonymousmaybe's complaint.

dr|z3d *auto-cycle

dr|z3d it's not quite stream isolation, but it's not that far off, given a short lifespan per dest.

eyedeekay I pretty strongly disagree, it doesn't address contemporary X-I2P-Header correlation at all, and you only need a pretty tiny amount of data to make some pretty good guesses about which past destinations were used by an existing destination, as long as they keep visiting your site

dr|z3d you might be able to correlate the visitor on a couple of sites, but if the dest is changing every 5 minutes, for example, you're going to find it extremely difficult to create a long term profile of the user.

eyedeekay Given a pretty big pool of visitors who have mostly similar browsers maybe

dr|z3d advanced fingerprinting of the browser's characteristics is a separate issue, and is largely mitigated by disabling javascript.

dr|z3d if you're fingerprinting browsers, and doing it well, then the dest of the client is secondary. so, you know, separate issue.

eyedeekay Unless your goal is specifically to correlate past and current destinations and that's what you're using browser fingerprinting to do

dr|z3d persistent attackers will persist!

dr|z3d the idea of multiple dests per tunnel is worth considering, for the http client and also things like snark.

dr|z3d instead of a single dest, a user-configurable number of dests are associated with a tunnel, each with their own leaseset, with cycling between them, on a schedule and/or randomly.

dr|z3d add in the ability to cycle a single dest on a schedule, and you have something that has the potential to defeat a bunch of attacks.

eyedeekay Because it's designed for the tabbed browsing case, multiproxy makes the destination stick to the remote end(aggressive) or the pseudonym(regular), picking one at random wouldn't make sense there

eyedeekay For other things it might