Many usability and security researchers over the years have observed the principle that security and usability are usually inversely proportional. To that end, it is imperative that every developer on the FreedomBox project pay attention to the "little details" of usability. Making a secure system like this would challenge even the best-funded commercial projects.
The working group for usability will need to collaborate, deeply, with all other groups. It bears repeating that usability is not a "task domain" that one can just box up and deliver at the end. The usability and security implications run through every decision, particularly for FreedomBox.
My suggestion is to arrive at a core set of user stories. All we need to do here, is tell stories about the *main things* that people will use the FreedomBox for. In this task I encourage people to please exercise restraint. This is first, to establish the common stories. Edge case stories are good for testing the common stories, once we know the common stories.
I have come to prefer user stories, because use-cases can make hidden assumptions that user stories expose. A good story will be Independent, Negotiable, Valuable, Estimateable, Sized Appropriately, and Testable (Cohn, 2004) See also: http://agileconsortium.pbworks.com/f/SDBP04_IntroToUserStories.pdf
For example: Alice needs to send a message to Bob but Alice lives in an oppressive, surveilled environment, and if the message is detected, she will go to jail merely on suspicion of seditious activity. (This story implies many features and possible cases).
Further, I encourage contributors to please pay attention to the work of Peter Gutmann (2009, 2011a, 2011b). He has made some sometimes startling observations about computer and network security and usability. Strongly recommended.
Gutmann, P. (2009, June 27). Things that make us stupid. Available from http://www.cs.auckland.ac.nz/~pgut001/pubs/stupid.pdf Gutmann, P. (2011a). Engineering security. Unpublished: Book Draft. Available from http://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf Gutmann, P. (2011b, May). Security usability fundamentals. In Engineering se- curity (pp. 17–193). Unpublished: Book Draft. Available from http://www.cs.auckland.ac.nz/~pgut001/pubs/usability.pdf Cohn, M. (2004) User stories applied: for Agile software development. Addison-Wesley Professional, 2004
Please contribute User Stories for the FreedomBox. Remember, this is a collaborative effort, no single one of us has all the answers.
A tale of why the hell can't I login after changing my password
Out of the box, logged in as root with the default "freedom" password and did the three recommended "ssh-keygen" lines.
The next thing I did was change the password of root with "passwd root" and of the default fbx user with "passwd fbx". Then I logged out, and could no longer log in over the network.
So I hooked up the guru plug jtag board and after a while figured out how to reset the "lost" root password, which as far as I can tell isn't documented anywhere for the FreedomBox in particular. I also set the date, as the plug thought it was 1942, and I know wrong dates can mess all kinds of stuff up (I'm 100% sure I typed the password correctly. I think the lockout has something to do with password expiry, but I didn't take time to look into the root cause.)
From U-Boot prompt:
setenv x_bootargs_root 'root=/dev/sda2 rootdelay=10 init=/bin/sh' boot
From the shell prompt:
mount -o remount,rw /dev/sda2 / date -s "24 SEP 2013 15:47:00" date passwd -d root passwd root mount -o remount,ro /dev/sda2 / reboot