[tech] Integrity checks for Gemini pages

nervuri nervuri at disroot.org
Sun May 23 13:20:35 BST 2021
On Sat, 2021-05-22, nothien@uber.space wrote:
>> 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.

Mismatches can be handled gracefully in the UI - a non-intrusive
notification for whoever is interested.  Hashes would be used rarely
anyway.

> Better to rely on explicit hash files in these situations, as is
> already the convention.

As you say, the solution already exists.  What I'm looking for are ways
to make verifying hashes (and signatures) more convenient for end-users.

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

Subscribing to pages, for example [1].  This is done by storing the hash
of a page, then fetching it periodically and notifying the user if it
changes.  Vaguely similar to what I'm suggesting.

[1] https://github.com/makeworld-the-better-one/amfora/wiki/Subscriptions#pages

Anyway, no point dragging on.  The niche for this thing may be too small
to justify the implementation effort, but if anyone likes the idea, they
are free to code it.  I might do it at some point.


Archive home | About this archive