[Freedombox-discuss] my summary of yesterday's Hackfest

Tue Mar 1 01:26:09 UTC 2011

Thanks for your quite relevant comments/questions!

Whatever I write is my personal opinion - I do not intend to speak on 
behalf of others.

On Mon, Feb 28, 2011 at 09:06:00PM +0000, Matt Willsher wrote:
>On 28 February 2011 20:17, Jonas Smedegaard <dr at jones.dk> wrote:
>> On Mon, Feb 28, 2011 at 03:55:10PM +0100, Michiel de Jong wrote:
>>
>>>  - xmpp is better than smtp in the same way "Internet Mail 2000" is: 
>>> it puts the burden with the sender, thus discouraging spam.
>>>  - downside is, this means you would have to send your 
>>> communications through several different channels. people will still 
>>> be using standard email, without using freedombox, and will not be 
>>> encouraged to use pgp there.
>>
>> FreedomBox peers have no use for smtp if a better alternative (e.g. 
>> xmpp) is provided too.  Non-FreedomBox peers either are geeky enough 
>> to know how to setup the preferred mechanism of FreedomBox, or cannot 
>> be expected to use GPG anyways.
>
>For Intra-peer communication sure. For outside communication xmpp isn't 
>widely adopted so SMTP is still required. Which ever protocol is used 
>should be as transparent to the end user as possible. e.g. If their 
>recipient has a xmpp address that is used otherwise SMTP is used.

We are dealing with non-geeks but not kids.

We should strive to provide a non-complex interface, but not 
oversimplify:

We can provide a boxing of secure communication and present a simple 
interface for that which is sensible.

Or we can provide a boxing of both secure and insecure communication 
mashed together - but a simple interface for that becomes less sensible, 
as it risks blurring the difference, ending up just offering 
"communication".

None of my non-geek friends have problems juggling between sending sms 
(i.e. cellphone texting), messaging with the custom interface of 
Facebook, and using email.

