Re: [gopher] Capability files are dangerous
On 14 May 2012 04:48, Denis Bernard <denis.bernard@laposte.net> wrote:
> Capability files are dangerous!
>
> 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.
Yes, and this is still, without going out of one's way, impossible.
The only way to know which flavour of a Gopher client is browsing is
to apply a series of rules and to find it by process of elimination...
and this was possible both before and after capability files. Let me
explain it in a different way, for those that want it more detailed:
every Gopher client has a unique style of retrieving and sending data,
like people have handwriting. My writing looks different from, say,
Dr Kaiser's, but if we both write the sentence, "The quick brown fox
jumped over the lazy dog", both examples can be recognized as the same
sentence. However, what Mr Bernard was referring to is more like a
User-Agent string, like a proper name. I spell my name
N-I-C-H-O-L-A-S, whereas Dr Kaiser spells his name C-A-M-E-R-O-N.
Clearly different at first glance.
> 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!
"Without to be paranoiac"? Don't you mean, "without being paranoid"?
If you "think" (thinking is logical, this doesn't seem to be) in the
way that your written word demonstrates, you are /highly/ paranoid,
because, once again, you compare capability files to User-Agent
strings, which are highly different. A capability file is, "I can do
X, Y, and Z, so give those jobs only." A User-Agent string is, "I am
John Doe, born on 31-Feb-1995." Now, sure, we can figure out (applying
logical thinking) that John Doe can do jobs X, Y, and Z, and if a
person does jobs X, Y, and Z in a time of W seconds, it must be John
Doe... but that isn't the same as shouting one's identity from the
rooftops, which is what every Web browser on the face of the earth
does!
> 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?
Hey, man, don't hate on cookies. Cookies are delicious delicacies!
But seriously, cookies were a great invention... as long as they were
used for storing data, and someone plainly marked a tick box that
cookies were to be enabled. "Does it must be the same for the Gopher
space?" If you mean that Gopher should make your life easier, then
YES, YES, and YES! I want Gopher to be the new Mobile Web. So if one
must lose out a /little/ on security to enhance usability by a
galactic leap, amen to that!
>
> 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.
Now I agree with this, but again, Mr Bernard has the wrong end of the
stick. Scripting languages weigh a product down, make it slower.
Load up Google Plus in Lynx and in Chrome and notice the difference,
but also notice the (mild) gain of convenience. Yes, web scripting as
used on a lot of amateur Web sites was a boggy, insecure mess, and
yes, it has no place on Gopher, but it isn't a perversion. Scripting
gave us easy-to-use Web applications as well, which I like.
> 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.
>
Yes... so? There is a standard to which they must conform, and if
they don't conform, the non-conforming parts will be skipped over as
long as the browser conforms. It's not wrong to make capability files
available. It's wrong to make a Gopher /client/ which does not
respect the existing capability file format and instead institutes its
own. MSIE did that.
> 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.
If I am not mistaken, malicious scripts were client-side. They would
be transferred onto the client by a server that didn't know better
(buffer overflow etc), or a malicious server. Capability files are
server-side. The most "malicious" that a server-side capability file
would be lying about capabilities. For instance, a sign on John Doe's
head saying "I can do jobs W and X" when he actually has no idea how
to perform job W... or another sign on Jane's head saying "I can do
jobs X, Y, and Z" when Jane also knows perfectly well how to do jobs
B, C, and D.
>
> 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.
Yes... so? It can be deduced. Somewhere on the coast of Brazil a
dragonfly passed wind. Tell me how that's in any way relevant. Web
browsers have it worse. They carry a sign with their name and
birthday printed in big letters on it. Far worse threat. By using
capability files we can clamp down on the amount of data trafficked in
and out and make the network faster to use, since devices only send
and receive the data they can read. *throws book in Chinese at Pierre
Grenouille Machin-chouette* Great, now read this. You can't, can
you? Still got a nasty bump on your head from it, though, didn't you?
Get the point?
>
> 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.
Yeah, so what? I'm British. You're a Frog. She's Belgian. He's
Finnish. There's five million people in Finland. Here's an IP
address. Go point out Tapio Korhonen, please. One problem, I know:
you can filter access based on IP address, I'm familiar with this and
people should hang for it, but Mr Bernard doesn't bring up fundamental
rights and liberties, he brings up privacy. Privacy is necessary for
financial transactions, not a small-time, experimental mobile data
transmission network (even though the common use of this network is my
dream).
> 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.
You're contradicting yourself. Until now, if someone
pings/arps/requests (what term is right in GOPHER for a "send it here"
request) for a root menu file, the root menu file is what will be
given. If someone pings a gopher server that has capability files,
they will get that. Aren't they the same length roughly, just a few
hundreds of bytes each? Ping of death attacks don't select for the
kind of traffic.. they just select for the length. Would it make
sense to forbid copies of the complete works of Shakespeare (or,
alternatively, a year's worth of "High Times" archives) just because
one can repeatedly request them and bring down a server?
And do not forget that: next year,
> you will have to play with 10 flavors of capability files!
>
> You are advised, now. Have fun!
>
> -- Denis Bernard
>
>
>
>
> _______________________________________________
> Gopher-Project mailing list
> Gopher-Project@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project
En lisant ce merde, je perds l'espoir pour mes frères (et sœurs) êtres
humains... ce tas de merde suppurant donnera n'importe qui un mal à la
tête. Non, "merde" est un titre trop charitable pour les "œuvres"
d'un branleur de chiens... pardonnez-moi, un écrivain...
_______________________________________________
Gopher-Project mailing list
Gopher-Project@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project
Reply to: