[spec] Regarding the proposal to remove status code 11

PJ vM pjvm742 at disroot.org
Sun Mar 14 14:43:34 GMT 2021


On 14/03/2021 10:32, Luke Emmet wrote:
> URIs are designed to be shared, bookmarked - they are a publicly 
> persistable reference of server state (see Fielding et al). They are
> a massive success on the internet as such.
> 
> A URI query should be thought of as a query parameterisation - a way
> to address server state, rather than as a way to send state to the 
> server.

Key is "*should* be thought of". You have a clear concept of the URI as
only an identifier and nothing more. However, you cannot expect
everyone else to only use URIs in the way you think they should be used.

Fact is that it's *possible* to use the URI query as an input mechanism,
and that in the Gemini protocol it is the *only* thing that can be used
as an input mechanism. It's possible, so people *will* do it. They will
also use it to convey passwords. You can keep telling the world that you
think it's poor design, and people will keep doing it anyway.

This is my point: people are going to do it, and status code 11 is
necessary to allow doing it safely.

> To send state properly you need an idempotent mechanism, which
> Gemini doesnt have. The web does, as incidentally did early gopher
> before it adopted URIs. This seems to be a conscious design choice of
> Gemini.

Creating separate status codes for "input", one of which for sensitive
input, was a conscious design choice of Gemini.

> My view is that status 11 is a kind of security theatre - it gives a 
> false sense of security, when in fact it is logically equivalent to 
> status 10 - and in fact the spec allows valid clients to only 
> interpret the first digit, so a client may actually not know. We 
> should not be encouraging its use or authors or users to form a view
> it is "protecting" them in any significant sense.

How in the world do you get to the position that status codes 10 and 11
are "logically equivalent"? What? They are different codes, they are
defined to mean different things...

Sensitive input *is* protected in a significant sense, IF the client
recognises status code 11 and acts on it. If you are submitting
sensitive information via a URI query, someone looking over your
shoulder or someone gaining temporary access to your device and looking
through your browsing history are both legitimate threats, and status
code 11 allows clients to protect against these threats by not showing
the query on the screen and not storing it in the browsing history.

> No, its not possible for either clients nor servers to know which 
> URIs are "sensitive"
> 
> Q: here is a URI - should a client, proxy or server be prevented
> from recording or sharing it:
> 
> gemini://example.com/foo?bar
> 
> Ans: there is *no* way to know. It depends on the semantics of the 
> application and foo and bar.

Your reasoning is very flawed here. Sure, there is no way to know *for a
random person just by looking at the URI*. Note that the site creator is
NOT a random person just looking at the URI. On the server side, the
creator specifies what question is asked when "example.com/foo" is
requested, specifies if that is a sensitive question, so the server
knows whether the question should be asked with a 10 or a 11. Then, by
the server giving a 10 or a 11, the client can know whether the question
is sensitive and consequently how it should treat the input.

> the parameter will be simply appended in the clear to the subsequent 
> URI

"in the clear" reads to me as suggesting the query is not encrypted
between the client and the server. Note that the query is in the
request, which is TLS-encrypted.

-- 
pjvm


More information about the Gemini mailing list