[Freedombox-discuss] my summary of yesterday's Hackfest
On Tue, Mar 01, 2011 at 08:04:02PM +0000, Matt Willsher wrote:
>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:
>>> The user should [not] 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?
I mean if insecure is what they want to do _with_ _FreedomBox_.
You still used gmail/Thunderbird after joining Facebook.
You will still use gmail/Thunderbird/Facebook after byuing a FreedomBox.
FreedomBox is a gadget, just like all the others. Just like all the
others (except iLife), it does not intend to take over your whole life,
only those funky new things that made you opt-in on it.
Sure whenever possible it should embrace other similar stuff. But
"insecure messaging" is *not* similar to "secure messaging". And
"secured-by-Verisign messaging" also is not "secure messaging" because
Verisign only secures transfer not content which is the focus for this
>> 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.
Certainly - FreedomBox contains multiple freedom-enabling mechanisms,
and ideally they are interconnected.
Initially you have no FreedomBox friends so messaging-without-spying is
hidden. You could pour some WebIDs into your addressbook (a secured
FOAF file) but maybe don't know that trick and instead just use e.g.
blogging-without-spying at first. After some blogreading-without-spying
and occasional comment-on-blogs-without-spying, automagically your
messaging-without-spying becomes active. Behind the scenes an automated
local sparql analysis of the RDF blogroll resolved that a blogger you
commented on also commented on one of your earlier blog entries, and her
FOAF indicates she diggs messaging-without-spying (without revealing if
through a FreedomBox or by other means): this weak two-way relationship
gets added to your addressbook and your messaging-without-spying now is
usable and presents itself in your roster/desktop/panel or however the
freedom-enabling mechanisms are presented.
>> 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
>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
How is it a bridge? you accessing FreedomBox?Squirrelmail?imap?gmail
instead of gmail directly via web provides no freedom for you (but
causes the FreedomBox UI design to compete head-to-head with gmail
design!), and do not encourage any of your friends to switch over to
Let's not waste efforts running behind gmail, but leave it be and
concentrate on what it is we have to sell: freedoms!
>> 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
...on the expense of trust. Bad trade!
>> 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.
Selling FreedomBox as a better Facebook or a better gmail is suicide.
Seeling FreedomBox as a freedom-mechanisms boxed, some of which (like
tor exit node) does things for others without any fun interface, while
others (like "secure messaging" may look and feel familiar but is a cool
new thing, not a head-to-head competitor.
>> 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.
What? Why? Try provide an example.
>>> 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.
You mean a user-friendly admin UI we provide the users of the box?
>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
Debian mindset is to provide a fully working system consumable by
"users" (both derivatives, sysadmins and end-users), not just a pile of
fully working _pieces_ for sysadmins to tie together.
>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?
Imagine a package shipping with a config value affecting security.
Then a security update will fix that - but if we had edited other parts
of same configfile, then it would trigger a question like "do you want
to replace with newer package file, keep the old, or edit?".
...or if updates where fully automated, questions would be silenced
which means it would always keep existing file - thus not fixing the
If instead we had worked with the package maintainer to have our needed
customizations remote-controllable, then the security update would
handle it correctly without questions asked.
>I don't see why a configuration management model outside of the
>packages would be problematic.
It is completely sensible to take over configfile management.
...if you believe you can do a better job at it than Debian.
Personally I do not believe that I can do a better job handling the
configfiles of the systems that I maintain as a sysadmin.
If you are a superhero at configfile handling, I really really would
want you to help integrate your juggling into Debian packages instead of
tying your magic only to FreedomBox - as then your clevernes would be
beneficial also to lots of others with similar needs.
* 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
Size: 836 bytes
Desc: Digital signature