💾 Archived View for rawtext.club › ~sloum › geminilist › 006094.gmi captured on 2023-11-14 at 09:36:58. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
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 asonly an identifier and nothing more. However, you cannot expecteveryone 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 usedas an input mechanism. It's possible, so people *will* do it. They willalso use it to convey passwords. You can keep telling the world that youthink 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 isnecessary 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 sensitiveinput, 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 11are "logically equivalent"? What? They are different codes, they aredefined to mean different things...
Sensitive input *is* protected in a significant sense, IF the clientrecognises status code 11 and acts on it. If you are submittingsensitive information via a URI query, someone looking over yourshoulder or someone gaining temporary access to your device and lookingthrough your browsing history are both legitimate threats, and statuscode 11 allows clients to protect against these threats by not showingthe 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 arandom person just by looking at the URI*. Note that the site creator isNOT a random person just looking at the URI. On the server side, thecreator specifies what question is asked when "example.com/foo" isrequested, specifies if that is a sensitive question, so the serverknows whether the question should be asked with a 10 or a 11. Then, bythe server giving a 10 or a 11, the client can know whether the questionis 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 encryptedbetween the client and the server. Note that the query is in therequest, which is TLS-encrypted.
-- pjvm