Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
Carlo v. Loesch: > Somebody wrote: >>> In case others are not yet aware: #youbroketheinternet is not only >>> explicitly opposed to federation but not even interested in >>> interoperability with federated communication networks. > ... > I presume it is Mr Kuckartz writing, correct? Yes, Mr v. Loesch, that is correct. > 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 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. 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. > 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. > 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. > 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. > 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. Cheers, Andreas
Re: [Standards] How to add a new reference to XEP
Hello and sorry if this is wrong channel for the question. this is the right place :-) [...] Do you have an example how to add a reference, e.g., an RFC (that is not yet in xep.ent file) as an inline entity to xml file? http://xmpp.org/extensions/xep-0258.xml defines several at the top. For things like RFCs it's pretty easy to convince the editor to add them to xep.ent though. There are a number of RFCs already there, so you don't even have to think much about the format.
Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
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 :) On Tue, Nov 19, 2013 at 4:30 PM, Carlo v. Loesch wrote: > Oh.. I didn't receive some of the messages.. probably originating > from Andreas.. strange. Again a multi-reply to avoid clogging the > mailing list: > > > On Tue, Nov 19, 2013 at 01:27:29PM -0700, Peter Saint-Andre wrote: > > Hi Carlo! > > I need to spend some quality time with your long message, but I don't > > have time for that right now. One quick point... > > lol! Hi Peter, was a pleasure meeting you this summer. > > > As you might remember, the original Jabber community was focused on > > code but also on defining and documenting an open protocol. There were > > no corporate interests pushing agendas (although some of the jabberd > > developers had some support from Webb Interactive Services), just > > coders making sure that clients and servers could interoperate. > > The stuff I wrote wasn't specifically addressed, especially not > at early Jabber. I know well that it was all created with best > intentions. I wasn't happy about the choice of a document syntax > for a messaging protocol, but the only thing I *really* complained > about was the lack of providing a distribution strategy for larger > recipient groups. I was just echoing basic things any IRC developer > knows concerning multicast, but the Jabber community didn't believe > the problem exists. So even today it's a problem to have more than > a hundred friends on a federated XMPP network, then try to do social > networking with them. The more time passed, the harder it got to > tackle the problem, because by then there were companies earning > money by selling scalable XMPP server solutions - a federation that > actually scales properly would be detrimental to their business. > > Even if this maybe isn't how it actually went, it is a reason more > why having corporations in the mix is bad for freedom. They can have > an interest in blocking technologies from getting better, and they > might be getting away with it by smart rhethoric and convincing > representatives. This time however they are putting our civil liberties > at risk, so we need to prioritize. Companies should be *users* of the > Internet, not *owners.* But currently they are owning the majority of us. > Again I'm not talking about the small players on this mailing list > working to bring some earnings back home. > > > I think we need three things: open source, open standards, and an open > > community. In fact I wrote an article about it way back in 2003: > > Back in 2003 I probably agreed, but by now I understand what Richard > Stallman says when he's against "open" and underlines the necessity > of "free." I need no open source, no open standards, no open community. > I want free software, free hardware and a free community. May sound > similar but the political differences are actually big and the > repercussions are being felt since June. > > > But these days the threat model has changed and I think we need to go > > beyond merely "open" to "trusted". Yes, trust is a slippery concept, > > but in my mind it's connected to things like hardware (e.g., PNRGs), > > build processes, transparency of releases, community governance, > > software that does what the user intends and no more, etc. This is > > something bigger than any particular technology, so this list might > > not be the best place to discuss it. Maybe a blog post or new > > discussion venue is in order... > > You just described what #youbroketheinternet is about. > > > Somebody wrote: > >> In case others are not yet aware: #youbroketheinternet is not only > >> explicitly opposed to federation but not even interested in > >> interoperability with federated communication networks. > > This reminds me of a word that I learned on this list years ago.. "snarky" > I presume it is Mr Kuckartz writing, correct? For some odd reason I didn't > get this mail. > > Anyway - it's a question of user expectation. You can't tell your > grandpa that this is the first software that actually implements your > constitutional right of secrecy of correspondence.. unless you add a > friend via XMPP that happens to have her account on Google. It's too > complicated. 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. > > But if you look at the http://youbroketheinternet.org/map you can see > several federation technologies in the upper right corner. Why? Because
Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
Oh.. I didn't receive some of the messages.. probably originating from Andreas.. strange. Again a multi-reply to avoid clogging the mailing list: On Tue, Nov 19, 2013 at 01:27:29PM -0700, Peter Saint-Andre wrote: > Hi Carlo! > I need to spend some quality time with your long message, but I don't > have time for that right now. One quick point... lol! Hi Peter, was a pleasure meeting you this summer. > As you might remember, the original Jabber community was focused on > code but also on defining and documenting an open protocol. There were > no corporate interests pushing agendas (although some of the jabberd > developers had some support from Webb Interactive Services), just > coders making sure that clients and servers could interoperate. The stuff I wrote wasn't specifically addressed, especially not at early Jabber. I know well that it was all created with best intentions. I wasn't happy about the choice of a document syntax for a messaging protocol, but the only thing I *really* complained about was the lack of providing a distribution strategy for larger recipient groups. I was just echoing basic things any IRC developer knows concerning multicast, but the Jabber community didn't believe the problem exists. So even today it's a problem to have more than a hundred friends on a federated XMPP network, then try to do social networking with them. The more time passed, the harder it got to tackle the problem, because by then there were companies earning money by selling scalable XMPP server solutions - a federation that actually scales properly would be detrimental to their business. Even if this maybe isn't how it actually went, it is a reason more why having corporations in the mix is bad for freedom. They can have an interest in blocking technologies from getting better, and they might be getting away with it by smart rhethoric and convincing representatives. This time however they are putting our civil liberties at risk, so we need to prioritize. Companies should be *users* of the Internet, not *owners.* But currently they are owning the majority of us. Again I'm not talking about the small players on this mailing list working to bring some earnings back home. > I think we need three things: open source, open standards, and an open > community. In fact I wrote an article about it way back in 2003: Back in 2003 I probably agreed, but by now I understand what Richard Stallman says when he's against "open" and underlines the necessity of "free." I need no open source, no open standards, no open community. I want free software, free hardware and a free community. May sound similar but the political differences are actually big and the repercussions are being felt since June. > But these days the threat model has changed and I think we need to go > beyond merely "open" to "trusted". Yes, trust is a slippery concept, > but in my mind it's connected to things like hardware (e.g., PNRGs), > build processes, transparency of releases, community governance, > software that does what the user intends and no more, etc. This is > something bigger than any particular technology, so this list might > not be the best place to discuss it. Maybe a blog post or new > discussion venue is in order... You just described what #youbroketheinternet is about. Somebody wrote: >> In case others are not yet aware: #youbroketheinternet is not only >> explicitly opposed to federation but not even interested in >> interoperability with federated communication networks. This reminds me of a word that I learned on this list years ago.. "snarky" I presume it is Mr Kuckartz writing, correct? For some odd reason I didn't get this mail. Anyway - it's a question of user expectation. You can't tell your grandpa that this is the first software that actually implements your constitutional right of secrecy of correspondence.. unless you add a friend via XMPP that happens to have her account on Google. It's too complicated. 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. 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. 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. On 11/19/2013 08:56 PM, Philipp Hancke wrote: > There is the hypothesis that any federated network tends to cluster > around a number
[Standards] UPDATED: XEP-0329 (File Information Sharing)
Version 0.2 of XEP-0329 (File Information Sharing) has been released. Abstract: This document specifies a simple extension to existing protocols that allows an entity to request information about files. Changelog: Corrected namespace to use XSF format. (jl) Diff: http://xmpp.org/extensions/diff/api/xep/0329/diff/0.1/vs/0.2 URL: http://xmpp.org/extensions/xep-0329.html
Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
[...] There is the hypothesis that any federated network tends to cluster around a number of large nodes. E.g. for XMPP this would be gmail, jabber.org, jabber.ccc.de (applause to their efforts on making themselves unreliable!), ... This is true even of unfederated networks (Facebook, Twitter, LinkedIn, Skype, the current crop of cool new mobile chat apps). My hypothesis: human beings are herd animals and prefer to flock together in large numbers. "Are you on hot-new-service-X?" It's much easier to think and act that way than to strike out on your own. Right. The benefit of federation is that _I_ can ignore the herd to some degree. Interdomain federation is hard, especially delivering the same user experience as between users on the same domain. This is a huge factor. It's much easier to offer a consistent and quality experience if you control both ends of the pipe Yeah, http://vimeo.com/77257232 talks about that -- and the lack of open products. I do think that webrtc gives us a good chance to move the baseline experience from basic IM + presence to rich federation. And heck, we've got some movement here ;-) What amuses me most about webrtc is that "rich media chat" was listed as #6 of the six oldest ideas in chat @ http://antecipate.blogspot.de/2006/11/six-oldest-new-ideas-in-chat.html and "in-browser chat" is #2 Most people always complain about how there's no great email client, no great IRC client, no great Jabber client, and so on (don't even get me started on SIP clients!) - -- with plenty of justification. See above, as you say it's not limited to XMPP. It's a more general lack of accepting non-developer roles in opensource. Peter: I really appreciate that you enjoy writing specifications!
Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/18/13 3:49 PM, Carlo v. Loesch wrote: Hi Carlo! I need to spend some quality time with your long message, but I don't have time for that right now. One quick point... > 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. That means that the protocol standards > etc become a lot less important: As long as there is a well-defined > and reviewed GNU licensed codebase, all applications can be made > interoperable even if the protocol wasn't documented. Of course > that is not recommendable and in fact a proper review implies > documenting the protocol fully - but it is very distant from > today's notion of necessity of a protocol standards body. A > protocol can thus be driven by efficiency needs rather than lobby > interests. As you might remember, the original Jabber community was focused on code but also on defining and documenting an open protocol. There were no corporate interests pushing agendas (although some of the jabberd developers had some support from Webb Interactive Services), just coders making sure that clients and servers could interoperate. I think we need three things: open source, open standards, and an open community. In fact I wrote an article about it way back in 2003: http://www.onlamp.com/lpt/a/3660 But these days the threat model has changed and I think we need to go beyond merely "open" to "trusted". Yes, trust is a slippery concept, but in my mind it's connected to things like hardware (e.g., PNRGs), build processes, transparency of releases, community governance, software that does what the user intends and no more, etc. This is something bigger than any particular technology, so this list might not be the best place to discuss it. Maybe a blog post or new discussion venue is in order... Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSi8mxAAoJEOoGpJErxa2pGIIP/3yupgKNsZDmeGFTCpiPh9jH jT67SKV+M/d8v0rBBoohvRY50IURnaMaoJQcPC4Y40yAASnUag9sfnhw5J1CI6W2 iilSdVd1O9j1btjDPyOiYSXfwiKWDLD1aODhgQpaZ02pYu0/8MJMVTUaxfRP+NMN YuVRizR/avRIwNt0Wq7WEfKYqR0xQ+uFEwzxhCctTbcI400P3f6zjt2FSUDig08J Uq0S/O9bK9FBzOo2krLqsiFx0NYdrjjpDi+RcAYPfZ6L1ShQtzBEziph8xer0olH 30O1NOZmJn6qE/kquR+L4FldgPyiXf+QmvUOpwuRpflU8CniWZpjJ82T6EoZYNTP 78nK8qL4o6cmUdFPT6YTKbgS9aIDyeZPTRt0901Ayj4EJQQLpqTTKMZcriymOWVA PUOJ4ghvtir9AyU4MGRtBNny/UrpJ7xmNP+bmz40NtQdrGLcrZTOnx2FAoPOG4Ec Ee0vgSfkbMryaEYSjXSi/rer8qSg39rvRAyJX50I6+IQc4K2V2WYLPkoL4qnYxs8 xfQXOVpFHAedDnY+gXy4DcIzXHR1AnQ8pe3+7+Hrp1Pizloy2oZLDCMbcW1Fg/5s 7PMbTs/E2U9s/5DLrF6/6M4pt2yi7ROrEN8rWIm23JXhSwjLcaEc8WoB1JKM0kPQ zQEqjyKa9LMg45QglJMV =C8IT -END PGP SIGNATURE-
Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/19/13 12:56 PM, Philipp Hancke wrote: > [...] >>> Having no federation at least doesn't introduce yet another >>> huge possibility for security problems and as long as you own >>> the source code and aren't forced to use anybody's specific >>> offering it is highly inadeguate to call such a software a >>> silo. >> >> In case others are not yet aware: #youbroketheinternet is not >> only explicitly opposed to federation but not even interested in >> interoperability with federated communication networks. > > There is the hypothesis that any federated network tends to > cluster around a number of large nodes. E.g. for XMPP this would be > gmail, jabber.org, jabber.ccc.de (applause to their efforts on > making themselves unreliable!), ... This is true even of unfederated networks (Facebook, Twitter, LinkedIn, Skype, the current crop of cool new mobile chat apps). My hypothesis: human beings are herd animals and prefer to flock together in large numbers. "Are you on hot-new-service-X?" It's much easier to think and act that way than to strike out on your own. > Interdomain federation is hard, especially delivering the same > user experience as between users on the same domain. This is a huge factor. It's much easier to offer a consistent and quality experience if you control both ends of the pipe (I'm not saying it's easy, and I think the people who run these large, monolithic services deserve our admiration even though I prefer a more federated, decentralized approach). Most people always complain about how there's no great email client, no great IRC client, no great Jabber client, and so on (don't even get me started on SIP clients!) - -- with plenty of justification. Now, there's a lot that we could do to make things easier for those who would consider deploying federated services -- servers that are easier to run, clients that offer a better user experience, a higher level of security, etc. One reason for the ubiquitous encryption manifesto is that I think we owe it to our users to at least offer better security. But easier servers and clients are part of the picture too. Some argue that this is all a waste of time and that it would be more productive to start again (as Carlo says, redesign the entire stack). I have a great deal of sympathy with that attitude, and I do think that eventually we'll need to replace a lot of what we have now (even at the physical and link layers, e.g., more open hardware, wireless mesh links instead of centralized ISPs). But this is going to take a long time, and until we have more of that built out IMHO we need to do what we can to better secure the current generation of federated technologies. Let the conversation continue... :-) Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSi8YqAAoJEOoGpJErxa2pRIoQAK13kxdis9J72hQ36duipHGZ r+/BIRyvyup2wUldZ7d5VmKnXtTGdGvs/jkwRuCBQxkMwaLATG/EXnNH8h3c2THo OtkZCDP5fTMsUC6ZRnIrjv4B/bQTKTjhkq1L41ez7Xss05JowZrEMU2jMnGk9NDt 934INBg8D2E8UyiitALXu0kkeJ8kDjXO8svj03p9U8zSmHbi0TAJGc+mV79KF3qP BlbavkbDCTnr9AxmrSm1CvHt7owH+hyYPMVF7qOxpDlvgdtyK+B0xuWR9n42PDEM SAqe3os8P4lG/FRBiLeYh5oAvcLgr2D7SpEdMrZsyMossrSbACq6clv/769VDpwC dFOSWBeWRwHgRSYGCMLAq/e1UiHFI7I5vK7tjyn4ThlTn11dPT8G1K6N5R5ToP3T N1fR8pZCtIHVR+gyg1mVROS8ojdpOYPB+bsgV4d5P5Oq8wmJ/HUd1v/LlPm9EOcw vdEoe3R/vsDTvbDdh1cLJIq6BjYR1hlK2tABKuvUrCFJEgew5pHv2clXVGxC/E3i MR6MCSNpbUWZvIykRVBPNzZytX2oh4H0vuRSs1WBaJGkrEYTWqLoTdV8wasmM3GK KCDBsyTHJZEP+wgy3zRbYAoP+TAq2hHawY9pvqxNdh6lHluZRNPjK7GAEZQFXAgH 5rpZsw/xqTt5Tgat7o9D =gyyJ -END PGP SIGNATURE-
Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
Am 19.11.13 20:56, schrieb Philipp Hancke: [...] Having no federation at least doesn't introduce yet another huge possibility for security problems and as long as you own the source code and aren't forced to use anybody's specific offering it is highly inadeguate to call such a software a silo. In case others are not yet aware: #youbroketheinternet is not only explicitly opposed to federation but not even interested in interoperability with federated communication networks. There is the hypothesis that any federated network tends to cluster around a number of large nodes. E.g. for XMPP this would be gmail, jabber.org, jabber.ccc.de (applause to their efforts on making themselves unreliable!), ... Interdomain federation is hard, especially delivering the same user experience as between users on the same domain. I understand the rationale. I just don't agree with it. I don't agree with it either. What you end up having is silos that typically consist of proprietary technology with limited usability for the wider Internet user community. The benefits of XMPP are interoperability, the open standards process, and the large number of XMPP providers you can choose from. If you don't like one located in the US then pick it from some other country. If don't like any of them setup your own.
Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
[...] Having no federation at least doesn't introduce yet another huge possibility for security problems and as long as you own the source code and aren't forced to use anybody's specific offering it is highly inadeguate to call such a software a silo. In case others are not yet aware: #youbroketheinternet is not only explicitly opposed to federation but not even interested in interoperability with federated communication networks. There is the hypothesis that any federated network tends to cluster around a number of large nodes. E.g. for XMPP this would be gmail, jabber.org, jabber.ccc.de (applause to their efforts on making themselves unreliable!), ... Interdomain federation is hard, especially delivering the same user experience as between users on the same domain. I understand the rationale. I just don't agree with it.
Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
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. > #youbroketheinternet is only ironically pointing a finger, since we > know that governments are operating in best intentions like everyone > else.. 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. Different views regarding the motives of an attacker can lead to differences regarding attack models and defenses. > Having no federation at least doesn't introduce yet another > huge possibility for security problems and as long as you own the source > code and aren't forced to use anybody's specific offering it is highly > inadeguate to call such a software a silo. In case others are not yet aware: #youbroketheinternet is not only explicitly opposed to federation but not even interested in interoperability with federated communication networks. That is their decision but I do not think that this helps users. > 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 convinced that it will be far less relevant than some people hope it will be. Open standards can be "reliably respectful of privacy". They do not necessarily contain any proprietary technologies. 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. 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. > As long as there is a well-defined and reviewed GNU licensed codebase, Which license exactly? One which is interoperable with ASF projects? Cheers, Andreas
