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. 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. 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." >>> [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. 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. > DSCMs have security requirements... Yes. Using a VCS that can sign commits is helpful here.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
