💾 Archived View for bbs.geminispace.org › u › Morgan › 1828 captured on 2023-09-08 at 18:07:09. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-07-22)
-=-=-=-=-=-=-
Hi everyone!
I have refined the visual hash idea in a new post, please see what you think.
— Identity Again: Visual Hashing
The idea is to do as much as possible with no new servers at all.
Thanks :)
2023-06-11 · 3 months ago
I’ve linked my BBS and Station identities without any fancy crypto: made the profile pages include a link to each other.
It’s the same system that works for confirming profile links in Mastodon.
2023-06-12 · 3 months ago
Thanks @emilis!
That does indeed accomplish the same thing--but does not seem 100% satisfactory/scalable.
The problem I see is that as the number of sites grows, the complexity grows; you'd have to link all sites from all sites, or arrange that there is a chain of crosslinks :) ... as the complexity grows, it gets easier to confuse people. I could register somewhere new with your name, copy the list of links, and people may simply not notice that there is no backlink to this one.
Having a capsule makes it a bit clearer as you can link to everything from the capsule, but still it's the case that if you link from a fake identity to the capsule then people might not notice there's no backlink. You could also link from the fake identity to a copy of the capsule with a backlink added.
With your visual hash, e.g. "Long list ties, wise soup flows; edgy page demos." displayed due to you opting in across the sites, people can check that. There's one issue I didn't address yet though: someone could just paste your visual hash into a free form text field on their profile and it might be convincing. Probably there needs to be some recognizable visual context (e.g. a padlock emoji) that servers present with a real visual hash and block on free form text.
Security is hard! And fun. Thanks ;)
— I summarized my thoughts on my gemlog.
Thanks @skyjake! At first glance your two points don't fit with how I'm thinking about the problem--but I'll give them more thought.
Let me share my initial thoughts in case they are useful :)
Re: using the same certificate on many servers enabling more tracking; I think that's true of any mechanism for Gemini-wide identity. If a human can verify the identity via backlinks or PGP or anything else, so could the servers--and collaborate to track. In fact, the servers don't have to collaborate at all: if your identity is verifiable across multiple capsules then a third party can track your activity across multiple capsules.
And that's really part of the intention; if I want to be identifiable across capsules then it's the same as wanting someone to be able to find all my posts across all capsules, which is a form of tracking.
This already happens today if you use the same display name across capsules--except with something nobody wants, the possibility for impersonation.
I plan on writing in detail about what tracking is possible on Gemini and what isn't, compared to what happens on the web. My guess is that the tracking that happens on the web is mostly not possible on Gemini--exactly as intended. But it needs careful thought.
Re: trusting the server you are looking at; I actually think this is a correct thing to ask for, but I'll think about it some more. Here's my thinking so far.
Server certificates mean the trust you are placing is reliably linked to a real-world entity. (Unless there has been a man in the middle attack ongoing since you first saw it--a real security hole, but a topic for another day).
A malicious server can do lots of bad things. For example, it could show a fake identity with a link to a copy of the victim's real capsule that has a backlink to the fake identity. It could show entirely different versions of messages to different people. It could "ghost" certain people, making them think they are posting when they are not. And so on.
That's why I think that trusting a server to correctly show identities does not lose much in terms of security.
I do agree that real end to end signing would be great to have as an option--but because it's not in the protocol, I don't see it as a thing that can work on Gemini. Security that works except that nobody uses it, is not security :)
Anyway, thanks for the thoughts! As I said, I will reflect more :)
More somewhat-tangential thoughts/ideas. Not good or better ideas, not proposals--just exploring the problem space.
The original identity server idea can actually work with no unwanted tracking. Instead of pinging it to ask about individual users, servers wanting to use it just download all identity data in bulk every so often. Then, they don't leak any information about who visits what server and when.
The identity server could publish sha256s of sha1s instead of the sha1s directly, so that it would not leak the sha1s.
Or, a whole new way of doing it: this time the "identity server" is just something that checks cross-capsule link loops. So as well as cross linking your Bubble and Station profiles, you throw in a link to the identity server asking it to confirm the loop. When someone clicks that link it checks your Bubble and Station profiles and confirms that they do mutually link, meaning that they represent a real cross-capsule identity. This time there is no special server integration needed as well as no tracking :)
You could drive such a server from crawler data, making it a central directory of capsule-link-based identities that runs fully automatically with no per-user setup and no tracking. Then it's a "Gemini person search". Creepy? Yes--and that's why I mention it: not because it's a good idea, but because it underlines what information is already out there.
If we discard enough bad ideas maybe we eventually get to a good one ;)
Thanks.
I like thoughts. Thinking is good! ❤️🧠 I realized just now that I proposed earlier a scheme where servers could talk to each other to cross-verify handles. And I also said earlier that servers talking to each other was to be avoided. So I thought some more about a client-oriented approach. What if community sites offered a way to publish the publickey/cert associated with a handle according to a convention discoverable by a client.
2023-06-13 · 3 months ago
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.
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 · 3 months 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 · 3 months 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 · 3 months 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...
💬 skyjake · 37 comments · 1 like · 2023-06-08 · 3 months ago