On Saturday 28 Jul 2012 15:22:31 Matthew Toseland wrote:
> On Friday 13 Jul 2012 07:48:01 Steve Dougherty wrote:
> > Inspired by ArneBab [1] I had an idea for the first run setup. Here's
> > an attempt at drawing it in text:
> >
> > |------------------------------------
> > | Setup |
> > | ----- |
> > | |
> > | o > Low Security |
> > | o > High Security |
> > | o > Maximum Security |
> > | o > Custom |
> > | |
> > |------------------------------------
> >
> > This is intended to convey a box titled "Setup" containing a list of
> > radio buttons with security options. Each option has, to the left of
> > the text, a rightward pointing arrow.
> >
> > |------------------------------------
> > | Setup |
> > | ----- |
> > | |
> > | o V Low Security |
> > | Blah blah blah blah |
> > | blah blah blah blah |
> > | o > High Security |
> > | o > Maximum Security |
> > | o > Custom |
> > | |
> > |------------------------------------
> >
> > When an arrow next to a section is clicked, it turns downward as a
> > pane slides down from under the label containing an explanation of the
> > setting. Clicking it again toggles the explanation to slide up
> > underneath the section and the arrow to turn rightward again.
> >
> > |------------------------------------
> > | Setup |
> > | ----- |
> > | |
> > | . V Low Security |
> > | Blah blah blah blah |
> > | blah blah blah blah |
> > | o > High Security |
> > | o > Maximum Security |
> > | o > Custom |
> > | |
> > | > Blah blah |___________| |
> > | > Blah blah |__________V| |
> > | |
> > | [Done] |
> > |------------------------------------
> >
> > When a radio button is selected, if not already expanded the
> > explanation of that option slides down and the arrow turns. This would
> > be nice because it would allow the interface to demonstrate the
> > functionality of the arrows during normal operation in addition to
> > mouseover providing hints. Another pane slides out from underneath the
> > list of options which contains the necessary settings for that option.
> > Each setting has an input to the right of the label. To the left of
> > the label is an arrow which provides explanation for that setting like
> > the arrows in the option list.
> >
> > As this idea would already involve great amounts of Javascript, inputs
> > could do useful things like turn valid values green and invalid ones
> > red, or show estimated monthly bandwidth usage next to the bandwidth
> > limits.
> >
> > The "Done" button at the bottom would of course complete the setup,
> > and perhaps also present the option to generate a randomly named WoT
> > identity.
> >
> > Also shown here is a maximum security option. This could do things
> > like have the maximum security level for both network and physical, as
> > well as disable probes, disable routing by claimed peer locations, and
> > so on. The explanation on this one would make it clear the
> > ramifications of such an option, as well as mention which settings are
> > likely to be deemed impractical or have undue performance impact.
> >
> > One possibility - provided darknet invitations are implemented - is to
> > have a field for an invitation in the settings. It'd be fantastic if
> > that field was automatically filled in when setting up a node using an
> > invitation package.
> >
> > This design seems really exiting to me, though as I'm working on the
> > probes currently I don't have the time to work on this.
> >
> > Thoughts?
>
> On the whole, this is a good idea. Expanding the explanation and detailed
> settings when the radio button is chosen is sensible.
>
> Several issues:
>
> It is essential that we explain, clearly, and as early as possible, the need
> for friends, e.g.:
> High Security (only if you know people already on Freenet)
> Low Security (faster, you can use this even if you don't know anyone on
> Freenet)
> Custom (advanced settings)
>
> Is there any good reason to not use the old wizard for Custom? It's not THAT
> bad, and asking *everything* on one page would make it a rather gigantic page
> and/or unusably terse.
>
> Do we need Maximum? We can ask for an (optional) password on High. Network
> seclevel maximum doesn't do much, a few minor things e.g. probes. Physical
> seclevel = maximum arguably is a separate concern anyway - we might want to
> ask about it on High, and like the above, we can be concise ... E.g.:
>
> Downloads password: [ enter password ]
> Repeat password: [ enter password ]
> Warning: You cannot recover your downloads if you forget the password!
> (The above two lines only show up once the user starts entering a password)
> (All three are greyed out if the user clicks the next checkbox)
> [ ] Encrypt downloads and local cache and delete them on restarting Freenet
> (safer if computer is seized/stolen)
> Warning: You will lose your downloads when restarting your computer or
> Freenet! Also, Freenet will be slower and less secure against an attack over
> the internet. (PLAIN ENGLISH - WHAT DO WE CALL ATTACKERS ???)
> (Warning only shows up if box is checked)
> [ ] Don't encrypt anything, I am already using full disk encryption
> Warning: Checking this box will speed up Freenet a bit, but is slightly less
> secure, especially for temporary files
> (Warning only shows up if box is checked; I guess some full disk encryption
> software has secure deletion, I don't think it's true in all cases?)
>
> I'm not convinced that we need the last box, it's popular with freenet geeks
> but they can use custom. The middle box is probably useful for users in
> hostile environments, even if they are not very computer literate, so
> arguably should show up for High Security. We should definitely allow setting
> an optional password on High Security IMHO.
>
I agree in the long run we'll want to offer to generate a WoT identity during
setup. We'll probably also want to indicate which identity is logged in, and
make it easy to create new ones. This implies it must be reasonably fast! There
are also possibilities for portable identities, hidden identities and deniable
identities, that could substantially improve usable security against plausible
threat models IMHO:
- PORTABLE IDENTITIES: Store the data (private keys, snapshot of locally
configured settings, last editions etc) on Freenet. Fetch it with the
username+password (KSK). Hence can recover it from a new node, like social
networking etc. Dictionary attack on the network possible but slow unless
password is really weak.
- HIDDEN IDENTITIES: Store the data on Freenet, but tie it to a node-specific
secret key as well. Can't be dictionary-attacked on the network unless capture
the node first. Store the decryption key for the local Freetalk/WoT databases
on said Freenet data, so it can't be dictionary-attacked locally: you have to
capture the node and then brute-force it on the network (or more likely trojan
it).
- DENIABLE IDENTITIES: Above mechanism plus a fixed-size stego container for
local databases. The main difficulty with this is the size of Freetalk/WoT
databases!
- The main problem with all of these is that it would require a separate
database for each identity...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20120728/06635842/attachment.pgp>
