💾 Archived View for bbs.geminispace.org › u › cquenelle › 1883 captured on 2023-07-22 at 17:49:22. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
So the model would be like this: I see 'fred' on 'site1' and I think he's cool, so I go to his profile page and see that he is 'public' and my client offers to store his handle and cert in my client's "address book". Then if I go to 'site2' and click on fred's profile page, my client can say "BTW This is 'fred' from site1" It would be nice if clients didn't automatically save all the certs they encounter. But for people that you like, or hate, or like-to-hate, you can click on them to keep track of them, if they don't mind.
2023-06-13 · 6 weeks ago
Thanks @cquenelle :)
That pretty much lines up with the "visual hash" idea--except that with visual hashes the idea is to store them mostly in your brain ;) with new client support that need goes away, and so there's no need for the visual part, it can just be the sha1 or a hash of the sha1.
For the most part though I'm skeptical about adding anything new to the client--because there are a lot of clients, it needs a very strong level of agreement, possibly even it needs to be in the Gemini spec, which seems unlikely to happen.
I'm really looking for "zero client changes, almost zero user effort, almost zero server effort". Which may be impossible ;)
Thanks.
(I’m about to make some very strong claims about things I’m not 100% sure about, so please let me know if I’m missing something!)
This problem strikes me as having a familiar shape: attempting to manage the allocation of limited, valuable resources (unique personal identifiers in this instance) amongst a set of parties who have no reason to trust each other 𝘢 𝘱𝘳𝘪𝘰𝘳𝘪. Using a TOFU scheme to underpin a Gemini identity system seems to borrow some similar drawbacks from cryptocurrency systems, too, like having no real provision for users to rekey after a compromise without losing their claim on their resources. I suspect that without some trusted parties a Gemini identity system can only function by accepting some of the rigid, anti-social trade-offs that are commonly associated with cryptocurrency nowadays.
I’ve been thinking about two silly (but also kind of interesting, IMO) alternative approaches:
Sorry if this was too far off topic.
2023-06-18 · 5 weeks ago
Thanks @totroptof :) some interesting thoughts.
Bubble has a mechanism to set a temporary password to allow you to link a new certificate, but that doesn't help with recovery if you lose a certificate. I guess today you'd email Skyjake.
Email addresses and domains will probably be used as fallback proof of identity when certificates get lost.
I suppose the ideal setup today is, you should export and back up your certificates. Backup is hard to get right, it's a lot to ask of users.
Account recovery is a really hard problem. I suppose we are not going to have a centralized service where you can recover access via a code sent to your phone :)
2023-06-19 · 5 weeks ago
@Morgan: Reading your reply, I’ve realised I wasn’t really clear on what point I was trying to make. This is my second attempt after thinking about it for a bit 🙂
A motif I’ve noticed browsing some of the more technical writings in Geminispace is that many Geminauts don’t really seem to take security that seriously. That’s not necessarily a criticism; I think there are reasonable justifications for this position, particularly in the context of Geminispace. However, if the goal is to build a system that addresses some of the attacks made possible (in part) by this lack of security culture, I believe a system that isn’t designed for inevitable key compromise will fail to meet its goals.
To clarify, I don’t think “design[ing] for inevitable key compromise” means recovery codes sent by SMS. Looking at operators elsewhere on the internet, one can observe things like Let’s Encrypt restricting certificate validity to a maximum of three months and wide deployment of ratcheting key agreement systems in chat applications. To me (and please note, I’m no cryptographer), designing for key compromise looks like a focus on ephemeral (or at least relatively temporally limited) keys, regular rekeying and per-device keys. I’d argue that a system which requires users to export and back up private keys is the exact opposite, since
In the writings of solderpunk and others on the topic of Gemini I perceive a philosophy that’s essentially humanist with a particular de-emphasis on technocentric approaches. The “solutions” to the identity problem I posed in my last comment, as impractical as they are, were an attempt to try and examine the problem space in a way that seemed more consistent with this philosophy.¹
I hope that’s a bit clearer (it is for me at least :P)
Footnotes
─────────
[1] I don’t mean to imply an endorsement of those values; in fact, it’s a topic I intend to glog about at some point. 😉
Thanks @totroptof
Some more thoughts from me, although I'm no expert either :)
I think short key expiry is a distraction--it seems like what you want is secure key changes, backup proof of identity and intrusion detection. All of these are hard :)
But not entirely hopeless.
For example, you could have a second key pair that you print and keep only on paper. It's your emergency key in case you need to change the live one or regain control of it.
So that maybe covers secure key changes and backup proof of identity.
It would be nice to have intrusion detection, but I don't see how. For example, a server could notice that you are acessing your account from the other side of the world to where you usually are--by IP address--and ask for confirmation before trusting your cert from your new location. This would catch a lot of compromised keys. But it requires a level of sophisticated tracking and centralization unlikely to come to Gemini. Not saying that's a bad thing--just means it's a different problem to web account security.
I suppose "here is the latest activity associated with your cert" is a form of intrusion detection we could have on Gemini in a distributed way. Then if you see activity you don't recognize you can trigger a key change using your offline key. Somehow.
Fun stuff.
I̶n̶ ̶c̶a̶s̶e̶ ̶I̶ ̶f̶a̶t̶-̶f̶i̶n̶g̶e̶r̶ ̶s̶o̶m̶e̶t̶h̶i̶n̶g̶ ̶a̶n̶d̶ ̶a̶c̶c̶i̶d̶e̶n̶t̶a̶l̶l̶y̶ ̶p̶o̶s̶t̶ ̶t̶h̶i̶s̶ ̶a̶s̶ ̶a̶ ̶c̶o̶m̶m̶e̶n̶t̶ ̶i̶n̶s̶t̶e̶a̶d̶ ̶o̶f̶ ̶a̶ ̶d̶r̶a̶f̶t̶:̶ ̶t̶h̶i̶s̶ ̶i̶s̶ ̶j̶u̶s̶t̶ ̶m̶e̶ ̶j̶o̶t̶t̶i̶n̶g̶ ̶d̶o̶w̶n̶ ̶s̶o̶m̶e̶ ̶p̶o̶i̶n̶t̶s̶ ̶t̶o̶ ̶t̶h̶i̶n̶k̶ ̶a̶b̶o̶u̶t̶ ̶:̶)̶
Incredibly, exactly that happened. Sorry 😵💫
2023-06-20 · 5 weeks ago
No worries :)
Gemini Identity — @Morgan has a prototype implementation of an identity service for Gemini. This is certainly interesting! Some quick thoughts: If this is something that people want to use, it should not rely on a single central server. Anyone should be able to self-host their identity service and servers should not assume a default one. How does this mesh with people not wanting to be tracked across...