On Tuesday 23 November 2010 20:27:05 Ian Clarke wrote:
>
> I just wish we could focus on actual usability issues, and try to avoid
> getting sidetracked as we've been with this whole issue of identities and
> passwords.
Identities matter. In fact they are a critical part of the UI - just like they
are on a thousand web apps. WoT, Freetalk, FlogHelper, distributed search, Sone
(facebook clone by Bombe), Fritter (microblogging), everything hangs off
pseudonymous identities. None of that exists by default right now but it will
be a big deal in the near future. The fact of the matter is that if Freenet is
nothing more than fproxy then very few people will use it IMHO.
Also, they may actually help to simplify the setup process and bring Freenet
closer to what people want, making it easier to make the right tradeoffs for
each situation, and reducing the perceived cost of "getting it wrong" in the
wizard, see below.
On Tuesday 23 November 2010 15:43:35 Ian Clarke wrote:
> On Tue, Nov 23, 2010 at 9:34 AM, <cvollet at gmail.com> wrote:
>
> > Well, right now, we do ask a password if users want to encrypt the
> > client-layer or whatever that is we encrypt. So, the idea was to allow
> > that on a per-identity basis. If it's not possible/too complicated/not
> > useful, then yes, we can just go with the current master password, and
> > identities without any password.
>
> I'm just not sure I see a concrete benefit to encrypting per-identity, and I
> see a lot of usability pit-falls. We have enough usability problems to
> worry about without creating new ones.
The initial thought process was that we need identities for WoT, Freetalk,
FlogHelper and probably distributed search and nanoblogging. We may also need
them for tunnels later on, and in such a context separate client-caches might
be helpful. Even some per-identity network security config might be helpful, so
you might have one identity with a persistent cache, persistent downloads and
no tunneling, for general filesharing, and another with tunneling and no
persistent cache for risky stuff (making passworded identities deniable would
be useful but is probably a long way off). Multi-user support would be nice to
have but isn't a big priority, and for both multi-user support and separate
client caches etc, passwords make sense as an option. So that's basically the
thought process: Users are used to having to log in, a lot in Freenet 0.8+ will
rely on identities, and it makes a lot of sense to have some separate security
settings.
However, this is only really attractive if it simplifies things for the user.
In other words, allowing per-identity security settings makes most sense if we
get rid of at least some of the global security settings!
Arguably we can do this for physical security level. If there is a password we
can use it to encrypt stuff. If the user is worried about forgetting the
password he can simply not set one.
What about network security though? Can we make this per-identity? Some
elements of it clearly apply only to local requests: Tunneling settings, for
example. However some are global tradeoffs - FOAF, bloom filter sharing,
padding, cache everything (including local and nearby requests) in datastore.
Once we have the option for tunneling for the more paranoid users, turning off
the first two will make considerably less sense. Once we have a more efficient
transport layer (before 0.8), turning off padding will be a small enough
benefit that it can be an advanced-users-only option. Caching everything in the
datastore is more doubtful: It can only be enabled or disabled for both our
requests and those we receive at high HTL, and can give a significant
performance boost in some cases. But if the client-cache is a sensible size
maybe it doesn't make sense anyway, or at least should be a config option for
advanced users?
If network seclevel is per-identity, then we can just ask the user whether to
enable opennet. This simplifies matters because we are effectively asking them
two (related) questions at the moment on the network seclevel page.
Friends seclevel really should be set per-friend when they are added.
So the proposal is, when we create a new identity:
==
Name: [ NAME BOX ]
[ ] No password
[ ] I really don't care about incriminating data, increase speed by taking
no precautions with local data (E.g. I have already encrypted my hard disk)
OR
[ ] Password: [ PASSWORD ]
[ ] Wipe cache and downloads on restarting Freenet (All evidence of what
you have browsed will be permanently erased on shutdown, but if you return to a
freesite it will have to be re-downloaded)
How much do you want Freenet to protect your anonymity on the network level
when using this identity? More anonymity means less speed!
[ ] HIGH
[ ] NORMAL
[ ] LOW
WARNING: Freenet is currently set to connect to Strangers, this means even if
you set HIGH, security is far below what it would be if you add some Friends
and upgrade to darknet mode. However it is still worth setting HIGH if you are
concerned.
==
Re UI, there is another aspect that might be useful:
We can have a drop-down of the currently available identities. All
non-passworded identities would be in this list, plus all passworded identities
that the user has logged into but not yet logged out of. And then we have an
Other button for logging in a passworded identity or creating a new identity.
Get rid of the seclevels and this all fits comfortably on the status bar.
I do think that per-identity bookmarks make sense. Many users won't use
multiple identities but those that do would likely find it helpful.
-------------- 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/20101125/1899a972/attachment.pgp>
