Re: [Freedombox-discuss] Relationship driven privacy
Indeed, and in that dividing into actionable parts the problem is consensus: consensus that we need to break it down into parts, consensus on what parts, consensus on who defined the parts. To me this is independent from mailing-list / other communication. IMO it should come from TAC / Foundation, but if doesn't the only way I see to make progress is to suggest a collection of parts, amend it with other suggestions, and convince people it's the way to go. Once we've got that, I agree that we could use tools such as Etherpad to work more efficiently, in groups coordinated in time (time zone problem pointed out by someone else). I'm not clear as to how that fits with your vision? I think - let's enlist all the possible software pieces in existing Wiki (many would see, BTW, why it's so time consuming, comparing to easy Etherpad linking, for example), i mean - all the possibly existing/preferably up-to-date/related projects, then - divide into some working group parts: It's like that Leaving-the-Cloud part in today's Wiki, but i think - it needs to be more granulated, more specific like Privacy in Social Networks, Privacy in Browsing, Security in Social Networks etc.. It's ok if there would be double-posting, in advanced systems it called tags :) Along with it - i'm sure - we'll need the detailed enlisting of existing papers, conferences, wiki's, guru's... even blogs - that all would help to work real-time with outer world and show the community that it's not - particularly Debian project but a global initiative. Since FreedomBox is essentially - an idea, i think - it's a proper place to try-out this kind of social involvement. I think, also, it's a good way to encourage consensus - when people would clearly see that we are using the best-of-breed as possible, without any personal considerations. I'll make a brave assumption, but i believe - if FreedomBox would be shown as a race for win - for any evolving project, if that evolving projects would see that - if we would be included, it's the best place to introduce and receive Global feedback, and, why not, it's a Honor to be used so massively and make real job for the world not *only* in demo/academical reality, all the involved would benefit. If I get you right, it means 0) break into parts, 1) have an overview mechanism that allows newcomers and specialized participants to understand what's going on as a whole, and 3) have specialized groups document their progress in a wiki-like space (and report synthesis of progress in a common space for all participants). Yes, briefly, it's like this - for me, if combine what i'v written above with part 0) I still think a wiki is the best tool for that overview and documentation of progress (my humble opinion), but with Etherpad used to work in the groups. I don't see Etherpad as a means to provide a clear overview of how the project is divided into parts, but rather as a developing tool. But I have used that tool very little, so maybe I am mistaken? Here is - http://apenwarr.ca/log/?m=201103#13 - some pro/cons list of what's Etherpad being able to, Etherpad could provide a slightly clearlier overview with Tag/Topic main list, I'm a part of the team named XMPP-Concurrent-Confederation-Consortium, currently - basing in ourproject.org (they use the similar to Alioth Debian collaboration system, BTW, not very useful, comparing to GitHub, really) community and trying to help Kune project's needs. The link Wave-OT-XMPP is in Leaving the Cloud wiki section. We are working on derived from Google Wave/Completely reinvented OT(concurrent editing like in Etherpad, but more Wave like, all-including experience) social systems to federate and collaborate with each other and W3C FSW participants, whenever is possible. So, basically - we are creating a next-gen of etherpad-like systems, however we are all in pre-beta, so - can't help actually - right now, but - as i'v described in Discussion system topic - there are working alternatives, that could be - what FreedomBox infrastructure need. ERP specified - like Free Cloud Alliance is working on - http://www.freecloudalliance.org (their are ERP5 adepts that i'v heard of - a very solid system, being used by NASA or kind of - institutions) would you be interested in being part of an eventual UX group? I understand we have difficulties finding people in that area. I would be glad to help with my graphic and UX skills, depending on when and how FBox UX/UI team would be formed, ofc. Moreover - we (as an XCCC members team) are working on social systems that, hopefully, in one or another way could get into FreedomBox. Now we have C++/Go/Py/JS systems in different states of progress, and with different inner-design decisions, almost - for every taste. ..Among other we are making Open Augmented Reality - systems like http://arwave.org To be honest - AR privacy and security is far more endangered now, than most of Web systems FBox is about to protect,
Re: [Freedombox-discuss] Relationship driven privacy
On Tue, 2011-07-12 at 16:05 -0300, Sébastien Lerique wrote: If the Foundation and/or the TAC want to pull back and start planning as a smaller group I'm fine with it (although I would have loved to be part of that process), I think if done properly it would even serve the goals better (as a first step at least). But if that is the case, *we should know* instead of spending time discussing stuff in the wild with some hope that someone knows where all this is going. I'm not a member of TAC and I don't speak for them. I am helping the project and what I can say though is that if you haven't seen any communication is because there isn't much new to communicate. I saw lots of email messages exchanged talking about threat models, identity, sessions, privacy and other keywords on this mailing list and these long threads may have given false impressions about the project. I would suggest to pick the first point from the list on http://freedomboxfoundation.org/learn/ * Email and telecommunications that protects privacy and resists eavesdropping and start assembling software for it. I would start putting together one debian image OS that runs on the reference hw (the GuruPlug). Then add the basic packages that go in the box on top of the OS to reach that goal (tor, anonymous remailer, automatic gpg encryption...). Here things start to get tricky: on top of apt-get there have to be sensible default configurations and an easy to use GUI to configure each package. Anybody up to this task? Cheers, stef ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Relationship driven privacy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/07/11 20:38, Stefano Maffulli wrote: On Tue, 2011-07-12 at 16:05 -0300, Sébastien Lerique wrote: If the Foundation and/or the TAC want to pull back and start planning as a smaller group I'm fine with it (although I would have loved to be part of that process), I think if done properly it would even serve the goals better (as a first step at least). But if that is the case, *we should know* instead of spending time discussing stuff in the wild with some hope that someone knows where all this is going. I'm not a member of TAC and I don't speak for them. I am helping the project and what I can say though is that if you haven't seen any communication is because there isn't much new to communicate. That's very possible indeed. But I would still like to know what role the Foundation and the TAC have. The role I understand for the TAC, having been introduced by the Foundation, is in being a legitimate body to help get a consensus on where we're going and _how_ to get there (not necessarily being advisory for technical stuff, since a community of experts like we probably have on this list --not including myself-- could very well fill that role I believe). That consensus is missing, I believe. Though I could very well be mistaken. I saw lots of email messages exchanged talking about threat models, identity, sessions, privacy and other keywords on this mailing list and these long threads may have given false impressions about the project. I would suggest to pick the first point from the list on http://freedomboxfoundation.org/learn/ * Email and telecommunications that protects privacy and resists eavesdropping Yes I think it is a good way to go (and could fit in a group dedicated to privacy questions). But what does protect privacy mean? Is it only encryption? End-to-end encryption? Do you want to include stuff like Wave, for which you have to trust intermediate servers? Does privacy include hiding your network of contacts or what websites you visit? Do we want to avoid profiling from the websites a user visits (based on browser fingerprinting, etc.)? How can that be done? And many more questions. and start assembling software for it. I would start putting together one debian image OS that runs on the reference hw (the GuruPlug). Then add the basic packages that go in the box on top of the OS to reach that goal (tor, anonymous remailer, automatic gpg encryption...). Here things start to get tricky: on top of apt-get there have to be sensible default configurations and an easy to use GUI to configure each package. Anybody up to this task? That is a way to go, but I don't think we will build a FreedomBox that will spread if we head right into packaging. I do understand that coding is important and that we can't stay chatting for life, but I don't think the existing code can give us all we're aiming for, yet. So to write that missing code, I think it would be useful to understand what we want to write before starting. This is my view of things, after you've given yours. And unless one of us convinces the other or has more legitimacy than the other (which could very well be the case, because I have near to none I believe), we'll each go our way and do what we think is best. This is where the TAC could enter and say we, as the Foundation or as TAC people, think it's best to do like this or like that. Now I know this is not the way things usually work in free software dev. But, as I understand, Fbx has ambitions to build greater than before. To try and make my point clearer, let's take an example. Here's what James Vasile said on the TAC list back in June[0]: The more I think about the FreedomBox, the more I realize it needs a unified notion of a person and all the things we might want to remember about that person. Individual apps might consume that info and supplement it with additional databases, but there is surely some core of information, centrally located that can tell us who we love and who we trust and how to find them and talk to the them securely. Maybe we also want to know what services this box provides for that person or even hold some auth credentials, etc. The FreedomBox is special because we're building social deep in its heart. It feels right that if my FreedomBox trusts your microblog feed it also trusts your macroblog feed and knows where to find your photos-- even if all that stuff is on different boxes and run from different services. So how do we start defining that person model? And how does developing this model fit into the roadmap? Which sounds fantastic to me. But I see no way of doing this with existing software. Sam Hartmann answered[1], and things are very clear here: I strongly agree this is necessary. One of the hardest things to accomplish in a system like Debian is to provide this sort of unification
Re: [Freedombox-discuss] Relationship driven privacy
On 11-07-08 at 02:50pm, John Walsh wrote: At connection time, I should be allowed to opt-in to having my name published by a friend - it is my identity after all. I was also reminded about what I consider a major privacy flaw in all social networks. When you post to your wall you are posting to friends of your friends - you have no control over who sees your message on a friends wall. [snip] Another wish of mine, would be that for each profile you can define your messages/content maximum degree of separation from you. I recommend to pass such ideas (preferrably backed by code, obviously) to the [group] that develops interoperability standards for federated social networks! Last month was a coordination [meeting] in Berlin ([videos] available for some parts), and a few days ago a [follow-up mail] seems to touch this very issue (point #3). I believe discussing implementation details with the folks actually implementing is much more productive than doing it here ;-) - Jonas [group]: http://federatedsocialweb.net/ [meeting]: http://d-cent.org/fsw2011/ [videos]: http://d-cent.org/fsw2011/videos/ [follow-up mail]: http://groups.google.com/group/ostatus-discuss/browse_thread/thread/7f15df316d6c14d3 -- * 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 Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Relationship driven privacy
seems like we keep walking in circles how do we allow users to identify themselves or each other, yet remain anonymous. The process of identifying a user, determining someone is who they say they are crosses the threshold and puts the said user at risk of being identified ect ect. Yes, all aspects of freedombox should work to support user privacy, prevent identifying sources ect ect... though we cant keep pretending that we can identify a user without identifying them. The social networking is just one aspect of the freedombox, and some would argue its not a critical part because we could implement services that are already developed (Diaspora) and make modifications to enforce stronger privacy (if needed) and to work on our darknet/mesh ect ect. Im not sure why we keep talking about social networking. The guy that leaks information on a government, on a corporation, who posts information that a goverment is going to want to take down and arrest someone for these people should not be interested in a default associative property that is linked to the entire freedombox. The user should be in charge of setting up a pseudo-anonymous identity on service xyz. now, i know that the freedombox is going to be used by average individuals that are not interested in remaining anonymous for what ever reason. But lets not kid ourself, social networking is social networking... we can increase the privacy, make strong privacy relation policys, but posting your pictures and life story on a service is not in any way shape or form ... logical. we are not creating a cool new facebook, we are creating an entire new network that allows users to communication and preform operations on the net without fear of reprecussion or repression. And most importantly we are creating ways for users to use the Internet (if you would even call it that anymore) anonymously and that is not subject to centerlized services .. kill switches.. dns tdl blocks ect ect. On Fri, Jul 8, 2011 at 4:32 AM, Jonas Smedegaard d...@jones.dk wrote: On 11-07-08 at 02:50pm, John Walsh wrote: At connection time, I should be allowed to opt-in to having my name published by a friend - it is my identity after all. I was also reminded about what I consider a major privacy flaw in all social networks. When you post to your wall you are posting to friends of your friends - you have no control over who sees your message on a friends wall. [snip] Another wish of mine, would be that for each profile you can define your messages/content maximum degree of separation from you. I recommend to pass such ideas (preferrably backed by code, obviously) to the [group] that develops interoperability standards for federated social networks! Last month was a coordination [meeting] in Berlin ([videos] available for some parts), and a few days ago a [follow-up mail] seems to touch this very issue (point #3). I believe discussing implementation details with the folks actually implementing is much more productive than doing it here ;-) - Jonas [group]: http://federatedsocialweb.net/ [meeting]: http://d-cent.org/fsw2011/ [videos]: http://d-cent.org/fsw2011/videos/ [follow-up mail]: http://groups.google.com/group/ostatus-discuss/browse_thread/thread/7f15df316d6c14d3 -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss -- Thank you for your time ~Nathan nathan1...@gmail.com ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Relationship driven privacy
i think keysignings violate lutzs ease of use (grandma can use it) rule . On Wed, Jul 6, 2011 at 3:01 PM, Daniel Kahn Gillmor d...@fifthhorseman.netwrote: On 07/06/2011 02:43 PM, Tony Godshall wrote: Obviously a keysigning party is not appropriate for people who want to be anonymous. But I don't see why, if you've verified a claimed identity in some other reasonable sense you cannot sign someone's key even if its pseudonymous. i agree; given the fluidity of names, a persistent pseudonym can have at least as much value in terms of establishing identity as a government-approved official name. For example, a public activist now living in a free country might want to indicate trust of a pseudonymous source living under a brutal regime, Standard OpenPGP certifications do *not* indicate trust. They are assertions of identity and key-ownership. If the repressed source is known only publicly as fubar127, the non-repressed activist can use OpenPGP certifications to assert that fubar127 does in fact hold key X. and this public activist might want to convey the existence of such trust to news media / bloggers, etc. Again, the public activist does *not* need to indicate any level of trust here; merely that they believe the individual known as fubar127 does in fact hold key X. without compromising the source's true identity. I'd use the term official or government-issued identity here, since in the public sphere, fubar127 is at least as much their true identity as any other identity they hold. That way the various parties could distinguish communiques from that source vs. the regime's disinformation even if the original public activist is assassinated. Yep. Again, to be clear, this is about management of public identities, and binding public keys to public identities. it's not about trust. I think the critical insight here is: A persistent identity bound to strong public key is essential to being able to make a stable and lasting contribution to a globally-networked culture. It doesn't matter whether the identity is your official identity or not; and it doesn't even necessarily matter what form the cryptographic material takes (a self-signed X.509 certificate or even a raw public key might be sufficient in some cases). Having good ways that other people can publicly state their belief in your key+identity relationship is a good way to help ensure that your presence on the network will be difficult to remove, obscure, or infiltrate through technical means. --dkg ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss -- Thank you for your time ~Nathan nathan1...@gmail.com ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Relationship driven privacy
On 07/07/2011 02:41 AM, nathan nolast wrote: i think keysignings violate lutzs ease of use I agree that current keysigning methods are cumbersome, primarily due to the requirement that human beings have to cognitively process long hexadecimal strings (large numbers). I recommend reviewing the discussion elsewhere on this list about a new keysigning process proposed, going under various names like monkeysign or bump or hi-five, which should make the act of keysigning smoother and simpler. Hopefully it will allay some of your concerns. If it does not, i'd like to hear counter-proposals for how people can actually take control of their own security without any form of explicit key verification. Even the act of delegating all network identity decisions to a third party should include securely fetching and verifying a public key associated with that third party. (grandma can use it) rule . Can we please stop using grandma as the canonical non-technical user? The gender and age prejudice implicit in these statements only hurts efforts to build a diverse development community (and makes the community look like thoughtless jerks). If you don't personally know any technically competent older women (or younger women, who may one day become grandmas themselves, without losing any of their technical chops), i recommend getting to know more people out of your own age/gender bracket (i'm assuming from the name in your e-mail that you identify as male). Technically competent older women (some of whom are indeed grandmothers) are not unicorns, but I wouldn't blame any of them for not wanting to collaborate with a project that sees them only as grandma. Thanks, --dkg signature.asc Description: OpenPGP digital signature ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Relationship driven privacy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/06/2011 02:43 PM, Tony Godshall wrote: anonymous. But I don't see why, if you've verified a claimed identity in some other reasonable sense you cannot sign someone's key even if its pseudonymous. You can sign a pseudanonymous key and publish it. What you have to be cognizant of, however, is the trust level of the pseudanonymous key (set when the public key is signed), which ranges from 0 (no trust at all) to 5 (trust fully). That metric goes into the list of signatures a public key has picked up, and can make the difference between software using a key, using the wrong key, or not using the right key. It also can make the difference between people actively encrypting stuff to that public key (I know that key really belongs to J. Random Activist because the following six dozen people I have some trust in know that the keypair belongs to a fellow activist.) and avoiding contact with that user (Not many people trust that this public key really belongs to J. Random Activist; maybe it belongs to an impostor. I won't trust that key or use it to contact that person.) http://www.gnupg.org/gph/en/manual.html#AEN346 - -- The Doctor [412/724/301/703] PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: http://drwho.virtadpt.net/ Anger is always the shortest distance to a mistake. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4V/LsACgkQO9j/K4B7F8HguQCdG5vNNArGR52JJX1sICspksTb 5xcAoPG+QMJ9Q33SI5ejm73xwiil+XYc =rWx5 -END PGP SIGNATURE- ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Relationship driven privacy
On 07/07/2011 02:36 PM, The Doctor wrote: You can sign a pseudanonymous key and publish it. What you have to be cognizant of, however, is the trust level of the pseudanonymous key (set when the public key is signed), which ranges from 0 (no trust at all) to 5 (trust fully). Urgh, this is not the case. Normal OpenPGP certifications do *not* contain any indication of trust. GPG stores *private* ownertrust levels for each public key in its keyring. The user in control of the keyring gets to decide which keyholders to rely on for identity certification, and can change those decisions at will. That metric goes into the list of signatures a public key has picked up, Again, standard public OpenPGP certifications do *not* contain any indication of trust. Private decisions about ownertrust are factored against publicly-(or privately-)stated certifications of identity. But the identity certifications do *not* contain trust information. (I know that key really belongs to J. Random Activist because the following six dozen people I have some trust in know that the keypair belongs to a fellow activist.) This is exactly right; in this scenario, the trust is a privately-held piece of information (people i have some trust in), and the certifications simply say i know that this key belongs to the person identified by the User ID. (Not many people trust that this public key really belongs to J. Random Activist; maybe it belongs to an impostor. I won't trust that key or use it to contact that person.) This is subtly mistaken, i think. it's not not many people trust that this public key belongs to..., but rather no one *who i trust* has stated that this key belongs to... That is, the certifiers are stating knowledge of identity and key ownership, not trust. The *evaluators* of the OpenPGP certificates get to decide which certifiers they're willing to rely on (or trust). But the evaluators make these trust decisions privately, and independently of doing any certifications themselves. hope this helps clarify things, --dkg PS there is such a thing as a trust signature in the OpenPGP spec, but it is extremely rare in practice, and should probably remain so. Separating identification from trust has many nice properties that we shouldn't throw away. signature.asc Description: OpenPGP digital signature ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Relationship driven privacy
On Thu, Jul 7, 2011 at 2:41 PM, nathan nolast nathan1...@gmail.com wrote: i think keysignings violate lutzs ease of use (grandma can use it) rule . Is it enough if people just sign their grandmas' keys? ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Relationship driven privacy
Hi Mike and Everybody Friendika was mentioned in this thread but in a different context, so I wanted to point out what we do for profile personas. There may be some ideas you can use. It's a distributed system, but has multiple profiles. You can tailor any profile for any person or group of people. There is a default public profile. You can make this as sparse as you wish. Maybe just your name and what country you live in. Then you can add richer information specifically for different friends or groups. Some people might be able to see your email address. Others might be able to see your hobbies. Bu rather than control visibility of individual profile fields, you can instead build complete profiles specific to any audience - and have completely different contents in any of the fields - if you wish. To the ladies you can be a jet pilot, while your co-workers will see the truth. You can also clone any existing profile if you only want to change one thing for a particular audience but leave the rest the same. We make these available to individuals due to DFRN's authentication scheme. It's a dual-authenticated PKI exchange which establishes the identity of both sides of the communication stream - and in the case of profiles can then issue a browser cookie giving you a 'visitor id', which gives you certain rights on the remote system. You can post to your contact's profile wall and leave comments there, you can view private photos, and you can be assigned a profile specific to you. (No other distributed social service has these abilities that I'm aware of.) There are no password challenges between sites. No OAuth crap. All the visitor does is click on a profile link, and they are taken to the correct profile that they are allowed to see. Any failures in authentication take them to the default profile. It's a pretty slick system. Thanks for pointing out the flexibility of Profiles. I liked the way Friendika links profiles to an account and then you link a profile to a contact at connection time. You have full control of your personal identifible data - Fantastic. Using a social network service again reminded me of a pet peeve of mine. All social networks have a friend decide whether to publish me in their friends list. At connection time, I should be allowed to opt-in to having my name published by a friend - it is my identity after all. I was also reminded about what I consider a major privacy flaw in all social networks. When you post to your wall you are posting to friends of your friends - you have no control over who sees your message on a friends wall. Most of the time, my partner uses the FaceBook messaging system (email) because it's the only safe way of making sure that messages aren't leaked by friends of friends. This means social networks are a great way of connecting people, but they are not very effective at communicating with people because even if you separate messages through relationship-based groups as soon as you post to a wall all that work can fall apart. I think the solution is that we need a more social email interface than trying to fix the wall model. Basically, you have the Wall/Stream UI with content coming into you like your email inbox. In a sidebar you would have a list of Groups/Contacts (no Outlook folders/apps). You (the user) filter the content received (no more throwing over the wall), like you do with your email inbox and you forward the content by dropping it on a contact or group. When you click on a contact/Group you will see all their messages/content. Click reply to a message and it will go to that contact/Group. Another wish of mine, would be that for each profile you can define your messages/content maximum degree of separation from you. For example, if I define 1 degree of separation for my friends profile, then all my messages can be sent to my friends, but my friends would not be able to forward it to their friends without getting an error message saying you cannot forward the message. If you have 2 degrees of separation then a friend of a friend would not be allowed to forward the message to their friends. This would prevent message/content leaks. Of course, this could be circumvented, but that would be a deliberate act rather than an accident which I think happens too often with the Facebook Wall Model. What do people think? Is this a reflection of the FreedomBox Model or do you think my privacy wishes are a step too far? Do you have any other ideas for FreedomBox privacy models? ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Relationship driven privacy
Um... keysingings? https://secure.wikimedia.org/wikipedia/en/wiki/Key_signing_party Not that they're particularly user-friendly :-( Keysigning parties work well, but if pseudanonymity is your goal you'll have to either accept a much lower trust rating from everyone there because you won't produce ID, or you'll have to sit it out. Obviously a keysigning party is not appropriate for people who want to be anonymous. But I don't see why, if you've verified a claimed identity in some other reasonable sense you cannot sign someone's key even if its pseudonymous. For example, a public activist now living in a free country might want to indicate trust of a pseudonymous source living under a brutal regime, and this public activist might want to convey the existence of such trust to news media / bloggers, etc. without compromising the source's true identity. That way the various parties could distinguish communiques from that source vs. the regime's disinformation even if the original public activist is assassinated. Tony ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Relationship driven privacy
On 07/06/2011 02:43 PM, Tony Godshall wrote: Obviously a keysigning party is not appropriate for people who want to be anonymous. But I don't see why, if you've verified a claimed identity in some other reasonable sense you cannot sign someone's key even if its pseudonymous. i agree; given the fluidity of names, a persistent pseudonym can have at least as much value in terms of establishing identity as a government-approved official name. For example, a public activist now living in a free country might want to indicate trust of a pseudonymous source living under a brutal regime, Standard OpenPGP certifications do *not* indicate trust. They are assertions of identity and key-ownership. If the repressed source is known only publicly as fubar127, the non-repressed activist can use OpenPGP certifications to assert that fubar127 does in fact hold key X. and this public activist might want to convey the existence of such trust to news media / bloggers, etc. Again, the public activist does *not* need to indicate any level of trust here; merely that they believe the individual known as fubar127 does in fact hold key X. without compromising the source's true identity. I'd use the term official or government-issued identity here, since in the public sphere, fubar127 is at least as much their true identity as any other identity they hold. That way the various parties could distinguish communiques from that source vs. the regime's disinformation even if the original public activist is assassinated. Yep. Again, to be clear, this is about management of public identities, and binding public keys to public identities. it's not about trust. I think the critical insight here is: A persistent identity bound to strong public key is essential to being able to make a stable and lasting contribution to a globally-networked culture. It doesn't matter whether the identity is your official identity or not; and it doesn't even necessarily matter what form the cryptographic material takes (a self-signed X.509 certificate or even a raw public key might be sufficient in some cases). Having good ways that other people can publicly state their belief in your key+identity relationship is a good way to help ensure that your presence on the network will be difficult to remove, obscure, or infiltrate through technical means. --dkg signature.asc Description: OpenPGP digital signature ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Relationship driven privacy
On 4 Jul 2011, at 15:50, Melvin Carvalho wrote: You dont need AX (attribute exchane), just use the HTML5 data layer, which should be fine if freedom box is hosting a web server. I looked at WebID a year ago and thought the idea was simple and brillant. However, at the time, I thought WebID had an ugly interface (due to Firefox), there was no Persona's (AX) option, it wasn't clear to me what happens when a certificate expires and it wasn't widely used. What has changed? Well Chrome has a much better interface now, for example. But it could be a lot better still. Please also vote on this bug report: http://code.google.com/p/chromium/issues/detail?id=29784 But again user interface issues are not what is stopping people here building a wholly new stack. The UI is good enough to get going. Getting the browser vendors to improve their UI can be done either by helping out or by putting some pressure on them. And one way to put pressure is to show how useful client side certs can be with WebID by implementing cool services that use it. You need to work your way around some of the UI issues. But that is just what engineering is about. It's not that complicated. Hopefully this video gives an overview of where things are. http://www.youtube.com/watch?v=rnoRQZCL9I4 (from http://webid,info ) It's also in ogg format on http://webid.info/ embedded in html5. It shows exactly what the issue that WebID has. And in fact it turns out that it is the same problem cookies have: you can't see what identity you are using in your browser. This is a political issue that needs to be fought to give the users the ability to see what their persona is - be it with cookies or certificates. The WebID incubator group is working with browser vendors to fix bugs. yes, but we really need people to put pressure on the vendors. They won't fix anything by themselves. Here's one it would be helpful to vote up: https://bugzilla.mozilla.org/show_bug.cgi?id=396441 Social Web Architect http://bblfish.net/ ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Relationship driven privacy
Submit a patch. Its open source. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Henry Story henry.st...@bblfish.net wrote: On 4 Jul 2011, at 15:50, Melvin Carvalho wrote: You dont need AX (attribute exchane), just use the HTML5 data layer, which should be fine if freedom box is hosting a web server. I looked at WebID a year ago and thought the idea was simple and brillant. However, at the time, I thought WebID had an ugly interface (due to Firefox), there was no Persona's (AX) option, it wasn't clear to me what happens when a certificate expires and it wasn't widely used. What has changed? Well Chrome has a much better interface now, for example. But it could be a lot better still. Please also vote on this bug report: http://code.google.com/p/chromium/issues/detail?id=29784 But again user interface issues are not what is stopping people here building a wholly new stack. The UI is good enough to get going. Getting the browser vendors to improve their UI can be done either by helping out or by putting some pressure on them. And one way to put pressure is to show how useful client side certs can be with WebID by implementing cool services that use it. You need to work your way around some of the UI issues. But that is just what engineering is about. It's not that complicated. Hopefully this video gives an overview of where things are. http://www.youtube.com/watch?v=rnoRQZCL9I4 (from http://webid,info ) It's also in ogg format on http://webid.info/ embedded in html5. It shows exactly what the issue that WebID has. And in fact it turns out that it is the same problem cookies have: you can't see what identity you are using in your browser. This is a political issue that needs to be fought to give the users the ability to see what their persona is - be it with cookies or certificates. The WebID incubator group is working with browser vendors to fix bugs. yes, but we really need people to put pressure on the vendors. They won't fix anything by themselves. Here's one it would be helpful to vote up: https://bugzilla.mozilla.org/show_bug.cgi?id=396441 Social Web Architect http://bblfish.net/ _ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Relationship driven privacy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/01/2011 11:14 PM, Tony Godshall wrote: Um... keysingings? https://secure.wikimedia.org/wikipedia/en/wiki/Key_signing_party Not that they're particularly user-friendly :-( Keysigning parties work well, but if pseudanonymity is your goal you'll have to either accept a much lower trust rating from everyone there because you won't produce ID, or you'll have to sit it out. - -- The Doctor [412/724/301/703] PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: http://drwho.virtadpt.net/ It's an animal thing. --Riddick -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4TTTMACgkQO9j/K4B7F8EHFQCg3XuXg7f8e1a5dC1KIz9UTXAD Qr8AnjHqACu4chv8iBy1CE4v/mmIVShz =KAhE -END PGP SIGNATURE- ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Relationship driven privacy
On 4 July 2011 07:25, John Walsh fiftyf...@waldevin.com wrote: Hi Melvin, From: Melvin Carvalho [mailto:melvincarva...@gmail.com] Basically at myopenid.com you can create different Personas (profiles of information), which you choose at the time you login with openid. For me you could have a friend persona, a sibling persona etc. I believe the technical term is attribute exchange. If freedombox friend process had a similar UI then there would be no distinguishable difference between the user. Myopenid is a good model, and great interface, but openid has shifted to more corporate, rather than it's original user centric roots. Hosting your own profile is barely supported by OpenID these days, but we can do that same thing with WebID which is user centric. I didn't know that hosting your own profile was barely supported now. That's a pity and would probably rule out OpenID as an option for FreedomBox. There are some people in the OpenID ecosystem that still like the self hosting pattern, so you never know things may change. However, it's not really seen as a priority by the board. You dont need AX (attribute exchane), just use the HTML5 data layer, which should be fine if freedom box is hosting a web server. I looked at WebID a year ago and thought the idea was simple and brillant. However, at the time, I thought WebID had an ugly interface (due to Firefox), there was no Persona's (AX) option, it wasn't clear to me what happens when a certificate expires and it wasn't widely used. What has changed? Hopefully this video gives an overview of where things are. http://www.youtube.com/watch?v=rnoRQZCL9I4 (from http://webid,info ) The WebID incubator group is working with browser vendors to fix bugs. Here's one it would be helpful to vote up: https://bugzilla.mozilla.org/show_bug.cgi?id=396441 ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Relationship driven privacy
Friendika was mentioned in this thread but in a different context, so I wanted to point out what we do for profile personas. There may be some ideas you can use. It's a distributed system, but has multiple profiles. You can tailor any profile for any person or group of people. There is a default public profile. You can make this as sparse as you wish. Maybe just your name and what country you live in. Then you can add richer information specifically for different friends or groups. Some people might be able to see your email address. Others might be able to see your hobbies. Bu rather than control visibility of individual profile fields, you can instead build complete profiles specific to any audience - and have completely different contents in any of the fields - if you wish. To the ladies you can be a jet pilot, while your co-workers will see the truth. You can also clone any existing profile if you only want to change one thing for a particular audience but leave the rest the same. We make these available to individuals due to DFRN's authentication scheme. It's a dual-authenticated PKI exchange which establishes the identity of both sides of the communication stream - and in the case of profiles can then issue a browser cookie giving you a 'visitor id', which gives you certain rights on the remote system. You can post to your contact's profile wall and leave comments there, you can view private photos, and you can be assigned a profile specific to you. (No other distributed social service has these abilities that I'm aware of.) There are no password challenges between sites. No OAuth crap. All the visitor does is click on a profile link, and they are taken to the correct profile that they are allowed to see. Any failures in authentication take them to the default profile. It's a pretty slick system. ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Relationship driven privacy
On 3 July 2011 00:58, John Walsh fiftyf...@waldevin.com wrote: Behalf Of Tony Godshall ... The same principle exist between a reporter and a whistleblower. The pseudonymity article suggests the technology exists to protect freedom fighters through unlinkable pseudonyms. It's important, I think, to be able to extend the web of trust to people we can identify and trust, not just the I met at a key signing and confirmed his government ID, but also the guy who organized the protest and wears the baseball cap and shades and owns the freedomfigher...@gmail.com e-mail address... Agree Outside the FreedomBox network, I will still need to access websites using the insecure practise of username/password. ... Not so insecure if the password is encrypted... indeed it may be more secure than carrying around media containing your key, which may be taken from you by an authority... The hard thing to know is if your password is encrypted and the password rules are constantly changing the rules for password. Does this password require numbers only? At least one capital letter? Are non-alphanumeric characters required or accepted? Can the sites staff see the password so that you must come up with another new password to remember? Finally you only get 3 chances from your 20 possible password before we disable your account. For me, a master password to your keys for is the best option ... I would like to see FreedomBox support OpenID and WebID i.e. the FreedomBox owner is the identity manager. OpenID is in wide use, and has personas which is similar to relationship profiles. WebID is more secure than OpenID, but AFAIK does not have relationship profiles and is not widely used. Can you tell us more? Basically at myopenid.com you can create different Personas (profiles of information), which you choose at the time you login with openid. For me you could have a friend persona, a sibling persona etc. I believe the technical term is attribute exchange. If freedombox friend process had a similar UI then there would be no distinguishable difference between the user. Myopenid is a good model, and great interface, but openid has shifted to more corporate, rather than it's original user centric roots. Hosting your own profile is barely supported by OpenID these days, but we can do that same thing with WebID which is user centric. You dont need AX (attribute exchane), just use the HTML5 data layer, which should be fine if freedom box is hosting a web server. Why can't new users today create their own account after passing a challenge test using their personal information? The challenge test would be performed on a device (MAC address registered on server) in a secure area (identity check required for area access) and the user's personal information must already exist on the HR/owner's server (Web of Trust). Well, that's opens our freedom fighter up for compromise, doesn't it? Our oppressed hero probably wants all his activities done under one or more pseudonyms... I am not suggesting FreedomBox do this, but wonder why doesn't this WOT model exist already? I wasn't really thinking of a freedomfighter use case. More like a secure place such as a home or office. I can't understand why granting access to a system is not automated when you have the new employees details in a HR database or at home when a family member is listed in the owner's address book Um... keysingings? https://secure.wikimedia.org/wikipedia/en/wiki/Key_signing_party Not that they're particularly user-friendly :-( Tony ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Relationship driven privacy
Hi Tony, -Original Message- From: apgodsh...@gmail.com [mailto:apgodsh...@gmail.com] On Behalf Of Tony Godshall Sent: Sunday, 3 July 2011 2:04 AM To: fiftyf...@waldevin.com Cc: freedombox-discuss@lists.alioth.debian.org Subject: Re: [Freedombox-discuss] Relationship driven privacy ... Another concern for me is the project has a BSD license. Does this make it incompatible with the freedombox project? Which licences does the freedombox support? ... The BSD license without the advertising clause meets all relevant FLOSS definitions: https://secure.wikimedia.org/wikipedia/en/wiki/Debian_Free_Sof tware_Guidelines http://www.opensource.org/osd.html http://www.gnu.org/licenses/license-list.html#ModifiedBSD Thanks for the links. It's a pity the modified BSD license doesn't have it's own unique name to avoid all the confusion because I cannot tell which BSD license it uses. It was interesting learning about the social contract. I don't think Friendika's will be accepted by Freedom because it hooks into social networks i.e. leaking people's privacy. There is a new fork (Friendika-Z) within the project to not hook into social networks. That might be of interest to FreedomBox and it's license when the fork is released. ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Relationship driven privacy
From: J David Eisenberg [mailto:jdavid.eisenb...@gmail.com] You might also want to investigate Friendika (1); I'm running a Friendika server (2), and it also allows groups, though I haven't worked with them extensively. The Friendika protocol is documented and in the public domain (3) (1) http://project.friendika.com/ (2) http://friendika.dsn-test.com/ (3) http://info.dfrn.org/ and http://dfrn.org/dfrn2.pdf Thanks for the links. The Friendika features are quite impressive for a 1 year old project. I read the protocol documentation until it got too technical for me. I created an account to see a clean UI with plenty of features. I haven't played with it that much but initial impressions are good. Friendika's documentation makes a good point that all communications do not need to be reciprocal. Boy gives a girl his number allowing the girl to call him, but the boy cannot call the girl until she gives him permission(her number). I never thought of that use case. The Friendika documentation states that distribution is limited to friends of friends with a license attached (nice) and you can revoke your content from people on a dfrn network node. I like that a content owner can revoke their publications from people on the dfrn network. However, I was concerned with Friendika's claim that they protect your privacy after having connected to the Facebook network in a recent release and now the project is created a fork that will not connect to other networks. Another concern for me is the project has a BSD license. Does this make it incompatible with the freedombox project? Which licences does the freedombox support? ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Relationship driven privacy
... Another concern for me is the project has a BSD license. Does this make it incompatible with the freedombox project? Which licences does the freedombox support? ... The BSD license without the advertising clause meets all relevant FLOSS definitions: https://secure.wikimedia.org/wikipedia/en/wiki/Debian_Free_Software_Guidelines http://www.opensource.org/osd.html http://www.gnu.org/licenses/license-list.html#ModifiedBSD ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Relationship driven privacy
... Friendika's documentation makes a good point that all communications do not need to be reciprocal. Boy gives a girl his number allowing the girl to call him, but the boy cannot call the girl until she gives him permission(her number). I never thought of that use case. ... Yes, I think it's important to be able to control who has access and how much access to the material one publishes through one's freedombox even if who is only known by pseudonym. ... and in my mind that extends to controlling even what the (real) ip address of one's freedombox is because that would give the authorities a method to identify one and our protester could be no more... Tony ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Relationship driven privacy
Behalf Of Marc Manthey At the time you friend (connect) a profile instead of Accept you must choose a relationship(s) (sibling, parent, etc.) or Ignore. The same as facebook this relationship selection remains private. These relationships can be based on XFN(1). This minimises leaking and optimises privacy based on relationships. yep, thats exactly the same google + does (circles ) So you are saying Google forces the user to place a friend in at least one circle? check this paper guys, we dont need to reinvent the wheel A Hybrid P2P/Infrastructure Platform for Personal and Social Internet Services http://research.nokia.com/files/pimrc08-camera.pdf I tried reading the paper but it was too technical for me. I am not trying to reinvent the wheel. I just thought FreedomBox would only accept stable software. AFAIK there was no stable social networking software. At first glance friendika seems stable to me with a version number of 2.2, but you guys are the techies. Will friendika be excluded from selection because of it's BSD license? ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Relationship driven privacy
Behalf Of Tony Godshall ... The same principle exist between a reporter and a whistleblower. The pseudonymity article suggests the technology exists to protect freedom fighters through unlinkable pseudonyms. It's important, I think, to be able to extend the web of trust to people we can identify and trust, not just the I met at a key signing and confirmed his government ID, but also the guy who organized the protest and wears the baseball cap and shades and owns the freedomfigher...@gmail.com e-mail address... Agree Outside the FreedomBox network, I will still need to access websites using the insecure practise of username/password. ... Not so insecure if the password is encrypted... indeed it may be more secure than carrying around media containing your key, which may be taken from you by an authority... The hard thing to know is if your password is encrypted and the password rules are constantly changing the rules for password. Does this password require numbers only? At least one capital letter? Are non-alphanumeric characters required or accepted? Can the sites staff see the password so that you must come up with another new password to remember? Finally you only get 3 chances from your 20 possible password before we disable your account. For me, a master password to your keys for is the best option ... I would like to see FreedomBox support OpenID and WebID i.e. the FreedomBox owner is the identity manager. OpenID is in wide use, and has personas which is similar to relationship profiles. WebID is more secure than OpenID, but AFAIK does not have relationship profiles and is not widely used. Can you tell us more? Basically at myopenid.com you can create different Personas (profiles of information), which you choose at the time you login with openid. For me you could have a friend persona, a sibling persona etc. I believe the technical term is attribute exchange. If freedombox friend process had a similar UI then there would be no distinguishable difference between the user. Why can't new users today create their own account after passing a challenge test using their personal information? The challenge test would be performed on a device (MAC address registered on server) in a secure area (identity check required for area access) and the user's personal information must already exist on the HR/owner's server (Web of Trust). Well, that's opens our freedom fighter up for compromise, doesn't it? Our oppressed hero probably wants all his activities done under one or more pseudonyms... I am not suggesting FreedomBox do this, but wonder why doesn't this WOT model exist already? I wasn't really thinking of a freedomfighter use case. More like a secure place such as a home or office. I can't understand why granting access to a system is not automated when you have the new employees details in a HR database or at home when a family member is listed in the owner's address book Um... keysingings? https://secure.wikimedia.org/wikipedia/en/wiki/Key_signing_party Not that they're particularly user-friendly :-( Tony ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Relationship driven privacy
We can do it like Facebook. Everybody friends your profile and you manually group them. The grouping is private in that your friends don't know what groups they're in (and most of the time, even if they've been grouped at all). At the time you friend (connect) a profile instead of Accept you must choose a relationship(s) (sibling, parent, etc.) or Ignore. The same as facebook this relationship selection remains private. These relationships can be based on XFN(1). This minimises leaking and optimises privacy based on relationships. yep, thats exactly the same google + does (circles ) We can do it like Diaspora. Explicit groups where the interface requires that you group people and is public about which groups you're interacting with when. I haven't explore Diaspora because I thought it was alpha software. Well it is same with http://project.friendika.com , but worth to have a look at. Another approach is to use URLs. Give all your friends the http://fbox.example.com/wild-and-crazy-guy address. Give your family the http://fbox.example.com/pious-father address. Give your coworkers the http://fbox.example.com/always-at-my-desk address. Each of these are just different views of the same profile. And then you could manually change what people see if somebody's status changes from, say, /boyfriend to /ex-boyfriend. Exactly, thats what i am talking about !!! +1 The interface should be obvious about which groups you are talking to. Perhaps the css could change in obvious ways (backrgound color?) or perhaps the software could be smart enough to know you don't want to share me-drunk.png with the group labelled WORK I think change of colour is important for mixed groups, e.g. you have people in a group with different relationships and no mutual relationships. Done in google + IMHO check this paper guys, we dont need to reinvent the wheel A Hybrid P2P/Infrastructure Platform for Personal and Social Internet Services http://research.nokia.com/files/pimrc08-camera.pdf greetings marc -- Les enfants teribbles - research / deployment Marc Manthey- Vogelsangerstrasse 97 50823 Köln - Germany Tel.:0049-221-29891489 Mobil:0049-1577-3329231 blog: http://let.de twitter: http://twitter.com/macbroadcast/ facebook : http://opencu.tk ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Relationship driven privacy
please, take a look on XMPP initiatives for federated social staff with security and privacy in mind. XMPP is very flexible and mature stack of protocols, and, with all respect, we'll need the flexibility. i'll repost: http://primarypad.com/OeMj2ZnZqo list, there are - enough projects in various states of progress. Visual design and compound - i think - is the last thing to worry about now, there is a need of strong - federated kernels upon which we could build any design. BTW - Lorea.org like n-1.cc has a pretty flexible design format, too, my opinion is - best tool for the job - we could divide some initiative projects into chat/jingle/micro-blog/blog/office-pads/forums/wiki's/buddy-lists/group-lists/apps-list/dvcs-list/etc. parts, so - parts would be interchangeable in case of various distributives or other, still - usable as a one infrastructure with help of federation protocol(s); clever storage scheme's; useful ID's By that it would be easier to see what can be united, where to line the privacy layers, etc. That's all - i'm talking about social level of F-Boxes, if F-Box foundation is aimed to replace the whole proprietary stack that mostly used now (including Twitter, LinkedIn, GMail, GDocs, tumblr.. including Google+ ofc. - will they federate to some degree, or not) PS: kind of http://www.freecloudalliance.org/project/ung with unhosted.org could be the approach to think about. ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Relationship driven privacy
because cisco bought it ? that's only - one, small, outcome ;) ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Relationship driven privacy
... The same principle exist between a reporter and a whistleblower. The pseudonymity article suggests the technology exists to protect freedom fighters through unlinkable pseudonyms. It's important, I think, to be able to extend the web of trust to people we can identify and trust, not just the I met at a key signing and confirmed his government ID, but also the guy who organized the protest and wears the baseball cap and shades and owns the freedomfigher...@gmail.com e-mail address... Outside the FreedomBox network, I will still need to access websites using the insecure practise of username/password. ... Not so insecure if the password is encrypted... indeed it may be more secure than carrying around media containing your key, which may be taken from you by an authority... ... I would like to see FreedomBox support OpenID and WebID i.e. the FreedomBox owner is the identity manager. OpenID is in wide use, and has personas which is similar to relationship profiles. WebID is more secure than OpenID, but AFAIK does not have relationship profiles and is not widely used. Can you tell us more? Why can't new users today create their own account after passing a challenge test using their personal information? The challenge test would be performed on a device (MAC address registered on server) in a secure area (identity check required for area access) and the user's personal information must already exist on the HR/owner's server (Web of Trust). Well, that's opens our freedom fighter up for compromise, doesn't it? Our oppressed hero probably wants all his activities done under one or more pseudonyms... I am not suggesting FreedomBox do this, but wonder why doesn't this WOT model exist already? Um... keysingings? https://secure.wikimedia.org/wikipedia/en/wiki/Key_signing_party Not that they're particularly user-friendly :-( Tony ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Relationship driven privacy
On Jun 29, 2011, at 9:28 AM, John Walsh wrote: Families/individuals should manage their own personal identities through their own domain name, but instead most people have Google and Facebook manage their personal identities - nobody would do this in the real world. exactly john, but you know what makes twitter and facebook BIG so they called it the social revolution ? it wasnt java script or CSS this was invented way before , it was IMHO http://oauth.net so it gives the user the ability to comment sign up or like without registering or confirmation, One klick partizipation is the magic of our social life The Exchange of profile information with oauth made the world simpler but raised a lot of privacy concerns because you cant verify each app that pulls your information out of facebook or twitter. So i believe the freedombox needs something similar, like http://openid.net or http://oauth.net for example because we have centralised identity providers allready http://techliberation.com/2011/01/09/facebook-as-identity-provider/ greetings Marc -- Les enfants teribbles - research / deployment Marc Manthey- Vogelsangerstrasse 97 50823 Köln - Germany Tel.:0049-221-29891489 Mobil:0049-1577-3329231 blog: http://let.de twitter: http://twitter.com/macbroadcast/ facebook : http://opencu.tk ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Relationship driven privacy
There are a few options in how we sort contacts into groups. We can do it like Facebook. Everybody friends your profile and you manually group them. The grouping is private in that your friends don't know what groups they're in (and most of the time, even if they've been grouped at all). We can do it like Diaspora. Explicit groups where the interface requires that you group people and is public about which groups you're interacting with when. Another approach is to use URLs. Give all your friends the http://fbox.example.com/wild-and-crazy-guy address. Give your family the http://fbox.example.com/pious-father address. Give your coworkers the http://fbox.example.com/always-at-my-desk address. Each of these are just different views of the same profile. And then you could manually change what people see if somebody's status changes from, say, /boyfriend to /ex-boyfriend. The interface should be obvious about which groups you are talking to. Perhaps the css could change in obvious ways (backrgound color?) or perhaps the software could be smart enough to know you don't want to share me-drunk.png with the group labelled WORK. I'm interested in other ideas and mechanisms for managing identities and making sure information doesn't leak between identities. Thanks, James ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
