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
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