Jump to content

Google Wave


ydoaPs

Recommended Posts

Google's preview video makes what they are trying to do look very cool. However, since it is only in the beta stage and I only have two contacts I haven't been able to fully use it. Once it is fully released it looks like it might be a cool thing to have.

 

PS: If anyone wants an invite I have two or three left, just PM me. Also add me djbruce11@googlewave.com

Edited by DJBruce
Added Post Script
Link to comment
Share on other sites

  • 5 weeks later...

I'm not that impressed with Google Wave. Despite important technologies like one-way hashing, secure signing, and end-to-end encryption, Google chose to ignore all that and create nothing more than a pretty user interface to a shaky, archaic underlying implementation. But thanks for offering!

Link to comment
Share on other sites

Well, it's hard to do end-to-end encryption on a system where two hundred different people can be sharing the same document. There's no system outside of shared keys that I can think of that would handle end-to-end encryption in that sort of use case.

 

Public-key encryption works great when you're corresponding with one person but doesn't work at all when you're corresponding to many at once. However, you could probably make a Wave extension thing (a "robot") that facilitates public-key encryption if you're corresponding with one person.

 

You could also not do end-to-end encryption but instead have the server have a public key and have it know the public keys for all its clients, so it could decrypt incoming messages and re-encrypt them with the keys of everyone who should receive the message. But then you're just reinventing TLS with more complications.

 

I do agree, however, that the SSL certificate hierarchy is quite annoying. If I were able to reinvent SSL nowadays to cover modern security threats, I think I'd do it much differently. But alas, we're stuck with phishing because proving users do not fully understand the complexities of certificates and what they mean...

Link to comment
Share on other sites

TLS is point-to-point though, not end-to-end

 

Are you trolling? It can be either, depending on how it's deployed. In the most common cases, TLS is end-to-end. And what are you advocating as an end-to-end alternative? OTR?

 

and it only uses the SSL certificate hierarchy, which is quite archaic IMO.

 

Uh huh, PKI is "archaic". Uhh, what alternative are you proposing exactly?

 

PKI works, works well, and it's ubiquitous. Furthermore, what standard has the scope of PKI and even has technical advantages over it? What are those technical advantages? And why should we care when PKI works as well as it does?

 

TCP is also "archaic", and unlike PKI there are actually better alternatives, like SCTP. Unix and C are likewise "archaic".

 

Learn to worse is better.

 

XMPP does have some promise

 

