[spec] Regarding the proposal to remove status code 11

[Luke Emmet]

Apologies - I should improve my proof reading - there were a couple of typos - some missing negations. Here is a fix, but in summary I meant to say

 - Gemini's request method *is* idempotent (equivalent to the web's GET)
 - Gemini does not have a *non* idempotent method (safe for sending state to the server)

On 14-Mar-2021 09:32, Luke Emmet wrote:

> Gemini is really a read-only medium as its method is GET only - there is no idempotent method to send data. Servers that attempt to put transient state with side effects (changing a password among other things) by putting these into the URI is poor design IMO.

Gemini's method *is* an idempotent method, there is no non-idempotent method in Gemini.

> 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. 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.

[...] To send state properly you need a *non*-idempotent mechanism, [...]

> 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.
>
>
>> Secondly, let's look at why exactly it is considered a bad idea to put
>> sensitive information in a URL. The reasons given by RFC 3986 §7.5
>> (quoted at the Gitlab issue) are:
>>
>>> URIs are frequently displayed by browsers, stored in clear text
>>> bookmarks, and logged by user agent history and intermediary
>>> applications (proxies) > The last problem can be avoided by not using relay-type proxies (by
>> which I mean proxies where the TLS connection is with the proxy rather
>> than with the destination). Note that all the other problems can be
>> addressed by client software IF it's possible to distinguish between
>> sensitive and non-sensitive input. When the server sends 11, the client
>> can hide the input the user is typing, and throw away the query after
>> sending the request, before displaying the URL in the URL bar or saving
>> 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.
>
>> So actually, if we reason from the assumption that password
>> authentication will happen anyway (as I've argued above), removing
>> status code 11 has rather negative consequences, as it removes the
>> ability to distinguish between sensitive and non-sensitive input.
>
> Status 10 and 11 are currently logically indistinguishable and status 11 is misleading.
>
> If we keep status 11, the FAQ could warn off its use and I think clients should warn users to say something like "The server requested to mask the input, however be aware that the parameter will be simply appended in the clear to the subsequent URI, and this does not offer a genuine security feature."
>
>> My conclusion is that removing status code 11 would be unwise, and
>> instead it would be better to include a recommendation in the best
>> practices document to throw away the query part after sending a request
>> that results from user input on a 11 page. Maybe there should also be a
>> recommendation to store client certs in a password-encrypted vault, as
>> of course storing long-lived certs unencrypted is about as much of a
>> problem as storing sensitive queries in the browsing history.
>>
>> Thirdly and lastly, about Gitlab. I strongly dislike the fact that
>> discussions which can have quite an impact on all Gemini users are
>> happening in Gitlab issues; to stay up-to-date on all these requires
>> regularly going through multiple webpages, and to comment requires a
>> Gitlab account! I think this is a mistake.
>
> I don't think its a big deal - if the BDFN finds it a useful and practical way to gather issues with the spec, I'm happy to contribute wherever the conversation may happen.
>
>> [1] https://gitlab.com/gemini-specification/protocol/-/issues/17
>
>   - Luke