💾 Archived View for skyjake.fi › gemlog › 2023-06_i-am-spartacus.gmi captured on 2023-11-14 at 07:48:22. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-06-14)
-=-=-=-=-=-=-
📅 2023-06-12
After a few days of musing, I am of the opinion that Morgan's Gemini identity proposals are fundamentally flawed and I am not going to implement them in Bubble.
CircaDian: Identity Again: Visual Hashing
There are two core technical issues:
1) Using the same client certificate on many servers enables the servers to track the user.
2) Hashes, of SHA or visual persuasion, are not trustworthy when shown on a Gemtext page.
By "tracking" I mean that a server that you did not contact can be made aware of your presence and activity on the server you _did_ contact, without your knowledge. The only way to prevent this is for you to associate a unique and separate client certificate with each server. Then even if the servers secretly share hashes or entire certificates (sans private key) with each other, they cannot tell which users are the same ones. (Malicious servers would share IP addresses, too, but if you find that worrisome, you are probably using solutions like VPN and Torsocks.)
Even if this would never happen in Geminispace in practice, because we are generally well-meaning and courteous, it must be accounted for or Gemini cannot be taken seriously. Another point in Gemini's favor is that the server software landscape is very heterogenous: even if some servers share information with each other, the vast majority will not be participating in this kind of schemes.
When it comes to certificate hashes, a further problem is that relying on information that a server displays on a page requires trusting the server to not forge that information. After all, you can send whatever content you want on a page. Trusting data received from a remote server must have a solid technological basis, like cryptography. Relying on a gentleman's agreement is not a valid security model.
Ok, but what if the server is open source? Assuming everyone wants to open-source their servers, sure, you could check the code and see how the response is constructed, but you can't tell if that version of the code is actually running on the server. You can only have trust in the admin.
How do you solve the issue of many Spartacuses, then? (Spartacusi?) The solution to proving your identity must be technological and simple, cannot be forged, and not require special tools or client/server support, nor can it require reusing client certificates on many servers. This leaves one option:
Two-way links. This shows that you have control of both endpoints. Anyone with a regular Gemini client (and servers, too) can fetch the links and verify that they indeed point to each other. This allows extending the "web of trust" from your own capsule to a community capsule, or doing so between multiple accounts, if you don't have a capsule.
For those who want to show additional proof of their identity, PGP is an established and quite well-known solution, although it can be cumbersome in practice. Anything you sign with PGP can be trusted to be valid information from the owner of the associated key pair.
In the end, security and privacy in Gemini is based on the ownership of private keys. It is up to you to keep those as safe as you can, and be mindful of what you share with remote servers.
CC-BY-SA 4.0