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

Tue Mar 1 17:35:18 UTC 2011

On Tue, Mar 01, 2011 at 03:51:05PM +0000, Matt Willsher wrote:
>On 1 March 2011 01:26, Jonas Smedegaard <dr at jones.dk> wrote:

>> On Mon, Feb 28, 2011 at 09:06:00PM +0000, Matt Willsher wrote:

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

In above, your expectation then is "insecure messaging"!

>The user should have to care about the underlying protocols just the 
>task they instructing the FB to do.

I fully agree - question is if "insecure messaging" is what they want.

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

You tell me that our users cannot comprehend a new paradigm called 
"secure mail-style messaging", so for the sake of user-friendliness we 
need to drop the "secure" part?

>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 agree with your summary - We seem to disagree on what to offer:

For "freedom to send email-style messages" they do not need our box.

I want us to offer "freedom of mail-style messaging without spying" 
which can only work for FreedomBox peers (and geeks setting up same 
technologies as we are "boxing"), not their old email- or MSN- or 
Facebook-friends.

Seems you want us to offer "freedom of mail-style messaging, without 
spying whenever possible".

I want our users to trust our box, not gamble with it.

Just as cellphones did not also cover fax, and just as Facebook does not 
also cover email, our tool does not cover related but less secure 
messaging paradigms.

Whenever sensible we should cover both freedoms and non-freedoms.  
Sensible examples are blogging and tweeting: Publish to the world on 
your own device, and optionally replicate into data silos like Twitter 
and Facebook (maybe just an excerpt to help tell those still trapped 
inside those silos that the world outside is more comprehensive).  The 
freedom here is to aboid central logging at blogger.com and the silos, 
and it is ok to relax that to only _mostly_ avoid that logging.

But when the freedom is "messaging without spying" where the _content_ 
needs discretion, not transport activities of it, then being relaxed is 
more problematic.

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

Perhaps we agree,then :-)

It makes sense for me that the box contains private key(s) for its own 
identity/identities.

For identity handling of its user(s), it makes sense to me to *not* 
handle private keys, only public keys, even for the owner of the box.

...and it might make sense to then not handle GPG at all, if we judge 
that our target userbase is too non-geeky to sensibly handle GPG, but 
only can comprehend to put trust in deviced, not in humans behind them.

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

This is too big a subject to cover extensively in one email thread, I 
think. :-)

Actually, of your examples mentioned above, the Debian packaging of sudo 
now (since Squeeze) offers a config.d mechanism that other packages can 
hook into, and packaging of apache has for some time offered a (better!) 
combination of config.d and symlink-enable-disable script.

In fact I have borrowed the apache mechanism for the boxer tool I 
recently mentioned here on the list :-)

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

FreedomBox do not have the luxury of "a competent admin".  FreedomBox 
needs to work "out of the box".  Or even, ahem, "in the box" :-D

When working with configs, it is quite understandable that at first you 
see us as "admins" of the box.  But then comes a new release of Debian 
and we learn that the model of os acting as admins do not really fit: We 
_deploy_ systems and then loose contact with them.  We are _deployers_, 
not admins.  And as such we are much better off passing _all_ of our 
customizations to pristine Debian packages into Debian than trying to 
work from that new role of "deployer" which neither upstream (Debian or 
upstream coders) nor our users can comprehend.

Users get their stuff from one provider.  They should not care which 
roles was involved in which parts of the assembly of it.

Debian provide stuff for their users.  They should not care which kind 
of user (derivative distro, deployer, end-user) is targeted.

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

We perfectly agree that end-users are on their own if "hacking on top".

The issue I am talking about is that _we_ hack on the _Debian_ stuff and 
then pass it on to our users.  Then later it explodes in _their_ faces 
when _Debian_ wants to upgrade a config which _we_ hacked on.

You may argue that the box never changes.  Should not ever be upgraded 
to newer versions of Debian.  That is indeed an approach, but not a 
sensible one long-term IMO.

>>> 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 find it unlikely that next generation of freedom fighters will want 
to work on Plug devices.

But I find it highly likely that the freedom-enabling technologies that 
they will want to include in their designs share many similarities with 
our current project.

So I find it most likely that all contributions survive long-term if 
integrated with the various packages rather than is tied to the specific 
solution we aim at.

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

you see Debian packages and their usage more separate than me.

Yes, esp. complex packages are difficult to setup automated, but it is a 
goal of Debian to do so.  So please help challenge Debian to improve in 
this area!

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

how do you mean?  Each and every package in Debian has at least one 
volunteer already:  Miminum requirement is to file sensible bugreports.

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

You believe that needed configs are impossible for thousands of Debian 
volunteers to automate.

I agree with you that us tens of FreedomBox volunteers are able to 
compose needed configs by hand.

What I find Hubris is to maintain it on our own.

But sure lock down the boxes to completely acoid maintainance - the 
users can just treat them as any other consumer electronics: When 
looking dusty, just throw it away and buy something new and more shiny.

 - 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/6bcfb10f/attachment.pgp>