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

[Matt Willsher]

On 1 March 2011 17:35, Jonas Smedegaard <dr at jones.dk> wrote:
> 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"!

Fair point, but we don't want to alienate some of our target audience do we?
For many it will mean "you can't communicate with your friends unless they
two have a Freedom Box". Bootstrapping secure as default is a long standing
problem that has yet to be solved adequately. Offering all methods but
favouring secure is a step in the right direction, no?

>> 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 that is the only way the can communicate with someone they want to
communicate with the answer is surely yes?

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

No, not at all. I'm saying that the secure can only be an option if both
ends support it. Thing is most users don't actually care that there mail
might be read or intercepted. Those that do are already using encryption.

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

Agreed to a limit. The box would still offer decentralisation away from the
likes of google and hotmail.

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

I agree but going from the situation now (little to no security) to your
dream is a huge step. I think we need to have bridge to steer down that
path.

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

Yes, initially, until the ground swell towards security by default exists.
Usability and putting these tools in the hands of the masses is to me what
FB is about. I'd be quite happy for 0.1 to just offer mesh or just offer
messaging in some easy to use form. This project has a long road to utopia I
believe.

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

I want us to have enough users to make this something other than a niche
device.

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

How do we market that to an audience that, on the whole, cares more about
who they communicate with not how. And even the who is open to question due
to the lack of security measures.

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

Decentralisation is a key tenant to me but again, provide a bridge to utopia
is better than nothing.

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

But if that is an important goal then all parties will assure their
security. If what they are doing is important enough they want security they
will find it. FB is about making it easier to access, to me.

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

I think we probably agree on more than it first appears :)

> 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 your point and the large response to this question has clarified a lot
for me. I agree that a separation of device identify and user identity is
ideal. Perhaps smart cards or similar technologies would help facilitate
this result?

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

I though the very same thing when I came to this part of the mail! :D

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

But something still needs to managed though linked files.

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

Yes, I saw that.

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

To me the 'competent admin' is the configuration management tool developed
by real competent admins and developers.

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

I do not believe that we should be asked the packagers to take the role of
administrator, which to me is what the above implies. I see you point. It's
just alien to me and I think it puts too much onto the package maintainers.

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

I agree. They shouldn't even need to know what OS is under the hood.

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

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

I would expect that Debian will not make config level changes with in a
release? So if we stayed with, say, squeeze for now we wouldn't face the
issue you're outlining because the upstream shouldn't be trying to jump all
over our configuration. Or is that not the case?
For going between major releases a careful and staged approach is needed.
 For many, if not most, of the packages there will be little change. The
major upgrades where there is major config changes may need some work, but I
don't see why a configuration management model outside of the packages would
be problematic. I has many benefits, including maintaining the
configuration, making sure that permissions are maintained and gives a
consistent method of orchestrating the system. Done correctly this kind of
orchestration could server as a model for other systems. Perhaps this isn't
the project to do some adventurous architecting.

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

That depends on how good it is. I can see your point about the packages, and
I can see there are benefits, I just don't see how it can be a complete
solution to the issue of configuration management. There needs to be other
methods.

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

Yes. My background is Solaris and RHEL. The explicitly do not take user
input as part of their installation. They provide reasonable defaults and
let the users tailor the installation via 'traditional' means. I like this
approach. It maintains separation. I've worked on both sides of the fence
and I like a clear divide.

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

I believe the problem domain is so complex for anything but basic packages
that it should be part of the package system. Before you know if you have
xml parsers and even  specific grammer parsers as part of the packaging
infrastructure. As a packager all I care is that the software ends on the
system and will run. What the end user does with it is up to them.
If you've not read the cfengine tutorial or maybe even better Mark Burgess
papers on promise based systems for automation I implore you do to so. If
offers a degree of flexibility that packaging within a box just can't
deliver and offers a consistent model across any scale of architecture.

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

If they loose a key maintainer you could end up with a package that isn't
'correctly' maintained between releases.

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

I believe providing all things to all people through the packages is not the
place it should be.

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

No, we let a configuration management tool do the heavy lifting. Is this the
project to develop that? Maybe not. But I can't see the Debian contributors
being able to come together to deliver everything we need to get FB
together. There will have to be some other management system available to
us.

Further to all of this the UI needs to be decoupled from the package and
software management. We really can't have a UI making direct root and
configuration calls. There has to be a controlled intermediary which just
accepts the data to be configured and applies it.


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

Ah heck, I hack at Perl. Hubris is a good things, dangnabbit (along with
that there laziness and impatience) :)

Gosh that's a long old mail. I really need to start showing something for it
rather than just giving it all this talk.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20110301/06d2db97/attachment-0001.htm>