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
---
Previous in thread (11 of 39): 🗣️ Sandra Snan (sandra.snan (a) idiomdrottning.org)
Next in thread (13 of 39): 🗣️ PJ vM (pjvm742 (a) disroot.org)