I've been holding my tongue on this, because Michael's been stating the very logic that I have stated in the past; however, my views have been changing somewhat, and I think there are ways to approach this that can at least partially satisfy all parties.
The first thing I want to be clear about is that IRC is, fundamentally, not private. Even if you encrypt server<->server links and have every client connect with SSL, you still have the potential for privacy violations. For instance, if the server itself is compromised—most servers are hosted, after all, and physical access is game-over in terms of security—then all message traffic flowing through it could be intercepted in the clear. The only reliable means of making an IRC conversation private is end-to-end encryption, i.e., the client encrypts the message before sending it to the server, and only the target(s) of the message are able to decrypt that message; the server wouldn't have the key in that case. You could still be vulnerable to some metadata collection, but I doubt there's a really good way to prevent that anyway; the network has to know where to route a message, after all. The second thing is, despite the Scandinavian origin of *ircd*, the people who currently work on *ircu* all live in the US and are subject to the rules of America, for better or worse (and right now, I would venture to guess that the majority of Americans that actually pay attention and know what's going on would come down on the "worse" side of that equation). That said, it is certainly possible to add code to ircu that would encrypt the links and still legally make it available for download from the US; IANAL, but I believe the current rules allow for open-source software to be posted publicly with merely a notice that individuals from those proscribed countries aren't allowed to download it, and perhaps some sort of notification to a government agency that it exists. Such rules are, however, subject to change and, alas, capricious interpretation :/ I don't think we have to implement the encryption in ircu directly, however: if instead we provide a means for ircu to load an external module of some sort that wraps connections—think in terms of link compression, for instance—I believe we won't run afoul of any US export restrictions…or encryption rules in other countries that restrict the use of encryption by their citizens, for that matter. That also, incidentally, solves the issue of CPU loads on a large network: we simply don't recommend the use of those extensions on large networks. And, finally, any encryption-based module could be hosted from a completely different country. The caveat with this approach, however, is that it will be a lot of work to refactor ircu to the point where such extensions could be configured and loaded. The work I did in rewriting the core network loop helps, but there's still a *lot* that would need to be done to allow such an external module…and neither Michael nor I really have a lot of time to devote to that kind of development, and there aren't really very many other active developers right now. (In fact, I haven't been very active in ircu myself for some time, now.) I have two suggestions, then. The first is, if you or your group is willing to devote time to the necessary development, we would likely be willing to review your work; the caveat here is that both Michael and I have very high coding standards, so it could take a while before we're happy with what you produce. The second suggestion—which you may wish to produce even if you also decide to work on the first suggestion—is to implement an SSL proxy; you would likely need to combine that with an appropriate iauth in order to inject the correct originating connection information, but that should be fairly straightforward. It is awkward to do things that way, certainly, but you should be able to develop such a proxy quickly, then use that while working on the more comprehensive solution. I will say that, from our perspective, probably the best argument for accepting the module loading code I suggest is the possibility that we could apply compression to server<->server links rather cheaply, even though it seems likely we won't try to use the SSL link on client->server links. -- Kevin L. Mitchell <klmi...@mit.edu>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Coder-com mailing list Coder-com@undernet.org http://undernet.sbg.org/mailman/listinfo/coder-com
