[tech] Integrity checks for Gemini pages

[nothien at uber.space]

nervuri <nervuri@disroot.org> wrote:
> On Fri, 2021-05-21, nothien@uber.space wrote:
> >If servers have not yet been fixed to use close_notify, then there's
> >no hope that they would implement any new companion specs /
> >technologies for providing integrity.
> 
> My suggestions don't entail changes in server software.

But your suggestions are patch-up solutions over issues with server
software.  Instead of adding more complexity into the situation, push
for better (more correct) server software.

> >If a user of such a server wants integrity, then they should request
> >it of the maintainer of the server code, or switch to a different
> >server; there are many out there with the same features.
> 
> The user of a pubnix or a flounder-style hosting service would likely
> not be in a position to determine what server is used.  But they would
> be able to create well-known files or append hash fragments to a few
> links.

But they can (and should!) request their providers to update their
software.  Users should never have to pay for the faults of their server
providers anyways.

> The idea of hash fragments for third-party links would be especially
> interesting to explore, I think.

They would only be feasible for static files, such as tarballs etc. that
never change, as otherwise any changes (e.g. fixing typos) would break
hash fragments from third-party sites to the current one.  The issue
thus becomes that it may be misused (i.e. used in the wrong contexts);
there is no way to stop this from happening, and it would only add more
pain to the situation.  Better to rely on explicit hash files in these
situations, as is already the convention.

> >Integrity on the server-side is out of the scope of Gemini
> 
> As are many features of current Gemini clients.

Such as?  I'm considering specifically the communication of data over
the network via the Gemini protocol.  Gemini clients obviously have more
things to do.

~aravk | ~nothien