Malicious Links

Jonathan McHugh indieterminacy at
Sat Jul 10 16:54:54 BST 2021

Thanks for an informative post.

Just one point of concern:

In the UK term 'nonce' was a perjorative term - its mercifully left the everyday lexicon. Just as the term 'fag' used to mean an 'old lady who picks up sticks', language moves on.

While I understand that it has a cryptographic definition, is it possible to have/use another term than 'nonces'?

Having grown up watching the satirical series, Brass Eye, the following could be featured as a comedy monologue:
A nonce introduces randomness, and sometimes time-stamping, into communications so that the application can verify the user. This added uniqueness makes it impossible for hackers to use prior communications to impersonate the legitimate parties for nefarious purposes.

Jonathan McHugh
indieterminacy at

July 10, 2021 2:57 PM, "nervuri" <nervuri at> wrote:

> On Fri, 2021-07-09, nothien at wrote:
>> What does the Gemini community think? How big of a problem is this?
>> Are there any other feasible workarounds? Which major (and minor) sites
>> are affected? Does this call for some sort of change in protocol?
> See previous discussions:
> gemini://
> -
> gemini://
> -
> Takeaways:
> Server-side: mandate client certs for requests with non-trivial
> consequences and use nonces (CSRF tokens) to be extra-safe (see the
> first link).
> Client-side: never use a client certificate when following a link from
> outside the client certificate's scope, as defined in section 4.3 of the
> spec. This rule could be added to the spec itself. Here's how the
> scope is defined:
>> A client certificate which is generated or loaded in response to such a
>> status code has its scope bound to the same hostname as the request URL
>> and to all paths below the path of the request URL path. E.g. if a
>> request for gemini:// returns status 60 and the user
>> chooses to generate a new client certificate in response to this, that
>> same certificate should be used for subsequent requests to
>> gemini://, gemini://,
>> gemini://, etc.,
> Another client-side takeaway: consider Solderpunk's idea of a
> "containerised" client, exemplified in [1].
> Such client-side precautions should cover most cases of CSRF, except, to
> quote Solderpunk:
>> It is not foolproof - it cannot protect against application-internal
>> CSRF attacks, e.g. some kind of multi-user application where one user
>> can post text/gemini content which is rendered by another user of the
>> same application.
> Nonces (CSRF tokens) should be used in such instances.
> [1]

More information about the Gemini mailing list