Re: [Standards] Discussion venue Re: e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
I have compiled a commented list of potential electronic discussion venues (mostly mailing lists) and existing communities which aim at improving security and privacy for users of the Internet. Should I send that to this list or put it on a Wiki page and just send a link? I can offer to put it on the W3C FSW CG Wiki (P2P people are also welcome there and should not be offended by the fact that the name includes "federated"). An alternative might be the GNU consensus Wiki. But I do not want to exclude producers of proprietary software. I am open for other suggestions. The general idea is to help to link some of the existing communities which currently are quite separate, to foster collaboration and to find relevant communities for those wanting to help. Cheers, Andreas
[Standards] Interoperability and Federation Re: Discussion venue Re: e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
Dave Cridland: > Without interoperability, you might get functionality, but it'll be > either a silo or a monoculture. > > If it's a monoculture it won't stay that way - you'll end up with > version drift - in which case you'll either need to figure out > interoperability (hard to do in retrospect for a fracturing monoculture) > or else eventually suffer functionality fracture. That is the best concise explanation of the importance of interoperability in distributed systems I have seen so far. Thanks! The FSF seems to agree: "We hope they all will be willing to work together to define ways to inter-operate." http://www.gnu.org/consensus/faq And while I am mentioning GNU consensus, their FAQ states this: "Isn't federation flawed? How can I trust a commodity server? In that sense, yes. You can't trust a server controlled by a third party. That's why we're looking at peer-to-peer solutions in the long run, and promote user control of their data, and end-to-end, secure solutions. But not all use-cases require that amount of privacy. Federation makes a lot of sense for affinity groups, public contents, and local communities. We don't believe in one-size-fits-all." Cheers, Andreas
[Standards] Discussion venue Re: e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
Peter Saint-Andre: > 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... There are quite a few existing venues for subsets of these topics or aspects. But none of them so far seems to be appropriate for all of them. I had hoped that the "assembly" which is being organized for 30C3 in Hamburg at the end of this year might be a venue but it also is only about a subset by explicitly rejecting interoperability with federation based approaches. And for the current organisers improving existing open standards also is off-topic. At the same time I am generally not in favor of creating new venues if existing ones can be used by extending their charter. Something for FOSDEM 2014 ? Cheers, Andreas
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] 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
Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
Simon Tennant: > IMHO, e2e security would probably make more sense as a XEP and working > group that has the time to zoom into all the implementation details. Can that be solved by an XEP ? What about this IETF draft? (I still have to read it) End-to-End Object Encryption and Signatures for the Extensible Messaging and Presence Protocol (XMPP) draft-miller-xmpp-e2e-06 https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e/ There exist people who mention XMPP as belonging to "faulty technologies" for which they want to create alternatives: http://youbroketheinternet.org/ And I try to find out what can be done to improve XMPP regarding security and privacy. Cheers, Andreas > On 18 November 2013 10:30, Andreas Kuckartz <mailto:a.kucka...@ping.de>> wrote: > > Peter Saint-Andre some time ago wrote: > > On 7/16/13 4:27 AM, Carlo v. Loesch wrote: > >> Since XMPP isn't suitable for keeping meta-data private I would > >> presume that e2e privacy is out of scope for this mailing list, > >> really. > > > > True. > > Where would the topic e2e privacy for XMPP be "in scope" ? > > Cheers, > Andreas
[Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
Peter Saint-Andre some time ago wrote: > On 7/16/13 4:27 AM, Carlo v. Loesch wrote: >> Since XMPP isn't suitable for keeping meta-data private I would >> presume that e2e privacy is out of scope for this mailing list, >> really. > > True. Where would the topic e2e privacy for XMPP be "in scope" ? Cheers, Andreas
Re: [Standards] Encrypted group / multi-party chat
Peter Saint-Andre: > On 8/28/13 7:19 AM, Andreas Kuckartz wrote: >> What are the suggested standards to implement encrypted group / >> multi-party chat? > >> Or are there any standards missing? > >> So far group / multi-party chat does not seem to be a feature >> specified for OTR, but I found this paper by Ian Goldberg >> et.al.: > >> Multi-party Off-the-Record Messaging >> http://www.cypherpunks.ca/~iang/pubs/mpotr.pdf > >> Multi-party Off-the-Record Messaging [three pages longer] >> http://www.cacr.math.uwaterloo.ca/techreports/2009/cacr2009-27.pdf > >> > As we've discussed before, encrypted groupchat is hard. I suggest > that the otr-dev list is a better place to discuss it. Thanks for the suggestion. I just subscribed to that list (and already noticed that you are there as well). Cheers, Andreas
[Standards] Encrypted group / multi-party chat
What are the suggested standards to implement encrypted group / multi-party chat? Or are there any standards missing? So far group / multi-party chat does not seem to be a feature specified for OTR, but I found this paper by Ian Goldberg et.al.: Multi-party Off-the-Record Messaging http://www.cypherpunks.ca/~iang/pubs/mpotr.pdf Multi-party Off-the-Record Messaging [three pages longer] http://www.cacr.math.uwaterloo.ca/techreports/2009/cacr2009-27.pdf Cheers, Andreas
Re: [Standards] XEP tagging idea..
Dave Cridland: > We have, I think, dependency information in XEPs. We could in > principle build reverse dependencies, too. That won't achieve > everything you want, but it might achieve some of it. Exactly, and I find those dependencies helpful. > You're imposing more work on the XEP Editor, and the Council. I'm not > in favour of anything which increases their workloads without a known > corresponding gain. That's not to say I think this is a terrible > idea, I'm just saying it's speculative, and needs to be worked on > outside the main standards process workflow at least to begin with. +1 >> Right now all the XEPs are files in a repo, so I don't know how we >> do this tagging and relavance index the smartest way. >> > I think someone (you?) clones the repo and tries out some ideas. There is no need to change the XEPs in any way. The dependencies can be collected independently and made available as Linked Open Data using JSON-LD, RDF or whatever. Cheers, Andreas
Re: [Standards] Proposed XMPP Extension: Chat Markers
Are there already projects considering to implement this? Cheers, Andreas XMPP Extensions Editor: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Chat Markers > > Abstract: This specification describes a solution of marking the last > received, read and acknowledged message in a chat. > > URL: http://xmpp.org/extensions/inbox/chat-markers.html > > The XMPP Council will decide in the next two weeks whether to accept this > proposal as an official XEP.
Re: [Standards] [IOT] (no subject)
A small suggestion: Could you please fill the subject of mails in the future? Thanks, Andreas
Re: [Standards] UNSUBSCRIBE: Re: XEP-0196 modification
Pranav Kedia: > UNSUBSCRIBE One can not unsubscribe by sending mails to countless people subscribed to a mailing list... Have a look here: http://mail.jabber.org/mailman/options/standards Or send a mail to standards-requ...@xmpp.org with subject "unsubscribe" Cheers, Andreas
Re: [Standards] Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
I agree with that sentiment. Green-colored text and strange fonts were popular when MySpace was popular. This is something from the past, not the present or future. The present and future require semantic elements (such as ) and attributes (such as those used by RDFa). Cheers, Andreas Peter Saint-Andre: > On 9/27/12 5:32 PM, Peter Saint-Andre wrote: > >> On 7/31/12 6:43 PM, Mathieu Pasquet wrote: > >>> I am also not sure about the and >>> elements: they are shown as a recommended element to support >>> (7.8), but the business rules (8.7) states that they should >>> not be used, but rather or with appropriate style >>> attributes. Is it only for backward compatibility, then? > >> I think we need a broader discussion of this topic, since it >> caused so much controversy when we first defined XHTML-IM. I will >> review the old list discussion and more modern opinions on this >> topic, then post to the list again. > > Here is the relevant business rule: > > ### > > The use of structural elements is NOT RECOMMENDED where > presentational styles are desired, which is why very few structural > elements are specified herein. Implementations SHOULD use > appropriate 'style' attributes (e.g., this is bold and this is > indented) rather than XHTML structural elements (e.g., > and ) wherever possible. > > ### > > That now seems wrongheaded to me. Sure, *if* you just want a > pretty presentation (say, a bit of green-colored text), then > 'style' attributes are appropriate. However, it seems to me that if > you want to quote something or emphasize something then using > or is the right thing to do. > > (I also wonder why we don't support for inline quotation...) > > Peter
[Standards] Stamping on one's head Re: Fwd: Minutes 20121011
> 4) Any other business > Brief discussion of XEP 71, to continue on standards list. This made me curious and I belong to those who reads conference minutes. And to my astonishment I found this: [15:18:46] I have one AOB XEP-0071 and how to come to agreement on structured elements vs. stylistic presentation, but I suppose I'll just post to the list about that [15:18:50] I started and then got distracted, as so often happens. [15:18:57] I wish to stamp that on the head of everyone involved the slightest in anything related to publishing web pages [15:19:23] stpeter: I think at this stage the answer is "We don't substantially change the XEP". [15:19:34] But yes, that discussion can happen on-list. ... [15:19:47] To be more blunt. I'm a solid -1 on anything adding stuff [15:19:55] like rdfa http://logs.xmpp.org/council/121011/ According to http://xmpp.org/about-xmpp/xsf/xmpp-council/ ralphm is currently a member of the XMPP Council. Can someone please let me know if he has a veto right there? If that is the case there would be no reason for me to spend a minute more on finding a reasonable way to add RDFa to XEP-0071. I generally do not participate in discussions with a predetermined outcome. Cheers, Andreas
Re: [Standards] xep-027 encrypted filetransfers
Александр: > Hi all, i have implemented encrypted filetransfers in my > realization of xep-027 in new_gpg plugin fro miranda im/ng, but > currently it supported only in miranda, i would like to extend > xep-027 to have defined encrypted filetransfers. is it possible ? Did you look at XEP-0234 ? Cheers, Andreas
Re: [Standards] RDFa ? Re: Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
The "why?" is a good question. And I have a simple answer: It would be the most simple way to implement my use case, because I then know that the annotate.js library can be used (https://github.com/szabyg/annotate.js). annotate.js demos are available here, the second one is updated ever 24 hours: http://szabyg.github.com/annotate.js/ http://dev.iks-project.eu:8081/enhancervie I will have a look at the implementation changes which would be implied by using RDF/XML instead of RDFa. But I fear that it might complicate that work to much. Cheers, Andreas --- Ralph Meijer: > While I'm sure we could alter XEP-0071 to add support for RDFa, I have > to wonder why that is desirable. > > As I see it, the main purpose of having XEP-0071 was to standardize > existing efforts to have light *presentational* mark-up for instant > messages. In practice, a client would mostly use a chat UI element with > a few helper widgets for adding styles (like bold) and URLs. One > wouldn't typically write HTML directly. > > As an aside, I have personally gone as far as patching Gajim to further > restrict the allowed elements and styles (mainly because of iChat and > Adium). > > RDFa, on the other hand, would likely be for marking up a message > *semantically*. Standard practice in XMPP is to just add a new child > element to the stanza for that. I.e. as a sibling of > and (in this case) . You could simply add RDF/XML constructs, > while keeping our restrictions on the use of XML namespace prefixes in > mind. > > For non-IM purposes, I have used embedded Atom Entry documents (as > Publish-Subscribe payloads), using link elements for denoting triples. > > I also have to note that we have traditionally shied away from using > all-encompassing vocabularies in favor of application-specific ones. > E.g. XEP-0080 defines its own way to record addresses and geo-location > information, instead of using an existing gazillion page RFC. :-) > > In any case, I'd welcome alternative points of view, of course.
Re: [Standards] RDFa ? Re: Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
A correction. I wrote: > RDFa does not require any additional elements but only support for > these four attributes (the 'a' in RDFa stands for attributes): > vocab, property, resource, typeof I forgot a few, but that does not change the argument. Cheers, Andreas
Re: [Standards] RDFa ? Re: Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
I have had a closer look at the documents. I think it would be possible to add RDFa support to XEP-0071 by making a rather small number of modifications which would not break existing implementations. RDFa does not require any additional elements but only support for these four attributes (the 'a' in RDFa stands for attributes): vocab, property, resource, typeof This is similar to the "Style Attribute Module Definition" and "Style Attribute Module Profile" in sections 6.6 and 7.6 which add the "style" attribute. Creating a new XEP would either have to duplicate almost all of XEP-0071 or refer to it in almost all places which probably would make it unreadable. If that approach is reasonable and does not violate any XMPP rules I would volunteer to draft a set of suggested changes to XEP-0071. (What would be the most helpful technical format for that?) Cheers, Andreas --- Peter Saint-Andre: > On 10/1/12 1:22 PM, Andreas Kuckartz wrote: >> Does XEP-0071 include support for RDFa ? > >> (See http://www.w3.org/TR/xhtml-rdfa/) > >> If not: Would it be better to extend XEP-0071 or to create a new >> XEP for that purpose ? > > As far as I understand it, RFDa is another example of XHTML > modularization. Thus it wouldn't fit into the XHTML-IM > modularization; instead we'd need to define a new XEP. > > Peter
[Standards] RDFa ? Re: Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final
Does XEP-0071 include support for RDFa ? (See http://www.w3.org/TR/xhtml-rdfa/) If not: Would it be better to extend XEP-0071 or to create a new XEP for that purpose ? Cheers, Andreas
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
I think someone else also suggested this: I would rename the title from "Last Message Correction" to "Message Correction" and also eliminate "last" from the rest of the text, "of the last sent message" -> "of a sent message" "the most recently sent message" -> "a sent message" I will suggest to the Jitsi and buddycloud developers to implement XEP-0308. Cheers, Andreas
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
Kurt Zeilenga: > From a user perspective, often what I want to correct isn't the last stanza I > sent. I support that argument. Several Social Networking Services provide similar features and I expect XMPP to also support that. Cheers, Andreas
