Malicious Links

ew.gemini ew.gemini at
Sun Jul 11 07:24:26 BST 2021


gemproj at writes:

>  Hello,
>  Chris Brannon <chris at> writes:
>  > nothien at writes:
>  >
>  >> In Gemini, the restriction that information can only be sent to a server
>  >> by performing a request is considered a feature.  However, this can
>  >> backfire by removing the need for user interaction, even when it is
>  >> absolutely necessary.  Below, I provide an example to show why this
>  >> feature, combined with the existence of malicious links, can prevent (or
>  >> at least hinder) the sole use of TLS certificates in account-based sites
>  >> on Gemini.
>  >
>  > I think having destructive operations (create, update, delete) running
>  > over Gemini is probably a mistake to begin with, because it will lead
>  > down the path of trying to build yet another application platform on top
>  > of yet another document delivery system.  They tried that trick in the
>  > 90s.  Sadly it's still with us, and it's called the WWW.
>  Full ACK!
>  ~ew

> Isn't that basically what all applications (that are capable
> of any state change) do essentially? Build an application
> layer on top of a protocol? If you remove Gemini, you got TCP
> and UDP, and then IP.

> If Gemini permits something but doesn't have it out of the
> box, people will create another layer. It's natural I believe
> 🤷‍♀️

As far as I can tell, you can build anything on top of pretty
much anything sending and receiving data between two points.
However, that does not imply, it is a good idea.

gemini the protocol per se is a way to serve file content.

Apparently a lot of people think, but how can I make it do X or
Y too? And in my not so humble opinion, there are protocols
better suited for some or these things. Take "uploading" text.
There is sftp or scp at least. It requires an account on the
receiving side. Yes, well, imho that's a feature and not a
shortcoming. ymmv.


Keep it simple!

More information about the Gemini mailing list