In the last post I actually forgot to comment on the post I most agree with...
On 11/19/2013 01:26 AM, Thijs Alkemade wrote: > Federating over hidden services requires some extra work, but itâs not that > hard. Iâve written a Prosody module for it, which can be found at [1]. Some > more background at [2]. That's excellent news. Now the XSF should focus on migrating XMPP away from DNS/X.509 federation into the Tor network. There may be scalability issues involved however. > Tor already offers forward secrecy, if I remember correctly it uses TLS with > EDH. Unless you want to assert a clearnet identity, I don't see the added > benefit of using TLS when accessing a hidden service. The key sizes aren't extremily high, that's why Jacob Appelbaum usually recommends to use an extra end-to-end encryption layer. He likes to use https over .onion and PGP over Pond. I personally think key size isn't the most important criterion - moving into Tor is a huge improvement for privacy. > For s2s, you have the same solution as with most servers currently: dialback. > .onion addresses being cryptographically verified makes this actually secure > in this case. This would work even when federating between hidden services and > normal XMPP servers (although the normal server needs Tor access, of course, > and the hidden service must keep in mind to always use Tor to dialback). It's tricky because outside servers get connections from Tor exit nodes so they have to fully trust what the cryptography tells them and totally ignore where the packets are coming from. On Tue, Nov 19, 2013 at 06:14:23PM -0700, Jeremie Miller wrote: > Carlo, I happen to working very hard on something that sounds almost > exactly like what you're describing called telehash for many of the reasons > you express, and once it's a little more functional I have a strong desire > to demonstrate it working very compatibly/naturally with XMPP, of course :) I am familiar with TeleHash of course and wrote my $0.02 about it two years ago in the usual place: http://about.psyc.eu/Telehash - I'm glad you added encryption to the equation, but I still think you should - consider protecting transaction data (by using Tor for example) - that also liberates you from having to write your own NAT traversal - use a more advanced DHT implementation (check out GNS) - consider using a more efficient wire protocol (see http://lib.psyc.eu/bench/ for the performance shoot-out) - you may also want to consider many-to-many use case scenarios which you are currently not addressing If you don't intent to provide protection for transaction data and thus for the social graph, then there is nothing wrong with gatewaying to XMPP since the privacy assumptions are the same. I personally think systems that do not protect the social graph have this summer been proven to be bad for humanity - that's why I gave up on PSYC federation. But everyone has his or her own conscience. On 11/19/2013 05:29 PM, Andreas Kuckartz wrote: > Carlo v. Loesch: >> but if you ask me I would say because if >> taken in on a global scale, social graph data gives you enough >> information to be a threat to liberty and democracy of entire >> populations. I presume you can find plenty of scientific analysis, >> ... > > That is correct. Determining the social graph has for a very long time > been one of the tools of all repressive regimes. THEN WHY OH WHY ARE YOU BY ALL VIGOROUS MEANS LOBBYING FOR FEDERATION AND NOT TAKING THE LOGICAL CONSEQUENCES!?!?!????? > Having followed recent discussions around #youbroketheinternet I fear > that the second half of the sentence was not meant ironically. I > definitely disagree with that "best intentions" statement. I merely think it is out of scope of this mailing list to question the actual motives behind our governments' actions. Whatever led them to do the wrong things they did, we can take legislational and technical measures to limit the damage. Unless of course activists are more busy patching up broken systems rather than setting up working ones. >> By conseguence interoperability and "open standards" are no relevant goal: >> They were introduced in order to make companies have their proprietary >> technology >> speak a common language - but since proprietary technology by design cannot >> be >> reliably respectful of privacy, we must design our future communication paths >> free of proprietary contributions. > > I understand that #youbroketheinternet is not interested in > interoperability and open standards. That is one reason why I am No, you didn't understand it. You are reacting to it as if it was just some folks' opinion like you have yours, but if you were scientific in what you think and do, you should either have a good reasoning to criticize those words or start acting on the basis of them being a fact. > convinced that it will be far less relevant than some people hope it > will be. Yes, just like Facebook is far less relevant. Facebook is the world leader in chat systems although it is a silo, and it is the largest platform for mail-like messaging. How many people thought "oh my god, this isn't SMTP. this isn't standards-compliant" when they started mailing over Facebook? Please do not mention the XMPP and SMTP gateways they have for political correctness - they are strategically not very relevant. Fact is, Facebook can introduce platforms that do not care much for existing standards. Same story with the success of Skype and Whatsapp. Even Mumble is a success although it cares not for SIP etc. The idea that something that isn't standards compliant will be far less relevant has no foundation in real world numbers. > Open standards can be "reliably respectful of privacy". They do not > necessarily contain any proprietary technologies. Let's imagine Pond over Tor becomes an open standard. That means that companies would make hardware devices that implement the Pond protocol in a freedombox style. How will you be able to control that privacy has been respected? Maybe for the future we can get companies to release deterministic build procedures so the code can be audited. So hardware could be an acceptable business model for privacy under these conditions. Ok, but still the "open standard" is only good if there are no proprietary implementations that cannot be freely audited and reproduced. That makes it a lot less important than in the past. With the privacy threat at hand, the "open standard" is a minor priority. Open standards are especially bad for humanity when they are actually not doing their job well and at the same time impeding the development of new ideas and alternatives.. because.. hey, we have a standard. OStatus is a formidable example - it standardized things that aren't working properly at all. There isn't a single federated social networking platform that actually scales and functions well enough to challenge the likes of Facebook, and yet there is this hype of wanting to standardize things that do not work. > Maybe SMTP is bad due > to privacy issues especially regarding meta-data. But I think it would > be very wrong to underestimate the effect this standard has had in > enabling worldwide communication using the Internet. And as far as I > know the privacy issues were not built in deliberately. OF COURSE NO-ONE HAS DONE ANYTHING DELIBERATELY. Please don't distract by implying accusations that are completely absurd. PSYC has been an unencrypted and federated protocol for a long time, because in the 90s I wouldn't believe that anyone actually is so respectless to hoover up the conversation packets on the Internet. I thought all this chatter about Echelon was just paranoid. But nonetheless there is no reason to stick to old broken recipes in panic the new ones could not find acceptance. It's funny how we are frequently criticizing our politicians for not fixing planet Earth and at the same time we are panicking at the idea of having to obsolete SMTP and similarly architected things in order to introduce the necessary degree of privacy. It's the same typically human instinct: Conservation. We try to conserve what is actually way dysfunctional, thinking that we can somehow get back to the good old times. It's the same with the world economy and the energy and ecology questions. And on top of that you can put plenty of special interest. By not embracing the new and rather fixing up the old we are acting just like politicians. > BTW: Both the Tor and the GNUnet projects even support users of > Microsoft Windows while at the same time informing them that to "Stop > using Windows" is important. Which to you seems like a line of argumentation but it actually isn't. As if replacing a Jabber client (that requires you to set up an account on a server etc etc) with an end-to-end communications tool which is actually easier to handle, could be comparable to requiring people to install a new operating system. Apples and oranges! >> As long as there is a well-defined and reviewed GNU licensed codebase, > > Which license exactly? One which is interoperable with ASF projects? I am in favour of AGPL as it protects people from proprietary derivates that risk their intimacy and thus questions the entire usefulness of the project. On 11/20/2013 08:50 AM, Andreas Kuckartz wrote: > Carlo v. Loesch: >> If you want to talk to people on Google use whatever tools >> you want to use - don't mix it up with a system that is supposed to >> give you completely different degree of privacy - and uses completely >> different technology to achieve that - so there is no technological >> advantage in supporting XMPP or SMTP anyway. It would be an add-on >> that breaks user expectations. No good. > > One expectation of users is that they can continue to communicate with > other people without much hassle. In some cases this is impossible to That is not the aim of #youbroketheinternet. It makes no sense to insist on ease of use if the necessary confidentiality can't be guaranteed. If we don't intend to secure the social graph, then we don't need to start working on anything at all. XMPP already delivers what you want, why bother. > implement because terms of services of some proprietary platforms do not > allow this. One reason for those ToS is to prevent alternatives from > amplifying their network effects. Alternatives which are deliberately > preventing users from communicating severely weakens network-effects > which otherwise could work in favor of new technologies. People install communication software in parallel all the time. If they understand the goodness in a new software they will just start using it with a selected number of people.. and person by person that numbers will grow, just the way Facebook overtook Myspace. It's the same with PGP and OTR actually: you can't do OTR with someone that hasn't installed it. So the difference is only whether you ask folks to install an add-on or a real new approach. The effort is the same, the difference in results huge. That's why inciting people to install PGP is bad considering they could be installing Pond instead. > If #youbroketheinternet is becoming somewhat successful then such > "add-ons" will be created so it would be better to plan for that now. > That #youbroketheinternet is not interested in that is a flaw in the > concept and not in the interest of users. That is a flaw in your thinking that you refuse to understand that the privacy of the users is more important that your wish for legacy compatibility! >> But if you look at the http://youbroketheinternet.org/map you can see >> several federation technologies in the upper right corner. Why? >> Because their expertise at designing web interfaces for social >> networking is still very welcome. We just need to replace the >> networking engine underneath. Hey, it even mentions Buddycloud. > > Yes, I had suggested to include buddycloud and Jitsi. But that was not > simply because of their user interface but because they are using > federated protocols and that including those projects would amplify > network effects. Well, those are the wrong reasons. I doubt federation amplifies anything and federated protocols do not protect social graph data and thus are to be avoided. You can't ask a project to step back from the reason it is being launched. The reason Buddycloud is in there is because I presume it has some UI lessons to share and Jitsi even more. >> They just need to see that XMPP is not the future neither for the >> necessary privacy nor for the necessary scalability to achieve what >> they intend to achieve: be a serious competition to Facebook. > > If that were the aim of buddycloud then restricting the social > connections of users to those using #youbroketheinternet would be > counter-productive and a guarantee for failure. Buddycloud has no users compared to Facebook. You don't compete with Facebook by playing their game. You have to re-invent the game. You have to produce something which is so cool that people will prefer it over Facebook. What is the restriction? That people have to install a new software that provides them with cool new features? Woah, now that is a restriction! >> No, I think it's in a wrong assumption of the federation principle, >> that you can trust your university, your company or your boyfriend >> better. Most people don't have any reason to trust anyone, so they >> pick what is likely to have the least interest in them personally - >> that's usually a large silo offering. > > In companies and other organisations it is usually those organisations > deciding such questions and not the individual. And that is also true > for smaller groups such as this mailing list using SMTP. For companies and other organisations federation will probably continue to be the standard. But for the respect of constitutional privacy individuals should better move on. And mailing lists... well, I presume I'm not the only one who will be SO happy when they can be replaced by something more private and more democratic. Mailing lists are a pest. >> But history repeats itself. When the first cars were developed, 90% of >> the engineers where probably focused on refining the efficiency of >> horse carriages. > > Motorized cars used the same road network as the horse carriages. People > using the new vehicles were not limited regarding the set of places they > could drive to by requiring them to use a new non-existing road network. > The roads used by both cars and horse carriages were improved and only a > long time later horse carriages were no longer allowed on many roads. Yes, our technologies use the Internet, too.
