<p>Hi Johnathan, I never got around finishing these and sending them out, but maybe they can help as-is. It's incomplete and messy, and probably misinterprets much...</p>
<p>User stories document rev. 1<br>
Erik Harmon</p>
<p> Some user stories may address cases where a particular type of software is an end in of itself, for example instant messaging; the user _could_ use VOIP or email to communicate, but they just plain _want_ to instant message. I’ve tried to represent actual potential user stories rather than construct “needs” that the Freedombox can then fulfill, however some of them are borderline. Some of these are activist rather than daily user user stories, even though the fulltime activist/agitator is not the primary target for Freedombox. I included them because there are times when an ordinary person may need this functionality. I present this document as a conversation starter, not as a demand or a final product.</p>
<p>Non-functional Requirements</p>
<p> Ease of use for non-technical user. All communications box<->box and box<->user are encrypted. As much of the rest of communication, for example box<->public shall be encrypted. Minimal reliance on centralized services. Secure and high quality software. System is based on Debian. All software must be part of Debian; if desired piece of software is not, it must be added to Debian. This list could go on and on… </p>
<p>Secondary or “desirable” nonfunctional requirements.</p>
<p> Use and promote viable federated and peer-to-peer alternatives to centralized services that don’t make sense as individual services (name resolution, etc.) Build a web of trust among public Freedomboxes, to be leveraged by services to enhance security of the entire system (this might be a primary functional requirement? Many systems would be strongly enhanced by this.) Shared services to enhance anonymity (mix networks, anonymous proxy, etc.) This list could go on and on…</p>
<p>Definitions </p>
<p>User story: A short narrative in conversational language that describes how an actor might interact with the system, in just enough detail to get the goal of the user across. <br>
User: A person using the system, with potentially multiple goals and motivations. A user can have a name. <br>
Actor: Any entity that needs to be interacted with in the user story; a system or system user in the context of trying to achieve a _specific_ goal. A user can be described what they are trying to do (a role.) <br>
Goal: a user system requirement, in conversational language. Use Case: a sequence or tree of interaction between actors to fulfill a requirement.</p>
<p>Assumptions</p>
<p> User stories may rely on or help define overarching goals of the project, but such goals are not themselves represented by user stories. Each user story assumes that the actors want their communication to be reasonably protected on the wire, and for the actors to be reasonably authenticated, “reasonable” being defined in the context of the scenario. It is assumed that the balance between privacy and security is not the same for every actor and every use case. </p>
<p>Each user story is detailed with: a list of actors which actors have Freedomboxes the technical capabilities of each user potential software, either in general or specific packages, that could be used, and if it’s available—not appropriate to discuss comparative merits here, just list them. Items will be added or struck as a result of discussion </p>
<p>use cases to fulfill the desired outcome who the malicious actor is, explicit or implied, and their capabilities (e.g. wifi sniffer, low; tyrannical central government, high) this helps inform software and use cases the criticality of the security, and consequences of breached security (serious, jail; low, personal embarrassment) this helps inform software and use cases limitations on the user story, technical or practical (e.g. “This process is inherently inconvenient and will be difficult to make it likely that users will do this”) potential variations on the user story that the scenario does NOT cover, to limit scope per user story and avoid confusion (e.g. “in this user story we assume the actors live in a legal jurisdiction where home search and seizure is not the norm”); This is different than a so-called “misuse case” that would describe an attack on the system described in a user story. Listing misuse cases might be helpful.</p>
<p>User Stories </p>
<p>Edward has photos of his new daughter. He wants to share them with his mother over the Internet. She doesn’t have a Freedombox, he does. Juan and Rachel send instant messages to each other all day. The messages are personal and they would be embarrassed to know that anyone besides them was reading them. Only one of them has a Freedombox. </p>
<p>Pasqual and Alvar are activists and need to be able to send drafts of plans, flyers etc. to each other for upcoming events. Protest and political organization are legal in their country and do occur, but it has become clear that the government is reading activists’ email to find ways to interfere with and otherwise chill such activities. They need to be able to exchange messages and files securely and without relying on a third party. They both have Freedomboxes. </p>
<p>Rashid wants to watch videos on Youtube, but somebody on Youtube posted a video that offended the Royal Family of his country. Now the national ISP has a DNS block on Youtube. He has a Freedombox but knows no one else who does. Hong can’t get to websites relating to her religion because the country she lives in completely blocks certain websites using a “Great Firewall.” She doesn’t have a Freedombox, but her friend Eva overseas does. Eva can reach those websites, and wants to help her friend.</p>
<p> Daniel is a freelance graphic designer. When he finishes his work for clients, he needs to be able to put it up somewhere on the Internet and make it securely accessible to only them. The files are typically too big for an email attachment. He can expect his average client to be able to work a web browser and email, but that’s about it. He has a Freedombox, they don’t. (I’m considering basic computer tasks done by a sole proprietorship to be within the scope of the project, maybe they’re not.) </p>
<p>Evan and his friends live in a country whose government slurps up all the electronic data it can, and it’s not clear how long it’s stored, who has access to it, or what it will eventually be used for. Evan’s social circle is made up of fairly technologically savvy computer users, and they’ve all decided to get Freedomboxes. They want to do all their regular communication such as instant message, email and file sharing, but without the eavesdropping. Evan and his friends comprise of five people, and they all have Freedomboxes. </p>
<p>Roger microblogs frequently every day. He’s got about a thousand “followers” and doesn’t care who is reading his updates. However, his account unexpectedly just got banned because of a link he posted, reason unknown, and he can’t sign up anymore. Roger wants to be able to microblog without being censored, ideally to the same sized audience. He has a FreedomBox, his followers do not. </p>
<p>Tristan and David met at a Linux Users Group and want to communicate further outside the group. They both have Freedomboxes and want to link them together so they can do that. How do their boxes negotiate identity verification, authenticate to each other, and discover services? </p>
<p>Sandeep wants a personal website and to be able to share it publicly with other Freedombox users. He wants people to be able to find his website by using his name. <br>
Rebecca likes the utility of social networking sites, but dislikes the one she is currently using. She doesn’t have a lot of control over who sees what, and wishes she could do more things with her own data inside the system. She’s OK switching platforms if she can find one that offers her that control. She has a Freedombox. </p>
<p>Nancy has a number of files she wants to be able to access from her desktop or laptop, even if she’s at a coffee shop or the library or other such places with Internet access. She has a Freedombox. Her desktop and Laptop run Microsoft Windows. </p>
<p>Tom wants to be able to back up the files on his laptop. He has a Freedombox. His apartment has been burglarized before, so if he’s going to keep backups on his Freedombox he wants them to be encrypted. </p>
<p>Anna is a proponent of “direct action” in a hostile and undemocratic state. She needs to be able to communicate securely with like-minded individuals she knows. This entails hiding her traffic so that eavesdroppers cannot tell who she is communicating with; encrypting her traffic so that it cannot be read if eavesdropped; and assurance that only the intended recipient will receive and be able to read the messages, and likewise them for her. She and her peers have Freedomboxes.<br>
</p>
<p>Sent from my Moto Xoom.</p>
<div class="gmail_quote">On Jul 20, 2011 10:38 AM, "jonathan d p ferguson" <<a href="mailto:jdpf.plus@gmail.com">jdpf.plus@gmail.com</a>> wrote:<br type="attribution">> hi<br>> <br>> As a former usability/security researcher, I would like to call attention to the principle that security and usability are usually inversely proportional. This has been observed by many usability and security researchers over the years. <br>
> <br>> 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.<br>
> <br>> 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. The "use cases" part of the Wiki is a good start, I just added a User Stories page too, as use cases come from stories: <a href="http://wiki.debian.org/FreedomBox">http://wiki.debian.org/FreedomBox</a>. <br>
> <br>> 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: <a href="http://agileconsortium.pbworks.com/f/SDBP04_IntroToUserStories.pdf">http://agileconsortium.pbworks.com/f/SDBP04_IntroToUserStories.pdf</a><br>
> <br>> 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).<br>
> <br>> Further, I encourage the list 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. <br>
> <br>> Thanks.<br>> <br>> have a day.yad<br>> jdpf<br>> <br>> References:<br>> <br>> Gutmann, P. (2009, June 27). Things that make us stupid. Available from <a href="http://www.cs.auckland.ac.nz/~pgut001/pubs/stupid.pdf">http://www.cs.auckland.ac.nz/~pgut001/pubs/stupid.pdf</a><br>
> Gutmann, P. (2011a). Engineering security. Unpublished: Book Draft. Available from <a href="http://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf">http://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf</a><br>> Gutmann, P. (2011b, May). Security usability fundamentals. In Engineering se- curity (pp. 17–193). Unpublished: Book Draft. Available from <a href="http://www.cs.auckland.ac.nz/~pgut001/pubs/usability.pdf">http://www.cs.auckland.ac.nz/~pgut001/pubs/usability.pdf</a><br>
> Cohn, M. (2004) User stories applied: for Agile software development. Addison-Wesley Professional, 2004<br>> <br>> On Jul 14, 2011, at 8:43 AM, James Vasile wrote:<br>> <br>>> The idea of working groups has been proposed a few times by a few<br>
>> different people. From my point of view, this seems like a good idea.<br>>> It's time.<br>>> <br>>> There are two questions here. First, what working groups should we<br>>> form. Second, how shall those groups operate? I think if we answer the<br>
>> first, each group can answer the second on its own. I'm happy to<br>>> arrange hosted infrastructure to the extent <a href="http://debian.org">debian.org</a> or github don't<br>>> suit.<br>>> <br>
>> We've had many suggestions for which working groups to form. Let's<br>>> gather them in this thread, choose a minimal starting set and see if we<br>>> can define and populate them.<br>>> <br>
>> Best regards,<br>>> James<br>>> <br>>> _______________________________________________<br>>> Freedombox-discuss mailing list<br>>> <a href="mailto:Freedombox-discuss@lists.alioth.debian.org">Freedombox-discuss@lists.alioth.debian.org</a><br>
>> <a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss</a><br>> <br>> <br>> _______________________________________________<br>
> Freedombox-discuss mailing list<br>> <a href="mailto:Freedombox-discuss@lists.alioth.debian.org">Freedombox-discuss@lists.alioth.debian.org</a><br>> <a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss</a><br>
</div>