💾 Archived View for rawtext.club › ~sloum › geminilist › 006927.gmi captured on 2023-11-04 at 12:57:40. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2021-11-30)

-=-=-=-=-=-=-

<-- back to the mailing list

Malicious Links

nervuri nervuri at disroot.org

Fri Jul 16 09:55:08 BST 2021

- - - - - - - - - - - - - - - - - - - 

On Thu, 2021-07-15, mbays wrote:

Better. But I think "display" is still assuming too much about the
client. What about audio-only clients? We could make it "present", but
still we may find that it's too restrictive... what if a client wants to
present only a shortened form of the URI, say without the scheme? Do we
really want to say that it's in contravention of the spec? And so on.

"Display" is used throughout the spec. I'm fine with using a moregeneral term like "present", but maybe a separate issue should be openedfor replacing all instances of "display". And, yes, I do think clientsought to include the scheme, especially those that support multipleprotocols; I don't see this as a blocker.

Really, I don't think this kind of prescriptive text for the details of
how clients should operate belongs in the spec at all.

That's what the specification is: prescriptive text for how clientsshould operate. If the text makes sense, we should add it, and this isa small requirement that brings a big benefit, as with web browsersusing SameSite by default.

Perhaps it would make more sense to add some general discussion about
this issue, either to the spec or to best-practices.gmi, saying that
clients should ensure that a client certificate is used only when it's
clear that the user intends it to be, and pointing out these cases where
it might not be clear (links and redirects into the scope of
a certificate). Then let client authors decide how to implement this in
whatever way makes most sense for their particular clients.

This would also be good. As I wrote on GitLab, «"MUST" is what I thinkmakes the most sense, as it provides the most protection without anyserious downside. But if I'm wrong about that, then taking it down to"SHOULD", or putting it into the best practices document, is still waybetter than nothing.»

So, here's the next iteration of the text:

Before following a URI which is in scope of a client certificate from a URI outside of that scope, clients MUST/SHOULD display the target URI and what client certificate would be used to connect to it.

Doing this will help protect against Cross-Site Request Forgery (CSRF). It applies to: * following a link on a page * going through one or more redirects

We could expand on this with a short explanation of CSRF and maybe anexample.