Does the Gemini protocol support redirection to the external scheme?
e.g. gemini:// -> gopher://
Mar 27 Β· 3 months ago
21 Comments β
π¦ zzo38 Β· Mar 27 at 22:31:
I think you can redirect to any URL, although clients probably should not automatically handle them.
π Not4uffinonMobile Β· Mar 28 at 03:49:
Yes, does seem as though that works.
π» ps [OP] Β· Mar 28 at 03:53:
I want the prove from specification, if someone is able to find it :)
Improvisation around that may cause potential privacy and security issues for the client user.
π clseibold Β· Mar 28 at 04:37:
@ps If you go to the redirection section of the spec, it says nothing about whether or not you can or cannot use a different scheme in redirect URLs. Redirect URLs are also allowed to be absolute. This means redirecting to a different scheme is allowed.
It also, however, does not make any recommendations or obligations to clients to accept or reject them. So, this means clients can choose whatever they want.
Anyways, Titan uses scheme redirects to move you from a titan edit url back to a gemini URL, so at the very least scheme redirects should be allowed for some protocols.
Changing the scheme doesn't cause privacy issues unless you are switching to a different hostname, or including a fragment or query string in the redirect. The last two are disallowed. For switching to a different hostname, instead of disallowing that, you could just prompt the user.
Sometimes redirecting to a different hostname is useful if one server was split into two different servers (or, two different hostnames). For example, I moved my religious texts sections from auragem.ddns.net to scholasticdiversity.us.to, so the original links to them on auragem redirect to scholasticdiversity.
This is why I believe this should be allowed by clients, even if they have to prompt users about it.
π» ps [OP] Β· Mar 28 at 06:16:
@clseibold, thanks for your detailed explanation.
I plan to make this redirection optional in a future Yoda release. At this moment, it blocks redirection attempts on host name changes and requires manual confirmation to continue. However, this is my own improvisation, as I feel uncomfortable expecting the client to redirect me somewhere outside.
On another note, with the paranoid approach of blocking everything (even auto-loading images), I wonder about the availability of the redirection feature in the Gemini protocol.
Perhaps the TOFU model provides a partial answer.
π» ps [OP] Β· Mar 28 at 06:21:
@clseibold, regarding the Titan <-> Gemini redirection, it is an exception, and there is nothing about this in the specification either.
A scheme change may lead to external app openings, which could involve HTTP in a browser, where the user (e.g. connected over TOR) could be de-anonymized by visiting certain resources. Therefore, the scheme change is potentially unsafe, even more so than a hostname change, imho.
π clseibold Β· Mar 28 at 06:49:
@ps That's a good point. But I would expect a smallnet/gemini browser to allow schemes that the browser can handle that aren't like HTTP, and to prompt the user for schemes that would open an external app (which even Firefox does), or that would redirect to HTTP.
Like, you have to think about usability and what the users would want. You can't just broadly disallow everything because of a few specific security hypotheticals.
If a particular protocol allows automatic background connections (like in HTTP/HTML/JS) or has identifying information (like HTTP), then prompt for those specific schemes. Better yet, make this be the default and then just allow the safe schemes that your browser supports to automatically go through.
This solution is not really complicated to get to, imo. A simple allow list with the schemes "gemini", "spartan", "titan", "gopher", "gophers", "scroll", and "nex" would suffice. All other schemes outside of this allowlist would prompt the user.
The redirection from Titan to Gemini of course wouldn't be in the Gemini spec, it would be in the Titan spec. And I believe it is mentioned there, but I haven't checked.
π» ps [OP] Β· Mar 28 at 07:09:
The redirection from Titan to Gemini of course wouldn't be in the Gemini spec, it would be in the Titan spec. And I believe it is mentioned there, but I haven't checked.
I didn't find that line when I worked with its features. There are a few words about the Titan request returning a Gemini response, but there is nothing about handling redirection, and their capsule is offline all the time.
I just remembered that there were some external references to the common URL specifications. I'm not sure that the URL standard includes redirection policies.
π clseibold Β· Mar 28 at 07:19:
@ps You're right, Titan's spec doesn't have it. Just another example of Titan's spec not being the best, lol. This is where being overly anal about specs just makes the entire user experience awful. Do sane things. The sane thing is to allow a redirect back to gemini after somebody edits a Titan resource, and even Bubble does this.
Unfortunately, we have to take liberties when specs are too ambiguous or not well written. But this is where we have to look at what the community is doing, and then what the community expects, as secondary and tertiary sources.
π» ps [OP] Β· Mar 28 at 07:25:
Web browsers were the protocol makers in those times. That's what we have now :)
π mbays Β· Mar 28 at 08:29:
See the cross-protocol redirects section in the best practices document.
β geminiprotocol.net/docs/best-practices.gmi
π clseibold Β· Mar 28 at 08:33:
@ps I don't agree. That's overly broad. What we have now is *nothing* like the mess of browsers in the early 2000s. We don't have JS, iframes, CSS, referer headers, HTML style tags.
Like, obligations of redirects in the spec are liberal. That doesn't automatically make Gemini as bad as the web. You're kinda comparing grapefruits to grapes, imo.
π½ spc476 Β· Mar 28 at 09:03:
I wonder about the availability of the redirection feature in the Gemini protocol.
@ps, I was responsible for adding redirects to Gemini. It happened because a page I bookmarked in Gopher moved, and it took me way too long to find that it had moved to a new location because Gopher doesn't support redirections. And given that Gemini was inspired by Gopher, I felt having redirection in Gemini would be A Good Thing.
π» ps [OP] Β· Apr 01 at 07:33:
@spc476 I found that redirection is a kind of web evil, similar to AJAX, as it performs tasks on behalf of the user. If this feature is already available, the only way to specify what constitutes an external redirection: changing the scheme, host name, port including all possible combinations. This is important because different client implementations can lead users through various, unexpected logic.
π½ spc476 Β· Apr 02 at 01:53:
@ps: A redirect is nothing like AJAX. It's just the server notifying the client that hey, this resource moved to this new location. Do with that what you will. AJAX is actual CODE that the server sends to the client to execute. Completely different.
π¦ zzo38 Β· Apr 02 at 05:37:
Whatever the default settings may be, it can be made to be configurable by the user. For example, the user may configure it to always ask for all redirects and never automatically redirect. (Some implementations might just never automatically redirect at all and always ask, regardless of that, if you want to make it more simplified, that you don't have to figure out if it should be considered valid or not.)
π» ps [OP] Β· Apr 02 at 07:19:
@spc476
AJAX is actual CODE that the server sends
REDIRECT is actual CODE that the server sends
Both are designed to execute without user confirmation, relying on the client's trust in the server.
π» ps [OP] Β· Apr 02 at 07:23:
@zzo38 of course, I can customize even Firefox for the Web to meet my needs, but I'm looking for Gemini specifications that client developers should follow to avoid creating privacy vulnerabilities. This protocol is designed with those privacy goals in mind, and it even prevents me from viewing images without manually following their URLs.
But that is only my opinion, thanks for your answers.
π clseibold Β· Apr 02 at 10:26:
@ps Let me ask you a series of questions:
1. Can Gemini redirects force your client to send your IP to 10 different servers at once?
2. Can one Gemini redirect modify your address bar's input multiple times in a row?
3. Can Gemini redirects modify your browser's past history?
4. Can Gemini redirects store cookies?
5. Can Gemini redirects access any protocol that it chooses, including HTTP?
6. Can Gemini redirects force your client to upload any specific data, outside of TLS/tcp connection data, to any number of servers?
7. Can Gemini redirects force your client to access *any* server whatsoever without changing your client's UI state?
8. Can Gemini redirects modify the previous page your client was at?
9. Can Gemini redirects modify the page they are redirecting your client to?
10. Can Gemini redirects pass a token/id to the page they are redirecting your client to?
11. Can Gemini redirects create popups, new windows, or new tabs?
12. Can Gemini redirects create infinite loops?
π» ps [OP] Β· Apr 02 at 10:34:
@clseibold, for me, itβs the same: it doesn't matter how the client handles the response data - whether in the body with AJAX or in the header with redirection. JavaScript also implements this feature in web browsers, and I dislike that behavior.
From the subject, I gathered the following points:
- the Gemini protocol does not restrict external redirection.
- it also does not specify what an external URL is, which makes it difficult to handle canonically for privacy purposes.
In conclusion, I am more interested in the Gopher protocol now than in Gemini because of this. This is my personal point of view; I disregard the logic if it takes the unspecified form.
π clseibold Β· Apr 02 at 10:36:
@ps Please answer my questions. You're trying to compare AJAX to Gemini redirects as if they supported the *exact* same features and have the *exact* same security problems.
So prove it.
@ps According to your definition, literally every single response code is "code" that is executed by the client. The problem with your approach is that you are not differentiating between a spectrum of types of execution. Comparing AJAX and redirects as if they had the same level of security problems is just dumb. You're being extremely illogical by engaging in this "all or nothing" fallacy.
This is literally the problem with saying "everything done by a client should not be done without the user's permission". How do you define the user's permission? What about an error code response that is sent back to the client. Was that done *with* the user's "permission"? I didn't want an error code, I just typed in an incorrect path to auragem thinking it was correct. I wasn't *asking* the server for an error code! OR is the fact that I *expect* an error code for an incorrect path I typed in part of the *permission structure* of the UX of the protocol?!?
It's obviously the last one. Which gets to the entire point - protocols should do what is expected of them, no more, no less. *That* is the ultimate point. If a user expects a protocol has redirects, then redirects are perfectly fine and are not a security problem when well defined.
Redirects are expected, and they are also easy to get notification for. AJAX does things that are not expected, that can do things *without* notifying the user via UI, and the things it can do is *A LOT* more than just redirecting the user.
They are not even CLOSE to the same thing, and you're actively beign disingenuous by implying that they are. It's a whole lot of FUD.
@ps The problem with your argument is not that it is about redirects having some security problems, it's your utterly ridiculous claim that they are one and equal in all aspects to AJAX.
The question that is most apt to your argument is this: Can Gemini redirects upload JSON data to a server?
Considering that AJAX is about uploading data to servers or requesting information in the background, not redirecting browsers, they don't even support the same functionality.
Somebody already linked to you the Gemini best practices document about redirects. Honestly, I don't know what more you want. If you're overly-paranoid about security, then I can't imagine why you are on the internet in the first place rather than home alone with a tin foil hat on.
And yes, I'm suggesting you're being unrealistically obtuse about the security stuff here, and it's not healthy.
Source