It was thus said that the Great solderpunk once stated: > > Is this behaviour really desirable? > > > > I vote for no. The text/gemini files already support links to > > non-gemini URLs. Allowing server-directed redirects to non-gemini URLs > > would simply mean that I could no longer be sure that a gemini:// URL > > would access a gemini resource. Meaning that I could no longer be sure > > that the transaction is encrypted. And that's just with gopher - the > > server could make all sorts of surprising things happen on my computer > > if the client happens to support other protocols. > > Hmm, good question! > > I share the intuition that cross-protocol redirects violate the > principle of least surpise, and also make URLs non-transparent. I mean, > redirects do that to some extent anyway, which is why some clients (like > Bombadillo) request explicit confirmation before following any (I may > add this as a user-specifiable option to AV-98), but cross-protocol > redirects are arguably as bad as it gets. > > I think I'd be happy to explicitly forbid these in the spec, unless > somebody can think of a compelling legitimate use case? Possible actions: client denies the redirect client denies redirects to non TLS-protocols otherwise, redirects client asks to redirect or not client asks to redirect to non-TLS protocol, othersise redirects, client warns user about redirect client warns user about redirect to non-TLS protocol client does redirect I think that covers all possible actions. If it were left up to me, I would probably say "ask for redirect to non-TLS, otherwise, warn (or mention) about redirect". -spc
---
Previous in thread (12 of 17): 🗣️ Bradley D. Thornton (Bradley (a) NorthTech.US)
Next in thread (14 of 17): 🗣️ solderpunk (solderpunk (a) SDF.ORG)