Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Jabber and the Open Source Community

By julian in Culture
Thu May 18, 2000 at 07:27:23 PM EST
Tags: Software (all tags)
Software

Jabber is an Open Source instant messaging system which I feel is very important for the entire community. I do not say that it is vital for the entire community, but if it is successful, I believe it will help improve the general public's impression of Open Source.


The core idea behind Jabber is to have an instant messaging protocol which is extensible enough to work with many other IM protocols transparently. Two years ago, XML quickly entered Jeremie Miller's mind as an easy way to achieve this. One kuro5hin user asked how this fits into JWZ's ideas for unity of interface, and when looked at this way, Jabber clearly unifies all of the protocols it supports under a single protocol, so to clients, every protocol (ICQ, AIM, Yahoo!, MSN, and even IRC) is exactly the same.

How does Jabber do this? Jabber, like all major internet services (smtp, http, etc.) is not bound to a single server. Anyone can run a server, and all of the servers can talk to one another. A JabberID consists of user@server, just like email. The major insight Jeremie had was that all translation between protocols should be done by the server, instead of other multiple protocol solutions, which rely upon the client to do everything. This way, a client just has to support Jabber and the ability to register with other protocols.

Jabber supports other protocols through programs called transports. These transports convert the foreign protocol to Jabber's XML protocol, and talk to the main Jabber server process using etherx. Currently there are transports for ICQ, AIM, MSN, Yahoo!, IRC, and a very recent addition is RSS. All of the transports are currently alpha quality, but are maturing quickly and will hopefully be officially released soon.

Probably one of the most asked questions by Open Source users is whether Jabber will be secure. Currently, most clients do use plaintext to communicate with the server. Fortunately, you can run a server on your home computer if you really want, but that doesn't solve the problem. Jabber server supports SSL communication with Jabber clients, and it's just a matter of getting the clients to use it. I'm very interested in giving my client (Gabber: The GNOME Jabber Client) SSL support, and will try to do it as soon as I can. There are also plans to integrate GnuPG. Since Jabber has eMail-like IDs, it will be relatively simple to integrate.

How will Jabber benefit the whole community? Even if the community doesn't care about instant messaging at all, there is no denying that there are many people in the general public which do use it. I believe that AOL will slowly merge AIM and ICQ, creating the single largest instant messaging system in the world. No other instant messaging system can even come close to AOL's current combined userbase. They would then be free to completely close of the protocol and take measures to stop anyone else from creating clients. This would be an utter disaster for open protocols. That is why Jabber is needed now, to allow everyone to talk to one another, and slowly move them over to an open protocol. If it so happens that this protocol runs on Open Source server software, that will be a major gain for the community. I don't think we want everyone using MSN Instant Messenger and Microsoft's servers, even if that protocol is technically open for the most part.

If an Open Source instant messaging system does become popular, I think that the general public will respect the community much more, and realize that the Open Source model really can create systems better than anything currently out there. Yes, there is Apache and BIND and other fundemental pieces of software (including Linux itself) which are Open Source, but instant messaging is something that nearly everyone in the general public can understand. The last statistic I read about AOL said that it had more than half of the Internet users in the United States signed up on it. How many of those users truly understand exactly what Apache and BIND do, and how vital they are to the Internet? Maybe after some explaining, but they'd more readily understand something like instant messaging being open for anyone to write a client for and anyone to use.

In conclusion, I feel that Jabber is not vital for the survival of the Open Source community, but it will greatly aid the cause.

Please feel free to ask further questions about Jabber, and if you have the time, check out The Linux Show. On the 16th of May, Temas, DizzyD, myself, and Doc Searls were on discussing Jabber. Unfortunately, they have up to an hour of music before the actual show in the archive. Further information about Jabber can be found on Jabber.org - the official developer site, JabberCentral - the official end user site, and Jabber.com - the future site of Jabber, Inc., the company which will be supporting many of the core Jabber developers.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o Kuro5hin
o Yahoo
o Jabber
o JWZ's ideas
o The Linux Show
o Jabber.org
o JabberCent ral
o Jabber.com
o Also by julian


