So is there any downside to re-using the same certificuite on multiple sites? In theory would it allow two severs communicating to realize that i am the same user and thus track me? Lagrange makes it very easy to use the same certifucute and i feel like making new ones for every site would be a little cluttered. If i should be using a diferent one on each, wouldn't it be best if lagrange made the process less manual?

Jul 16 · 5 months ago

13 Comments ↓

There is one big down side: security.

If you have one cert used everywhere then when one place is compromised they all are. If you have to replace a key you have to do it everywhere.

Yeah, there are downsides to using the same certificate everywhere, however in practice the chances of anything bad happening are pretty small. Server operators have very little incentive to start tracking people, for instance. Losing the private key is probably the biggest practical problem.

It is certainly unwieldy to create separate certificates for every site, and I suppose a feature to automate that could make sense, although it would necessitate some improvements to how Lagrange manages the keys for you (e.g., they should primarily be stored in a secure keychain, unlike currently).

For the time being, I recommend creating a handful of identities based on usage and privacy needs. You could have one for casual Gemini games, one for social sites, and a unique one for your personal capsule.

yeah, if you have to many identities you'll eventually forget who you really are 😅

and about tracking ... I thought on making a script to track my capsules hits but the truth is I really don't care how many people visit it and I believe that a lot of geminauts feel this way

@skyjake: I think this is an area where the otherwise excellent Lagrange gets it wrong. There are almost no good uses for sharing an identity across multiple sites. In fact, I'm not sure there's a single use case for doing so in the entirety of Geminispace at the moment. (Please correct me if I'm wrong!) I wouldn't even think of what you generate as an "identity" really: It's better thought of as a passkey.

The default should be to generate a fresh passkey for each site. This would prevent tracking, and it would not compromise functionality for the user in any way. The UI would need to reworked, but the end result would be simpler and more usable. (I can elaborate, if desired.)

@skyjake: Thinking about this just a little more, I think the main thing I'd like to see is identity/passkey organization by site rather than in a flat list. When I go to change identities for a site, I should see only the identities specific to that site by default. I also have no real interest in naming identities for sites most of the time: I just want the name to be the site for which it is intended. One tap/click should be all that's needed to make a new identity for a site in most cases. Editing a passkey should allow you to add additional sites if desired, similar to how most password managers work.

It's possible I'm missing something here. Just thinking out loud, in large part.

@repeater I don't disagree in that abstracting the client certificates further would improve UX. The current implementation is a really thin UI over the plain TLS client certificates, which has the benefit of allowing people to use manually or externally generated certificates easily, just by putting PEM files in the right directory.

However, higher abstractions come with certain assumptions about how the client certificates are to be used. I don't really want the client to impose a certain usage pattern. An optional automatic identity (or "passkey") feature could be useful, but since there only is a handful of capsules where you'd realistically want to use a certificate, it doesn't seem like a worthwhile time investment to implement this.

@repeater The fields in the client certificate (like the common name) are important to some Gemini services, like games where you'd declare your player name via the certificate (e.g., Spellbinding).

@skyjake: I think I'm basically just asking for a UI very similar to a typical password manager, where passkeys are freshly generated for each site the same way passwords should be. That would probably be ideal.

I can't even begin to justify the work required to implement such a thing given how few sites can be logged into at the moment anyway though, so…perhaps you did the right thing after all, the more I think about it! I'll stop my ranting now.

When it comes to the identities sidebar, yeah it's pretty rudimentary. It becomes cumbersome if you have lots of certificates, and definitely should be worked on.

@skyjake: Ah, didn't mean to race you on the replies. Sorry about that.

I was unaware that some sites use the common name in the certificate. That certainly changes things a bit. Thank you for the correction there, and for your thoughts in general.

@repeater & skyjake: good idea but please don't forget the other browsers. So if say there is a common format for cert per site, I could copy e.g. a folder into my Gemini.koplugin or Amfora or all the other browsers people use.

It sounds to my pleeb brain as a formal spec change, or will devs start using these per site folders for per site scripts, per site stylesheets, etc.

Sites that use certificates should probably mention what they expect the certificate to contain (including optional things). I agree that the default should be to create a new certificate and key per site (and I think should probably use the same key algorithm and signature algorithm as the server's certificate by default since this is most likely to be compatible with the server), but it should be possible to import any X.509 certificate that you want to as long as you have the corresponding private key.

I did make up a format for transfering certificates, bookmarks, and other things between different browsers, although it is not currently in use. However, if the formats used by other browsers are known, a program can be written to convert to/from the format.

According to gemini spec:

Clients MUST NOT automatically generate a client certificate and use it to repeat the request without the active involvement of the user. Clients MUST NOT use a client certificate generated in response to this status code for a request to a different host, a different port, or a path on the same host and port which is above the the path of the URL in the original request unless directed to do so by the user.

Unless I'm misinterpreting this, the protocol already enforces different client certificates for different hosts. And that would be great news from a privacy standpoint, because otherwise using the same client certificate everywhere would be an absolutely distinct fingerprint, not worthy of a protocol that claims to address privacy issues!

Thank you very much for bringing up this point avan. I will now be using a different (certificate-free) browser for regular browsing, than I do for posting.

@zzo38: From what I'm reading, the spec seems to be all but set in stone, so your voluntary approach looks like the best hope.