[gopher] Capability files are dangerous

[Wolfgang Faust]

On Mon, May 14, 2012 at 4:48 AM, Denis Bernard <denis.bernard at laposte.net>wrote:

> Capability files are dangerous!
>
>  Overbite Project provides a module for the Internet browser FireFox
> to ease Gopher netsurfing. This project is going to promote a
> capability file (caps.txt) to be installed inside a Gopher server.
> This practice is dangerous for users of the Gopher space and the
> administrators of Gopher servers.
>
>  Up to day, any Gopher client was able to deal with any Gopher server
> (more or less). The spirit of Gopher is to keep it as simple as
> possible and, mainly, for retrieving files anonymously.

Neither servers nor clients need to implement this; if one does and the
other doesn't this is handled gracefully. Caps.txt merely provides a few
enhancements to the user experience. In no way does it reduce the anonymity
of the user.


> Up to day, it
> was impossible, for an administrator of a Gopher server, to know which
> flavor of a Gopher client was browsing its site. The only information
> available was from the IP address. Now, with a capability file like
> “caps.txt”, there is a fingerprint. Without to be paranoiac, everybody
> heard of web sites serving contents (or refusing to serve!) according
> the software or the system that the client have. That will happen for
> the Gopher space too!
>
The gopher client provides no information to the server through caps.txt;
caps.txt is purely for advertising the server's capabilities.

>
>  A capability file creates an indirect kind of permanent connexion by
> a kind of proxy. That is the opposite practice of the gopher space
> until to day. We have seen, by the past, how much loss of privacy and
> security did cookies in the World Wide Web. Does it must be the same
> for the Gopher space?
>
How does retrieving information about the server create a connexion by
proxy? Again, the client is still completely anonymous (aside from the IP
address, which would be known anyway).

>
>  Worse, this will encourage the propagation of scripting languages
> that aims to bring more intelligence to the browser or more
> intelligence to the server. We already know, as seen in the Web world,
> what this perversion produced: chaos.
>
Servers can have as much intelligence as they want. We already have gopher
servers which allow you to program new modules in Python or add CGI scripts.
Caps.txt does not require, suggest, or otherwise imply the ability of the
client to understand any sort of scripting language. Gopher clients could
already support JavaScript by running any JS in an HTML page they are
served.

>
>  To day, there is only one modern browser available for Gopher
> netsurfing and only one capability file. Next month, you will have
> an enthusiast developer branding a new Gopher browser... and a new
> flavor of capability file. Next year, you will have 10 brand new
> Gopher servers... and 10 flavors of capability files.
>
Different servers and capability files are perfectly acceptable. Diversity
is a good thing! Do not confuse diversity with incompatibility. If all of
the clients and servers follow the standard (which shouldn't be too hard),
then everything will work together and it doesn't matter how many clients,
servers, or caps.txt files are out there.

>
>  Without to be paranoiac, everybody heard of malicious scripts
> infecting Web browsers or malicious code making Web servers slaves.
> Everybody heard of government in some countries that take care of the
> mental health of their citizens. Forging an inoffensive Web client, a
> government can check the illness of a particular Gopher user.
>
How does a caps.txt file facilitate checking the illness of a Gopher user?
Here you are being a *misinformed* paranoiac. Stating that caps.txt will
allow a government to check the illness of a Gopher user is like stating
that the world will end in 2012 because the Aztecs saw a vision from Jesus
Christ.

 That is, in short, for clients. Now, for you administrator:
>
>  A capability file offers interesting informations about the Gopher
> server software version that you run and its hardware. Knowing the
> version of the capability file, the version of the software of the
> server, it is easy to deduce how much the administrator is lazy or
> incompetent.
>
Most of the servers out there have slightly different characteristics. It's
possible to determine what server (and to some extent, version) is running
on a particular site anyway. If the administrator doesn't want this
information to be public, they can simply remove it from the caps.txt file.


>   You can find, in a capability file, private informations provided
> by its unadvised administrator like the geographical position of its
> server. So, if somebody claims that you are serving a file under a
> copyright that you don't hold, knowing the city where the server runs,
> he can easily find the door of the competent justice court. If you do
> not provide that kind of information, jurists will have to ask to the
> Internet provider who are you according your IP address (supposing
> your domain name is kept in anonymity). It takes time and they need to
> have strong motivation to do that.
>
The geographical location is provided *by the server administrator*,
(generally) not automatically by the server. If the administrator does not
want this to be public, they simply don't have to put this in.
Additionally, geolocation data can be extracted with reasonable accuracy
from the server's IP address.

  Providing a precise resource at a root Gopher server, like a well
> known capability file, makes this server vulnerable to a massive
> attack. Until to day, if a Gopher server is flooded by requests, it
> just have either to display a root menu file (gophermap) or an error
> message. The other resources can stand on other severs: thanks to
> Gopher protocol to be a distributed system! If you provide a
> capability file, your server must have to reply the full content of
> this additional file requested. You can tell me that is the the same
> with a resource that doesn't exist: server replies with a short
> message of one line. But, for a capability file, the reply is much
> more long than an error message.

The server need not treat the caps.txt file as a special case. If it is
overloaded, it can simply return the normal error message and the client
will assume that the server doesn't support caps capabilities until it
retrieves the caps.txt again next time.


> And do not forget that: next year,
> you will have to play with 10 flavors of capability files!
>
If all of the servers and clients follow the specification (which they have
no reason not to), then different flavours shouldn't matter. They are all
valid caps.txt files which can be parsed by any client.

  You are advised, now. Have fun!
>
Don't worry--I will!

>
> -- Denis Bernard
>

In short, I think that you are woefully misinformed about the capabilities
of caps.txt and would do well to carefully read the specification at
gopher://gophernicus.org/0/doc/gopher/gopher-caps.txt .

When I get a gopher server (sometime this summer), I will gladly implement
a caps.txt file, as I believe that this system provides a wide array of
benefits to both the client and the server with no risk to the minimally
competent server administrator, and none at all to even the least competent
client user.

-- 
Wolfgang J. Faust
01010111 01101111 01101100 01100110
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/gopher-project/attachments/20120514/f1e17555/attachment.html>