[Freedombox-discuss] Identity UI

Markus Sabadello markus.sabadello at gmail.com
Tue Jun 26 15:51:55 UTC 2012


Okay I'm a bit late to this (pretty complex) thread, but here are a few
thoughts..

I agree GPG keys seem to be the logical basis for establishing identity and
relationships on a network of FreedomBoxes.
I think everything that has been built so far is very smart.

How do you find and connect to someone else's FreedomBox:

- My understanding from Nick's
talk<http://www.youtube.com/watch?v=zQTmnk27g9s>at the last hackfest
is that in order to establish a relationship with
someone else's FreedomBox, you need their public key and their FreedomBuddy
hidden service address (these two things together were called "identity
schema" in Nick's talk). This makes a lot of sense to me and I'm curious if
this is still the latest thinking.
- If you only have someone's FreedomBuddy hidden service address. but not
the public key, well then you can just discover the public key from the
hidden service, so yes it seems all you need is someone's .onion address to
find and connect to their FreedomBuddy.
- At some point there was talk of a global public DHT ("Neruda") for
looking up the "identity schema", but that seems redundant considering that
Tor hidden services already have a built-in DHT.
- I guess theoretically one's "personal public key" and the Tor hidden
service's public key could be the same, then you would only need a single
public key, but I'm pretty sure that's a bad idea.
- You can get someone's FreedomBuddy address in any number of ways, like
Melvin says, from your profile on the web, from a key server, from an URL
shortener, from an e-mail signature, from WebFinger, from your Skype
profile, etc.
- In the future there could be more complex discovery mechanisms, e.g.
friends of your friends, or people who are geographically close to you, or
who like the same music :)

How do you connect to and authenticate to your own FreedomBox:

- This needs more thinking, but perhaps there should be different access
levels to your FreedomBox, not sure..
- "Trusted" access.. You sit at home in your trusted home network, or you
access your FreedomBox remotely via a trusted device which you previously
provisioned with your key. You might or might not still need to enter a
password.
- "Restricted" access.. You sit at an untrusted place and use an untrusted
device (e.g. Internet cafe), You will definitely at least have to enter a
password.
- Physical access.. Yes that could play a role for recovery or for
provisioning new trusted device. E.g. you're connected directly to the
FreedomBox'es wifi, or even with a cable, or you press a button, or you
read the LEDs, etc.
- Yubikey or similar physical token that you carry with you.. Might also be
useful to authenticate. The Yubikey could be plugged directly into the
FreedomBox'es USB port. Or your could take it to the Internet cafe and
copy&paste its one-time-password password into your FreedomBox'es web
interface to access it.

Reverse Proxy:
- I think a public DNS, IP and reverse proxy service (with TLS) such as
PageKite (as Michiel describes) makes a lot of sense.
- You don't need this if you sit at home and if all you want is your
FreedomBox to talk to someone else's FreedomBox, but you do need the
reverse proxy for two other purposes.
- To easily access your FreedomBox and use its services remotely, when
you're at the Internet cafe (but then you probably want stronger
authentication, e.g. with Yubikey, or alternatively more restricted access).
- To expose your FreedomBox to the Internet and make it a server in the
existing client/server landscape. E.g. turn it into a Diaspora node,
Unhosted "remoteStorage", webserver, XMPP server, etc.

WebBox:
- I agree there's a lot in there we can learn from. I think especially
Hosted Linked Data and a SPARQL service should be part of the FreedomBox at
some point.
- I admire Henry Story's work, but I don't think WebID is ready for
end-users. Working with client certificates in your browser, getting them
into your (several) browsers, recovering them, etc. is way too complicated.
- I do think however the WebID mechanism could be useful for communication
between FreedomBoxes, rather than between user and FreedomBox.
- E.g. once we start building a super cool semantic Linked Data / SPARQL
application on the FreedomBox, then WebID could be the way to authenticate
one box to the other (after they establish their FreedomBuddy relationship).

Markus

On Mon, Jun 25, 2012 at 6:55 PM, Jonathan Wilkes <jancsika at yahoo.com> wrote:

> ----- Original Message -----
>
> > From: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
> > To: freedombox list <freedombox-discuss at lists.alioth.debian.org>
> > Cc:
> > Sent: Monday, June 25, 2012 1:59 AM
> > Subject: Re: [Freedombox-discuss] Identity UI
> >
> > On 06/25/2012 12:14 AM, Jonathan Wilkes wrote:
> >>  You say at the top that you're not convinced that Tor is a requirement
> > for
> >>  the Freedombox, yet Tor solves all the problems addressed below that.
> >>
> >>  Anyway, how do you solve the "magic routing problem" without it?
> >
> > I'm not saying Freedombox should avoid Tor.  I agree, it seems like a
> > good fit.
> >
> > But I'm not knowledgeable enough about all other possible cryptographic
> > mix networks or alternate routing proposals to rule all of them out and
> > state that Tor is unequivocally a requirement for anyone wanting to
> > implement the freedombox vision.
>
> I'd agree with that.  If there are other solutions out there
> that are user-friendly, well-documented, well-supported,
> well-developed, and widely-used that can be up and running
> behind a NAT with one-click, then those would be good possibilities,
> too.
>
> >
> > And even if i wanted to do that, i haven't contributed enough (anything,
> > really) to the concrete work of the project to presume to tell the
> > people actually doing the work what is or isn't a requirement.
>
> The people doing the work are already using it:
> http://freedomboxfoundation.org/index.en.html
>
> >
> > Note also that Tor brings with it its own bit of centralized control, in
> > the form of the 8 directory authorities [0] (4 need to be compromised
> > for an adversary to gain control over your tor connection), but i think
> > that's an improvement over the status quo, at least.
>
> I didn't know about that.  Since early Freedombox adoption will contain
> a lot of devs, I wonder if they could add either more
> directory authorities or at least some redundancy for the ones already
> existing.  Since Tor and FB goals have so much overlap it seems like
> it should be possible to create the trust necessary to do that.  Then
> again, I'm not sure why there are 8 in the first place-- maybe its better
> for them to limit the necessary trust for such an integral part of the
> network.  In any case, I'll do some learning...
>
> -Jonathan
>
> >
> > Regards,
> >
> >     --dkg
> >
> > [0] https://www.torproject.org/docs/faq.html.en#KeyManagement
> >
> >
> > _______________________________________________
> > 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/20120626/825186bb/attachment.html>


More information about the Freedombox-discuss mailing list