[Freedombox-discuss] Initial User Experience (was: Tor .onion domains)

Marc Trius derpayatz at riseup.net
Tue May 10 03:46:43 UTC 2011


I am not a developer or a hacker of any kind, and I know very little about the technical issues involved in developing the Freedom Box. However, I have taught myself how to use and administer computers, and I have some experience in helping people who know even less than I do about computers and Free Software become more knowledgeable and empowered users. Therefore I hope that my perspective might be useful in this particular discussion.

I see the Freedom Box not only as a huge step forward in popularizing network privacy, but also as a tool for creating a polity or network of empowered and liberated human beings. I think that it is important to design for users who are not technically savvy and already aware of privacy issues, because: 

1) Users who live in countries that are preceived to be less hostile to dissent are likely to be unaware of the need for rigorous protection of their privacy. Such users might be introduced to the FB by friends or by rumor, and might get one without a very clear vision of the kind of surveillance that we are subjected to on the Internet by governments and corporations.

2) Users who live in countries where awareness of state repression is more widespread, and who might be drawn to the FB out of a desire to avoid censorship and be safer from the state, might still not be knowledgeable about how information privacy works, and need to learn more about it.

Therefore, any choices the user makes that impact privacy *directly*, such as the level of sharing of the box's nickname, should either be hidden or, if that cannot be done, presented in such a context that would make clear *both* the need for making the choice and its impact on the user's privacy. To do otherwise would be confusing and is likely to cause bad choices. For example, a user confronted with the choice above might pick the highest level of sharing simply out of vanity, and if there is a wall of text explaining the risks their eyes will probably water in the same way as when anyone but a lawyer sees an EULA.

When I introduce people to Linux and Free Software, the two most important questions I can ask is: "What do you use (or would like to use) your computer for," and, "How deeply involved to you want to be in administering your system?" These are important questions not only because it makes a difference in terms of what choices need to be made  (like what distribution to use, whether or not to dual-boot, what software to install --- or what level of sharing the FB's name is appropriate), but also because those are important questions for the user to *think* about, as they define the user's relationship with the machine. It is part of the process of empowering and liberating the user *and* a part of the user's learning curve.

Therefore, I envision the set-up process of the FB to be a sort of dialog maybe sort of like a multiple-choice dialog tree from old adventure games, centered around these two questions, but also doing much more than just allowing the user to set up their system.

The user would name their Box, and then the Box would start asking them questions and responding to their answers. I just don't know enough about the technical issues to mock up an example dialog right now, but it should have several characteristics:

1) It should teach the user about the issues of privacy and freedom in the context of computers and networking.
2) It should introduce the user to what the FB can do.
3) It should present information about the choices that are available to the user.
4) It should tell the user about the implications of the choices they make.
5) It should allow the user to change their mind after learning more about their choice.
6) It should allow the user to ask for more details or clarification.
7) It should teach the user a little about how the FB works
8) It should teach the user some computer literacy, according to how much they want to learn.
9) It should be accessible even after installation, so that it can help the user maintain or modify the system after it has already been set up.

I understand that the role of the FB is to provide end-users like me with secure networking, and that stuff like characteristic No.7 above is very tangential to this role. However, I feel that the *reason* why this community is creating the FB is to empower people, and I believe that the FB can be invaluable as a sort of "gateway drug" to more aspects of empowerment. I think that the extra work involved in creating such a sophisticated set-up procedure would be well worth it in the end.

I hope that my thoughts were helpful,
Thanks for your time and patience,
Marc Trius

On Mon, 9 May 2011 21:18:42 +0200
Jonas Smedegaard <dr at jones.dk> wrote:

> On 11-05-09 at 08:23pm, Michael Blizek wrote:
> > On 19:49 Mon 09 May     , Jonas Smedegaard wrote:
> > ...
> > > > - or none if the user wants to be invisible.
> > > 
> > > If the user wants to be invisible then the user will avoid [c], and 
> > > possibly [b] as well.
> > ...
> > > > It is not having a domain which is dangerous. But having a dyndns name 
> > > > which links your name with your IP address is. The user may think he 
> > > > is at least somewhat anonymous due to a dynamic IP.
> > > 
> > > I wrote "name" (not "dns").  A relationship *must* be established 
> > > between the box and you(r laptop or cellphone or whatever).  I propose 
> > > as user expecience for that to baptize the box.
> > 
> > It makes a bit more sense now. However, I still do not not see what 
> > the user would have to do, if he does not want to connect to the box 
> > from outside the LAN. He could connect to e.g. (as 
> > written in the handbook - he has to do this the first time anyway). 
> > Why does the user have to enter a name in this case?
> > 
> > The next question is then how should the name look? Should it resolve 
> > to an IP? Then we have the same problem as with DNS. This name would 
> > have to be e.g. an .onion address to be safe. But I guess this is not 
> > what you had in mind...
> I deliberately do not "have in mind" at all.
> You want .onion.  Fine - I don't care (for this discussion)!
> Can we now please get back to talking user experience design?
> You envision a handbook that instructs the user to type in a specific IP 
> number, which somehow ensures it is the correct box?
> > > I deliberately avoid the underlying technical details (tying a name 
> > > to a cryptography token) as I want to discuss User Experience here, 
> > > not technical implementation.  Think "WebID" everywhere I write 
> > > "name" if you really really must have a concrete example, but please 
> > > stick to general principles, not specific implementations, in this 
> > > discussion: Some followers on this list are UX designers, that are 
> > > helped if such discussions are uncluttered from noisy details about 
> > > other aspects.
> > 
> > The problem with this is that the "noisy details" can make big 
> > differences...
> How does it affect user experience if the nickname of the box resolves 
> of an .onion vs. an ip number?!?
> > I do *not* want FB to get it the way if a user wants to publish 
> > something. But I also do not want it to promote things which can be 
> > dangerous without warning - or even do them silently. This is a fine 
> > line.
> So we perfectly agree?
> > > > You could ask the user questions like:
> > > > [ ] I want to stay in contact with friends
> > > > [ ] I want to publish
> > > > [ ] ...
> > > 
> > > Yes.  Looks quite close to what I proposed.
> > 
> > The difference between first asking for a name and then asking what 
> > the user wants to do and the other way round looks pretty big to me.
> How is that a big difference, when it is *not* a dns name but a nickname 
> we are talking about?!?
>  - Jonas
> -- 
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private

Marc Trius <derpayatz at riseup.net>

More information about the Freedombox-discuss mailing list