Display: Sort:
Jabber and the Open Source Community | 29 comments (29 topical, editorial, 0 hidden)
I use Jabber & Gabber daily. Very ... (none / 0) (#5)
by jhillyerd on Thu May 18, 2000 at 05:06:53 PM EST

jhillyerd voted 1 on this story.

I use Jabber & Gabber daily. Very nice system, I hope once it gets a little more polished that it really takes off.

Julian points out some unique point... (none / 0) (#9)
by eliot on Thu May 18, 2000 at 05:07:42 PM EST

eliot voted 1 on this story.

Julian points out some unique points about how Jabber fits into the open source community. IMHO, definitily something that the k5 community would be interested in.
- Soli Deo Gloria -

>That is why Jabber is needed now, ... (none / 0) (#7)
by ravenskana on Thu May 18, 2000 at 05:15:45 PM EST

ravenskana voted 1 on this story.

>That is why Jabber is needed now, to allow everyone to talk to one another, and slowly move them over to an open protocol. This is the heart of the matter, IM systems need an open protocol.

Good writeup... (none / 0) (#4)
by DJBongHit on Thu May 18, 2000 at 05:28:49 PM EST

DJBongHit voted 1 on this story.

Good writeup

~DJBongHit

--
GNU GPL: Free as in herpes.

I use Jabber already. It is a beaut... (none / 0) (#6)
by dash2 on Thu May 18, 2000 at 05:29:17 PM EST

dash2 voted 1 on this story.

I use Jabber already. It is a beautifully elegant solution and a neat example of how client-server computing can improve on the standalone model. Basically all the hard stuff gets handled en masse on the server. So shall it all be.
------------------------
If I speak with the tongues of men and of angels, but have not love, I am become sounding brass, or a clanging cymbal.

Truly IM is an emerging market, and... (none / 0) (#10)
by temas on Thu May 18, 2000 at 05:31:44 PM EST

temas voted 1 on this story.

Truly IM is an emerging market, and Jabber stands tall and proud as an early leader in the field. Better yet it's open source. Julian does a great job of summing up the tech, and some of the feelings of the Jabber group.

Extremely well-written and presente... (none / 0) (#8)
by Jynax on Thu May 18, 2000 at 05:55:57 PM EST

Jynax voted 1 on this story.

Extremely well-written and presented, with the potential for some interesting discussion, although I'm guessing most people are going to be thinking/saying "That's a good idea." and leave it at that. As for myself, I'm heading over to that there Jabber site to learn some more...

I've used AIM for about 2 years now... (3.50 / 2) (#1)
by rusty on Thu May 18, 2000 at 06:00:57 PM EST

rusty voted 1 on this story.

I've used AIM for about 2 years now, and (most surprising to me) usually for actual business stuff. It's a great tool for those little "need to know right now" things, especially if your workforce is goegraphically distributed. I *do* think instant messaging is important, because so many open source projects involve widely dispersed developers working more or less on their won. Sure, for the larger ones there's always an IRC channel somewhere, but for small projects (like, say Scoop ;-)) it's a PITA to create a whole IRC channel just for that. Instant messaging fills a huge gap, as is clear by the number of users the different services have attracted in just a couple short years.

Jabber has gotten a lot of attention lately, because of it's promise to allow users to simply use one client for all their friends and co-workers on whatever service. I think this is the wide-audience "hook", but look how they manage to sneak open protocols in the back door. :-)

____
Not the real rusty

Much rather be using something open... (none / 0) (#3)
by warpeightbot on Thu May 18, 2000 at 07:05:12 PM EST

warpeightbot voted 1 on this story.

Much rather be using something open source than something owned by Steve Case anyway.... much less old Borgy-Bill.

Why not hook this up to Gnutella, e... (none / 0) (#2)
by xah on Thu May 18, 2000 at 07:13:42 PM EST

xah voted 1 on this story.

Why not hook this up to Gnutella, etc....?

Also, define "open source." Is it like the SCSL or NPL? It won't unify anything unless it's a GNU, BSD, or X style license, IMHO.

Re: Why not hook this up to Gnutella, e... (none / 0) (#11)
by julian on Thu May 18, 2000 at 07:30:56 PM EST

Yes, there has been much talk of hooking it up to Gnutella. You can be pretty sure someone will do it eventually. :)

Most of the major pieces are GPL/LGPL. I believe that fits most people's definition of Open Source. :)
-- Julian (x-virge)
[ Parent ]
Usenet replacement? (none / 0) (#28)
by Anonymous Hero on Sun May 21, 2000 at 07:17:37 PM EST

Ever since the Jabber project started I've been hoping it'd eventually allow message/file sharing along the lines of Usenet but in a much more modern tone. I haven't looked at Gnutella so perhaps this is what it does but Napster I know isn't quite what I hope for. I see the need for XML based listings of messages and file paths (which should be copied to/from the server using some binary protocol.. FTP maybe) and the use of multiple servers so that you can have mirrors of each group built-in but you aren't as reliant on an ISP (or other provider) to give you all the groups you want to read. This way when my friend got online their Jabber server would allow me to share files with them transparently in the way Napster does but the files could also be mirrored in the way Usenet does in some sort of logical partitioning. This essentially makes it so everyone has their own group server but they only have to mirror/share with those they want. ^TDL^

[ Parent ]
Re: Why not hook this up to Gnutella, e... (none / 0) (#16)
by Anonymous Hero on Fri May 19, 2000 at 12:43:41 AM EST

hooking this up to a gnutella-type service (where the servers can allow jabber clients to interface the information on a servant) will most definately happen eventually.

Sending messages via a servant though scares the pants off of me. In order for this to work you would have to send messages through multiple people who would then be getting your conversation. You also would have a tremendous bandwidth hit - imagine everyone on IRC echoing every single conversation (including DOS attacks) to multiple outgoing servers. Ouch.

[ Parent ]
Re: Why not hook this up to Gnutella, e... (none / 0) (#26)
by xah on Fri May 19, 2000 at 05:19:26 PM EST

Thanks for making those interesting points. It clearly would be a disadvantage in speed to transfer packets through middleman servers. But the advantage in security is anonymity.

[ Parent ]
Multiple servers (4.50 / 2) (#12)
by Reed on Thu May 18, 2000 at 10:20:24 PM EST

I think the fact that Jabber is based off a paradigm of multiple servers (user@server) is one of the best things going for it. I really wish it would get more hype than it has, if for no other reason then this. Ding is the only other multi-server instant messanging system I've heard of, and over time, having this style is the only way the system will scale cleanly.

This article mentioned most of the great points about Jabber, and did mention this, but I don't think enough emphasis has been given to the scalability of the Jabber protocol versus most of the others out there.

Re: Not necessarily a panacea... (4.50 / 2) (#14)
by eliot on Fri May 19, 2000 at 12:23:11 AM EST

baylink -

Good points you bring up. Hopefully I can answer your questions here.

BTW, I am for the most part responsible for the Jabber.org site and take full responsibility for the (or the lack of) content. We *are* working very diligiantly on improving it. Your constructive comments would be most appreciated... perhaps you can throw us some ideas on topics that we haven't thought about covering yet. Feel free to email me personally to discuss improvements to the site.

Point by point responses:

1) No, you can have a complete and seperate Jabber server on your own. Exactly like you can have your own email server. You can even have your own server on an internal network - completely functional on its own.

2) Actually, that FAQ item was referring to whatever results the IETF IMPP group came up with. Unfortunatly, they gave up after two years of wrangling with each other. I don't want to go searching for a URL for this, but they have called for submission of protocols for reviewal by June 15. Be assured that we are HARD at work preparing our submission.

As far as RFC 2779 is concerned... I hadn't personally read through it yet, but after you mentioned it, I went and skimmed through it. A couple of things to note:

  • The date.. the only date I can find on there is for February 2000. It seems like this was around before then, but.. as far as that goes, we have been hacking and IMPLEMENTING our protocol for about two years before that date.
  • RFC 2779 is EXTREMELY general. It gives some basic guidelines on how a protocol should work. Actually, just from my skimming, it looks like the Jabber protocol fits with RFC 2779 very well. After I post this, I'll read through it completely and see if I can find any differences. I'll keep you updated.

3a) We don't really care about how many servers there are. The email example comes in again... we really are looking forward to the day when each ISP offers their customers their own Jabber account as a standard service. There's no reason why that couldn't happen. Then of course there are many huge businesses that want huge user base's, and we understand that too. In fact, we're working with a group to establish a distributed server (a cluster basically) to handle 10 million users. (I believe the 1.1 devel series of the server will have this clustering capability..) That's a LOT of users.

3b) Security is a major concern within our group. Unfortunatly we've had a heck of a time implementing anything really good because of possible man-in-the-middle attacks. At any rate, you COULD setup an XDB that encrypts your roster information. But then again, you'd have to think about man-in-the-middle attacks. :( In light of the fact that you could setup your own local server with a secure XDB, man-in-the-middle may not be much of a concern since not many folks would be in the middle.

Anyhoo.. I hope I answered your concerns. If you really are a security freak, we'd love to have someone like you helping us think through these problems!


- Soli Deo Gloria -
[ Parent ]
Re: Not necessarily a panacea... (4.50 / 2) (#18)
by Akuma on Fri May 19, 2000 at 02:56:08 AM EST

Oh, no problem (that was me, I am logged in now). I am also usually a bit blunt, no attacks meant :)

The documentation for the project really does bug me, but I am acting the part of a programmer, not a technical writer on the project currently. Maybe once I finish with my current project I will switch hats and help eliot out (he does a great job, but the amount of documenting the project needs is more than one person can provide, really).

Client to server ratio probably will be small initially, because people are used to non-distributed systems. There is technically no advantage to being located on a machine with 10 million users as there is to being connected to a machine with 200 users.

The initial 'market' for something like the jabber server will be portal sites, and they will of course want as many people as they can get, and to retain them by offering services. So yes, with ISPs not adopting jabber and only having services provided by portals, the number of jabber server 'sites' will be limited - but this is of course a usage limitation, not pertaining to and actual implementation of jabber itself.

the current message system allows for arbitrary expansion - hashes and messages both can be allowed easily. However, the topology of a distributed system like this is client->server->server->client, with the servers having no real limitation on who they connect to. Man in the middle attack vulnerability for this type of system is thus a big issue.

i won't comment too much on traffic analysis - i personally consider it more of a paranoia. You can gain a lot of information from it, but it is not a security attack. Usually people already know someone is talking to someone else - that is the reason they try to break the security in the first place.

traffic analysis is relly hard to eliminate. Random packets that are encrypted so that the contents cannot be discerned from normal packets is one possibility, and if you really wanted to implement this you can easily send a bunch of whitespace to the server in bursts, or a message to yourself so the traffic is two-way. But all-in-all, traffic analysis goes beyond making something secure from third parties, to making something so that third parties don't even know they should be attacking it. it is out of scope for most protocols, even things like secured financial transactions.

The main reason the server maintains the list is because it also authenticates other people to be able to see you. Without the list, these people (who you assumably trust) will not be able to even see if you are online or offline. Because the server uses this as a list of people who are 'authorized' to see your state and a list of people who have authorized you to see their state, it is not easily movable. You would basically need to delete the entire list when you are going offline, and request reauthentication from everyone when you go online. For this reason, it would be hard to use Public key encryption on the rosters, as the server would be unable to use them. Any other arbitrary data not in the user roster can be encrypted just as messages can, the encryption and decryption is done client side.

The connection between a client and a server can be sent through SSL for some measures of security, so basically this becomes an issue of whether you trust the service provider to be able to keep your information safe, and to not exploit it - the same things you have to trust about all online retailers, for instance. The real difficulties come from the distributed nature - I simply cannot trust other servers to be safe. So encrypted messages can be used in this case when data simply must be protected between users.

Again, i usually am rather blunt with replies - but i understand that it is really difficult to find out the implementation details of the jabber system due to less-than-perfect documentation. The security that we have in place is also most definately not perfect - if for no other reason than because it has not gotten proper peer review. I hope we can get adequate documentation up, I would really like more constructive criticism and proper review of the security in jabber.




[ Parent ]
Re: Not necessarily a panacea... (4.00 / 2) (#15)
by Anonymous Hero on Fri May 19, 2000 at 12:38:57 AM EST

1) The services are similar to those provided by a machine running smtp and imap. How do you consider this to be a proxy?

The only possible 'proxy' functionality comes if you ignore Jabber altogether and consider the entire server and protocol to just be a means to interfacing with the gateways of other interfaces (a protocol for gatewaying to ICQ, to AIM, etc).

But this is not the point of Jabber at all - it is meant ot be a replacement for these - but the leverage that these services have in terms of sheer user usage requires to an extent that interoperability be provided, so that you can actually communicate with people while jabber is still in its early stages of taking over the world.

The fact that Jabber so cleanly integrates with these other services (requiring NO knowledge by the client software that the users even are on a service besides jabber) is a testament to the extensibility of the design.

2) Some very nice members (in particular e-t) of the jabber developer community are busy working on writing RFCs and Internet Drafts of the current XML Stream protocol/technology that we use, and the overall Jabber protocol.

The only way that I have found that Jabber has been 'wishy-washy' to the requirements specified by the IMPP group is that we do not want to become the IMPP list(IMO rightly so). If you have been subscribed to the IMPP list or even browsed through the archive, you will see that the working group totally lacks direction and leadership. The project has totally stagnated, and the list has a practically zero signal to noise ratio. The IMPP working group has not even decided what sort of substrate to build the protocol on, whether communication should be exclusively peer to peer, exclusively client-server, etc.

Jabber is a project meant to provide something that 'works' over something that is an IMPP standard. If Jabber becomes the IMPP standard, excellent! I will be so proud. If it doesn't, then nothing lost - we are not then outlawed from using our protocol instead of the IETF-endorsed standard.

3) how many email servers are there out there? tens of thousands? how about web servers (after you take into account that most sites are on virtual hosts, and count clusters as 'one server'?) The server is completely free in both senses of the word, the protocol is open. There is nothing preventing someone from setting up as many servers as they want. If more servers are needed, they can be installed and run. I have set up a redhat install and a jabber server in <45 minutes, and that was with compiling jabber instead of using a precompiled package.

Is there an actual 'barrier to entry' that you see with jabber that doesn't exist with email? With jabber it appears to actaully be easier to get accounts - servers can be set to let clients simply register if they want accounts.

If you don't trust an administrator, set up your own server for you, your family and friends. At least with jabber (unlike AIM or ICQ), you can do something about paranoia :)

[ Parent ]
Re: Where the security needs to be. (5.00 / 1) (#21)
by eliot on Fri May 19, 2000 at 01:31:39 PM EST

I'm not sure how this part of our conversation got moved down to its own post, but I'd like to be able to answer these concerns as well.

First, we are doing are HARDEST to make Jabber secure. We desperatly want Jabber to be secure. We have a full-time security expert (temas by name) who has been involved in the open source community and various security projects for years. Please try to understand that we are not by CHOICE making Jabber insecure. The model that instant messaging presents is very difficult to secure. The protocol is, however, very easy to extend... so if you have some concrete ideas on how a distributed instant messaging platform could be secure, please fill us in.

It is somewhat difficult to respond directly to your post because of the way it was structured, but let me present a way that you could setup a secure roster, message and presence system with Jabber:

  • Version 1.0 of the server uses OpenSSL to create a secure stream from the client to the server. Unfortunatly, because of basic security problems, we have so far been unable to extend this to server-to-server. Note that this is not a difficulty with Jabber itself, but with simple security problems that any system would encounter. That's why you don't see a complete SSL email solution.
  • Like I noted before, you could easily hack at XDB (the default storage mechanism for storing user information and rosters) to keep your information on the server secure from prying eyes. Since you would be implementing quite a secure setup, you probably would want to setup your very own server with these modifications. That way your roster information would be sitting on the server securely and it would not be transmitted anywhere besides between your client (which is connected via that SSL stream). If you don't want to have your own server, then you obviously will require SOME level of trust with the adminstration. But again, this isn't all that much different than email.... if an admin wanted to read your unencrypted mail (and I really don't know many folks that regularly use any type of encryption.. even in the business world), it's really not that difficult.
  • Again, like I said before, a client could implement - RIGHT NOW - a method of using GnuPG to send fully encrypted messages. Since Jabber uses the standard email format of addresses (user@host), no modification to GnuPG would be necessary. Simply a client issue. Since we've designed the protocol from the ground up to handle expansion, no client would be broken by this and the server would just pass it on through without understanding a bit of it.

I believe the above points would provide an adequatly secure system for what you seem to want and it could probably be completely implemented within a couple of weeks (since most of it is already there.. OpenSSL and protocol expansion, it just takes some regular C hacking).


- Soli Deo Gloria -
[ Parent ]
Rosters & RFC 2779 (none / 0) (#22)
by eliot on Fri May 19, 2000 at 01:43:09 PM EST

By the way, I meant to mention this in the last post... As promised, I read through RFC 2779 last night after my post... there is some major points in there that relate to this very topic.

RFC 2779 specifically requires several things regarding presence notification and subscriptions that mandate having the roster on the server. It would be *very* difficult to implement using client-only rosters. They don't talk much about security of the roster on the server though....

Secondly, RFC 2779 mandates that the whole system be distributed... like Jabber is. So even if you do a completly conforming protocol as per RFC 2779 and 2778, you are going to have the same problems we have.

I'm posting my other comments about the Jabber's conformance to RFC 2779 and its companion, RFC 2778 in a few minutes in response to the first thread started by baylink and I...


- Soli Deo Gloria -
[ Parent ]
Re: Where the security needs to be. (4.00 / 1) (#23)
by DizzyD on Fri May 19, 2000 at 02:05:00 PM EST

Somehow, it seems like everybody is missing the point, IMHO. Yes, Jabber is designed from the ground up to store roster (a.k.a contact list) server side. Yes, it is offloading the work the client does to the server side. Yes, your concerns about server security are valid, given your specifications for security.

The point, however, is that _one_ of Jabber's primary design-goals (even after security-related contemplations) is to act as a "service proxy". The idea is to simplify the clients and provide a homogenous interface to a myriad of systems -- in a way that is transparent to the clients. Hence, the server bears a greater load and requires more trust on the part of the client.

The conflict between your vision of a "secure" (I quote, since security is a relative thing) system and the Jabber project is aggravated by fact that flexibility and security are opposing forces. Typically, the more flexible a system is, the less secure it is. Based on your previous posts, I am certain you understand that, so I'll digress. :)

My reason for posting is simple -- don't discount the system before you try it. :) Am I biased? Of course! I just wanted to be sure to clarify the fact that Jabber (at this point in time) is all about unifying the IM world, in a open, flexible manner. It is _more_ secure than the alternatives...and someday..who knows? :)

[ Parent ]

Userbase IS the key... (none / 0) (#20)
by Alhazred on Fri May 19, 2000 at 10:48:18 AM EST

The only real measure of success with something like this IS success. Given that systems like ICQ, AIM, and MSM are already out there with millions of users each means that a completely new system, no matter how technically superior, is going to have a tough row to hoe. Interoperability with existing systems will be helpfull, but in truth ICQ has already shown itself to be remarkably robust and shows no signs of collapsing user the assault of millions of users. Is there really a compelling reason for an ICQ user such as myself to migrate to Jabber? At this point I don't really see a compelling argument from the user perspective, and that is the ONLY one that matters in the long run.
That is not dead which may eternal lie And with strange aeons death itself may die.
Re: Userbase IS the key... (4.50 / 2) (#24)
by eliot on Fri May 19, 2000 at 02:23:19 PM EST

Valid points... but the cool thing about Jabber is that I can use it and be most happy with communicating with my friends who refuse to switch from their proprietary protocols and we can all be happy little campers.

FYI, ICQ is *not* robust and is struggling to handle the current load. Come on... look me straight in the network connection and tell me that ICQ is reliable. AOL was able to stick literally *thousands* of servers to help support it... but my word! that is a pathetic solution to scaling. We were talking about this type of thing at our last Jabber meeting and one of the guys called it "brute force scaling."

Anyway, I don't really care if my ICQ friends switch. I've got a client that I love (<a href="http://gabber.sourceforge.net">Gabber), that works fantastically well, and some (soon-to-be) security features like GnuPG for my friends who do switch and we're all happy! That is the power of Jabber. I've got a client that suits my needs and I don't have to require all my friends to switch before it is useful to me.


- Soli Deo Gloria -
[ Parent ]
AOL trying to take over... (none / 0) (#25)
by dash2 on Fri May 19, 2000 at 03:33:22 PM EST

Here is a story from PCWorld about AOL not cooperating on developing open standards.
------------------------
If I speak with the tongues of men and of angels, but have not love, I am become sounding brass, or a clanging cymbal.
Security Model and encryption (none / 0) (#29)
by Anonymous Hero on Mon May 22, 2000 at 12:21:08 PM EST

My suggestion for the security model would be to model what hushmail.com does in order to provide 1024 bit security for their email service. The information is encrypted while on the server. The client decrypts. This way no one but the server who wrote the message and the receiver whom decrypts the message would ever know what the message said.

Jabber and the Open Source Community | 29 comments (29 topical, 0 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!