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

Mon May 9 12:39:04 UTC 2011

Hi!

On 12:43 Mon 09 May     , Jonas Smedegaard wrote:
> On 11-05-09 at 07:36am, Michael Blizek wrote:
> > On 18:16 Sun 08 May     , Jonas Smedegaard wrote:
...
> > > The idea is to emphasize egocentric vs. friend-oriented vs. 
> > > world-contributing, and for each sort by how controversial the tools 
> > > are.
> > 
> > I think a sharing page which make a distinction based on the risk 
> > rather than friends vs. public is more straightforward.
> 
> [details snipped]
> 
> > Whatever you publish or for yourself should not be here. There should be a
> > separate page where you can configure whether you want to run web/mail/...
> > servers or not. 
...
> I disagree.
> 
> I believe that from a user point of view, before even considering risk 
> level, there is a question of "who do I want to provide freedoms?".  
> Risk level can even be skipped - default is obviously "no risk".
> 
> If I gave such a box to my mom, then - even though being my mom and 
> therefore quite curious and encouraging about what I do myself - she 
> would likely turn off the box again, not run such a thing under her own 
> bed, if its main question communicated to her was "how much risk are you 
> willing to take?"

I can see your point. However, a default of "no risk" would pretty much mean
that you do not share anything at all. While this might be a sensible default,
let's hope that this is not what most people want.

> Jim activates the box, is asked a few questions, and is then hooking up 
> with his friends.
> 
> What was he asked?  Was he - up front - asked about risk level?  Nope, 
> that was not necessary, because anything that can be applied a default 
> need not be asked - and the sensible default here is "no risk!"

I am not suggesting that this is the first thing the user is asked. I am
suggesting that if the user want to share ressources, we educate him about the
risks involved - and let him choose what is OK for him. After all, you want(?)
him to be able to mirror wikileaks and run tor exit nodes. The risk of doing
so is very relevant. In contrast, it is not that relevent whether the backup
service can be used only by friends or by anybody. That is unless there are
side effects like being able to fingerprint a box.

Besides where would you put the explanation e.g. of what the backup service
does, if you split its options into "allow friends to create backups" and 2
pages later "allow everybody to create backups". And what do you do both are
activated and the user then chooses to disable "allow friends to create
backups"?

> <nitpicking>
...
> So really it is not "no risk" but "tiny risk" or "in the safe zone".
> 
> </nitpicking>

I agree that there is no "no risk" sharing. This is why we have to educate the
users about the risks and provide easy ways to activate "low risk" sharing.

> First, Jim is asked the very minimal of personalizing his box: Give it a 
> name!

Why does the *box* need a name???

>  Technically there is more to it - a cryptograhically unique blob 
> is generated, which stays on the box for now but is used later as basis 
> for e.g. WebID and GPG.  If later creating additional names for other 
> members of the household then more such blobs are created, and if later 
> doing a reset then the blob(s) are erased from the box.

You want to use the boxname as a random generator seed for crypto keys!?

> Next he is asked if the name is a) private, b) can be revealed when 
> anyone asks, or c) is proactively promoted to the world.

And you need this name for???

> Above he implicitly made choices affecting the risk level.  The machine 
> cannot know if he stupidly named the box after his creditcard pin code, 
> but if he chose b) or c), we can start show a little "risk meter", still 
> far down in the "safe zone".  Jim can perhaps (depending on the UI) 
> click on this risk meter to get to those questions on preferred risk 
> level, but if not it is simply informed to him what his actions cause on 
> the risk meter.

Sorry, but I disagree. Making your name public and maybe even linking it to
your IP is something a would call very high risk. When publishing stuff, the
user has to evaluate the risk for himself.

> With name and exposure-of-name, Jim now has a machine which he can 
> reach, and if he chose b) or c) then others can too.  It does nothing 
> other than that, because no services was activated.  So he is not yet 
> finished with its initial activation.

I would rather say he first tries to activate the service and is then asked
to enter a name the service will be reachable at.

> There is a bunch (well, in first revision a rather tiny bunch, but 
> still) of services on the box, and he is done when picking and 
> activating at least one of those.
> 
> The box need to somehow prioritize what to suggest first - to rate the 
> services.  Jim already tought the box a tiny hint about risk level in 
> the answer of the exposure-of-name question.  But too little yet.

This might be a way if your goal is publication and communication. But I do
not see it fit for ressource sharing. How do you expect users to do ressource
sharing without doing any of the publication/communication stuff?

> We don't wanna scare off neither Jim nor the friendly journalists 
> checking out the potential doomsday machine, so by default we want to 
> suggest some harmless services.

The problem is rather that services which ask you to publish personal data are
far from harmless. If we do not want to scare people not to do this, then who
should?

> If Jim chose a) as exposure-of-name, then e.g. Backup-of-PC would be 
> proposed first, as that involves only himself and the box.

And you need the name for...

> When 
> multiple services rank equally high then (depending on UI) they are 
> shuffled around at each view.
> 
> If he chose c) then also Live-chat and Public-website (with optional 
> blog and microblog extensions) would rank highest.
> 
> If activating e.g. Host-public-web-forum or Public-website with blog AND 
> public comments enabled, then in addition to the risk meter would emerge 
> an altruism meter, being low initially (so far _interest_ in altruism 
> exist, but none practiced yet).
> 
> If Jim chose b) or c) then a Find-friends feature emerge.  Until some 
> friends are actually located it is possible to activate friends-only 
> services, but they rank at most next-highest as it makes little sense 
> to socialize alone.
> 
> With at least one friend located, e.g. Offer-backup-mirror-for-friends, 
> Friends-only-chat and Friends-only-website rank highest together with 
> selfish and self-centered (and if c) chosen also altruistic) services.
> 
> If Jim chose a) then e.g. Offer-backup-mirror-for-friends would still 
> rank pretty high, because maybe Jim didn't realize initially the 
> consequence of avoiding the social network. If then selecting a service 
> which require proactive exposure of machine name to his friends, before 
> it is activated he is asked if ok to change his former choice for 
> exposure-of-name - and the risk meter then goes up accordingly.
> 
> The meters not only measure based on core exposure-of-name config and 
> choice of activated services.  As mentioned already, altruism meter also 
> measures how much offers to the public is in fact being used.  Similarly 
> risk meter takes into account what kind of services are active, and the 
> meter can be configured to weigh e.g. "public exposure" or "friends not 
> part of selected GPG web of trust" as especially risky.

Sorting lists of services by seemingly unrelated options sounds very complex
and confusing. Mixing ressource sharing into this will not make it any easier.
Why not group them:

publication/communication:
- email server
- instant messaging/jabber server
- web site: static, blog, ...
- ...
  They ask you for network configuration individually (e.g. (dyn)dns, static
  IP, tor hidden service, pagekite, ...).
ressource sharing:
- tor server
- who should be allowed to create backups
- ...
  They may need to ask you for incoming port, UPnP,...
backup:
- create backup now/scheduled
    ftp, ..., use other FB for backup

	-Michi
-- 
programing a layer 3+4 network protocol for mesh networks
see http://michaelblizek.twilightparadox.com