Interestingly, when I logged into email I found that a similar message had arrived on the google-talk-open list...
****** -------- Original Message -------- From: Paul Johnson <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Date: Thu, 12 Apr 2007 02:22:01 -0700 Subject: Re: Can my company read my Google Chat messages? On Thursday 12 April 2007, r0tt3n wrote:
On Apr 11, 10:09 pm, "Joope" <[EMAIL PROTECTED]> wrote: > I'm needing to know will google chat leave a trail or messages that > the IT's at my company can read? We have an instant messenger on our > computers at work and they can read that. So I'm wondering if this is > different then the instant messenger at my job. Thanks for all your > help! The short answer is yes. The long answer is for now, definitely, but they might not be able to for long. If you manage to locate the google talk suggestions and feedback page, it asks you to choose 5 out of about 15 frequent feature requests. One of them is instant message and voice call encryption. Without encryption, the messages could be read by anyone with access to the traffic, as it the case now with your company's local network.
Doesn't Google already support SSL on client-to-server and server-to-server connections? If so, just make sure you're using an SSL-enabled client and it's encrypted client-to-server. If the person you're contacting is on another Jabber server and their server is SSL aware, the server-to-server connection should be encrypted as well.
Then there's Psi and others, which works with Google Talk and uses industry standard OpenPGP for total end-to-end encryption.
-- Paul Johnson Email and IM (XMPP & Google Talk): [EMAIL PROTECTED] ******Even members of the IETF security mafia have expressed to me the sentiment that "PGP is good enough for me, that's why I use Psi".
What's going on here? In part, I think there is a certain elitism. Security isn't easy, and if you're not willing to put *some* level of thought into what you're doing, then you don't deserve to enjoy the benefits of end-to-end encryption. With something like OTR, you need to check the fingerprints of your chat partners (just as, for example, you do in using ssh -- though how many geeks even validate fingerprints the first time they connect to a new host via ssh?). With ESessions you will need to check either fingerprints or use Short Authentication Strings (SAS). With XTLS you'd have to do something similar as well.
But all of this is probably a bit much to expect from Aunt Tillie or even the kind of Joe User (or in this case "Joope User") who posted to the google-talk-open list last night.
I admit that I vacillate between democracy and elitism when it comes to security.
What I see is that most people mouth the words "I care about privacy and security" but they don't do anything about it, so they are not voting for privacy and security with their time or money.
Those of us who have studied security know that Aunt Tillie and Joe User are horribly misguided to believe that their communications are secure if all the c2s and s2s channels are encrypted. What about Ivan (the ISP) and Justin (the Justice System)?
So yes we need end-to-end encryption, but I pose the heretical question: "Perhaps we already have the technologies that will solve the e2e problem *for those who care*?" And by that I mean OpenPGP or S/MIME.
Yes, OpenPGP and S/MIME are too hard to grok and deploy for Joe User. It's not easy to generate and manage OpenPGP keys. You have to jump through hoops to get an X.509 certificate. But to me that means we need better tools, not necessarily different technologies. Do these technologies solve enough of the problem for most of the people who care about security? Or can we do better?
I would love for us to get ESessions implemented and deployed (or XTLS or some kind of more sophisticated technology than OpenPGP or S/MIME), and I will continue to work on that. But I think it's valuable for us to question our assumptions along the way.
Now, I'll have a chat with Ian about a simplified profile of ESessions so we can bootstrap development. :)
Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml
file:///tmp/nsmail.tmp
Description: PGP signature
smime.p7s
Description: S/MIME Cryptographic Signature
