Malicious Links

Chris Brannon chris at
Sat Jul 10 12:15:03 BST 2021

nothien at writes:

> In Gemini, the restriction that information can only be sent to a server
> by performing a request is considered a feature.  However, this can
> backfire by removing the need for user interaction, even when it is
> absolutely necessary.  Below, I provide an example to show why this
> feature, combined with the existence of malicious links, can prevent (or
> at least hinder) the sole use of TLS certificates in account-based sites
> on Gemini.

I think having destructive operations (create, update, delete) running
over Gemini is probably a mistake to begin with, because it will lead
down the path of trying to build yet another application platform on top
of yet another document delivery system.  They tried that trick in the
90s.  Sadly it's still with us, and it's called the WWW.

Gemini eliminates a lot of the things that were tacked on to HTTP to
help make it useful for applications.  There's no distinction between
idempotent and not-idempotent operations, no cookies, and so forth.

Here's version 0.9 of the HTTP spec:

The family resemblance between Gemini and HTTP 0.9 is astonishing.  Take
HTTP 0.9, evolve it just a smidge, add some features, change some names,
mandate TLS, and VOILA, you get Gemini.

> Consider a website, gemini://, where users can set up
> accounts.  It uses TLS certificates for authentication and provides
> important settings through the Gemini interface.  For example, one can
> delete their account by visiting a certain URL: perhaps
> gemini://  Although this makes sense, you may
> already begin to understand the problem at hand.

If you have a site that does something more complicated than serve
documents and satisfy search requests, that's starting to look a lot
like an application.

Chris Brannon
Founder: Blind and Low Vision Unix Users Group (
Personal website: (
Chat: IRC: teiresias on and OFTC, XMPP: chris at

More information about the Gemini mailing list