Re: Proposing gobby?

[Eric Larson <elarson novell com>]

On Wed, 2005-11-16 at 14:53 +0000, Gustavo Carneiro wrote:
> Qua, 2005-11-16 �09:24 -0500, Eric Larson escreveu:
> > On Wed, 2005-11-16 at 12:17 +0000, jonobacon gmail com wrote:
> > > On 11/16/05, Ross Burton <ross burtonini com> wrote:
> > > > On Wed, 2005-11-16 at 11:54 +0000, Gustavo J. A. M. Carneiro wrote:
> > > > >   I subscribe the good opinion about Gobby, generally, but the security
> > > > > of its network protocol leaves a lot to be desired.
> > > >
> > > > Agreed: whilst I'd like to use Gobby, the fact that the data is sent in
> > > > plain-text isn't good.  Some way of authenticating the servers/peers are
> > > > who they say they are (think ssh host key fingerprints), and encrypted
> > > > transport streams would be required before I'd use it for work.
> > > 
> > > It seems to me that a collaborative editing feature in GNOME would be
> > > a really killer feature, but it should really happen in the
> > > applications that we all know and love. I would much prefer to use a
> > > GEdit, Abiword and ultimately OOo plugin to do this. What Gobby could
> > > offer is a library to handle this and a standard UI for establishing
> > > and maintaining connections. This would sacrifice Gobby for inclusion,
> > > but open the possibility for a general GNOME feature - Live
> > > Collaboration.
> > 
> > It seems that the Gobby developers should provide a better idea
> > regarding the intended use cases for Gobby. The argument that one would
> > rather edit in something like GEdit may not really address the purpose
> > of Gobby. Following the same logic, this potentially makes the lack of
> > security features more understandable as well. I say this because one
> > tool that addresses a specific collaboration need is better than forcing
> > users to understand applications like Abiword, X-Chat and GEdit out of
> > their original scope. 
> > 
> > To put this another way, why sacrifice the usability of something like
> > Abiword or GEdit to support a corner case when Gobby can handle it more
> > gracefully. This is the same for security concerns. Why force Gobby to
> > deal with security when it may never really be needed. When it was used
> > at GNOME summit, I don't believe that anyone would have any problems if
> > someone was listening in on collaboration. This may be the primary use
> > case (collaboration under a locally controlled network) they may merely
> > need to be emphasized. 
> 
>   Yes, I totally agree the security is sufficient for a local controlled
> network.  OTOH, the software doesn't warn about potential security
> vulnerability when running over a WAN.
> 
>   I can picture this already (IM conversation):
> 
> <joe> hey, we need to finish that lab report from the last class..
> <andy> it's raining a lot... I'd rather stay at home... :|
> <joe> hey, I have an idea, let's use gobby and work this online
> <andy> great idea!.. here, connect to 194.117.99.11 port 12345
> <andy> pass phrase 'secret'
> <joe> ok, i'm in! let's do this, then!
> [... half an hour later ...]
> <andy> WTF are you doing, you're deleting all our work!
> <joe> I'm not doing anything, I swear!
> <andy> sh*t, what's all this garbage? I've been hacked! :-/
> <joe> crappy GNOME software, doesn't even have decent security :|
> 
>   You get the picture... :)
> 
>   This happens because the home user doesn't have any feeling for the
> limitations of the security of the protocol.  Sure, the security can be
> adequate in some cases, but the end user doesn't know which cases, and
> just uses it even when not secure.

I totally agree and I feel that the Gobby developers need to address
this. My original comment hopefully will push the developers to analyze
Gobby to see if a warning needs to be issued to users or if they need to
fix the security (which seems the most logical IMHO). I think your use
case is a great example as well.

Eric