💾 Archived View for gemi.dev › gemini-mailing-list › 000194.gmi captured on 2023-11-04 at 12:32:01. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
How is gemini meant to deal with authority's userinfo? E.g. gemini://username:password at mozz.us/ gemini://username at mozz.us/ Orthodox? If so, how does the server communicate authentication failure back to the client? Thoughts?
On Tue, 9 Jun 2020, Petite Abeille wrote: > How is gemini meant to deal with authority's userinfo? > > E.g. > > gemini://username:password at mozz.us/ > gemini://username at mozz.us/ > > Orthodox? > > If so, how does the server communicate authentication failure back to the client? This kind of stuff really is distracting from the business of just getting some decent Gemini content written. We should stick to solving problems as they arise in reality, rather than focusing on theoretical issues which raise a sort of "gotcha" about the existing spec and philosophy, and we ought most particularly so to do if we disagree with that philosophy. Mk -- Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/
> On Jun 10, 2020, at 06:19, Martin Keegan <martin at no.ucant.org> wrote: > > We should stick to solving problems as they arise in reality It's a real question for me. Groupthink has its limits.
> How is gemini meant to deal with authority's userinfo? > > gemini://username:password at mozz.us/ > gemini://username at mozz.us/ > > Orthodox? > > If so, how does the server communicate authentication failure back to the client? I don't think that user/password is the right way to handle authentication in Gemini. The URL RFC also specifies: > Use of the format "user:password" in the userinfo field is > deprecated. So only user@? is still a valid URL. If your server handles user@ in a different way than without authority, i think that's totally in-spec, but authentication is probably not. One possible usage for authority could be home-dirs instead of an official site: Instead of using => gemini://random-projects.net/~felix/ one could also access the directory via => gemini://felix at random-projects.net/ But that's just some brainfart. Regards - xq [0] https://tools.ietf.org/html/rfc3986
> On Jun 10, 2020, at 13:15, Felix Quei?ner <felix at masterq32.de> wrote: > > I don't think that user/password is the right way to handle > authentication in Gemini. Why not? Gemini mandates a secure communication channel (TLS) already. The userinfo is identical to the Basic Authentication scheme, but encoded the URL directly. Rather convenient altogether. > The URL RFC also specifies: > >> Use of the format "user:password" in the userinfo field is >> deprecated. This is more related to authentication over an open channel. > So only user@? is still a valid URL. > > If your server handles user@ in a different way than without authority, > i think that's totally in-spec, but authentication is probably not. I guess user@ could be any magic token/ticket, for the client to maintain a state on the server. Perhaps a subset of 40 TEMPORARY FAILURE, e.g. 49 Unauthorized, would be an appropriate response if Authenticate: Basic is required by a resource. > One possible usage for authority could be home-dirs instead of an > official site: I was more looking into a way for the client to maintain some states (e.g. preferences) on the server: C: gemini://token at mozz.us/?ua=lightweight -- user-agent store its preferences on the server S: 30 gemini://token at mozz.us/index.gmi-- redirect to an appropriate resource C: gemini://token at mozz.us/index.gmi -- lightweight version of the resource S: 20 text/gemini -- customized as per the user-agent stated preferences A bit of content negotiation in other words. For all practical purpose, it serves the same purpose as the various 6x (CLIENT CERTIFICATE REQUIRED) statuses. Minus the burden of the actual TLS gymnastic.
xq wrote: > One possible usage for authority could be home-dirs instead of an > official site: > > Instead of using > => gemini://random-projects.net/~felix/ > one could also access the directory via > => gemini://felix at random-projects.net/ > I actually really like this, it provides a consistent way to do this for any site. makeworld
On Tue, Jun 09, 2020 at 08:58:04PM +0200, Petite Abeille wrote: > How is gemini meant to deal with authority's userinfo? > > E.g. > > gemini://username:password at mozz.us/ > gemini://username at mozz.us/ > > Orthodox? > > If so, how does the server communicate authentication failure back to the client? > > Thoughts? I have to admit I was not thrilled to see this come up, predictably enough. But you're, of course, right, this is a defined part of the URI spec. And, in fact, because clients are already specced as sending a URL to the server, nothing needs to be done to make this valid. Most URL-parsing libraries will probably make it very easy for the server to extract the username and password. So, if servers want to make use of this information, I guess they can. They can even make use of statuses 10 and 11 to let users setup usernames and passwords. For this to "catch on", client authors would need to add some support to make it easy to add this information to queries. I am not very keen to add extra status codes to facilitate this. We already have status codes in there for an authentication system which has quite some strengths compared to this (non-brute forcability, much reduced risk of accidental password leakage through URL copying and pasting, etc.). Cheers, Solderpunk
On Wed, Jun 10, 2020 at 01:15:33PM +0200, Felix Quei?ner wrote: > > If your server handles user@ in a different way than without authority, > i think that's totally in-spec, but authentication is probably not. > > One possible usage for authority could be home-dirs instead of an > official site: > > Instead of using > => gemini://random-projects.net/~felix/ > one could also access the directory via > => gemini://felix at random-projects.net/ Hmm. But RFC3985 says "The userinfo subcomponent may consist of a user name and, optionally, scheme-specific information about how to gain authorization to access the resource". I think using even just a username without a password for non-auth purposes is, at the very least, against the spirit of the spec. There are practical difficulties, too. If servers used the username to select a user directory, instead of the traditional tilde URL, then for people to be able to meaningfully copy and paste links from their client's UI, said UI would need to render the userinfo component. That's going to be very dangerous if some other servers are using it for actual authentication. Putting credentials into URLs in general seems like playing with fire to me. Client certificates are much safer in this regard, and more useful. The documentation for an app can say "To change your profile details, go to gemini://fancyapp.com/edit/profile" and if I'm "logged in" via an active cert I can follow that link and it will work. Or I can paste the URL at which I get an error to the developer to help them debug, and they don't have to know my identity. Etc. Cheers, Solderpunk
On Wed, Jun 10, 2020 at 02:18:47PM +0200, Petite Abeille wrote: > I was more looking into a way for the client to maintain some states (e.g. preferences) on the server: > > C: gemini://token at mozz.us/?ua=lightweight -- user-agent store its preferences on the server > S: 30 gemini://token at mozz.us/index.gmi-- redirect to an appropriate resource > C: gemini://token at mozz.us/index.gmi -- lightweight version of the resource > S: 20 text/gemini -- customized as per the user-agent stated preferences > > A bit of content negotiation in other words. I think the entire notion of serving up "lightweight" and "heavyweight" versions of a resource is very un-Gemini, and application and client authors are both going to balk at the idea. The whole point is that there *are* no heavyweight clients or apps in Geminispace, by design. How do you make a heavy text/gemini document which isn't intrinsically heavy by virtue of its content? Cheers, Solderpunk
> On Jun 10, 2020, at 22:31, solderpunk <solderpunk at SDF.ORG> wrote: > >> A bit of content negotiation in other words. > > I think the entire notion of serving up "lightweight" and "heavyweight" Do not let the specific example distract you from the general concept: content negotiation. Replace "lightweight" & "heavyweight" with "red" & "blue". Or whatever. The main point is that the URL userinfo bit can be used to maintain states between gemini requests, as it's passed back and forth between client and server. Actually, it could be used to fingerprint gemini clients automatically: C: gemini://mozz.us/ S: 30 gemini://cookie at mozz.us/ C: gemini://cookie at mozz.us/ S: 20 text/gemini => gemini://cookie at mozz.us/beer/ A magic cookie! https://en.wikipedia.org/wiki/Magic_cookie
On Thu, Jun 11, 2020 at 01:34:12AM +0200, Petite Abeille wrote: > Actually, it could be used to fingerprint gemini clients automatically: > > C: gemini://mozz.us/ > S: 30 gemini://cookie at mozz.us/ > C: gemini://cookie at mozz.us/ > S: 20 text/gemini > => gemini://cookie at mozz.us/beer/ > > A magic cookie! This is possible regardless using query strings, or even more obnoxiously, dynamic paths/links. At the end of the day all you can do is call out dodgy behaviour, and if site owners tried it anyway, attempt to make this sort of thing visible to client users. Cheers, Tom
> On Jun 11, 2020, at 01:54, Thomas Karpiniec <tkarpiniec at icloud.com> wrote: > > This is possible regardless using query strings, or even more > obnoxiously, dynamic paths/links. Very true. They are all equivalent: gemini://cookie at mozz.us/beer/ gemini://mozz.us/beer/?cookie gemini://mozz.us/beer/#cookie gemini://mozz.us/beer/cookie Even though, query strings seem to be "special" in gemini, i.e. equivalent to a POST related to 1x (INPUT). > At the end of the day all you can do > is call out dodgy behaviour, and if site owners tried it anyway, > attempt to make this sort of thing visible to client users. Sure. The thought about userinfo was rather less nefarious: a casual way for user-agent to customize their server access. Same as 6x (CLIENT CERTIFICATE REQUIRED), but less ceremonial. I.e. automated cookie tagging is the equivalent of server driven 61 TRANSIENT CERTIFICATE REQUESTED. And named token would be the similar to 62 AUTHORISED CERTIFICATE REQUIRED. Minus the yak shaving.
On Thu, Jun 11, 2020 at 02:20:17AM +0200, Petite Abeille wrote: > > On Jun 11, 2020, at 01:54, Thomas Karpiniec <tkarpiniec at icloud.com> wrote: > > > > This is possible regardless using query strings, or even more > > obnoxiously, dynamic paths/links. > > Very true. They are all equivalent: > > gemini://cookie at mozz.us/beer/ > gemini://mozz.us/beer/?cookie > gemini://mozz.us/beer/#cookie > gemini://mozz.us/beer/cookie But the userinfo case seems to be clearly the worst. If a server uses a redeirect to attach a "cookie" token to the client's URL using a query or a fragment, that won't get carried across when relative links are absolutised, so the scope is limited to that one document, unless the client somehow plays along by recognising the cookie and propagating it itself (which no sane client will do). The path option *will* survive absolutisation, (well, if you gemini://mozz.us/beer/cookie/, with a trailing slash) but to give every visitor a unique cookie and track them across the site this way (and, yes, I've always known this is unavoidable, it's mentioned in some of the very earliest Gemini writings, from before the project even had a name) requires all content at the site to be dynamically generated. Which is possible, of course, but it's a barrier of sorts, at least. The userinfo approach both survives absolutisation *and* works with a perfectly static text/gemini file using relative links. It's an extremely easy and lightweight way to unambiguously track users within one server, and unlike guessing based off IP (which is also of course unavoidable) it is robust against multiple users sharing an IP at once. Of the four approaches outlined above, userinfo clearly has a much higher "damage inflicted to effort required" ratio than the others. I don't yet have a clear idea of to what extent URI schemes are permitted to "pick and choose" from the components of the generic URI scheme as presented in RFC3986. It is clear that the "authority" component (what normal people think of as the hostname and port) is not required, but if a scheme does require an authority does it also *need* to permit the userinfo? The gopher URI scheme (RFC4266) a defintion clearly does not allow one, but URIs for gopher are a tacked on after-thought and I don't know how carefully that scheme was designed. But if it's legitimate for me to declare that the gemini:// URI scheme does not support userinfo, I'll do it in a flash. This cookie redirect thought experiment proves that it's far too dangerous, it's just barely better than an actual HTTP cookie (in that it's not easily sent to third parties). Of course, just saying it's unsupported isn't enough, because servers can try to do it anyway, so every client now needs to explicitly check for this and either error out or remove the userinfo. "URIs were a mistake", as the kids say. Gopher's menu item format might be a total PITA for users, but you know exactly what the valid scope of each component is and there are no "side channels". > > At the end of the day all you can do > > is call out dodgy behaviour, and if site owners tried it anyway, > > attempt to make this sort of thing visible to client users. > > Sure. Ultimately, yes, but one can try to reduce the number of places dodginess is possible to be as few as possible to reduce the burden of playing this whack-a-mole game. > Same as 6x (CLIENT CERTIFICATE REQUIRED), but less ceremonial. And also less consensual. The ceremony is there for a reason. Gemini is supposed to be as close to anonymous by default as the limitations of running it over TCP/IP allow. Turning that off, to partake of an application which maintains state, is *supposed* to be a song and dance. It should be impossible to not realise you're doing it. I don't even mind if doing it is slightly inconvenient, because it should always be a conscious and considered choice. It should also be extremely easy to write a client which is obviously totally incapable of doing it. Yes, this rules out the notion of "lightweight content-negotiation". So what? Has anybody ever once missed that concept in Gopherspace, or in nascent Geminispace? How much value does that idea have for a network where the majority of content is very minimally formatted plaintext? Could it ever possibly be worth the risk of introducing something which can be twisted to act as a cookie? Sometimes taking a strong stand against very clearly very bad things (pervasive and uncontrollable tracking) means choosing to live without some nice things that seem harmless on the surface. It's a shame, but that's the way it is. Thankfully it turns out most nice things are actually pretty easy to do without once you get rid of it. > I.e. automated cookie tagging is the equivalent of server driven 61 TRANSIENT CERTIFICATE REQUESTED. Characterising 6x status codes as "server driven" is extremely misleading. The server can only issue *requests* for a certificate. There is no mechanism for the server to just ram one down the client's throat. The client has to opt in, and they can at any point opt-out. If I delete the private key matching a certificate, that's the end of that identity. I'd call that "client driven". If I delete one of your userinfo cookies, the server can recognise my IP and feed me the same value again, resurrecting it. Yes, there's a risk they'll get it wrong if that IP is a pubnix or VPN address, but probabilistic persistent tracking is better than no tracking at all, so they'll try it, and will be right some of the time. > Minus the yak shaving. I guess some yaks are our friends. Cheers, Solderpunk
On Thu, Jun 11, 2020 at 09:02:54AM +0000, solderpunk wrote: > But if it's legitimate for me to declare that the gemini:// URI scheme > does not support userinfo, I'll do it in a flash. This cookie redirect > thought experiment proves that it's far too dangerous, it's just barely > better than an actual HTTP cookie (in that it's not easily sent to third > parties). By my reading of RFC 3986 (s3.2) you explicitly have that right: "Some schemes do not allow the userinfo and/or port subcomponents." > Of course, just saying it's unsupported isn't enough, because servers > can try to do it anyway, so every client now needs to explicitly check > for this and either error out or remove the userinfo. In my experience, an advanced client requires a certain amount of URL munging anyway (at least if you want to pass Sean's test suite). Saying that a client SHOULD remove any userinfo component before initiating a request is not an undue burden. But at the same time it's clearly not required for a minimally functional client. Cheers, Tom
> On Jun 10, 2020, at 22:28, solderpunk <solderpunk at SDF.ORG> wrote: > > against the spirit of the spec Specifications are mechanisms. Tools. Syntax. To be combined in interesting and curious ways. To an end. Spirituality has nothing to do with it. An oldie, but a goodie: "Why specs matter" -- Mark Pilgrim, circa 2004 https://pwn.ersh.io/notes/why_specs_matter/ https://en.wikipedia.org/wiki/Mark_Pilgrim https://web.archive.org/web/20051016203842/http://diveintomark.org/archives /2004/08/16/specs https://github.com/dpk/diveintomark/blob/master/archive-html/74bd6e47732d71 1fafd1fdb131006daae30709cf.html
> On Jun 11, 2020, at 11:02, solderpunk <solderpunk at SDF.ORG> wrote: > > The userinfo approach both survives absolutisation *and* works with a > perfectly static text/gemini file using relative links. It's an > extremely easy and lightweight way to unambiguously track users within > one server, and unlike guessing based off IP (which is also of course > unavoidable) it is robust against multiple users sharing an IP at once. > Of the four approaches outlined above, userinfo clearly has a much > higher "damage inflicted to effort required" ratio than the others. Thanks. That said, this all hinges on automated redirects, beyond end-user control, all opaque to them. This is the crux of the issue. If user-agents MUST-SHOULD prompt for decisions as to whether to follow a redirect, this would be all transparent and under user control. If you truly care about user control and transparency, this is the inflection point.
On 6/11/20 11:32 AM, Petite Abeille wrote: >> On Jun 10, 2020, at 22:28, solderpunk <solderpunk at SDF.ORG> wrote: >> against the spirit of the spec > Specifications are mechanisms. Tools. Syntax. To be combined in interesting and curious ways. To an end. Spirituality has nothing to do with it. A 'spirit' is intentionality, the heart of what a spec is trying to communicate. The tools and syntax serve this end. If you are referring to yourself with the why_specs_matter link, then I would suggest a useful "asshole" would identify these concepts that are contrary to the intentions of gemini and recommend solutions in the spec to prevent them rather than circumventing those intentions.
> On Jun 11, 2020, at 14:03, James Tomasino <tomasino at lavabit.com> wrote: > > A 'spirit' is intentionality, the heart of what a spec is trying to communicate. The tools and syntax serve this end. I would venture only concrete implementations have actual intentionality. On the other hand, how many angels can dance on the head of a pin? > If you are referring to yourself with the why_specs_matter link, then I would suggest a useful "asshole" would identify these concepts that are contrary to the intentions of gemini and recommend solutions in the spec to prevent them rather than circumventing those intentions. Exactly. [2020-06-11T11:55:23.337Z] <@tomasino> ugh, Petite Abeille again Did I overdo it? Apologies. Still, shooting the messenger do not change the facts on the ground. Gemini has 3 basic moving parts: URI, MIME, and TLS. To be useful -as in actionable- the spec should be cognizant of their reach and define clear boundaries if necessary. A prescriptive specification is fine, a touchy-feely one less so.
On Thu, Jun 11, 2020 at 07:58:45PM +1000, Thomas Karpiniec wrote: > By my reading of RFC 3986 (s3.2) you explicitly have that right: > > "Some schemes do not allow the userinfo and/or port subcomponents." Thanks very much for finding that. I realise it must seem ridiculous that I'm building on top of these RFCs without having read then in fine detail. I would *love* to have the time to print out the URI, MIME and TLS RFCs, sit down with a coffee and a pen and go through them all closely, but it's not likely to happen anytime soon. I am grateful to be able to "crowdsource" some details. And this is great news. I will update the spec this weekend - to simplify the client certificate stuff as discussed, but at the same time I will add a new section defining the Gemini URI scheme and explicitly disallowing the userinfo component. Servers receiving a request whose URL contains a userinfo component should respond with "59 BAD REQUEST". Clients should strip userinfo from links in text/gemini documents or status 3x <META> lines. Then this nasty loophole is closed. Cheers, Solderpunk
On Thu, Jun 11, 2020 at 01:32:00PM +0200, Petite Abeille wrote: > An oldie, but a goodie: > > "Why specs matter" > -- Mark Pilgrim, circa 2004 > https://pwn.ersh.io/notes/why_specs_matter/ An enjoyable and short read, thanks! Cheers, Solderpunk
On Thu, Jun 11, 2020 at 01:37:46PM +0200, Petite Abeille wrote: > Thanks. I didn't *mean* that as a compliment, but upon reflection you're right to take it as one. To be frank, your posts often frustrate me or stress me out, but I realise that you are, in fact, performing a valuable service in pointing out loopholes and overlooked details, and this one in particular was a very valuable catch, thankfully easily fixed. I hope to goodness this was the last surprise of this magnitude that you manage to dig up. > That said, this all hinges on automated redirects, beyond end-user control, all opaque to them. This is the crux of the issue. That's true, it's not quite fair to blame this entirely on the generic URI scheme, the issue also highlights the dangers posed by redirects. > If user-agents MUST-SHOULD prompt for decisions as to whether to follow a redirect, this would be all transparent and under user control. Also true, but the case of phishing in the web/email world demonstrates precisely how well relying on users to be able to reliably detect nasty things via manual inspection of URLs works out in practice. In this particular case, given the dubious value of userinfo for Gemini in the first place, it's much simpler and much more reliable to simply remove the threat entirely, than to expect people to catch it themselves. I will consider pushing more strongly for manual intervention in redirects, but I'm very aware that taking this to extremes will inevitably result in training users to approve the follow automatically without a moment's thought. Much better to make redirects themselves as safe as we can. MUST-SHOULDing confirmation for cross-domain redirects might be a good idea, though. Those pose a great risk, with the potential for execrable link shorteners. Cheers, Solderpunk
> On Jun 11, 2020, at 17:09, solderpunk <solderpunk at SDF.ORG> wrote: > > And this is great news. I will update the spec this weekend - to > simplify the client certificate stuff as discussed, but at the same time > I will add a new section defining the Gemini URI scheme and explicitly > disallowing the userinfo component. Cool. May I suggest two further, hmmm, tightenings? (1) Mandate a line length limit for every gemini artifacts, both protocol and text format. 1024 bytes for everything. (2) Normalize all the sigils to <SIGIL><SPACE>. Drop the optional whitespace concoction [<whitespace>].
> On Jun 11, 2020, at 17:09, solderpunk <solderpunk at SDF.ORG> wrote: > >> An oldie, but a goodie: >> >> "Why specs matter" >> -- Mark Pilgrim, circa 2004 >> https://pwn.ersh.io/notes/why_specs_matter/ > > An enjoyable and short read, thanks! You are welcome :)
> On Jun 11, 2020, at 17:25, solderpunk <solderpunk at SDF.ORG> wrote: > >> Thanks. > > I didn't *mean* that as a compliment, but upon reflection you're right > to take it as one. To be frank, your posts often frustrate me or stress > me out, but I realise that you are, in fact, performing a valuable > service in pointing out loopholes and overlooked details, and this one in > particular was a very valuable catch, thankfully easily fixed. I hope to > goodness this was the last surprise of this magnitude that you manage to > dig up. Do not poke the bear :P But do look at TLS fingerprinting. Gemini traffic should blend in with the crowd, and not stand out in any obvious ways.
On Thu, Jun 11, 2020 at 06:02:48PM +0200, Petite Abeille wrote: > Cool. > > May I suggest two further, hmmm, tightenings? > > (1) Mandate a line length limit for every gemini artifacts, both protocol and text format. 1024 bytes for everything. With regard to the protocol, isn't this already the case? >From section 2: ``` Gemini requests are a single CRLF-terminated line with the following structure: <URL><CR><LF> <URL> is a UTF-8 encoded absolute URL, of maximum length 1024 bytes. ``` So, that's requests handled. >From section 3.1: ``` Gemini response headers look like this: <STATUS><SPACE><META><CR><LF> <STATUS> is a two-digit numeric status code, as described below in 3.2 and in Appendix 1. <META> is a UTF-8 encoded string of maximum length 1024 bytes, whose meaning is <STATUS> dependent. ``` So, that's responses handled. What am I forgetting? With regard to lines of text/gemini, that's unfortunately not really compatible with the idea that content should be written with long lines and then wrapped by the client to fit the viewport. It took *months* of discussion and arguing to settle on that convention and now that I've had a chance to see it in action I'm actually pretty fond of it. Having content display cleanly on different devices is quite nice, and almost a pre-requisite for widespread adoption in the modern world (not that widespread adoption is an explicit goal of the project, but there's no reason to stand in the way of it without good cause). I can't think of any way to achieve that property with a short fixed line length that doesn't tremendously complicate rendering. What's the motivation for this in text/gemini? > (2) Normalize all the sigils to <SIGIL><SPACE>. Drop the optional whitespace concoction [<whitespace>]. Does anybody else have strong feelings on this, one way or the other? After the change to the list item definition, this *would* increase consistency in the spec, which is generally a good thing. But dealing with optional whitespace is not exactly difficult for clients to do and I feel like a little bit of flexibility in something designed to be written by humans is not a bad thing... Cheers, Solderpunk
> On Jun 11, 2020, at 19:19, solderpunk <solderpunk at SDF.ORG> wrote: > > What's the motivation for this in text/gemini? Mostly the link line, which contains an URL. If limiting overall line length is a nuisance, perhaps just applying the 1024 limit to the URL itself would do. In term of the spec, this could be stated as ANY URLs, be it in the request, response, or links, MUST be 1024 bytes long at most. Similar to HTML's LITLEN limit, which is 1024 in some contexts - as pointed out by Sean a while back. This would positively constrain the reach of all those marvelous URL schemes you don't approve of, while not eliminating their experimental use altogether :D
---
Previous Thread: [ANN] AV-98 1.0.0 released!
Next Thread: A client SHOULD NOT send the fragment part of a URL to the server?