jdev - 2022-08-14


  1. Link Mauve

    adx, here is my recommendation: https://docs.modernxmpp.org/client/groupchat/#bookmarks

  2. r4v3r23

    MattJ: would you want uncencrypted messages sent to you on signal?

  3. r4v3r23

    or any other encrypted messaging app?

  4. Link Mauve

    r4v3r23, would you want to be unable to have this present discussion? :)

  5. MattJ

    r4v3r23: it's not about what is sent to you - you can't control what people send you. It's about what to do after you receive something. There is no security gained by ignoring.

  6. MattJ

    r4v3r23: even Signal does this - their Android app at least supports receiving unencrypted SMS messages. They don't ignore them, and they even let you reply unencrypted.

  7. r4v3r23

    MattJ: OK so imagine signal wasn't also an SMS app

  8. MattJ

    So, imagine that the basis of your argument existed 🙂

  9. MattJ

    The fact is, it's often helpful to be able to communicate with unencrypted/legacy users. It's how you could lead them to upgrade, for example.

  10. MattJ

    That's undoubtedly why Signal does it. Most people don't have Signal, so by supporting SMS they allow people to seamlessly upgrade when both parties support it.

  11. r4v3r23

    MattJ: that's not my question, and you're not going to convince me

  12. r4v3r23

    I wanted to know if an OMEMO based encrypted messenger was possible

  13. Mx2

    There has come a new app, those conversation forks are dead end

  14. Mx2

    Still many common features aren't important enough it seema

  15. MattJ

    r4v3r23: Conversations already marks unencrypted messages with a strong red background. It would probably be no more than a few lines of code to hide those messages completely.

  16. MattJ

    It just has no advantage and nobody wants that

  17. nav

    r4v3r23: it might be a more productive use of your time if you stop to think about what other people are telling you rather than try to convince them that you have a good, practical and feasible idea. But to summarise the answer already given to your specific question, yes an end to end encrypted messaging application is possible (why specifically OMEMO though?) if you have very tight control over every aspect of the system and its environment. What you are presenting smells strongly of an XY problem though.

  18. Sam

    So I was asking about chardata the other day and apparently was wrong that it wasn't allowed inside the top level of stanzas. Eg. <iq>\n\t<foo/>\n</iq> is acceptable. However, if that's allowed, wouldn't <iq>somemixedcontent<foo/></iq> also be allowed? That seems more of a problem

  19. jonas’

    how was the conclusion that <iq>\n\t<foo/>\n</iq> is acceptable reached?

  20. lovetox2

    jonas’, nobody could cite a document that says otherwise

  21. jonas’

    for which definition of "acceptable"?

  22. lovetox2

    usage in xml streams

  23. jonas’

    in xml streams, or in xmpp xml streams?

  24. lovetox2

    xmpp

  25. lovetox2

    its obvious that this is valid xml

  26. lovetox2

    the question is if xmpp has something that forbids it

  27. jonas’

    well

  28. jonas’

    you can at least not rely on support

  29. jonas’

    for IQ stanzas, in particular, RFC 6120 describes exactly what's in an IQ stanza, and anything beyond that is not necessarily supported by all entities

  30. jonas’

    https://www.rfc-editor.org/rfc/rfc6120#section-8.2.3

  31. jonas’

    the enumeration on page 106

  32. jonas’

    the enumeration on page 106--107

  33. lovetox2

    that interpretation seems to be a stretch

  34. jonas’

    why?

  35. lovetox2

    the whole document is one level to high

  36. jonas’

    (replying with bad-request would be completely ok in such a case)

  37. Sam

    That seems more reasonable to me too, but I was told multiple clients send formatted XML in the wild

  38. lovetox2

    you are searching in a IQ definition for rules whats allowed in xml streams

  39. lovetox2

    thats the stretch

  40. jonas’

    Sam, ah, mixed content and "ignorable whitespace" are two different beast

  41. jonas’

    Sam, ah, mixed content and "ignorable whitespace" are two different beasts

  42. jonas’

    lovetox2, well, the rules don't need to be the same for <message/> etc.

  43. Sam

    No as far as XML is concerned

  44. jonas’

    lovetox2, case in point: all the SASL nonzas

  45. lovetox2

    But Sam is interested in the general case

  46. lovetox2

    not for one particular stanza

  47. lovetox2

    that maybe not clear from his example

  48. jonas’

    in the general case you need to support everything

  49. jonas’

    because, as I said, SASL.

  50. jonas’

    (and XMPP extensibility)

  51. Sam

    So where does it say "chardata that is just whitespace is okay, anything else bad"? Seems like a major oversight if it's not

  52. Sam

    Except for sasl and starttls which ban it just in those places, of course

  53. Zash

    I tried checking the XML specification but can't for the life of me navigate to it on w3.org

  54. jonas’

    Zash, https://www.w3.org/TR/REC-xml/#sec-white-space

  55. jonas’

    I have bookmarks for those :-)

  56. Zash

    Thanks

  57. jonas’

    #sec-white-space does not say that whitespace is ignorable on the XML layer, it needs to be defined by the application

  58. Sam

    oh, so it is different. Now I have no idea what to do. I'll elide the rant about how there's apparently a magical attribute that nobody knows about or supports because XML can't decide if it's a document language or a data serialization format and is therefore bad at both.

  59. r4v3r23

    nav: I was just curious of building a messenger with those properties was possible

  60. Sam

    I guess this really does mean that space should be passed through and other chardata should result in an error though? I really can't tell

  61. jonas’

    Sam, everything should be passed through

  62. r4v3r23

    instead I got comments of why enforced E2EE is stupid

  63. Sam

    jonas’: so if someone sends <iq>foo<bar/></iq> what does that even mean? IQs are only supposed to have one child, does this violate that rule?

  64. Sam

    Is it different for message/presence since they can have multiple children?

  65. jonas’

    Sam, that violates the *schema*

  66. jonas’

    which is different from what the XML layer does

  67. jonas’

    (IQs can also have two children, mind, if one of them is an error)

  68. Sam

    Does it? I can't tell that it's banned anywhere according to this

  69. jonas’

    (IQs can also have two children, mind, if exactly one of them is an error)

  70. Zash

    (or zero children, for type=result)

  71. Sam

    Sure, doesn't matter though, the question is still valid. I guess the answer is to go figure out what other things are doing because this is underspecified? I really have no idea.

  72. jonas’ goes to check how aioxmpp handles that

  73. jonas’

    ah, drops unexpected character data by default

  74. Zash

    Prosody only cares about child tags

  75. jonas’

    (everywhere)

  76. jonas’

    in the true extensibility spirit of XMPP (ignoring unexpected/unknown stuff)

  77. Sam

    I guess that's fine; feels weird to allow sending it in the first place, but I can't think how it could be abused

  78. Sam

    I guess this is fine; no idea really 🤷 https://codeberg.org/mellium/xmpp/pulls/324

  79. nav

    r4v3r23: Yes it is possible. See Whatsapp for instance.

  80. nav

    As for the XMPP network, it might happen that one day some form of support for end to end encryption will be required (probably not OMEMO, given its unclear legal status), in the same form that RFC7590 already mandates support for TLS. It still doesn't mean that people *have* to use it. See also HTTP vs HTTPS.

  81. techmetx11

    nav: >unclear legal status

  82. techmetx11

    elaborate

  83. techmetx11

    please

  84. nav

    techmetx11: https://nextleap.eu/deliverables/deliverables-period1.zip See D3.3 & D3.6, for instance

  85. nav

    For some reason 3.6 is not in the zip. Here's an online copy: https://ec.europa.eu/research/participants/documents/downloadPublic?documentIds=080166e5c208ad8b&appId=PPGMS

  86. nav

    Musiani goes in some more detail in this paper: https://hal.inria.fr/hal-01426845/document

  87. nav

    The long and the short of it is that OMEMO (or rather the protocol called Axolotl) is not a standard, and apparently quite intentionally so, as that allows the IP rights holder to exercise control over it, and monetise it.

  88. jonas’

    is that still an issue for omemo 0.8?

  89. nav

    Normally you would use patents for that kind of thing

  90. nav

    jonas’: I don't know. Hence the "unclear" qualifier.☺

  91. nav

    But I wouldn't want to be the next Wire.

  92. Sam

    I don't think any of that is true; the original axolotl spec was published using creative commons IIRC, the implementation everyone relied on was GPL, and newer OMEMO versions aren't based on it anyways and are an XSF spec. That all seems pretty clear, unless I'm wrong about that?

  93. Sam

    (I did not download the zip file, so maybe it tells me why I'm wrong, but that seems unsafe so apologies if it's in whatever that is somewhere)

  94. MSavoritias (fae,ve)

    Yeah that seems like a baseless fear

  95. lovetox2

    if a muc service does that merge multiple presences into one when connecting with different devices

  96. lovetox2

    is there a way to break this?

  97. lovetox2

    like can i break out of that as a device intentionally, maybe by changing nick or connecting to the muc in a certain way

  98. jonas’

    I don't fully undesrtand what you mean by break yet

  99. jonas’

    what's the goal?

  100. lovetox2

    to join a muc with 2 different resources

  101. nav

    Sam: > newer OMEMO versions aren't based on it anyways I just checked https://xmpp.org/extensions/xep-0384.htm and it refers me straight onto https://xmpp.org/extensions/xep-0384.html#nt-idm45811904665168 for the actual implementation.

  102. lovetox2

    and not get merged to one

  103. jonas’

    lovetox2, then you need two different nicknames

  104. jonas’

    (or two different accounts, then it'll complain to you about a nickname conflict if you attempt)

  105. lovetox2

    i have devica A and device B of the same account

  106. lovetox2

    i want to join a muc, with two different resources

  107. jonas’

    then use two different nicknames

  108. lovetox2

    or nicknames

  109. lovetox2

    ok so the MUC merging depends on the user joining with the same nickname across devices

  110. lovetox2

    ?

  111. jonas’

    yes

  112. lovetox2

    what if i change the nick from one device while im in the MUC

  113. lovetox2

    will the MUC somehow tell my other device that my nick has changed?

  114. jonas’

    it depends on the implementation

  115. Sam

    My mistake. Doesn't matter though, that specifically says "This document is hereby placed in the public domain."

  116. lovetox2

    ok so i need to test it

  117. jonas’

    in theory, an implementation has the folowing choices: - Reject the change (I think that's what old prosody did) - "split" the nickname: the changing device will see a successful nickname change *and* a join for the old nickname (for the other device), everyone else will see a join of the new nickname. - Force-change the nickname of the other device

  118. jonas’

    in theory, an implementation has the folowing choices: - Reject the change (I think that's what old prosody did) - "split" the nickname: the changing device will see a successful nickname change *and* a join for the old nickname (for the other device), everyone else will see a join of the new nickname. - Force-change the nickname of the other device(s) alongside the one initiating the nick change

  119. jonas’

    I think current prosody does the "split", because client support for the forced nickname change was questionable

  120. lovetox2

    ahhh great info thanks

  121. lovetox2

    thats what im seeing

  122. lovetox2

    and i thought its a Gajim bug

  123. lovetox2

    the splitting thing

  124. Zash

    I'm not actually sure if you can do server-initated force-rename of someone

  125. jonas’

    sending presence with code 110 and code 210 *may* work

  126. jonas’

    (which is how servers can override your nickname choices, and I suppose client implementations need code for handling that anyway and as most MUC operations are asynchronous (presence instead of IQ, so not tracked), I *suppose* that it'd just work)

  127. Zash

    While that may carry the appropriate semantics, I don't remember seeing any text about that case and when some clients had trouble with the server rewriting their nickname on join...

  128. Zash

    Worth testing I suppose

  129. lovetox

    Gajim handles that

  130. lovetox

    the Status Code is in the XEP and it says what its for, service changed your nickname

  131. nav

    Sam: the papers I linked to explain why the (non-)specification and one implementation being publicly available don't matter, as Wire found out much to their disadvantage (incidentally, please note that the licensing status of the document in which it's written does not convey any rights over the specification itself). Have the XSF commissioned a legal review? If not, the Nextleap project (https://cis.cnrs.fr/nextleap/) is as close as it gets that I'm aware of.

  132. Sam

    nav: What happened to wire? Can you summarize the documents? As far as I know there is no patent on the algorithm and the spec and implementation are licensed in an open way, so this all just seems wrong.

  133. lovetox

    i never heard that there are patents, i doubt that highly

  134. MattJ

    No, their defence is based on copyright and trademark, not patents

  135. nav

    Sam: I just linked to all of that, why not get it from the horse's mouth? And the summary is: "legal status unclear".

  136. nav

    MattJ: Exactly.

  137. Sam

    I'm not downloading a random zip file and I don't really want to try and read a long PDF on my phone.

  138. Sam

    MattJ: Copyright and trademark of what? Who's defense? Sorry, didn't understand that

  139. nav

    Sam: that's fine, but then please consider not jumping to conclusions.

  140. Zash

    The thing where they put their trademark into a protocol constant?

  141. Sam

    I just asked you to summarize, I didn't jump to any conclusions

  142. MattJ

    Sam: copyright of their implementations and trademark of "Signal" and "Signal protocol"

  143. nav

    My apologies, I then misunderstood the meaning of "so this all just seems wrong."

  144. MattJ

    So don't violate the GPL and don't advertise your implementation as using the Signal protocol

  145. Sam

    The implementations are copyright but licensed GPL, so that seems fine as long as you use that license or write your own impl

  146. Sam

    You beat me to the next thing :) what Matt just said

  147. nav

    No.

  148. MattJ

    There was an issue that even if you create your own implementation from scratch, there are some constants (some say intentionally) embedded in the protocol that mention "Signal"

  149. nav

    That's what got Wire in hot water.

  150. MattJ

    But this is not relevant in the latest version of OMEMO

  151. Sam

    There us zero chance you are violating a trademark if you gave a constant that says SignalProtocolv1 or whatever somewhere. Zero.

  152. Sam

    But as you said, doesn't matter anyways.

  153. MattJ

    Sam: they say different, and given that they make $$$ from licensing the protocol, they'll defend it too

  154. Sam

    nav: hot water how? You still haven't explained what happened to wire?

  155. Sam

    MattJ: oh, fair enough, if they're actually suing people over it it doesn't matter if it's technically okay or not, you still don't want to have to defend yourself

  156. Sam

    Do either of you have a link to an instance of them doing this? Searching "signal lawsuit" and the like is turning up nothing

  157. Sam

    Either way, none of this makes recent omemo legally gray area since that constant isn't used.

  158. nav

    Sam: I appreciate that you may not have access to a proper computer right not. If this is of interest to you, may I suggest coming back to it later when you do? You are jumping to pretty unwarranted conclusions.

  159. Zash

    So, how's your MLS implementations coming along?

  160. Sam

    What conclusions? Just explain what you're talking about so I don't have to read a ton of papers

  161. nav

    > What conclusions? > none of this makes recent omemo legally gray area > doesn't matter anyways. > There us zero chance you are violating a trademark > so that seems fine …etc.

  162. nav

    It's your choice not to inform yourself, but please do not disinform others.

  163. nav

    As it stands now, I would be very wary of implementing XEP-0384 in anything that's not GPL licenced.

  164. nav

    Note that this also includes MIT + BSD licences as well as closed source.

  165. nav

    Which makes that XEP non licence neutral.

  166. nav

    Which is not exactly the best state of affairs for an open protocol.

  167. MattJ

    Sam: there's not too much public about it, and I'm likewise not at my computer right now. But here's an overview: https://wireapp.medium.com/axolotl-and-proteus-788519b186a7

  168. MattJ

    I might be able to find some other references later

  169. MattJ

    I see no problem with modern OMEMO

  170. nav

    MattJ: How so?

  171. MattJ

    Because what would their argument be?

  172. Zash

    "See you in court for no reason!!!"

  173. lovetox

    nav, all this has been discussed and considererd on list when the XEP was made

  174. lovetox

    the opinion of the community is that is totally fine to implement under any license

  175. lovetox

    its not enoguth to say "hey maybe look at some links, maybe things are different"

  176. MattJ

    Other projects are also doing the same

  177. lovetox

    if you have concrete objection you need to formulate your argument in full

  178. MattJ

    It's not like OMEMO is the only one

  179. moparisthebest

    Some in the community (like me) don't care if it's impossible to implement a non-gpl OMEMO client

  180. moparisthebest

    But it was determined that's not even the case so whatever :)

  181. nav

    > the opinion of the community is that is totally fine to implement under any license Was that the result of a legal review?

  182. nav

    As in, an actual IP lawyer being consulted?

  183. Zash

    You pay for a lawyer and find out

  184. nav

    Not that that would make things clear (nothing in law ever is), but at least would give some weight to the argument.

  185. lovetox

    the spec is written in a way that you can implement it without looking at copyrighted material

  186. nav

    Zash: I'm not looking at implementing XEP-0384 in any context at the moment, but if that need ever comes up, I certainly will.

  187. lovetox

    so it follows if you do this, you dont need a lawyer that tells you that you didnt infringe copyright

  188. nav

    lovetox: Maybe I'm grossly misreading it, but the spec deals with the signalling rather than the underlying protocol (Axolotl) itself.

  189. lovetox

    of course if you look at copyrighted material, and copy it, then you are on your own

  190. nav

    > you dont need a lawyer that tells you that you didnt infringe copyright A lawyer will never tell you that.

  191. nav

    > of course if you look at copyrighted material, and copy it, then you are on your own So do we agree that the legal status of OMEMO encryption is unclear, then?

  192. lovetox

    there is no omemo encryption in general

  193. lovetox

    there is YOUR implementation of it

  194. lovetox

    and yes im unclear of the status of YOUR implementation

  195. lovetox

    could be well that you infringed someones copyright while implementing it

  196. flow

    nav, the omemo xep uses https://signal.org/docs/specifications/doubleratchet/ as building block which is an open spec put in the public domain

  197. nav

    So you are saying that XEP-0384 is fine, as long as you do not implement it?

  198. lovetox

    as long as you infringe no ones copyright while implementing it

  199. flow

    Hence I am not sure how implementing omemo based on the XEP and the provided open specification brings you into any kind of legal trouble

  200. nav

    flow: That was discussed already. Would you be able to point out where it says that the specification is in "the public domain" (whatever that means for a specification)?

  201. flow

    https://signal.org/docs/specifications/doubleratchet/#ipr

  202. nav

    Looking at https://signal.org/docs/specifications/doubleratchet/ it says "This document is hereby placed in the public domain."

  203. nav

    document ≠ specification

  204. flow

    hmm, not sure, given we talk about the document which specifies the protocol

  205. nav

    flow: you then are going to have to take my word for it, or get your own lawyer. ☺

  206. nav

    At least one company have been sued (Wired) and another chose to pay hefty licensing fees (Whatsapp). Is this really something that should be promoted as an "open" standard?

  207. flow

    I have a philosophy of not conulting a lawyer for obvious things to me and wait for the cease and desist eltter first, which, worked out fine for me

  208. flow

    und I haven't heard of any laywers letter regarding OMEMO in the past

  209. lovetox

    nav, wired has been sued, and as a result changed nothing, there impl still is there, so what should tell us that?

  210. flow

    I know about the Wired story

  211. lovetox

    disclaimer: My wired knowledge consists of the link MattJ posted earlier

  212. flow

    But the Whatsapp things is new to me, and given that there are strong ties between Signal and Whatsapp it appears unlikely or highly likely that there is more to the story

  213. nav

    flow: I can share with you a copy of Romeo and Juliet just fine, but I cannot share with you my electronic copy of this https://www.penguin.co.uk/books/54572/romeo-and-juliet-by-shakespeare-william/9780141396477

  214. nav

    That's the difference.

  215. moparisthebest

    Was Wired GPL ?

  216. lovetox

    yes, according to the blog post

  217. flow

    nav, well, you could share the electronic copy of this if it was placed in the public domain, no?

  218. nav

    flow: if both the contents and the representation are out of copyright, yes.

  219. nav

    Please note: this is analogous to the discussion about "source available" and free and open source.

  220. flow

    so in the core of the wire article is this "but if you do an independent implementation, using the published reference documentation and background knowledge from having seen their code online, you can be accused of copyright infringement"

  221. flow

    which is true if your independent implementation is not GPL-derivate compatible licensed

  222. MattJ

    There is a third-party write-up here, with comment from Signal: https://www.forbes.com/sites/thomasbrewster/2016/05/11/wire-skype-sued-moxie-marlinspike-extortion/

  223. flow

    and I totally understand that Moxie would then ask for a license fee, if you don't want to put it under a GPL-derivate compatible license

  224. flow

    I would do the same

  225. flow

    *understandable

  226. nav

    flow: that is your choice, but in implementing an open protocol, other parties might have other interests at heart.

  227. flow

    I am sorry, but I fear I don't get what you are getting at :)

  228. flow

    and from reading the latest link MattJ just posted, especially the Update section with Moxie's response, the picture in my head that someone just tried to create a derivate work from the GPL licensed libsignal, whithout obeying the GPL, is just solidifying

  229. nav

    The situation here is somewhat analogous to what we've seen in the past with video codecs and such.

  230. flow

    I can't comment on that because there haven been multiple situations with codes in the past decades that all are slightly different

  231. flow

    maybe not only even slightly different, but even completely different

  232. nav

    flow: What I'm getting at was posted hours ago: the legal status of (implementing) OMEMO is unclear.

  233. nav

    Someone asked for clarification and I posted relevant references, which apparently some chose not to read but argue about them anyway.

  234. nav

    It has been pointed out that the underlying technology is licenced and that the licence is actively and aggressively enforced. XEP-0384 does not mention any of this.

  235. nav

    No legal review has taken place, and someone suggested that it is caveat emptor, yet XEP-0384 is silent on that too.

  236. flow

    nav, would you be so kind to re-post the references again? I have to admit that I did not read the complete backlog

  237. flow

    I am also not sure where it has been pointed out the the underlying technology has been licensed. the "reference" implementation, libsignal, is under an open source license, maybe that is what you mean? but the specification itself is in the public domain

  238. MattJ

    nav: XEP-0384 builds on top of public domain specifications published by Signal, it doesn't use anything they assert copyright over

  239. flow

    so if you don't look at the libsignal code, then you can create an implementation and put that implementation under whatever license you like

  240. nav

    flow: https://logs.xmpp.org/jdev/2022-08-14?p=h#2022-08-14-ceb48d4a212ed1ea

  241. nav

    flow: that's called reverse engineering. In theory you can (and I've done it, in a different domain). In practice, well…

  242. nav

    …the first thing you learn when you take a law class: "there is no true or false, no yes or no, no black or white".

  243. flow

    nav, what exactly is reverse engineering?

  244. MattJ

    In copyright matters the general term is a "clean-room implementation"

  245. flow

    nav, where exactly is (what?) reverse engineering?

  246. nav

    What MattJ says

  247. MattJ

    It's a well established practice for avoiding copyright issues

  248. nav

    Specifically, clean-room implementation is one form of reverse engineering, and what I was actually referring to. Thanks for the remark.

  249. flow

    ok I have multiple large PDF files in front of me

  250. nav

    Note that you might still get sued though.

  251. flow

    I am not sure, even with the restrictions (D3.3?) you gave me, where it says that the technology that current omemo uses is licensed

  252. flow

    I am not sure why we are talking about reverse engineering now

  253. flow

    given that all of omemo can be implemented by just looking at open standards

  254. nav

    flow: did we not already discuss the Wire and Whatsapp *licensing* cases?

  255. flow

    yeah, but those where about the license of *software*, not of an standard

  256. flow

    It feels like you are not properly separating software licensing concerns and standard ones

  257. nav

    flow: already discussed, read the history log.

  258. flow

    I probably won't, but if you can give me a brief summary I'll read it

  259. nav

    Wire got accused of looking at OWS' libsignal source code to implement theirs.

  260. nav

    Which, it was argued, made theirs a derived work (this is a legal term of art, basically means we still kind of own some of it)

  261. nav

    According to Wire, you cannot implement Axolotl just be reading the "specification".

  262. flow

    I think you are also not considering the timeline here

  263. lovetox

    yes that was their opinion in 2015 or even earlier

  264. nav

    Which is in itself a well-known trick from patent writing.

  265. lovetox

    this is not the case anymore

  266. flow

    the double ratched specification only came end 2016

  267. nav

    Always leave out the one crucial detail.

  268. flow

    these days you can implement omemom without looking at libsignal

  269. flow

    these days you can implement omemo without looking at libsignal

  270. lovetox

    which is exactly what i wrote half an our ago

  271. flow

    I think multiple people stated by now that implementing omemo by just using the available open standards is not an issue

  272. nav

    flow: why are you trying to convince me that everything is fine with no evidence whatsoever? In the face of a proprietary protocol which, as has been established, the rights holder actively seeks to enforce licensing upon?

  273. lovetox

    nav, this gets old now

  274. nav

    > these days you can implement omemo without looking at libsignal Where should I look instead?

  275. lovetox

    your arguments is pointing to links, and if we bring a counter argument then you point again to the link

  276. lovetox

    either you take part in the discussion or not

  277. nav

    lovetox: I know it gets old. And I'm surprised at the reaction here.

  278. flow

    nav, start with xep384, everything else is linked by that xep

  279. lovetox

    i wrote half an our ago > the spec is written in a way that you can implement it without looking at copyrighted material now you ask > Where should I look instead?

  280. MattJ

    So the summary of OMEMO's "legal status" is: 1) XEP-0384 references only public domain specifications published by Signal, 2) GPL implementations can leverage most of libsignal, 3) non-GPL(/compatible) implementations must use a clean-room implementation, 4) Signal themselves haven't sued anyone and deny extortion of Wire (whether this is true does not really matter)

  281. flow

    nav, start with xep384, everything else you need to know to implement is linked by that xep

  282. flow

    MattJ, +1

  283. flow

    (only that xep384 probably also references other open specifications, besides the one published by Signal, like the ones published by the XSF ;))

  284. nav

    MattJ: And XEP-0384 mentions none of that. I feel that at the very least 2) and 3) should be in there, as well as a note to the effect that the underlying technology might have IP restrictions which might prevent certain uses or implementations.

  285. nav

    And now for a question, does the XSF have any sort of legal counsel at all?

  286. flow

    why should a XEP tell you how software licensing works?

  287. nav

    flow: do you know what an essential patent is?

  288. MattJ

    nav: you think "the underlying technology might have IP restrictions" is true? We basically just established that it isn't true.

  289. Link Mauve

    nav, you have GPL implementations of most XEPs, it’d be weird to have to mention in each of them that if your software isn’t compatible with this license you shouldn’t use those implementations.

  290. flow

    nav, I don't

  291. nav

    Link Mauve: that's a different albeit related situation. There might indeed be other XEPs where the underlying technology is not freely available.

  292. flow

    Ideally there is a policy that XEPs have to be only based on other open standards that are available free of charge

  293. Link Mauve

    nav, I didn’t say they weren’t freely available, just that there exists implementations under a given license.

  294. Link Mauve

    There might exist implementations under a different license too.

  295. Link Mauve

    I’ve never looked at OMEMO, so I can’t comment on that part.

  296. nav

    flow: the "essential patent" appellative refers to the practice of pledging to allow other parties use of someone else's IP without that someone else forfeiting their rights to that IP, in the context of implementing a standard.

  297. MattJ

    At least in 2016 they confirmed they had no patents on the protocol, and I fail to find any: https://news.ycombinator.com/item?id=11727870

  298. MattJ

    So... I'm not really sure what more there is to say

  299. nav

    For instance, I have a patent (or other claim) to X, and X is needed to implement RFC98938. I promise that I will not sue anyone who uses X to implement RFC98938.

  300. flow

    I am also not sure where to put the "essential patent" pice in the omemo picture

  301. flow

    I just wondered if it would be a good idea to prominently mark XEPs that are only based on open standards as such

  302. nav

    MattJ: a patent is just one type of IP right. I did not say anything about Axolotl and patents. I was trying to establish flow's level of awareness of the general domain of intellectual property, since I (don't think I) know him personally, that's all.

  303. nav

    flow: > Ideally there is a policy that XEPs have to be only based on other open standards that are available free of charge That seems like a good idea to me.

  304. nav

    …that's why I mentioned essential patents, to introduce that aspect of the discussion.

  305. nav

    Also, I had somehow assumed that to be the case, as is already the case in other areas of technology, such as ISO standards.

  306. nav

    That's why I found XEP-0384 a bit of an outlier.

  307. MattJ

    What makes it an outlier?

  308. nav

    But as Link Mauve pointed out, this probably (likely?) affects other XEPs as well.

  309. Link Mauve

    nav, did I?

  310. Link Mauve

    I only mentioned that there are XMPP libraries licensed under a GPL license.

  311. nav

    Link Mauve: > nav, I didn’t say they weren’t freely available, just that there exists implementations under a given license.

  312. nav

    Yup, that's it.

  313. MattJ

    We had a whole drama about it depending on a specific implementation which was GPL, and it got updated due to that (despite some disagreement)

  314. Link Mauve

    Speaking of which, the new https://xmpp.org/software/libraries/ doesn’t mention the license of a particular library, this should probably be fixed.

  315. nav

    MattJ: The fact that I was aware of the shenanigans concerning its licensing.

  316. MattJ

    What shenanigans?

  317. nav

    Link Mauve: 👍

  318. Link Mauve

    nav, but there are no shenanigans, that’s the conclusion of the past hour of discussion.

  319. nav

    Link Mauve: that's the conclusion only because seemingly nobody bothered to read the references that I posted.

  320. Link Mauve

    nav, it got debunked by Signal according to “19:25:45 MattJ> At least in 2016 they confirmed they had no patents on the protocol, and I fail to find any: https://news.ycombinator.com/item?id=11727870”

  321. nav

    Link Mauve: I never mentioned patents in the context of Axolotl.

  322. MattJ

    What is the context of this discussion, if not Axolotl?

  323. nav

    And forgive me for giving more credibility to a CNRS researcher than to the main interested party and a blog post.

  324. nav

    MattJ: I never said anything about Axolotl being or not being patented. That's a red herring. What I did mention is that their approach to IP enforcement is *different* from patenting.

  325. MattJ

    OK. I missed that then.

  326. nav

    no probs

  327. nav

    But, to wrap it up: does the XSF have access to legal counsel? Is there any sort of legal review or involvement in the publication of XEPs, or is it completely caveat emptor?

  328. nav

    I'm asking because, again, when working to ISO standards one is reasonably clear of the conditions under which a standard may be implemented.

  329. MattJ

    The XSF does not have a permanent legal council for stuff like this. We would seek such counsel if deemed necessary, but there is no indication here that it is necessary.

  330. nav

    And I, perhaps foolishly, assumed it would be the same with XEPs.

  331. MattJ

    The XSF's IPR policy is on the site

  332. nav

    MattJ: Thanks. I just found it via Google.

  333. flow

    nav, I actually look at the PDFs, but couldn't find anything related

  334. flow

    related to the discussion

  335. flow

    but then again, those XEPs are big

  336. flow

    and, tbh, just because it is a academic publication shouldn't give it automatically credability

  337. flow

    even if it was peer reviewed, which I am not sure if this even was

  338. MSavoritias (fae,ve)

    Yep. Its basically the same coclusion we arrived half an hour ago. Read the XEP, look for an implementation that fit your license.

  339. MSavoritias (fae,ve)

    If a dev doesnt look at licenses that his thing

  340. MSavoritias (fae,ve)

    And the XEP has nothing to do with the libsignal implementation. Its an open standard

  341. flow

    for example you mention D3.3 and D3.6. D3.3 is "Problems of peer-to-peer instant messaging: from contact discovery to battery consumption", which does not seem to deal with license or IP issues. And I can't even find a D3.6

  342. nav

    flow: that must be a different D3.3. This one, of which I do not have access to an offline copy that I can share right now and for which the one online copy I was able to find was inside that ZIP file linked from https://nextleap.eu/deliverables.html is titled "Draft Decentralized Case Studies" (the direct link on that page 404, hence why the need to go to the ZIP). The discussion is on page 14 &ss.

  343. nav

    D3.6 is indeed missing from the archive but I shared a link above (https://ec.europa.eu/research/participants/documents/downloadPublic?documentIds=080166e5c208ad8b&appId=PPGMS – PDF). Relevant discussion starts on page 16.

  344. nav

    The authors have also published a number of papers on the subject, some of which are listed here: https://nextleap.eu/publications.html That's a bit heavier reading as you might expect and albeit interesting, probably do not add much to the discussion.

  345. flow

    nav, yes there is a whole D3.3DraftDecentralizedCaseStudis.pdf, which includes the § 3.3 I menionted

  346. Sam

    A giant list of papers on various topics indeed does not add anything to the discussion. If you can't even summarize it, and the only evidence you have is one or two papers that mention it in passing (possibly? In at least the one of them I just tried to look at I couldn't find anything related) then this discussion probably isn't going to go anywhere and I'd say the other side has presented a lot more evidence and should probably be trusted more.

  347. flow

    but the D3.3 PDF does not really talk about license, leave alone license issues wrt to the omemo specification

  348. lovetox

    i read 3.6 its just a summary of the history of the signal protocol and everything we talked about

  349. flow

    and the D3.6 PDF essentially just states that libsignal is GPL licensed

  350. nav

    flow: > Ideally there is a policy that XEPs have to be only based on other open standards that are available free of charge https://xmpp.org/about/xsf/ipr-policy/#contrib-approval

  351. flow

    so nothing so far in the PDFs convinces me that there are any license issues with omemo

  352. flow

    nav, yeah, I assumed that we have something like this in our IPR, but wasn't sure :)

  353. nav

    flow: that is clear and the goal is not to convince you. I just hadn't realised that there was no process or resources whatsoever to determine the licensing and availability status of technology underlying XEPs, that's all.

  354. MSavoritias (fae,ve)

    nav: have you read the mailing list at the time of it being discussed? Because you have been told that there were. Who is the one spreading the "disinformation" as you say here

  355. nav

    MSavoritias (fae,ve): Nope, though I have been told earlier on that there is none with a legal background that gets consulted in the process of approving XEPs. Do you recall the approximate date when this discussion that you refer to would have taken place in the mailing list?

  356. flow

    I think there is such a proces, but we just don't call a laywer each time

  357. nav

    "I think there is such a process" doesn't sound terribly confidence-inspiring. 🤪 Surely it's documented somewhere?

  358. MSavoritias (fae,ve)

    nav: Probably around the time the XEP got posted. It should be in the bottom of the page in versions.

  359. nav

    First revision you mean?

  360. MSavoritias (fae,ve)

    Yeah

  361. MSavoritias (fae,ve)

    So around then: 2015-10-25

  362. nav

    👍

  363. flow

    well, you can't really compare the XSF with the ISO

  364. nav

    To be clear, personally I don't have an issue with things just being thrown out there without compliance review, especially since we're far from the heydays of XMPP (and the funding that goes with it), but as a suggestion, perhaps a disclaimer to the effect – or at least getting rid of § 3.2 of the intellectual property rights policy (since there is no active enforcement) might be in order?

  365. nav

    MSavoritias (fae,ve): Thanks. The discussion I found takes place around May 2017 but I found no mention of a legal review and crucially, one person there, a developer, seems to make the fatal mistake of mixing up the rights to the document with the rights to the standard (to be fair, a casual reading of the OWS document does lead one to make that mistake).

  366. MattJ

    I'm not really sure what you're expecting an alternative would be though. There's no such thing as an exhaustive IPR review (i.e. anyone at any time can claim anyone is infringing, regardless of whatever review has/hasn't been performed)

  367. MattJ

    I can understand why a standards org that charges for access may undertake IPR reviews on behalf of its members, but that's quite obviously beyond scope of the XSF. The IPR policy details our scope and expectations of contributors.

  368. nav

    MattJ: XSF IPR § 1.2 (https://xmpp.org/about/xsf/ipr-policy/#intro-role) on the part of OWS is what I would expect.

  369. nav

    There is no such statement from them, is there?

  370. MattJ

    They explicitly decalare their specs as public domain, so yes

  371. nav

    Where that? Here? https://signal.org/docs/specifications/doubleratchet/#ipr

  372. MattJ

    Exactly

  373. nav

    So no, sorry.

  374. MattJ

    ?

  375. nav

    We've been going back in circles and I got the information I wanted hours ago, so it's time to end this increasingly pointless discussion. Once again: "This document is hereby placed in the public domain." does not mean what you think it means. There is a reason why IPR § 1.2 is written the way it's written and the two are in no way equivalent.

  376. nav

    I have already said this: "this *document" … blah blah … public domain" means you're free to save a copy of that webpage to your hard drive, or post it on your own blog, or print it out, frame it and sell it. It does not give you any rights to the actual specification and most certainly does not mean "that in perpetuity any entity may independently, and without payment or hindrance, create, use, sell, distribute, or dispose of implementations of XMPP and of any XMPP Extension. "

  377. MattJ

    The document is the specification

  378. nav

    Nope. The document is the document.

  379. MattJ

    And the specification is...?

  380. nav

    Why would they (OWS) do that is not for me to guess, and I see how it's open to misinterpretation.

  381. MattJ

    I don't see any potential for misinterpretation. A specification is a type of document. I see no problem with saying "this document"

  382. nav

    MattJ: Really, ask a lawyer friend to explain this to you. I have already tried, and failed, by giving the example of an out of copyright work and a (forget what it's called now, a realisation?) of that work.

  383. MSavoritias (fae,ve)

    Or we can just read all the sources that have been given to the contrary here

  384. MSavoritias (fae,ve)

    Including wire mixinp up licenses for the implementation

  385. nav

    Yes, you can do whatever you want. Feel entirely free.

  386. MSavoritias (fae,ve)

    *not* the specification. As far as i understood that example that was brought up

  387. Mx2

    So finally was messing with xml stream acknowledged?

  388. Mx2

    I remember it pretty good

  389. MattJ

    ?

  390. nicoco_

    goffi: I have a question about prosody's mod_privilege which you authored I think, I hope here is an OK place to ask. if a component sends a chat message on behalf of another JID, is this chat message supposed to create a MAM entry? After a little playing with it, I *think* it does not. is this the expected behaviour?