13:08 < jrandom> 0) hi 13:08 < jrandom> 1) 0.4.2 and 0.4.2.1 13:08 < jrandom> 2) mail.i2p 13:08 < jrandom> 3) i2p-bt 13:08 < jrandom> 4) eepsites 13:08 < jrandom> 5) ??? 13:09 < jrandom> 0) hi 13:09 < jrandom> sorry to interrupt dm's agenda 13:09 < jrandom> status notes up @ http://dev.i2p.net/pipermail/i2p/2004-November/000492.html 13:09 < jrandom> [hi] 13:10 <+postman> ((hi)) 13:10 <+postman> :) 13:10 < jrandom> so, as y'all read through that overwhelmingly interesting email, we might as well get the meeting underway 13:10 < jrandom> 1) 0.4.2 and 0.4.2.1 13:11 < jrandom> 0.4.2 is out, as you know, and the results are mixed, but when its not failing bad, it seems to be doing much better ;) 13:12 < jrandom> there will be a release with a whole slew of bugfixes soon - i've been holding off to try to get as many things improved as possible 13:12 < jrandom> as things stand now though, it looks like the 0.4.2.1 release will not yet get the i2p-bt port into tip top shape quite yet 13:12 <+postman> jrandom: what do the bugfixes address - all errors in the new streaminglib or other stuff as well? 13:13 < jrandom> a fast busy loop in the streaming lib that came up from a poorly tested scenario, some SAM issues, IP address detection problems, among other things 13:14 < jrandom> dev.i2p.net/cgi-bin/cvsweb.cgi/~checkout~/i2p/history.txt?rev=HEAD has the full list 13:14 <+postman> k 13:14 <+postman> thx 13:15 < jrandom> oh, one thing to note about 0.4.2.1 is that it, like 0.4.2, will need to modify your wrapper.config again, so please pay attention to the update instructions when they're out :) 13:15 < jrandom> does anyone have any questions/comments/concerns about 0.4.2? 13:15 < jrandom> (/0.4.2.1) 13:16 < clayboy> been working great here, have been tracking cvs too, always smooth 13:16 < jrandom> wikked 13:17 < bla> It's table (0.4.2): up for days already 13:17 < bla> s/table/stable/ 13:17 < jrandom> ah nice, yeah, the bugs havent been hitting everyone 13:17 < jrandom> ok, if there's nothing else on that, lets jump on to 2) mail.i2p 13:18 < jrandom> i hear postman has some things to discuss 13:18 <+postman> hello 13:18 < jrandom> hi postman, you're up :) 13:18 <+postman> weeks ago i conducted a poll regarding IMAP 13:19 <+postman> since a few weeks passed now i decided to close the polls and to count the vote 13:19 <+postman> result is: not needed - won't be done. period 13:19 <+postman> after talking to susi - she was quite fine wioth pop3 on her webmail interface 13:19 < clayboy> reason wins! :) 13:19 < jrandom> w3wt 13:20 <+postman> so let's just stick to the pop3 end bury any silly imap ideas 13:20 <+postman> :) 13:20 * jrandom gets the shovel 13:20 <+postman> 2.) we're close to 100 registered users 13:21 < clayboy> wow 13:21 <+postman> not all of them public of course, but it still sounds like a quite reasonable number regarding the size of the network 13:21 <+Ragnarok> so... how about that LDAP address book? :) 13:21 < jrandom> nice 13:21 <+postman> 3. a feature to upload/share you public pgp key is active since weekend 13:21 <+postman> please use it 13:21 <+postman> www.postman.i2p/user/acc.html 13:22 < clayboy> i'm not taking any credit for that idea :> 13:22 <+postman> the public keys can easily be downloaded with the help of the addressbook 13:22 <+postman> or direct as www.postman.i2p/public/accountname.pub 13:22 < jrandom> ooh cool 13:22 <+postman> the system works quite fine 13:22 <+postman> thanks to duck for pointing at a few bugs 13:23 <+postman> 4.) i think about offering accountbased routing 13:23 <+postman> like ppl say 13:23 < jrandom> account based routing? 13:23 <+postman> all mail for foo@mail.i2p gets transported to the following destination 13:23 <+postman> and user presents a valid destination key for it 13:24 <+postman> postman.i2p will then manually route mail to those accounts to mailsystems 13:24 <+postman> just an idea(tm) 13:24 < jrandom> ah nice 13:24 <+postman> i am looking forward to develop and discuss the whole matter 13:25 <+postman> that's it for now 13:25 <+postman> more follows next week 13:25 <+postman> thanks 13:25 < nmi> postman: sorry, transported to a particular i2p destination you mean? 13:25 * postman hands the mike back to jrandom 13:25 <+postman> nmi: yes 13:25 < ant> am SMTP i2p destination? 13:25 < ant> an 13:25 <+postman> nmi: provided the destination accepts smtp and mail for that account 13:25 < jrandom> that sounds very cool, gets rid of the trust aspect of the mail fiiltering 13:26 < nmi> ah, ok. clever. i had thought of doing something similar using mixminion single-use-reply-blocks but your idea is better... 13:26 < jrandom> its probably a lot of work to set up on the client side, but perhaps someone could do some hacking 13:26 <+postman> jrandom: i am working on it 13:26 < jrandom> w00t 13:26 <+postman> jrandom: the user will have the usual webinterface ( acc.html...) 13:27 <+postman> jrandom: and inserts the destinationkey 13:27 < jrandom> well, right, but then there's the MTA configuration 13:27 <+postman> the rest will be done automatigally 13:27 <+postman> yes, on the postman.i2p AND the receiving sinde 13:28 < nmi> jrandom: yeah, it would be cool to have a really stripped down smtp proxy for people not wanting to run a full MTA 13:28 < jrandom> right right 13:28 <+postman> jrandom: i will provide a simple setup config for ppl interested 13:28 <+postman> jrandom: for postfix, exim and sendmail 13:28 <+postman> jrandom: those can be stripped down to BARE necessities 13:28 <@duck> seriously, do you think that there are many users for that? 13:28 < jrandom> postman: this all sounds pretty kickass. i look forward to hearing more when you're ready 13:29 <+postman> jrandom: no idea about windows smtp servers tho 13:29 <+postman> duck: well 13:29 <+postman> duck: 8 weeks ago there was no need for a mailsystem and no users either 13:29 <+postman> duck: it's investment 13:29 <@duck> true 13:29 <+postman> duck: in 6 months we'll be happy to have it 13:29 < jrandom> duck: the potential comes with moving away from a trusted SMTP filter 13:29 <+postman> :) 13:30 < jrandom> er, perhaps i should say, moving /to/ a trusted smtp filter (no offense postman ;) 13:30 <+postman> and there will be a few ones 13:30 <+postman> AND 13:30 <+postman> (now the punchline) 13:30 <+postman> we could easily create maildomains :) 13:30 <+postman> like duck@duck.i2p and other stuff 13:30 <+postman> :) 13:30 <@duck> ah 13:31 <+postman> the only problem would be the official/private mapping 13:31 < jrandom> hosts.txt! 13:31 * jrandom ducks 13:31 <+postman> but this is another thing for the webmanagement console :) 13:31 <+postman> LOL 13:31 <+postman> jrandom: i rely on shaky sql databases :) 13:31 <@duck> ok; I see it fitting in 13:32 <+postman> ok 13:32 <+postman> then i will work it out and present an concept soon 13:32 <+postman> yess, yet more work 13:32 * postman leans back relaxed 13:32 <+postman> :) 13:32 < jrandom> kickass, thanks postman 13:33 < jrandom> ok, unless other people have further mail.i2p related questions, shall we move on to 3) i2p-bt? 13:33 < jrandom> consider us moved 13:34 < jrandom> ok, as the email mentioned, i broke the i2p-bt port 13:34 * jrandom hangs head in shame 13:34 < jrandom> in other news, duck, do you have anything wrt i2p-bt you want to discuss? 13:34 <@duck> as a result of jrandom's work not much has been done :) 13:35 <+Ragnarok> booo, hissss 13:35 <@duck> oh Ragnarok had some patches 13:35 * jrandom2p pelts jrandom with tomatoes 13:35 <@duck> I think, see the history file :) 13:35 < jrandom> oh cool 13:35 <@duck> we got some things in the queue too 13:35 <+Ragnarok> well, I was hissing at jr, but ok :) 13:36 <@duck> but I dont want to change (too) much on the unstable ground 13:36 <@duck> (like breaking bt while i2p is getting fixed) 13:36 < jrandom> aye, good plan 13:36 <@duck> . 13:37 < jrandom> ok cool, anyone else have anything on i2p-bt? 13:37 < jrandom> if not, moving us along to 4) eepsites 13:38 < jrandom> well, i know the issues have been discussed a few times since we first got the eepproxy, but there have been some recent queries warranting their mention again 13:39 < bla> yes... 13:39 < jrandom> what we have now for browsing eepsites and normal websites anonymously just plain isn't safe 13:39 < clayboy> disabling java, javascript, cookies and flash helps, though 13:39 < jrandom> DrWoo has done a great job with his page describing the dangers and how you can protect yourself 13:40 < jrandom> right clayboy, definitely 13:40 < clayboy> url? 13:40 < bla> clayboy: Yes, on the HTML side, but not on the HTTP side 13:40 < jrandom> but if there's one thing i've learned with the router console, its that no one follows more than two steps into the instructions ;) 13:40 < clayboy> bla: good point 13:40 < jrandom> clayboy: http://brittanyworld.i2p/browsing/ 13:41 < bla> I've done some experiments here: http://forum.i2p/viewtopic.php?t=182 13:41 < bla> Doesn't look good as it is 13:42 <@duck> who has the evil applets? 13:42 < ant> there was a security exploit found in java 13:43 < ant> for some older 1.4.x vers 13:43 < ant> not 1.5 13:44 < jrandom> nightblade: the 'attack' used in this person's case was really trivial, and, according to the person, worked from 1.1.6-1.5 13:44 < ant> hmm 13:44 < jrandom> (download a .exe, run the .exe) 13:45 < jrandom> i was suprised to see some java security permissions fire up on instantiation of new File(filename) but no security permissions fire up on instantiation of new FileOutputStream(filename) 13:45 * jrandom stops handing out hand grenades 13:46 < jrandom> (i havent verified their code, but did see much of it) 13:46 < jrandom> but anyway, eepsites 13:47 < jrandom> well, i dont think it would be prudent to remove the eepproxy altogether 13:47 < jrandom> but i dont really have time right now to implement any of the solutions listed 13:48 < bla> jrandom: Stripping out all Accept* headers would be a good thing, for now 13:48 < jrandom> what do y'all think? any volunteers? shall we wing it until we do get time? 13:48 < ant> bla: I don't think it is a big deal that people can see some browser headers 13:49 < ant> millions of people use those browsers 13:49 < bla> And always adding a User-Agent: header, even if the client didn't send one. I makes requests homogeneous 13:50 < bla> Nighblade: Yes, but if your browser says Accept-Language: xx (just made up on the spot), and there happens to be only 1 I2P node in a country that speaks language xx, almonimity is gone, completely 13:50 < bla> The Accept-Language: header is there though, in some browsers. And we can't rely on it always being "en" 13:50 < ant> ok but what if removing some of those headers violates the HTTP spec? 13:50 < jrandom> adding those two cases are easy enough, and i'll get them into 0.4.2.1, but it really isn't safe to explicitly filter headers like this 13:50 < jrandom> nightblade: we break so many aspects of the HTTP spec it hurts 13:51 < bla> Nightblade: Only one of the threee browsers I listed did send the header, so it shouldn't be much of a problem 13:51 < ant> HTTP was not designed for anonymity 13:51 < jrandom> the eepproxy is duct tape and shoe polish 13:51 < bla> jrandom: Why isn't that filttering safe? 13:52 < bla> jrandom: We could even consider stripping _all_ headeers, except for the Host: header and the GET header 13:52 < jrandom> bla: stripping all headers except the host would be safer, yes 13:52 < bla> jrandom: After all, what do we need more for an anonymous HTTP? 13:52 < jrandom> but thats beyond the amount of time i can put into it 13:52 < jrandom> i can add the Accept and user-agent filters in ~ 30s 13:53 < jrandom> much beyond that and i throw my hands in the air and rewrite the http proxy ;) 13:53 < bla> jrandom: How come stripping all of them is more difficult? 13:53 < jrandom> read the code. 13:54 < jrandom> (patches welcome) 13:54 < jrandom> but what we're looking at here is still just a short term solution 13:54 < bla> jrandom: Point well taken ;) But seriously: I think the Accept* and User-Agent fixes would do really fine for now 13:54 < jrandom> we need someone to work on something that will last us long term 13:55 < ant> * dm just ate 20 slices of cheese... drool. 13:55 < jrandom> bla: i heard that last time someone asked us to filter the User-agent and referrer headers ;) 13:55 < jrandom> (but yeah, i'll get those two into the next rev) 13:56 < ant> those headers are usefl 13:56 < ant> useful 13:56 < ant> For service providers. 13:56 < jrandom> yes, they are 13:57 < jrandom> we've already had some apps break because we filter referrer too 13:57 < bla> dmm: Yes, indeed. However, they also provide a browser or OS fingerprint 13:57 < ant> I have an idea! 13:57 * jrandom takes cover 13:58 < ant> Hard code the User-Agent to: Nokia6230/2.0 (03.15) Profile/MIDP-2.0 Configuration/CLDC-1.1 149.254.201.133 13:58 < ant> eh? eh? 13:58 < jrandom> we already hard code the user agent header 13:59 < ant> I2P-enabled cell phones 13:59 * jrandom mounts a DoS on that phone 13:59 < ant> To what? 13:59 < ant> My poor phone!!! 13:59 < jrandom> ok, anyone else have any thoughts on the eepproxy/eepsite stuff? 14:00 < bla> MYOB/6.ss (AN/ON) 14:00 < bla> no\ 14:00 <+Ragnarok> we should reinvent html using s-expressions! 14:01 < jrandom> (i really do think using a bbcode style macro language is the way to go, at least for some things ;) 14:01 < jrandom> ((or xml for you geeks)) 14:02 < ant> Microsoft endorses use of XML 14:02 < ant> So I'm all for it. 14:02 <+Ragnarok> xml is just excessively wordy s-expressions :) 14:03 < ant> Is this a good time for me to aplaud jrandom for his work on this project? 14:03 * jrandom volunteers Ragnarok to work on it, after getting the next gen address book ;) 14:03 <@duck> I dont think that 'invent your own markup language' will work for general browsers 14:04 <@duck> maybe for the blog thing inside myi2p 14:04 <+Ragnarok> it's always a good time :) 14:04 < ant> applaud even 14:04 < jrandom> duck: the proxy will need to filter content anyway, it would be simple enough (heh) to inject the results of macro expansions into the resulting filtered content 14:05 < ant> * dm tips his hat to jr. 14:05 < jrandom> gracias dm et al 14:05 < ant> something like PDF would be safer than HTML 14:05 < jrandom> lol 14:05 <@duck> .txt files! 14:06 < ant> i've seem PDF files with clickable links, but the files themselves are huge 14:06 < ant> seen 14:06 < ant> Uncompressed Bitmaps? 14:06 < jrandom> yes, lets all write in pdf 14:07 <+Ragnarok> erg, postscript is fugly 14:07 < ant> how is html insecure? 14:07 <@duck> anyway 14:07 < ant> cat: with javascript, activex, applets,... 14:07 < jrandom> cat-a-puss: all the different ways to encode dangerous data 14:08 < ant> languages aren't secure or insecure, clients are. 14:08 <+Ragnarok> the realy problem is how to do anon dhtml... 14:08 < jrandom> (and we'll never, /never/ be ahead of the game as long as we explicitly filter) 14:08 < ant> Java/javascript are enclosed in tags. So strip those out, plain html is not harmful right? 14:08 < ant> We need to use a data format that is parsed by a client made by a company that we trust. 14:08 < jrandom> Ragnarok: macros, and/or reference known safe and locally installed javascript 14:08 < ant> I trust Microsoft, therefore I suggest Internet Explorer, Microsoft Word, or Notepad 14:09 < ant> Flight Simulator 2002 is acceptable as well. 14:09 < ant> Freenet already has an "anonymity filter" strips out all Java / Javascript / ActiveX etc. Borrow that and the only thing I can think could get through would be Image exploits... unless there is something I am missing. 14:10 < jrandom> freenet's anon filter is a good start for one or two of the different camps, but would likely require some work to get forms working as we want them 14:10 < ant> the eepproxy would have to run as a separate process, because of licensing 14:11 < jrandom> that still leaves us a heavily crippled html 14:11 < jrandom> (with no css) 14:11 < ant> Okay, how about Flash? 14:11 < jrandom> nightblade: we can work around that (same way we work around i2ptunnel being GPL) 14:11 < ant> Imagine a world wide web with only flash. 14:11 < ant> What a rich and wonderful world that would be. 14:12 < ant> well Just create a warning: "Eepsite browsing is hazardous to your anonymity. Please use Gopher." 14:12 < ant> actually gopher is not a bad idea 14:12 * jrandom ports archie 14:12 <+Ragnarok> gopher! 14:12 < ant> There was Betty as well, wasn't there... 14:12 <+Ragnarok> I remember gopher :) 14:13 <+Ragnarok> man, those were the good old days. I think I had a screaming 14.4 baud at the time... 14:13 < ant> I only browsed gopher in text mode, and I don't know if it supported graphics 14:13 < jrandom> they didnt have gui browsers last time i used gopher ;) 14:14 < jrandom> anyway, there are lots of options 14:14 < ant> what was that browser called back then? the one before Netscape... 14:14 < ant> i forget 14:14 < jrandom> mosaic 14:15 < ant> yeah 14:15 < ant> Mosaic 2.0 14:15 < ant> "Welcome to I2P, please wait while we install Gopher and Mosaic." 14:15 < jrandom> heh 14:15 < jrandom> yeah, probably no javascript exploits in those 14:16 < jrandom> ok, anyway, thats that, i suppose 14:16 < jrandom> moving on to 5) ??? 14:16 <+Ragnarok> there's still a gopher package in debian 14:16 < jrandom> anyone have anything else (not gopher related)? 14:17 < ant> What will happen to I2P when you need to start working again? 14:18 < jrandom> i'll be on i2p fulltime through the spring, at least. we can discuss things beyond then as that time approaches 14:19 < ant> o k 14:19 < jrandom> in any case, if i got hit by a bus tomorrow, everything is in cvs and all code is free 14:19 <+Ragnarok> I assume you're planning to have a 1.0 before then. What do you think the odds are? 14:19 <+Ragnarok> before spring, not your untimely demise... 14:20 < jrandom> certainty. 14:20 < ant> ahaha.. yes, what are the odds of 1.0 before tomorrow when you get hit by that bus? 14:20 < jrandom> (assuming no buses ;) 14:20 < ant> I just had a very sad thought. 14:20 < ant> Depressing really, but... If you were to get hit by a bus, no one here would know of it. 14:20 < ant> On filtering: What if we created a better proxy, such that all the applications on the computer's traffic could go through it, then we would not need to filter Javascript et alt because they can't find out who we are anyway. 14:21 < ant> You would just die, and we wouldn't know what happened :( 14:21 < ant> God why did he have to die?!?!? why?!?! 14:22 < ant> Can you put a clause in your will to email the mailing list if you die? 14:22 < jrandom> cat-a-puss: javascript can send the contennts of your bookmarks, your IP address, and all sorts of things to a remote site 14:22 < jrandom> dm: people who know me irl know i'm involved in i2p. enough of this morbid shit 14:23 < ant> ah cool. 14:24 < ant> jrandom: yeah, but that sort of thing requres an exploit right, not just say forwarding them to some page that uses a different protocall that is not proxied. We probably be reasonable safe from those with a scanner on incomming content and automatic updates. 14:25 < jrandom> cat-a-puss: erm, perhaps i misunderstood - are you suggesting that it may be safe to have javascript enabled in the browser, as long as the connections that that javascript code makes are proxied also? 14:26 < ant> jrandom: yeah, as long as there is no buffer overflows etc. 14:26 < jrandom> if so, thats still vulnerable to plain old javascript that reads the javascrip environment and sends it "anonymously" to http://cia.i2p/data. 14:27 < jrandom> the data available to javascript includes your IP address, as well as your bookmarks and all sorts of other things 14:27 < jrandom> so even though the connection to cia.i2p was anonymous, the content exposes you 14:31 < jrandom> ok, anyone else have something to bring up for the meeting? 14:31 <@duck> yes: 14:31 <@duck> what does the new 'active peers' counter mean 14:31 < jrandom> ah 14:31 < jrandom> yeah, that changed 14:32 < jrandom> in 0.4.2.1, the new Active: x/y will have x=# of peers you've sent or received a message from successfully in the last minute, y=# peers seen in the last hour or so 14:32 < jrandom> this is part of the code to deal with some peers giving out bad info in the IP autodetection phase 14:33 * duck will try to remember it 14:33 < jrandom> so it'll vary much more than before 14:33 < jrandom> heh so dont worry when the value is lower than you're used to ;) 14:34 < jrandom> ok, if thats it, then y'all should check back onto the mailing list and website over the next day for the 0.4.2.1 release 14:34 < jrandom> it'll be backwards compatible, blah blah blah 14:34 < jrandom> in any case 14:34 * jrandom winds up 14:35 * jrandom *baf*s the meeting closed