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

[Matt Willsher]

On 1 March 2011 01:26, Jonas Smedegaard <dr at jones.dk> wrote:

> Thanks for your quite relevant comments/questions!
>
> Whatever I write is my personal opinion - I do not intend to speak on behalf
> of others.

Likewise.  I find your view on this interesting as it a topic that
doesn't often get much attention.

I've been quite liberal with my snipping below. I don't mean to remove
anything to sway any point of view my way, so I'm sorry if anything
comes across that way. There are a lot of very good points that I have
removed because I either agree or they because redundant.

> 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:

>> 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.

I, even as a geek, prefer unified interfaces and the tool to just do
the job. In the case of communication with other people I don't really
care what protocol is used as long as it gets to the recipient and it
is at least as security as I believe it to be. For example, I type in
a mail address john at example.com. This looks to see if example.com and
xmpp and if the users public key is known. If so it can be sent
encrypted through xmpp. If not, does the system have a SSL public key
for S/MIME mail? If not, warn the user the mail is sent in the clear.
But don't be alarmist about it.
The user should have to care about the underlying protocols just the
task they instructing the FB to do.

> 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.

There are only a certain number of paradigms regarding communication.
Off the top of my head there is the letter type email, the telegraph
style sms/tweet or the conversational style instance messages. There
is some over lap with the distinction being length of message - email
is suited to long communication like the one we are writing here, SMS
and IM suited to short items.

In summary, the interface should reflect the users action not the
underlying technology.

> 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!

I see no reason to fight head to head. The end user doesn't need to
know the technology being used. As long as they trust the FB all is
well.

>> 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?
>
> 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.

My point is rather: why not just use X.509 keys and certs and why use
GPG/PGP at all? X.509 is multi purpose, well adopted and well trusted.

> 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.

But these configurations can be large and complex. Even capturing
simple cases is difficult in many cases. Take BIND, Asterisk, Apache
even sudo. They are are complex pieces of software with complex
configuration requirements. There is no way the package maintainer can
make sure their changes don't tread on the toes of a current
configuration, and nor should the dictate the way in which software is
configured.
My view of a package, specifically debs because this doesn't apply to
plenty of other package system, is that it should provide basic setup
options to glue the software to the current installation. It makes
sense to give a basic configuration out of the box for those learning
the system, but a competent admin will soon find the simple cases that
can be encapsulated by the packages to be restrictive and counter
productive.

> ...  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.

FB can't be expected to handle a case where it is has been manually
hacked at. If modifications aren't not done through the managed
channels it adds far too much complexity. It rather like voiding a
warranty by opening your nice new electrical device. Sure, do it if
you want, but don't expect the supplier to pick up the pieces if it
goes wrong.
The FBs are consumer devices and not tinkers toys  and need to be
treated as such to avoid stability problems.

> Does above make sense?
>
> Tell me if not - then perhaps I can try provide a concrete example.
And if you think I've missed the point please provide an example.

>> 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.

No, I would expect new volunteers/employees will come along but they
need to work with whatever their forbearers put in place.

> 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.

Sadly that is often the case. It is badly managed in the enterprise as
well. A way of doing it does need to be found, and I appreciate you
recognise this. I believe that the management should be done outside
of the packages in a way suiting how the packages will be used. There
is nothing to say a package maintainer won't end up ripping out some
config options FB needs because they become troublesome to maintain.

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

Only if someone volunteers to do it.

>> 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.

I don't consider it hubris. The tools exist to manage configuration.
Those tools needs their configuration developing as with any other
system. I just don't believe that config solely done via debian
packages is a scalable or even desirable way forward.  For some
packages you can use includes for complex cases. For others you simply
can't. And even when there are includes they need to be managed some
how.

Kind Regards,
Matt