On Wednesday 31 Jul 2013 23:27:26 Steve Dougherty wrote: > On 07/31/2013 10:50 AM, Matthew Toseland wrote: > > On Wednesday 31 Jul 2013 00:01:05 Steve Dougherty wrote: > >> On 07/30/2013 05:45 PM, xor wrote: > >>> On Tuesday, July 30, 2013 02:38:28 PM Steve Dougherty wrote: > >>> [snip] > >>> How do you obtain the list of identities which you offer > >>> the user to chose from? You should use GetIdentitiesByScore with > >>> positive score filter (and context filter "Infocalypse", I think > >>> it supports that as well). Where do you present him with the > >>> list? Ideally, the UI which shows the list should pass through > >>> the ID so you don't have to filter by nickname. > >> > >> There is no list to choose from. The user types something like "hg > >> pull freenet:p0s/WoT" and Infocalypse resolves it to a URI (not > >> necessarily one in the same subspace) and fetches it. > > > > Okay. The difficulty here is that there might be more than one p0s. > > We should always use the p0s we used last time, for security's sake. > > This is probably part of the reason why e.g. git has a list of > > remotes for each repository. > > > > Maybe you should keep a list of aliases? Or boost an identity's trust > > when you pull from it? Really this should be WoT functionality. > > I don't see why this needs to be anything more complex than aborting > when an identifier used to look up an identity matches more than one > identity. One need only specify the entire identity ID, perhaps with > nickname for convenience, to always uniquely specify an identity. This > partial matching is only for convenience.
That makes a DoS too easy, makes mistakes too easy, and generally sucks lemons for both security and usability. > > For local identities it should be really easy for someone to figure out > which one they mean because the search space is very limited, and they > created every identity in it. For remote identities it might involve > more investigation. > > I think that making sure the identifier refers to the identity they want > is the user's responsibility, not the software's responsibility. All the > software has to do is halt if the user is anything less than specific > enough to be exact. Git already HAS this functionality. A git repository has a list of remotes by nickname. Each remote corresponds to a specific external repository URL. That's all I'm asking for. > > The only possible problem I see with this is people pasting nicknames > with maliciously indistinguishable UTF-8 characters intended to > impersonate another identity. The solution to that is: "Type the > nickname yourself or check/include the identity ID." More dubious security issues for no reason. :( git remote add operhiem1 operhiem1/fred ^^^^^^^^ Look it up at *this* point git pull operhiem1 ^^^^^^^^ Use the full URL (public key / USK / WoT identity) that we added. > > >>> [snip] > >>> I think such a function is mandatory for WOT anyway: There can be > >>> multiple identities with the same nickname but the UI needs to > >>> display unique nicknames. The de-facto solution for that is to > >>> amend the nickname by including "@<part of identity ID long > >>> enough to make it unique>". Freetalk does this already in its own > >>> code. Instead WOT should compute those amended nicknames and > >>> store them. > >> > >> I'd be fine with adding this as a "DisplayNickname" field or > >> something. It seems like a useful supplement to identicons. > > One thing I don't like about this way of handling nicknames is that they > can change, and it's confusing when someone's name changes. If there is > "person@AB" and I'm seeing them as "person@A" and "person@AC" comes > along I have to go back and check which one is the "person@A" I knew > from before. However, identicons and displaying the entire identity ID > on a details page are enough that I don't think it's something worth > looking into right now. > > > Right, managed locally, with older nicks and higher trust nicks > > taking precedence. Or something like that? > > I prefer the policy of: "Refuse to perform any ambiguous operation. Do > not jump to assumptions about the user's intent. Being surprising is > bad." I see no reason to build some system with a complex set of rules > and assumptions when requiring the user to be more specific is easier to > program and easier to understand. And make it trivial for anyone to make developer's lives a PITA, even when we have enough information to deal with the problem transparently. > > It's worth noting that with the "fn-" commands URIs are in some cases > saved in full USK form, so they only resolve once. Perhaps it would be > good to have the built-in commands do something similar with setting > paths in .hg/hgrc. (Including comments to make it clear what identifier > resolved to the USK.) That way an identifier need only resolve once, > after which it becomes a path which is always the same identity. Exactly. > > > DSCMs have security requirements... > > Yes. Using a VCS that can sign commits is helpful here. > Right, but the key security requirement here is that if I pull from operhiem1 today, and there's no ambiguity, or even if there was, we remember which operhiem1 that was, and then when I pull from operhiem1 tomorrow, it uses the same operhiem1: The same cryptographic identity. I agree that signed commits are important, but they're not what we're discussing here. And they themselves need a PKI.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