XMPP is truly amazing, and is the only popular messaging system with pubsub and presence (RabbitMQ does have some bolt-on solutions for adding presence to AMQP but they aren't standardized like they are with XMPP).

 

but only if it employs the technologies that actually work. Otherwise, it's just an empty envelope.

 

What are these technologies you keep alluding to?

 

As someone who works with XMPP and PKI on a daily basis I find your naivety infuriating. I really hope this is just a troll.

Link to comment
Share on other sites

In the most common cases, TLS is end-to-end.
It is most certainly not, in the most common cases. Take the common case of two people communicating via two different jabber servers. Instead of encrypting your message for your recepient, you encrypt the message for your jabber server. It decrypts the message then, if you're lucky, and 90% of the time you're not, it re-encrypts the message, not for the intended recepient, but for the second jabber server. The second jabber server does encrypt it to the recepient, after decrypting it, and delivers it quite neatly. When each step in a series of delivery steps de-crypts then re-encrypts what they're delivering, that's called point-to-point encryption. End-to-end encryption, there is theoretical support for it in jabber, but mostly people just use... uh OTR. I doubt that would work well for Google Wave though.

 

The thing is, I could PGP encrypt and armor my message, send it to a friend, and it'd be TLS encrypted through all those XMPP Wave servers, but I wouldn't care about that, because even if I sent it plaintext in email, it would still be PGP encrypted armored data. So PGP comes closer to being a solution to the problem of message security in transport, while Google Wave just becomes a slight improvement on email, that encrypts and decrypts things several times for no apparant purpose at all.

 

Uh huh, PKI is "archaic". Uhh, what alternative are you proposing exactly?
Well I'd propose some kind of trust network, or some sort of decentralized credits system, where people could establish trust relationships with each other, and thereby avoid many of the risks that come from impostors or ne'er do wells. PKI is just putting a lock on the henhouse and giving the key to the wolf. Because...

 

PKI works, works well, and it's ubiquitous.
PKI works, and works well, only if the certificate authority is trustworthy. The longer said authority is trustworthy, and the more ubiquitous this ultimate trust hierarchy becomes, the more damage will be done when that trust is broken. Compare that with a trust network, where as time passes, and ubiquitousness increases, the risk of total single point system collapse does not go up. So the fact PKI is ubiquitous is a weak point, because that makes certificate authorities a more attractive target for corruption, manipulation, and dirty dealings. And the fact that it works, and works well, belies the fact that it works well... for now. Say, how's that Federal Reserve PKI been doing lately?

 

TCP is also "archaic", and unlike PKI there are actually better alternatives, like SCTP. Unix and C are likewise "archaic".
Unlike PKI, I don't wish fondly that TCP were relegated to a previous era. I'm not a big fan of C anyway.

 

XMPP is truly amazing, and is the only popular messaging system with pubsub and presence
Uh, every popular messaging system has presence. As for pubsub, I think it's a lot more complex a problem deciding who can publish what and who can subscribe to what, than the actual mechanism of publishing and subscribing. The decision of what goes where and who gets what is the big problem, so the fact that XMPP has XML stanzas you can use to describe such a hypothetical, unimplemented publish/subscribe exchange doesn't seem like a big advantage to me. But I don't work with XMPP on a daily basis, so it's quite possible that I'm missing something.

 

I agree XMPP is pretty neat. It goes one step beyond HTTP allowing for a bidirectional exchange of streams of XML stanzas, instead of just a simple request/response, or pipeline that HTTP supports. It just doesn't solve the problem of how to make sure you're talking with people you can trust, and it doesn't solve the problem of making sure people you don't trust can't mess with the information you give out. I don't want to have to trust google.com in order to discuss something privately with my friend, or circle of friends. I only want to trust them.

 

The requirement that I trust google.com, and that I trust Thawte Consulting Inc. to tell me who gets to be google.com, and that I trust the USA government to keep both Thawte and Google from messing with me or my friends, those requirements make Google Wave seem less amazing to me than I would otherwise think. Sure I could make my own Wave server (maybe) but you know 99% of the people on it would be using Google, so I'd be SOL to avoid trusting them, or trusting some other giant faceless authority. How am I supposed to meet Google for coffee at a roadside cafe? Yeah...

Link to comment
Share on other sites

It is most certainly not, in the most common cases. Take the common case of two people communicating via two different jabber servers.

 

That is certainly not the most common use case of SSL. The most common use case is simple client/server communication. In that case, SSL is most certainly end-to-end.

 

If you want end-to-end encryption for an IM system, use OTR.

 

Uh, every popular messaging system has presence.

 

Can you name a non-proprietary, non-XMPP messaging system with presence? I can only name one: RabbitMQ.

 

The majority of messaging software out there does not support presence. Just to name a few such systems: JMS (e.g. ActiveMQ), JBoss HornetQ, ZeroMQ, Starling, Kestrel, Redis, MemcacheQ

 

There's plenty of messaging software out there that's not intended for use in an IM system. XMPP, on the other hand, has many uses beyond just IM systems, such as Vertebra.

 

The decision of what goes where and who gets what is the big problem, so the fact that XMPP has XML stanzas you can use to describe such a hypothetical, unimplemented publish/subscribe exchange doesn't seem like a big advantage to me.

 

Hypothetical? Unimplemented? I'm using pub/sub today with XMPP on ejabberd. The XMPP server is what needs to decide what goes where. The XMPP protocol provides the declarations needed to do it.

 

It just doesn't solve the problem of how to make sure you're talking with people you can trust

 

That's a separate problem, and one rather elegantly solved by OTR.

 

it doesn't solve the problem of making sure people you don't trust can't mess with the information you give out. I don't want to have to trust google.com in order to discuss something privately with my friend, or circle of friends. I only want to trust them.

 

Again, this is also solved by OTR

 

The requirement that I trust google.com, and that I trust Thawte Consulting Inc. to tell me who gets to be google.com, and that I trust the USA government to keep both Thawte and Google from messing with me or my friends, those requirements make Google Wave seem less amazing to me than I would otherwise think.

 

Well, secure, decentralized, and human meaningful: pick two. PKI is secure and human meaningful.

Link to comment
Share on other sites

  • 2 weeks later...
Can you name a non-proprietary, non-XMPP messaging system with presence?
Well IRC for one. But why would anything non-proprietary need to be non-XMPP? There's a strong impetus for open protocols to standardize, and I sure haven't seen any better ideas than XMPP for throwing stuff around. I thought you meant the proprietary ones though, of which there is an embarassment of presence notification.

 

If you want end-to-end encryption for an IM system, use OTR.
When did I say I was talking about an "instant" messaging system? Google Wave is a delayed, high latency messaging system, like email. OTR doesn't work on that, as it requires low latency interaction to set up a session.

 

What does solve the problem is this little thing called PGP. It solves the problem poorly though, not signing things like the "Subject" or the "external references". Google could have fixed the issues of PGP making a revolutonary content distribution network, but instead they just... turned email into XML, not adding on any security or authenticity. Sure I could use PGP over Google Wave, but I could also use PGP over email and it would work just as well, so why not just use email? Wave doesn't add anything to that.

Link to comment
Share on other sites

Well IRC for one.

 

IRC doesn't have a real presence system, at least not in the same sense as XMPP. The server will not notify you when users connect to the service, only when they become a subscriber of a particular channel.

 

But why would anything non-proprietary need to be non-XMPP?

 

Because you claimed "Uh, every popular messaging system has presence." which is patently untrue.

 

When did I say I was talking about an "instant" messaging system? Google Wave is a delayed, high latency messaging system, like email.

 

No it's not. Have you even used Wave? Wave shows you everything in realtime, down to the keystrokes other users are typing. In that regard it's even more realtime than IM.

Link to comment
Share on other sites

IRC doesn't have a real presence system, at least not in the same sense as XMPP. The server will not notify you when users connect to the service, only when they become a subscriber of a particular channel.

 

Well, the functionality exists, but it is not used. IRC Operators can opt to receive connection notices to be informed when users connect and disconnect, but I don't know of any client software that takes advantage of that to do "buddy lists" or anything.

Link to comment
Share on other sites

Well, the functionality exists, but it is not used. IRC Operators can opt to receive connection notices to be informed when users connect and disconnect, but I don't know of any client software that takes advantage of that to do "buddy lists" or anything.

 

And even then that's only half the functionality of a real presence system. An additional function of a presence system is the idea of status (e.g. Available, Away, etc). In something with a real presence system like XMPP, changes to your status are published to all of your contacts.

Link to comment
Share on other sites

  • 5 months later...

So Google Wave is now officially open for public sign up, although it is still not considered to be fully functional.

 

I know that a few members here have already had an account for quite some time. What do you guys think about it? Personally I think it is pretty cool, and I think that it definitely has promise. The problem I have is than so few users actually have accounts that it makes using it very limited. If they were to merge all there Gmail accounts into Google Wave accounts I think that it would definitely prove to be very useful.

Edited by DJBruce
Added Link
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.