On Saturday 13 November 2010 01:38:01 [email protected] wrote: > 2010/11/12 Matthew Toseland <[email protected]>: > > On Friday 12 November 2010 13:08:15 Ian Clarke wrote: > >> On Fri, Nov 12, 2010 at 1:28 AM, Gerard Krol <[email protected]> wrote: > >> > >> > On Fri, Nov 12, 2010 at 2:48 AM, Ian Clarke <[email protected]> wrote: > >> > > > >> > > I must agree with Matthew on this. Asking for a password is defending > >> > > against someone gaining unauthorized access to their computer, but that > >> > is a > >> > > bit like closing the gate after the cows have escaped. If someone has > >> > > access to your computer then you are pretty-much an open book to them > >> > > anyway. All demanding a password does is inconvenience the user, it > >> > won't > >> > > thwart an attacker. > >> > > >> > This *is* a question of usability right? Users are used to entering a > >> > password when logging in. > >> > >> With websites, perhaps, but not with their own software. > >> > >> > Writing usable software is often doing what the user expects instead > >> > of what actually makes sense to us technical people. > >> > >> This is true, to some extent, but I don't think it should extend so far as > >> creating completely unnecessary inconveniences, like demanding a password > >> for no added security benefit. > > > > Yes, but this is confusing: > > > > If they set HIGH physical seclevel, they need a password to unlock the > > client layer - probably including all the pseudonymous identities, but then > > they log in without a password? > > > > This is somewhat counter-intuitive, maybe it *is* worth considering > > one-client-layer-and-client-cache-per-identity, with the password optional > > but used for encryption if present? Then we could get rid of the physical > > security setup... > > > > The main difficulty is what to do with the other identities when we switch > > - the user probably doesn't want to shut them down and stop their downloads > > just because he wants to post as anonymous. So maybe this is a bad idea? > > > What we could do is: > - either, having several identities tied to an account (so once the > account is logged in, no need for a password for the identity, just > choose which one you want to use); so, with this we have a separation > between the account (1 per real user) and the identities (several per > real user).
Okay so you log in with a password (and possibly a username), and then you switch between different identities. > - either, and I don't know how or if it is feasible, having several > accounts which can run concurrently. Basically what you proposed (at > least I think), but with the option for the user when logging out to > keep the activities of this account running. This is feasible, somewhat heavyweight if we have multiple such identities though, and while it gains us physical security on the network level I'm not so sure - don't we want downloads for a specific identity to run continually, to avoid time correlation etc, as well as to improve performance? OTOH if the system is shut down ... Not sure. > > I have a question regarding identities btw: how is it managed when we > have several identities (do the identities share the trust list of a > "main" identity? each identity has its own trust list? ...) As Volodya explained, they are separate for WoT. They have to be because they are often published.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://freenetproject.org/cgi-bin/mailman/listinfo/devl
