On gopher conservatism
(WARNING: long, rambly, preachy content ahead)
Recently, ZLG wrote[1] about his distaste for an attitude amongst
certain Gopher users that we must actively resist Gopher becoming
"like the web". I would like to ask ZLG to expand on his thoughts
here, because absent the context of the original discussion in
sort of philosophy is being railed against. I may agree with it, or I
may not. The issue of Gopher conservatism is a complicated ones.
"Changing gopher" can mean a lot of things, with making changes to the
base protocol and getting them widely implemented in clients and
servers at one extreme, and simply changing conventions of usage
within the confines of strict backward compatibility with the original
software from Minnesota.
One concrete thing ZLG did mention was excessive hierarchy. I have
definitely been bothered by this. The "Why is Gopher still relevant"
document by Cameron Kaiser[2] that so many SDFers link to from their
root menu puts Gopher's hierarchical structure up on a pedestal and
says that this is why we all love Gopher, not because we're tired of
the obese and distracting web. I actually don't think this is true at
all for most active Gopher users today. There's not an awful lot of
deep hierarchy in most gopherholes, and where it does exist it's not
really that different from well-organised material on the web. While
it sounds nice and clean, I do get a little tired of the old "home" ->
"phlog" -> "this year" -> "this month" -> "latest post" dance. But
maybe that's a flaw with my workflow, and with better use of some
kind of tool like moku-pona I would be blissfully jumping directly
to content.
On the question of changing gopher in general, I am not quite as
conservative as some. There are a plenty of newer servers and clients
under active development these days and I am not completely opposed
to them doing new things which very old software can't handle. I
understand some people like to surf gopherspace from very old or
under-powered hardware, and a lot of this hardware may be more or less
permanently stuck with old software. I would genuinely hate to see
these people totally unable to browser modern gopher content at all
because some massive change broke their clients, and I would oppose
anything that could result in that.
On the other hand, I don't think I have a problem with lots of nice
small upgrades that would just result on them missing out on little
things. For example, there is a "telnet" itemtype in Gopher, and
clients which support it (like VF-1) let you launch a telnet
connection to some sever on some port just by selecting a gopher menu
item. It seems obvious to me and not at all contrary to the spirit of
Gopher that in 2018 it would be nice if the community could
standardise on a new itemtype for SSH that functioned in precisely the
same way. This would require no server-side changes and changing any
client that supports telnet items to support SSH ones too should be a
very simple effort. This would let those of us using modern clients
do some cool things. People stuck with ancient gopher clients are
probably also stuck without SSH clients that connect to modern servers,
so they're not going to miss out on anything anyway. I may have to
suggest this on the gopher-project mailing list.
So, clearly I am not opposed to all progress when it comes to gopher.
However, in general I am pretty skeptical about changes to gopher
beyond, perhaps, the level of usage conventions, and this actually is
precisely because I don't want Gopher to end up like the web, and I
am terrified of setting the community on any kind of slippery slope
toward this. I'll elaborate on what I mean, at length (naturally),
and this will also serve as my contribution to the recent thread
of people discussing what makes gopher special to them.
Visiting a website today is basically a massive exercise in trust. I
am saying to some random, unknown person: "here is my computer, do
more or less whatever you want with it".
This sounds like a crazy exaggeration, but it's not really. When I
send a HTTP request somewhere from within a modern browser, it is
absolutely impossible for me to know in advance:
of processing what I get back from the first one.
any of these connections.
code on a virtual machine (Javascript) which, while sandboxed, still
has the capacity to consume 100% of my CPU and/or RAM if poorly or
maliciously written.
hard drive as a result of any of these connections.
from any previous connections to any server may be sent to
arbitrary unknown servers as part of these unforeseen connections.
In this environment, it is impossible to make informed decisions about
what happens to you on the web. The web is something that happens
web user to webmasters is one of subservience. The only possible
course of action is blind trust. This trust can be and routinely is
violated, and webmasters do all kinds of nasty shit to you every day.
Some of it is "just" minor discourtesy, a total lack of common decency
toward one's fellow human being, like automatically playing videos.
Some of it is far more nefarious, like tracking you everywhere you go
from server to server over the net, and actively countering your
efforts to stop this (by e.g. using "supercookies" to replace the
regular cookies you delete). This is not just a lack of decency, this
is full on "act of war" stuff.
None of this is true on Gopher. When I select an item in a gopher
menu I know, a priori, and with total confidence, that I am asking my
computer to make exactly one connection to exactly one known server
and there is no way for the person running that server to trick a
non-buggy client into doing otherwise. If my client is well-designed,
then I will know before I select that item whether it is going to
display an image or play a sound or a video (okay, there is no
standard itemtype for videos and the "binary" filetype leaves you
unsure, but by current very wide-spread convention that is only used
in cases where the item name contains the underlying filename so you
can guess from the extension). There is no way for the person running
that server to persistently store data on my drive, and there is no
way for them to learn anything about anywhere I have previously been.
There is nothing at all analogous to the HTTP "Referer" header, and
there is nothing that facilitates an analog to the infamous browser
fingerprinting. Unless my client is badly buggy, it's pretty much
impossible for following a link in gopherspace to cause my CPU or RAM
usage to increase more than very slightly, for a second at most. The
whole thing is a short, sharp, singular event, concentrated in time,
with no side-effects.
Because of this, I surf through gopherspace fearlessly, unthinkingly,
with a light heart and a clear mind. I'm like a kid in a candy shop.
I don't have to trust anybody at other end of a socket on gopher,
because you can't hurt me here. The producer and consumer in
gopherspace are on equal footing. You can offer content to me,
clearly marked as to what is is, and I can consume it, or not,
item-by-item, as I wish. You can point me to interesting content on
other servers, but you'll never know if I follow those links, and if
I do follow them, those other servers will never know where I came
from.
This is what really makes gopher special to me. Yes, the content
here is great, I appreciate easy navigation and I like the simplicity
of the protocol and all that other stuff, I really do, but the thing I
care about the most is that gopherspace is not an experience that is
forced upon me, it's a safe place for me to actively explore under my
own will power.
I will fight tooth and nail against the widespread adoption of any
change in protocol, or software, or user culture, which I perceive to
threaten this state of affairs. So, in that sense, I do believe
that Gopher must not become the web, ever.
You might think I am being paranoid here and that the simplicity of
Gopher means we are all safe forever from any insidious would-be
spoilers of our textual haven, but it's not true, not by a long shot.
Tomasino has a page in his phlog[3] about achieving persistence or
sessions in gopher to sidestep the limits on applications that can be
built on it. Tomasino, my friend, I am sorry to have singled you out
here because I have no doubt you are not alone in thinking about this
stuff, and I also don't question at all that you absolutely had not
one iota of ill-intent in writing that stuff, but I must say, it
scares me that you are thinking and talking like this! Trying to
make Gopher stateful is kind a taboo topic to me. Yes, it can be
done, and yes, it would facilitate building applications, but why do
we want to build applications on Gopher? Gopher was certainly not
designed as and historically has not been used as a platform for
hosting applications. Gopher was designed to permit quick and easy
dissemination of well-organised information. That is an important job
for something to solve, and Gopher solves it well, so why-oh-why must
we shoehorn it into some other role? This feels to me like very much
like the first steps toward repeating the tragedy of the web.
I was really, really surprised when the folks from Bitreich - you
know, hardcore minimal software elitists from Germany with high-minded
principles and an honest-to-God manifesto - added a text-based "point
and click" style adventure game[4] to their gopherhole which uses your
IP address to maintain state between requests so that you can travel
around the game, adding items to your inventory and using them later.
Don't get me wrong, I love the game itself, and I've had fun playing
it, even though I can't get very far. I enjoy the slightly
self-deprecating nerd humour in there (your default inventory includes
an "old Thinkpad", naturally) and I applaud the creativity that went
into it. But come on, if those guys think that rough-and-ready
client fingerprinting based on IP address is acceptable, where can we
expect less principled types to stop?
The Bitreich game uses your IP address to track you through the game.
This is perhaps not a big deal, because your IP address probably
changes all the time, and is not uniquely tied to you because it can
be shared via NAT. But there are other ways to solve this problem.
There is no reason a suitably written server could not generate a
random hexadecimal string everytime somebody visited the root menu,
and insert that string as a prefix to all other sector paths. If a
visitor, not realising these tracking strings were in there (because
how often do you look at selectors before following links on gopher?)
bookmarked one of these selectors, then the host would know if they
returned a few days later, even if their IP address had changed. If
could also insert the same string into links they display to one
another (hell, if this server advertised its support for this kind
of tracking to other servers via a special selector, like Gophernicus'
"/server-status" selector, then any time it linked to another server
it could query it first and insert the tracking tag if it discovered
that it would be supported). By comparing logs, the admins of these
two hosts could track visitors between their two sites. This requires
no change to the protocol and no change to the client, it would even
work on ancient UMN gopher.
Right now there is nobody operating in Gopherspace who I believe would
have the least bit of interest in doing this, but my point is that
they could. It is technically possible. There is no protocol
simple enough to prevent this kind of thing. The only possible
protections against it are obscurity (and this will probably rescue
gopher from most ills, in the end) and/or a strong, widespread and
actively enforced social norm against it. This norm would have to be
pretty strict. If the culture is "maintaining a little bit of state
is okay if it's for a good cause", then slowly but surely, year by
year, the meanings of "a little bit" and "good cause" get stretched
further and further and twenty years later anything goes. This is
basically what happened to the web. If the norm is "no, not even a
little, not even once", then and only then is there a chance that the
status quo can be preserved.
Did I say, many, many lines further up, that "on the question of
changing gopher in general, I am not quite as conservative as some"?
Well, maybe that's not true, maybe I'm the the most powerful
God-damned force for gopher hyper-conservatism on the net. But I
swear it's not dogmatic. I'm just worried about something which has
already happened before happening again. I have no beef with changes
to gopher that can't possibly lead us down that road. New item types,
no problem. TLS support, bring it on. Anything that could
conceivably lead one day to user tracking? I will come at you in a
dark alley with a bladed instrument.
[1] gopher://zelibertinegamer.me:70/0/phlog/2018-03-18_1452.txt
[2] gopher://gopher.floodgap.com:70/0/gopher/relevance.txt
[3] gopher://gopher.black:70/0/explorations/gopher-application-development.txt
[4] gopher://parazyd.org:70/1/dotg
text/plain; charset=utf-8This content has been proxied by September (ba2dc).