Okay I'm a bit late to this (pretty complex) thread, but here are a few thoughts..<div><br></div><div>I agree GPG keys seem to be the logical basis for establishing identity and relationships on a network of FreedomBoxes.</div>
<div>I think everything that has been built so far is very smart.</div>
<div><br>
</div><div>How do you find and connect to someone else's FreedomBox:</div><div><br></div><div>- My understanding from <a href="http://www.youtube.com/watch?v=zQTmnk27g9s" target="_blank">Nick's talk</a> 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.</div>
<div>- 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.</div>
<div>- 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.</div>
<div>- 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.</div>
<div>- 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.</div>
<div>- 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 :)</div><div>
<div><br>How do you connect to and authenticate to your own FreedomBox:</div><div><br></div>- This needs more thinking, but perhaps there should be different access levels to your FreedomBox, not sure..</div><div>- "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.</div>
<div>- "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.</div><div>- 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.</div>
<div>- 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.</div>
<div><br></div><div>Reverse Proxy:</div><div>- I think a public DNS, IP and reverse proxy service (with TLS) such as PageKite (as Michiel describes) makes a lot of sense.</div>
<div>- 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.</div><div>- 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).</div>
<div>- 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.<br>
<br>WebBox:</div><div>- 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.</div>
<div>- 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.</div>
<div>- I do think however the WebID mechanism could be useful for communication between FreedomBoxes, rather than between user and FreedomBox.</div><div>- 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).</div>
<div><br></div><div>Markus<br><br><div class="gmail_quote">On Mon, Jun 25, 2012 at 6:55 PM, Jonathan Wilkes <span dir="ltr"><<a href="mailto:jancsika@yahoo.com" target="_blank">jancsika@yahoo.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>----- Original Message -----<br>
<br>
> From: Daniel Kahn Gillmor <<a href="mailto:dkg@fifthhorseman.net" target="_blank">dkg@fifthhorseman.net</a>><br>
</div>> To: freedombox list <<a href="mailto:freedombox-discuss@lists.alioth.debian.org" target="_blank">freedombox-discuss@lists.alioth.debian.org</a>><br>
> Cc:<br>
> Sent: Monday, June 25, 2012 1:59 AM<br>
<div>> Subject: Re: [Freedombox-discuss] Identity UI<br>
><br>
</div><div>> On 06/25/2012 12:14 AM, Jonathan Wilkes wrote:<br>
>> You say at the top that you're not convinced that Tor is a requirement<br>
> for<br>
>> the Freedombox, yet Tor solves all the problems addressed below that.<br>
>><br>
>> Anyway, how do you solve the "magic routing problem" without it?<br>
><br>
> I'm not saying Freedombox should avoid Tor. I agree, it seems like a<br>
> good fit.<br>
><br>
> But I'm not knowledgeable enough about all other possible cryptographic<br>
> mix networks or alternate routing proposals to rule all of them out and<br>
> state that Tor is unequivocally a requirement for anyone wanting to<br>
> implement the freedombox vision.<br>
<br>
</div>I'd agree with that. If there are other solutions out there<br>
that are user-friendly, well-documented, well-supported,<br>
well-developed, and widely-used that can be up and running<br>
behind a NAT with one-click, then those would be good possibilities,<br>
too.<br>
<div><br>
><br>
> And even if i wanted to do that, i haven't contributed enough (anything,<br>
> really) to the concrete work of the project to presume to tell the<br>
> people actually doing the work what is or isn't a requirement.<br>
<br>
</div>The people doing the work are already using it:<br>
<a href="http://freedomboxfoundation.org/index.en.html" target="_blank">http://freedomboxfoundation.org/index.en.html</a><br>
<div><br>
><br>
> Note also that Tor brings with it its own bit of centralized control, in<br>
> the form of the 8 directory authorities [0] (4 need to be compromised<br>
> for an adversary to gain control over your tor connection), but i think<br>
> that's an improvement over the status quo, at least.<br>
<br>
</div>I didn't know about that. Since early Freedombox adoption will contain<br>
a lot of devs, I wonder if they could add either more<br>
directory authorities or at least some redundancy for the ones already<br>
existing. Since Tor and FB goals have so much overlap it seems like<br>
it should be possible to create the trust necessary to do that. Then<br>
again, I'm not sure why there are 8 in the first place-- maybe its better<br>
for them to limit the necessary trust for such an integral part of the<br>
network. In any case, I'll do some learning...<br>
<span><font color="#888888"><br>
-Jonathan<br>
</font></span><div><br>
><br>
> Regards,<br>
><br>
> --dkg<br>
><br>
> [0] <a href="https://www.torproject.org/docs/faq.html.en#KeyManagement" target="_blank">https://www.torproject.org/docs/faq.html.en#KeyManagement</a><br>
><br>
><br>
</div><div><div>> _______________________________________________<br>
> Freedombox-discuss mailing list<br>
> <a href="mailto:Freedombox-discuss@lists.alioth.debian.org" target="_blank">Freedombox-discuss@lists.alioth.debian.org</a><br>
> <a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss" target="_blank">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" target="_blank">Freedombox-discuss@lists.alioth.debian.org</a><br>
<a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss" target="_blank">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div><br>
</div>