[tech] Integrity checks for Gemini pages

[nothien at uber.space]

nervuri <nervuri at disroot.org> wrote:
> We can't rely on close_notify, unfortunately.  According to Lupa [1],
> "33.3 % of URLs do NOT send a proper TLS shutdown (application close).
> Even 26.7 % of those who return status 20 are in that case."
> 
> [1] gemini://gemini.bortzmeyer.org/software/lupa/stats.gmi

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.  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.

> >And every single authenticated encryption method provided with TLS
> >ensures that the communicated data is the same at both ends - bit flips
> >and the like are detected and such malformed packets are dropped
> >appropriately.  One of the mechanisms for this verification is Poly1305
> >- check it out if you're interested in how and why these work.
> 
> You're referring to the transfer, but data may be corrupted
> server-side, on disk or in RAM.

Integrity on the server-side is out of the scope of Gemini, and is
really an implementation detail.  If a server operator decides that they
need to worry about on-disk integrity, then there are already good
solutions for that (e.g. RAID); and in-RAM corruption is so rare that I
don't think that adding a whole Gemini feature is worth it - it would be
so rare that the costs of adding it (in terms of computation and network
transfer) outweigh the benefits of detecting it.  In addition, in most
cases of on-disk or in-RAM corruption, the end user will easily be able
to tell that something went wrong, and if they find that it's a
consisent issue, then they can mail the server operator and let them
know.

~aravk | ~nothien