From: gopher-project-bounces+rachael=telefisk.org@lists.alioth.debian.org
Date: Mon May 14 16:34:12 2012
Subject: Re: [gopher] Capability files are dangerous
It looks like most people have already addressed the points I was going
to make, but FWIW:
> 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. 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!
For most servers, caps.txt will be just another file. Only Bucktooth and
Gophernicus generate it by pseudoselector. The server has no idea who is
fetching caps.txt and for what purpose. In fact, it is impossible to infer
whether it is a smart client doing it, or simply someone looking at the
file.
> A capability file creates an indirect kind of permanent connexion by
> a kind of proxy.
I don't understand this assertion. There is no persistent connection; it's
just another request.
> 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.
This is not an unreasonable concern, but the idea of caps was to allow
servers to advertise what they supported. If the server doesn't offer a
function (or the client doesn't implement it), the function doesn't occur.
The server won't have any way of knowing what the client does and does not
support, and the client doesn't have to implement any feature that the
server offers other than basic RFC-1436.
> 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.
Explain.
> 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.
> 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 geolocation and server information in the caps file is strictly optional.
It can even be spoofed; if you put caps.txt at the root of the filesystem,
Bucktooth will see it and serve *that* instead, completely overriding it
without further interpretation (it can even be verifiably incorrect). You can
provide all or none of the properties in that file, or you can just have a
blank file, in which case it acts as if there were no caps at all. I don't
know how Gophernicus implements this, but it is probably similar.
Also, no caps property is mandatory, even the filesystem ones. By default
Bucktooth will advertise that the server is Bucktooth and that the filesystem
is POSIX, but I don't think this would have been any more difficult to
determine in the default case, and it can always be overridden for those who
are concerned.
I think I should document these mitigations better, though, and I will do
that. I am always open to constructive criticism about the idea, but I think
that caps gives a backwards-compatible way of implementing forward-facing
features, and I believe that it does not change the security profile of sites
or clients that implement it in any meaningful way.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser@floodgap.com
-- Understanding is a three-edged sword. -- Babylon 5, "Deathwalker" ----------
_______________________________________________
Gopher-Project mailing list
Gopher-Project@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project
Thread start
(DIR) [gopher] Capability files are dangerous
(DIR) Followup: Re: [gopher] Capability files are dangerous
(DIR) Followup: Re: [gopher] Capability files are dangerous
(DIR) Followup: Re: [gopher] Capability files are dangerous
(DIR) Followup: Re: [gopher] Capability files are dangerous
(DIR) Followup: Re: [gopher] Capability files are dangerous
(DIR) Followup: Re: [gopher] Capability files are dangerous