On Tue, Mar 01, 2011 at 08:04:02PM +0000, Matt Willsher wrote:
On 1 March 2011 17:35, Jonas Smedegaard <[email protected]> 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 particular freedom.
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 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.
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 secure messaging.
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 niche device.
...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.
We don't. 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" :-DTo 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 package maintainers.
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 security issue!!!
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 -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: Digital signature
_______________________________________________ Freedombox-discuss mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/freedombox-discuss
