On Friday 12 November 2010 13:08:15 Ian Clarke wrote: > On Fri, Nov 12, 2010 at 1:28 AM, Gerard Krol <gerard at gerardkrol.nl> wrote: > > > On Fri, Nov 12, 2010 at 2:48 AM, Ian Clarke <ian at sensearray.com> 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? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20101112/b8e515ca/attachment.pgp>
