On Mon, May 14, 2012 at 4:48 AM, Denis Bernard
<denis.bernard@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