If I offered my friends a box that could do a new form of communication 
which was more secure than those they already know of, they could easily 
use that (if the box wasn't difficult to setup or interact with).

If, on the other hand, I offered them a box with which to both do a new 
more secure communication style and also communicate some of their old 
(e.g. classic mail) then the new tool needed not only to be good at the 
new thing but also be at least as good as the old one for old-style 
communication.

It is an uphill battle to compete head-to-head with existing tools: You 
then get to fight against perception and old habits, not only concrete 
functionality!

>> PGP makes good sense to support for users.  Not sure, though, that it 
>> is sensible for a FreedomBox to store private keys on behalf of 
>> users, which is needed for the Plug to decrypt emails.
>
>Where would the private keys live otherwise? Is the plug seen as 
>trusted?

I trust my FreedomBox as I trust my house or my car (if I had one).  I 
trust them enough to leave private papers and things of value to me, yet 
I do not trust any of them with the pincode for my VISA card.

I distinguish between me and mine.  Friends of mine I can share some 
secrets with, but some secrets are for that very special privacy sphere 
consisting only of myself - not even my girlfriend or my mother knows 
the pincode to my VISA card or the passphrase to my GPG key: even if I 
could trust them with all of of my earthly belongings, I would not trust 
them with tools that I consider reflecting my personal identity.

>> Makes better sense to me for the box to stick to SSL encryption and 
>> store its own private keys for that - and only manage public keys of 
>> e.g. PGP on behalf of user(s) and peers.
>
>I'm not sure if I've missed something here  (there is a lot to read on
>this list at the moment!) but why are SSL private keys to be stored
>and not PGP? Why make a distinction?

Uhm - I don't know either if this have already been raised here on the 
list, but I know that I haven't mentioned it before.

Two things are involved here: sphere of privacy, and method of 
cryptography.

I consider my FreedomBox a close friend of mine, but not an extension of 
myself.  My FreedomBox can be stolen much easier than contents of my 
brain can be (yes, with a gun to my head I would probably tell you my 
GPG passphrase, but getting hold of my FreedomBox would only require 
knowledge of my home and a schedule of my holidays).

GPG is most often used for very personal encryption but can technically 
be used also for other purposes.  The FreedomBox could use an own GPG 
identity separate from mine for e.g. encrypting data backed up and 
friends' boxes, but as I assume it will do quite a lot of http 
interaction already (I love the REST concept) and I want that to be 
secure, my box would already have an own SSL certificate, and I see 
little reason for it to then use _another_ cryptograhy system as well.

>>> it was discussed that Asterisk has currently no consensus on how to 
>>> proceed with adding the necessary configuration options to debconf, 
>>> so that would sort of block the route for plugpbx's configuration 
>>> going into a debian package.
>
>I'm a little bemused by the push to have the config controlled by the 
>package. The package is the software with rudimentary configuration. 
>Pushing corner case configuration to the package maintainer increases 
>their burden. Configuration IMHO should be separate from the package. 
>Again IMHO, RHEL/Fedora gets this better. Configuration is separate 
>from the package which should simply encapsulate the the original 
>software and all it to install following the distributions guidelines. 
>Further to this, if debconf or any debian specific configuration 
>management is used it makes porting to other platforms much more 
>difficult.

I have close to no knowledge about other distros than Debian, so cannot 
compare.  Might be that other systems works wonderfully - but we are 
gathered here to work with Debian, I believe, not any of those other 
systems.

(yes, I do notice that most here on the list discuss programming, not 
use of already existing and Debian-packaged code, and some apparently 
want to work with OpenEmbedded or other structures alien to Debian - I 
am not those people and do not agree with those approaches)

I see Debian packages not only as "compiled code" but as "maintained 
system-integration of code".  Configuration is an essential part of 
system integration.  And I expect Debian package maintainers to not only 
provide me what upstream provided them, but also handle migrations of 
e.g. changes to some config options - seemlessly if possible but asking 
me if no single upgrade path is possible to resolve without my help.

When I edit configurations provided by a package, then most likely later 
migrations cannot be reliably resolved without interaction with me. I am 
not around to ask if I gave away the system to my brother, my brother 
would be confused about those questions that only I would know why was 
asked - and also is not around either because the system have no 
interface (friendly enough to be exposed to my brother).  So my cool 
FreedomBox fails to upgrade to the next cooler version of Debian because 
I "hacked on top" of the package-provided configfiles instead of the 
long and tedious approach of convincing the relevant package maintainer 
to _maintain_ the customizations that I need for my boxing purposes, and 
therefore also promise to _maintain_ an upgrade path for them if later 
needed.

Does above make sense?

Tell me if not - then perhaps I can try provide a concrete example.

>> I disagree:
>>
>> My preaching is that we should throw ideas here (what I call 
>> "dreaming), but engage in inventing/improving code _elsewhere_ and 
>> engage in package code for Debian _elsewhere_, and here work on 
>> _installing_ and _configuring_ existing Debian-maintained code.
>
>I agree we should draw on others' work as much as possible but we can't 
>mandate to them they need to improve their packages just for the sake 
>of FB. We need to use there tools (the bricks) and provide our own 
>configuration (the mortar).

I do not expect us to succeed if asking e.g. the package maintainer of 
the xmpp server "ejabberd" to add the following debconf question:

   Configure for FreedomBox (yes/no)?

I do expect, however, that we might have a fair chance if proposing e.g. 
questions like these:

   Configure for which domain (default domainname / custom)?

   Configure http_bind proxy (yes/no)?

In fact, the first question is already provided today, so the package 
maintainer of that particular package already is familiar with using 
debconf - just needs to be enlightened on how http_bind (a.k.a. BOSCH) 
is beneficial for quite many situations - not only for FreedomBox.

>Given FB is controlled centrally as a distribution cases like rubbish 
>handling of modified configuration files can be thoroughly tested. In 
>my dream work, the FBs maintain their own state and make sure that they 
>don't drift and stay aligned to their 'true' configuration.

Seems you expect all of us volunteers to stay put, then.

I don't.  I expect most of us to loose interest in FreedomBox over time, 
or even if still working devotedly on it then loose interest in that 
tiny little crucial part having to do with package integration and 
upgrade paths of the hundreds or thousands of packages and configfiles 
involved.

I have seen it with Skolelinux.  A great project with active 
development, yet very little interest in housekeeping of configfiles.

Debian does this already - which I see as a key reason to use Debian in 
the first place.

>I'll finish by saying if I'm mis-understanding something important 
>about your view of configuration please let me know. I just can't see 
>how it would work in practice for anything other than simple cases.

Yes, difficult cases are difficult to convince others to adopt 
maintainance of.  But thinking that taking over the responsibility 
ourselves makes them easier is Hubris.

Regards,

  - Jonas

-- 
  * Jonas Smedegaard - idealist & Internet-arkitekt
  * Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20110301/119bb5fa/attachment.pgp>