💾 Archived View for rawtext.club › ~sloum › geminilist › 006086.gmi captured on 2023-11-14 at 09:37:16. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Luke Emmet luke at marmaladefoo.com
Sun Mar 14 09:53:38 GMT 2021
- - - - - - - - - - - - - - - - - - -
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