mbays mbays at sdf.org
Sat Jul 10 13:36:25 BST 2021
- - - - - - - - - - - - - - - - - - -
Malicious Gemini pages (or parts thereof) can contain links to such
locations. Depending upon the user's Gemini client configuration, it
may not show them the URL they are going to (e.g. Amfora, I think), and
they may accidentally delete their account at gemini://example.org (or
perform any other action involuntarily) this way.
I think you've hit the core of the problem there. I'd say this is a problem to deal with on the client side, not on the server side, and certainly not by changing the protocol. Clients should get some sort of explicit user authorisation before applying a client certificate to the destination of a cross-site link, e.g. by showing the full link, or by asking for confirmation.
Sometimes "cross-site" is too restrictive. To deal with multi-user sites, the rule should probably really be that a client certificate is only automatically applied to the destination of a link if it's already being applied at the source, because they're both below some common root where the certificate is active. That still leaves the case of interactive systems which include user-submitted links... probably that is a case where the system should be filtering those links server-side.-------------- next part --------------A non-text attachment was scrubbed...Name: signature.ascType: application/pgp-signatureSize: 195 bytesDesc: not availableURL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210710/c287e4a2/attachment.sig>