💾 Archived View for jsreed5.org › log › 2023 › 202306 › 20230616-privacy-in-gemini-revisited.gmi captured on 2024-08-18 at 17:56:20. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-06-16)
-=-=-=-=-=-=-
---
Last week Morgan prompted some discussion about identity in Gemini,^ with a proposal for protocol-wide identification and verification that a username corresponds to the same person across multiple capsules. In short, Morgan proposed a central (though not necessarily centralized) identity service in Gemini.
The issue cuts to the heart of a key question in Gemini, and indeed in any public space: how can one verify that someone is who he claims to be? If two accounts on two different capsules use the same name, can one be sure they are owned by the same person?
A fundamental difference between the Web and Gemini is in their authentication mechanisms. Most Web sites and applications use a password, while on Gemini, the norm is to use client certificates. Passwords are rarely unique; determining that an account has a given password is often not enough to conclude that the account belongs to a given person. In contrast, the cryptographic data in a client certificate makes it a unique piece of property, and as long as that certificate is store securely, it can be used to positively identify a user. This makes a client certificate a much more powerful identity tool than a password, but it also means privacy becomes harder to maintain.
I did not participate in the lengthy discussion about Morgan's proposal on BBS, but I wrote a few months ago about my own privacy concerns within the Gemini protocol.^^ Gemini uses a client-server model, and as such the client and server can do things with exchanged data independently from one another. Once a client passes information to a server, such as a certificate or inputted data, the client is powerless to stop the server from doing whatever it pleases with that data. In particular, servers can choose to share user certificates with each other, or with a user "directory" service that stores cert data and builds profiles based on servers that request information about that data. This can be done without user knowledge or consent, and nothing inherent in the Gemini protocol can stop it. Only the good will of capsule operators holds back the surveillance machine infecting the modern Web.
Skyjake weighed in on Morgan's proposal on Monday, stating that it would not be implemented in BBS server-side.^^^ He raised a second concern I hadn't thought of: servers can forge information such as hashes or randomart. Suppose a user makes an account on a capsule that publishes the SHA256 hash of the user's client certificate; it would be trivial for a malicious actor to create a capsule claiming ownership of the certificate with that hash. Skyjake noted that this scenario can be mitigated by showing that one has control over both endpoints. I do so by listing my username on Station and BBS on my capsule and linking my capsule on Station and BBS.
Privacy and anonymity are not built-in to Gemini, and they should not be assumed. All it takes is for someone, well-meaning or otherwise, to create a repository of information that can allow others to monitor your activity cross-capsule. To date, the only real method I know of to enforce privacy on Gemini is to use a different certificate on each site.
^^ Thoughts on Privacy Exploits in Gemini
^^^ I am Spartacus — Anonymous Identities on Gemini
---
[Last updated: 2023-06-16]