[Freedombox-discuss] Working Groups

[Erik Harmon]

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...

User stories document rev. 1
Erik Harmon

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.

Non-functional Requirements

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…

Secondary or “desirable” nonfunctional requirements.

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…

Definitions

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.
User: A person using the system, with potentially multiple goals and
motivations. A user can have a name.
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.)
Goal: a user system requirement, in conversational language. Use Case: a
sequence or tree of interaction between actors to fulfill a requirement.

Assumptions

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.

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

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.

User Stories

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.

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.

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.

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.)

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.

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.

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?

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.
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.

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.

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.

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.

Sent from my Moto Xoom.
On Jul 20, 2011 10:38 AM, "jonathan d p ferguson" <jdpf.plus at gmail.com>
wrote:
> hi
>
> 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.
>
> 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.
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:
http://wiki.debian.org/FreedomBox.
>
> 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 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.
>
> Thanks.
>
> have a day.yad
> jdpf
>
> References:
>
> 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
>
> On Jul 14, 2011, at 8:43 AM, James Vasile wrote:
>
>> The idea of working groups has been proposed a few times by a few
>> different people. From my point of view, this seems like a good idea.
>> It's time.
>>
>> There are two questions here. First, what working groups should we
>> form. Second, how shall those groups operate? I think if we answer the
>> first, each group can answer the second on its own. I'm happy to
>> arrange hosted infrastructure to the extent debian.org or github don't
>> suit.
>>
>> We've had many suggestions for which working groups to form. Let's
>> gather them in this thread, choose a minimal starting set and see if we
>> can define and populate them.
>>
>> Best regards,
>> James
>>
>> _______________________________________________
>> Freedombox-discuss mailing list
>> Freedombox-discuss at lists.alioth.debian.org
>>
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
>
>
> _______________________________________________
> Freedombox-discuss mailing list
> Freedombox-discuss at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20110720/92be70e0/attachment-0001.html>