Re: "Hi all. I'm wondering: why does the Gemini specification…"
In: s/Gemini
I can't say for sure why userinfo is explicitly disallowed in the Gemini spec, though I agree it's probably meant to enforce use of certificates as the only mechanism for user authentication. It's worth noting, though, that Gemini is best thought of as an extension to Gopher rather than a reduction of HTTP, and Gopher also does not support userinfo in URIs.
Also, I agree that sending user-supplied data as part of the URI isn't secure. That's another aspect of Gemini taking design cues from Gopher and not HTTP, since neither protocol has an equivalent to HTTP's POST method. The closest analogue available to Gemini is the Titan protocol--which is partly why Titan support is growing in Geminispace.
🚀 jsreed5
May 12 · 10 days ago
😎 flipperzero · May 12 at 17:57:
@jsreed5 Gemini is not an "extension" of Gopher because it uses none of the Gopher codebase nor any of the standards or most principles. Gemini is an elaboration of a concept which hybridizes the two -between- what Gopher and the Web provide in a bare-minimum presentation and execution.
btw on that note of titan, isn't spartan similar in that it's not encryptedd? I thought they still require certificate-authentication in order to interface between host to client for server-end operations anyhow, unless I'm mistaken and please feel free to correct me if so.
on further note to that, I observe that titan and spartan also employ the very approach we all seem to be mutually frowning down on the userinfo being appended to the URL - again, unless i'm mistaken, and instead is a hash of the cert assigned represented in URI scheme.
🦂 zzo38 · May 12 at 19:55:
Spartan allows the URL to include a username and password but they are not used (I don't know why it is allowed at all then; it does not seems to make sense). X.509 certificates are better authentication for many reasons, though. Scorpion does allow a password (implementation is optional) but recommends that you use X.509 instead if possible. Regardless of the protocol, if the userinfo in the URL is present, an implementation can be made to not display the password.
👽 spc476 · May 12 at 20:35:
For those curious as to what this is about, it's about including a username/password in the URL, like:
gemini://john:god@example.net/foo/bar
I'm partially responsible for this. Solderpunk was looking to add a reponse that asks for a username/password (like the above) when I suggested the use of client certificates as an alternative. My thinking at the time was the the server side could generate a certificate for the client to use to be granted authorization for parts of the site. Solderpunk took it in a completely different way, and then mandated that the user creditials in the URL was NOT the way to go.
😎 flipperzero · May 12 at 20:38:
@spc476 omfg wow hi! thanks for joining us here part of the discussion on Bubble BBS and I hope you find your time nice. :D Ok sorry aside from fanboying RE OG mailing list matters ehehe
I think this was a very good, important contribution! Your thinking was correct - look at misfin. Try out gemini://woodpeckersnest.space:1958 as an example of such implementation. This is also possible client-side as evidenced by skyjake's lagrange. I don't see anything wrong with, and very much prefer, this approach of user interaction and data integration between client to server far more than sharing plaintext details YUCK!
@skyjake excuse my tardiness being late back to the party like this, but thank you very much for your cited reference as it's what I thought was the matter (which is also why I cringed as much in description as I was making detail haha)
So far, this method seems to work just fine, if not just doing so by either web frontend or remote shell interface (like what I do with my spot) and screening things that way.
🚀 mk270 · May 21 at 16:02:
The use of userinfo is also a vector for extending the protocol via a side-channel. I could be mistaken, but this was cited on that accursed mailing list as one of the reasons for banning it.
🚀 lars_the_bear [OP] · May 21 at 16:47:
@mk270 : "userinfo is also a vector for extending the protocol via a side-channel"
I suppose it could be, if you used it for something _other than_ authentication. I guess that's why URL fragments are banned, also.
I agree that it makes sense to ban userinfo if it _isn't_ used for authentication, but that doesn't explain why it's banned for authentication. I guess some of the forgoing disucssion explains that, but I still think it was the wrong decision, on balance.
Original Post
🌒 s/Gemini
🚀 lars_the_bear:
Hi all. I'm wondering: why does the Gemini specification object so strongly to using "userinfo" credentials in the URL? I can see the advantages of client certificates for technically-minded users, and for server-side developers. But user/password is a pretty common paradigm in the ordinary web. Does anybody know why the "userinfo" approach was so roundly rejected?
💬 16 comments · May 11 · 11 days ago