XSF Discussion - 2020-01-13

  1. pdurbin has left

  2. stpeter has joined

  3. aj has joined

  4. Shell has left

  5. Dele (Mobile) has joined

  6. Dele (Mobile) has left

  7. Dele (Mobile) has joined

  8. aj has left

  9. sonny has left

  10. debacle has left

  11. emus has left

  12. Dele (Mobile) has left

  13. Dele (Mobile) has joined

  14. krauq has left

  15. sonny has joined

  16. krauq has joined

  17. mukt2 has joined

  18. Dele (Mobile) has left

  19. Dele (Mobile) has joined

  20. Dele (Mobile) has left

  21. Dele (Mobile) has joined

  22. mukt2 has left

  23. Dele (Mobile) has left

  24. Dele (Mobile) has joined

  25. Dele (Mobile) has left

  26. stpeter has left

  27. adiaholic has left

  28. adiaholic has joined

  29. Dele (Mobile) has joined

  30. pdurbin has joined

  31. vanitasvitae

    :D that deascalated quickly.

  32. pdurbin has left

  33. andrey.g has left

  34. stpeter has joined

  35. Dele (Mobile) has left

  36. Dele (Mobile) has joined

  37. Dele (Mobile) has left

  38. david has left

  39. andrey.g has joined

  40. david has joined

  41. neshtaxmpp has left

  42. neshtaxmpp has joined

  43. Dele (Mobile) has joined

  44. Dele (Mobile) has left

  45. Dele (Mobile) has joined

  46. Dele (Mobile) has left

  47. stpeter has left

  48. Dele (Mobile) has joined

  49. Vaulor has joined

  50. Yagiza has joined

  51. pdurbin has joined

  52. Dele (Mobile) has left

  53. Dele (Mobile) has joined

  54. Dele (Mobile) has left

  55. lskdjf has left

  56. Dele (Mobile) has joined

  57. !XSF_Martin has joined

  58. !XSF_Martin has left

  59. andy has joined

  60. Nekit has joined

  61. Dele (Mobile) has left

  62. Dele (Mobile) has joined

  63. sonny has left

  64. sonny has joined

  65. Dele (Mobile) has left

  66. !XSF_Martin has joined

  67. lorddavidiii has joined

  68. Tobias has joined

  69. Dele (Mobile) has joined

  70. Dele (Mobile) has left

  71. Dele (Mobile) has joined

  72. Dele (Mobile) has left

  73. Dele (Mobile) has joined

  74. Dele (Mobile) has left

  75. Dele (Mobile) has joined

  76. j.r has left

  77. j.r has joined

  78. Dele (Mobile) has left

  79. paul has joined

  80. Dele (Mobile) has joined

  81. karoshi has joined

  82. Dele (Mobile) has left

  83. Dele (Mobile) has joined

  84. Dele (Mobile) has left

  85. Dele (Mobile) has joined

  86. lovetox has joined

  87. lovetox has left

  88. wurstsalat has joined

  89. Dele (Mobile) has left

  90. Dele (Mobile) has joined

  91. emus has joined

  92. arc has joined

  93. Dele (Mobile) has left

  94. Dele (Mobile) has joined

  95. arc has left

  96. arc has joined

  97. Dele (Mobile) has left

  98. Dele (Mobile) has joined

  99. lorddavidiii has left

  100. lorddavidiii has joined

  101. !XSF_Martin has left

  102. lorddavidiii has left

  103. lorddavidiii has joined

  104. Dele (Mobile) has left

  105. lorddavidiii has left

  106. lorddavidiii has joined

  107. lorddavidiii has left

  108. lorddavidiii has joined

  109. !XSF_Martin has joined

  110. Dele (Mobile) has joined

  111. lovetox has joined

  112. winfried has left

  113. winfried has joined

  114. Dele (Mobile) has left

  115. lovetox

    about what was that talk, i did not understand one word

  116. waqas has joined

  117. waqas has left

  118. Dele (Mobile) has joined

  119. Dele (Mobile) has left

  120. mathijs has left

  121. mathijs has joined

  122. pep.

    lovetox, moparisthebest didn't fall for reverse psycology, that's the take away from this

  123. Dele (Mobile) has joined

  124. winfried has left

  125. winfried has joined

  126. sonny has left

  127. mathijs has left

  128. mathijs has joined

  129. mukt2 has joined

  130. arc has left

  131. sonny has joined

  132. !XSF_Martin has left

  133. mathijs has left

  134. goffi has joined

  135. mathijs has joined

  136. sonny has left

  137. sezuan has left

  138. sezuan has joined

  139. waqas has joined

  140. lovetox has left

  141. lovetox has joined

  142. lorddavidiii has left

  143. lorddavidiii has joined

  144. mathijs has left

  145. mathijs has joined

  146. Dele (Mobile) has left

  147. Dele (Mobile) has joined

  148. Dele (Mobile) has left

  149. waqas has left

  150. waqas has joined

  151. sonny has joined

  152. sonny has left

  153. sonny has joined

  154. Dele (Mobile) has joined

  155. sonny has left

  156. mukt2 has left

  157. Zash has left

  158. sonny has joined

  159. Zash has joined

  160. Dele (Mobile) has left

  161. Dele (Mobile) has joined

  162. Dele (Mobile) has left

  163. Dele (Mobile) has joined

  164. Dele (Mobile) has left

  165. eevvoor has joined

  166. Dele (Mobile) has joined

  167. lorddavidiii has left

  168. lorddavidiii has joined

  169. lorddavidiii has left

  170. lorddavidiii has joined

  171. Yagiza has left

  172. Yagiza has joined

  173. lorddavidiii has left

  174. lorddavidiii has joined

  175. lorddavidiii has left

  176. aj has joined

  177. lorddavidiii has joined

  178. Maranda has left

  179. neshtaxmpp has left

  180. Maranda has joined

  181. mukt2 has joined

  182. Alex has left

  183. Alex has joined

  184. aj has left

  185. lorddavidiii has left

  186. mukt2 has left

  187. lorddavidiii has joined

  188. lorddavidiii has left

  189. lorddavidiii has joined

  190. larma has left

  191. debacle has joined

  192. lorddavidiii has left

  193. larma has joined

  194. lorddavidiii has joined

  195. lorddavidiii has left

  196. lorddavidiii has joined

  197. reedhhw has joined

  198. waqas has left

  199. sonny has left

  200. Wojtek has joined

  201. debacle has left

  202. sonny has joined

  203. mukt2 has joined

  204. andrey.g has left

  205. eevvoor has left

  206. mukt2 has left

  207. pdurbin has left

  208. sonny has left

  209. lskdjf has joined

  210. mukt2 has joined

  211. debacle has joined

  212. lovetox has left

  213. sonny has joined

  214. Tao has joined

  215. lovetox has joined

  216. mukt2 has left

  217. Tao has left

  218. neshtaxmpp has joined

  219. mukt2 has joined

  220. sonny has left

  221. lovetox has left

  222. mukt2 has left

  223. eevvoor has joined

  224. lovetox has joined

  225. lovetox has left

  226. lovetox has joined

  227. mukt2 has joined

  228. mimi89999 has left

  229. sezuan has left

  230. lovetox has left

  231. lovetox has joined

  232. sezuan has joined

  233. sonny has joined

  234. sonny has left

  235. mukt2 has left

  236. mukt2 has joined

  237. mukt2 has left

  238. mimi89999 has joined

  239. lovetox has left

  240. sonny has joined

  241. mukt2 has joined

  242. adiaholic has left

  243. andrey.g has joined

  244. mukt2 has left

  245. pdurbin has joined

  246. adiaholic has joined

  247. sonny has left

  248. lovetox has joined

  249. emus has left

  250. emus has joined

  251. pdurbin has left

  252. emus has left

  253. sonny has joined

  254. emus has joined

  255. mukt2 has joined

  256. sonny has left

  257. sonny has joined

  258. sonny has left

  259. adiaholic has left

  260. adiaholic has joined

  261. sonny has joined

  262. eevvoor has left

  263. Tao has joined

  264. sonny has left

  265. Tao has left

  266. stpeter has joined

  267. calvin has joined

  268. !XSF_Martin has joined

  269. stpeter has left

  270. mukt2 has left

  271. calvin has left

  272. calvin has joined

  273. Wojtek has left

  274. calvin has left

  275. calvin has joined

  276. calvin has left

  277. calvin has joined

  278. Wojtek has joined

  279. sonny has joined

  280. calvin has left

  281. calvin has joined

  282. mukt2 has joined

  283. mukt2 has left

  284. stpeter has joined

  285. calvin has left

  286. calvin has joined

  287. stpeter has left

  288. Vaulor has left

  289. pdurbin has joined

  290. matlag has joined

  291. pdurbin has left

  292. stpeter has joined

  293. emus has left

  294. j.r has left

  295. stpeter has left

  296. j.r has joined

  297. mukt2 has joined

  298. adiaholic has left

  299. adiaholic has joined

  300. Vaulor has joined

  301. sonny has left

  302. sonny has joined

  303. calvin has left

  304. mukt2 has left

  305. neshtaxmpp has left

  306. adiaholic has left

  307. flow

    winfried, reading your comment on the PR: some believe that any libsignal wire protocol library would itself be required to be gpl compatible. INAL, but I think this is likely true

  308. flow

    *libsignal wire-protocol compatible library

  309. Zash

    lawyer up and argue that copying some constants does not constitute a derivate work!

  310. Zash

    or something

  311. moparisthebest

    winfried, exactly, my argument is basically the XSF isn't even qualified to decide that and moreover it shouldn't matter

  312. moparisthebest

    it surely also varies by jurisdiction, it's a useless restriction to put on XEPs

  313. lorddavidiii has left

  314. winfried

    Copyright works for the implementation, not for the principles underneath it. So if the protocol isn't described in a document with a license stating that any implementation of it needs to be GPL'd then code re-implementing the the protocol can have any license.

  315. lorddavidiii has joined

  316. winfried

    And the Signal protocol is nowhere described properly except in the code....

  317. Zash

    Is an implementation a derivative work of the specification?

  318. stpeter has joined

  319. eevvoor has joined

  320. winfried

    @Zash no. Reusing the text of it for a concurrent specification would be, as would be correcting the specification.

  321. Zash

    Some RFCs include example code which tends to be BSD/MIT-ish licensed, for sensible reasons.

  322. flow

    winfried, I'd argue that the signal protocl is nicely described, specified and document, but the constants ligsignal uses are not

  323. calvin has joined

  324. moparisthebest

    and in some jurisdictions that doesn't matter, in other's like the USA there is case law about that saying it's ok for interop I think

  325. moparisthebest

    under no circumstances should *programmers* at the XSF make legal judgements and enforce them on XEPs, in my opinion of course

  326. winfried

    @flow: it's long ago I read all the documentation I could find on Xototl (as it was called back then), and by then it was incomplete. It would be interesting to see the licensing of the protocol.

  327. flow

    winfried: https://signal.org/docs/specifications/doubleratchet/

  328. moparisthebest

    also I find it odd if we are going to "guarantee everyone can implement a XEP" that the guarantee seemingly only applies licenses

  329. moparisthebest

    https://xmpp.org/extensions/xep-0365.html we should also drop this one since most people aren't able to use STANAG 5066

  330. moparisthebest

    (sarcasm of course, but that goes to my point, once you start rejecting XEPs because you think certain people won't be able to implement them where do you stop)

  331. winfried

    flow: "This document is hereby placed in the public domain", interesting to see where those constants are defined and if these would be GPL....

  332. calvin has left

  333. mukt2 has joined

  334. dwd

    winfried, The constants are only defined within the source code as far as I've found.

  335. dwd

    moparisthebest, I'm not sure what you think it not implementable with XEP-0365. It wouldn't be fun, and you'd need the hardware to make any use of it, but it is possible to write a STANAG 5066 implementation without access to any radios.

  336. Kev

    Indeed, you can use 5066 across serial lines if you wish.

  337. moparisthebest

    and everyone agrees it's possible to implement OMEMO as long as your software is GPL

  338. moparisthebest

    or, even if not, as long as you just don't distribute it

  339. moparisthebest

    what's the difference?

  340. dwd

    moparisthebest, What's the similarity?

  341. moparisthebest

    both of them are implementable given certain decisions and constraints

  342. dwd

    moparisthebest, What decision and constraint for XEP-0365?

  343. mathijs has left

  344. mathijs has joined

  345. moparisthebest

    "implementing it without radios/being able to use/test it" seems the same as "implementing omemo and not distributing it" to me

  346. dwd

    moparisthebest, But you can test it without radios - just write a simulator (or, indeed, use an existing one).

  347. moparisthebest

    and you can test omemo without distributing it

  348. winfried

    trying to find those constants in https://github.com/signalapp.. does anybody have a pointer for me?

  349. dwd

    moparisthebest, I don't understand why you think that's the same thing.

  350. moparisthebest

    my question here is essentially, what makes the XSF qualified to make this license judgement

  351. moparisthebest

    I don't think it is, so I don't think it should, that's all

  352. dwd

    moparisthebest, And your view is that we should actively avoid doing so, which is rather different from acknowledging that whatever we may strive for, it might be unattainable in some edge cases.

  353. winfried

    moparisthebest: Only judges (inital, appeal and then higher appeal for each jurisdiction) are qualified to make license judgments. Until then we have to make our estimation...

  354. moparisthebest

    yes, we should actively avoid trying to make license/law decisions because we 1) are not lawyers 2) cross so many jurisdictions as to make even the attempt useless

  355. dwd

    moparisthebest, But we also cannot perfectly prove that our protocols work. So should we then avoid making interoperable protocols?

  356. moparisthebest

    that's different, it's something we do have control over, and what the focus should be on

  357. jonas’

    moparisthebest, you seem to be jumping between "GPL-only XEPs should be fine" and "the XSF should not care about licensing"

  358. jonas’

    which is it?

  359. moparisthebest

    if the UK govt bans communication outside of $new_govt_app tommorow do we just close up shop here or

  360. moparisthebest

    jonas’, the first being true because of the second

  361. dwd

    moparisthebest, Why is that relevant?

  362. moparisthebest

    dwd, isn't a "we shouldn't allow this XEP because of $possible_legal_concerns_over_licensing" the same thing?

  363. moparisthebest

    are we policing the legality of XEPs or not

  364. dwd

    moparisthebest, No.

  365. dwd

    moparisthebest, We aren't policing the legality of XEPs. We're trying to ensure that anyone can implement them without emcumberence. That doesn't mean analysing the law, it means following largely similar rules as any other standards development organisation, and avoiding cases where there is a strong suspicion that essentially nobody could implement without a constraint placed upon them (even if they might be happy in some cases with that constraint).

  366. dwd

    moparisthebest, I note that you didn't complain when we rejected XEP-0365 initially. In fact, you didn't say anything on the subject at all.

  367. moparisthebest

    there are a billion possible constraints on people implementing XEPs, this seems like a particularly arbitrary line

  368. winfried

    We may differ on opinion on how the XSF should relate to legal issues, but I am still trying to find those constants. I really want to see them before making my own judgment on the license status of OMEMO implementations.

  369. moparisthebest

    I don't care about XEP-0365 in particular, just the policy in general

  370. adiaholic has joined

  371. adiaholic has left

  372. adiaholic has joined

  373. jonas’

    winfried, https://github.com/Syndace/python-omemo-backend-signal/ there’s this code which is assumed to be the minimal part of OMEMO which is to be put under GPL

  374. jonas’

    winfried, stuff like this probably: https://github.com/Syndace/python-omemo-backend-signal/blob/master/omemo_backend_signal/doubleratchet/cbcaead.py#L26

  375. jonas’

    and, for the record, those constants feed into HKDFs, so it’s very likely that you cannot reverse engineer them by just looking at the wire format

  376. jonas’

    I’m not even sure that’s possible to do with clean-room stuff, but I’m not 100% certain on how it works. maybe it is. there’s still the trademark question tho

  377. eevvoor has left

  378. moparisthebest

    I think it's probably fine just to copy them, it would *definitely* be fine with clean-room, but I'm not even arguing that, just that we shouldn't be trying to make those judgements

  379. moparisthebest

    I wouldn't be at all opposed to a note about them, but rejecting a XEP because of a legal judgement we made is ridiculous

  380. moparisthebest

    (and again, with OMEMO, seems there are plenty of technical reasons to reject it which I have no problem with)

  381. winfried

    jonas’ wasn't the double ratchet taken from a MIT licensed library?

  382. moparisthebest

    constants are here what's the license of this? https://eprint.iacr.org/2014/904.pdf

  383. jonas’

    winfried, doubt it, then it wouldn’t be split off into the -backend-signal repository (wihch only exists to isolate the GPL things)

  384. jonas’

    winfried, you may want to ping Syndace about the details

  385. jonas’

    moparisthebest, are you back at trying to judge the license situation? ;)

  386. pep.

    jonas’, isn't everybody here?

  387. pep.

    That's what started this whole thing

  388. moparisthebest


  389. pep.

    Or we get a legal team! For every single jurisdiction in the world :)

  390. moparisthebest

    pretty sure none of us are lawyers, but I know 100% none of us are lawyers across all jurisdictions

  391. moparisthebest

    I was trying to answer winfried 's question with the links, also constants are https://hal.inria.fr/tel-01950884v1/document

  392. jonas’

    pep., I stopped trying, really

  393. winfried

    moparisthebest: trust me, lawyers won't give an answer too, certainly lawyers not because they may be sued if a judge judges differently.......

  394. pep.


  395. calvin has joined

  396. moparisthebest

    https://www.dinosec.com/docs/WhatsApp_E2E_Encryption_RootedCON-DinoSec-RaulSiles_v1.0.pdf also constants here

  397. pep.

    jonas’, sure, so did I (I don't think I even tried actually)

  398. moparisthebest

    all that's enough that likely that would be plenty for a "clean room implementation" ie, "I did not look at that GPL lib, I found the constants in these slides"

  399. moparisthebest

    and again, that shouldn't be a consideration the XSF should make, that's on the implementor

  400. mathijs has left

  401. mathijs has joined

  402. jonas’

    moparisthebest, I’d like to remind you about the three options from the other day

  403. moparisthebest

    so ralphm / dwd / jonas’ , ralphm is the one that said I should update that objective, if not and I really just want to make sure the XSF doesn't try to judge the legality of a XEP, what change should be made?

  404. jonas’

    moparisthebest, I’m not quite able to parse that sentence

  405. Kev

    If your objective is that the XSF stops aiming for XEPs to be unencumbered, I think the PR you proposed is the right one.

  406. pdurbin has joined

  407. Kev

    (Which I think is another way of putting what you've been calling 'judging the legality of a XEP')

  408. moparisthebest


  409. moparisthebest

    my argument is basically the XSF isn't qualified to do so, so we shouldn't

  410. winfried

    Thanks for all the pointers to the constants and publications of them. Lets stat it this way: if Marlinspike claims all OMEMO should be GPL'ed because of the use of the constants, then he would not have a strong case without suing all publications of those constants that are not GPL licensed. (Wondering what constants are used in Whatsapp....)

  411. Kev

    I don't agree, but I think the PR you've opened is the right way to propose the change.

  412. jonas’

    winfried, he might’ve given a license to WhatsApp for example

  413. jonas’

    which is his right to do

  414. jonas’

    (and which may be why he insists on GPL so much)

  415. winfried

    jonas’: true

  416. moparisthebest

    winfried, FYI I did https://www.google.com/search?q=%22WhisperMessageKeys%22 which is slightly cheating, but you could have equally searched for "textsecure audit" or whatever

  417. mukt2 has left

  418. pdurbin has left

  419. Shell has joined

  420. emus has joined

  421. mukt2 has joined

  422. Shell has left

  423. andy has left

  424. andy has joined

  425. Vaulor has left

  426. !XSF_Martin has left

  427. Vaulor has joined

  428. !XSF_Martin has joined

  429. Nekit has left

  430. mukt2 has left

  431. neshtaxmpp has joined

  432. dwd

    He didn't simply license to WhatsApp, they paid OWS to help them implement it: https://signal.org/blog/whatsapp-complete/

  433. Syndace

    winfried: I heard my name! Happy to clear up most questions about the OMEMO Licensing thing

  434. mathijs has left

  435. adiaholic has left

  436. mathijs has joined

  437. sonny has left

  438. mathijs has left

  439. mathijs has joined

  440. lovetox has left

  441. winfried

    Syndace: great!

  442. Syndace

    (sorry, now I'll be driving for a few minuten and can't respond)

  443. Syndace

    (sorry, now I'll be driving for a few minutes and can't respond)

  444. winfried

    No prob, I was cooking so I couldn't respond ;-)

  445. mukt2 has joined

  446. j.r has left

  447. j.r has joined

  448. adiaholic has joined

  449. winfried

    But to state my question already: is it correct that you included the WhisperMessageKeys used for the HKDF function in the GPLed part of your library? And do you see any other obstacles (except for a lot of work and code reviews etc) hindering writing a SignalProtocol protocol implementation from scratch?

  450. Wojtek has left

  451. Wojtek has joined

  452. lorddavidiii has left

  453. lorddavidiii has joined

  454. sonny has joined

  455. j.r has left

  456. debacle has left

  457. Syndace

    Okay here I am. Yes, I had to use WhisperMessageKeys and various other constants to stay compatible with libsignal. Those other constants include more strings (I thinkt there is WhisperMessage used somewhere and a third one) and two byte constant, one being used to encode the curve a public key is correspnding to and the other being used during key derivation. All of these constants are _inputs_ to cryptographic functions at some point, most of them being hash functions. There is also one more thing I had to take from libsignal: the protobuf structure definitions, which describe how the data is encoded into bytes that are then sent to other parties. All of these things were taken from the GPL'd repository of libsignal.

  458. Syndace

    Other than that the only obstacles are a basic understanding of cryptography, a lot of time to read and understand the specs by Signal, and quite a bit of implementation work.

  459. Syndace

    Oh and yes, all of these constants are obviously part of the GPL'd part of my library.

  460. Syndace

    It was not easy to split these parts cleanly.

  461. Syndace

    (and it's a little optimistic to call it "clean")

  462. Syndace

    winfried: Did that answer your questions?

  463. j.r has joined

  464. moparisthebest

    protobufs could clearly be reverse-engineered from the network at least though

  465. winfried

    Syndace: yes... I already found some of those constants, two byte constants and protobuf stuf in your code, was wondering how I should weigh them.

  466. moparisthebest

    and I don't think you can copyright constants, that's surely true in at least some jurisdictions

  467. Syndace

    moparisthebest: I am not sure, especially they made the constants contain "Whisper", which is probably a copyrighted name.

  468. Syndace

    This is an old trick that a lot of software uses. They embed some copyrightable material into their format and suddenly nobody can copy the format without violating copyrights.

  469. moparisthebest

    I file that under "hacks programmers think get them around copyright laws" :)

  470. moparisthebest

    yep, at least oracle database and apple, that I know of

  471. moparisthebest

    actually here I don't think you can copyright the word "Whisper" either

  472. moparisthebest

    again depends on a lot of things, including jurisdiction

  473. Syndace

    Famous examples include file formats that include a little poem or the Nintendo Game Boy Classic, which only boots games that contain the Nintendo logo at a certain position.

  474. Ge0rG

    Trademark, not copyright

  475. Syndace

    moparisthebest: Yes, this is again a thing us it people can't really know/decide.

  476. winfried

    It is tricky to enforce the copyright over configurations or 2-byte constants, but it is easier to enforce when it is 'Whisper' or a longer key.

  477. sonny has left

  478. mukt2 has left

  479. winfried

    But looking at all, I come to the conclusion that it is indeed impossible to implement OMEMO without using GPL'ed code.

  480. Daniel

    well that's why we are making NEWMEMO

  481. Daniel

    (working title)

  482. Wojtek has left

  483. Wojtek has joined

  484. winfried

    Daniel: good to hear, is that part of the work of the e2ee sig?

  485. Syndace

    I'd say NEWMEMO is the first big goal of SIG-E2EE

  486. moparisthebest

    that's still a legal judgement by a non-lawyer and is virtually guaranteed to be wrong in at least 1 jurisdiction right? XSF should not be even attempting to make these judgements

  487. sonny has joined

  488. Daniel

    probably. at least the idea for the sig came from the same people who are working on omemo and newmemo

  489. Syndace

    moparisthebest: It's the safe route, which is the route you should take if you have no idea

  490. !XSF_Martin has left

  491. Syndace

    But yes, the conclusion should not talk in absolutes

  492. moparisthebest

    safe route for, who? the implementor should decide for themselves, they know the relevant things like what jurisdiction they are in or what license constraints they have

  493. Syndace

    safe for everybody who doesn't know better :D

  494. !XSF_Martin has joined

  495. Daniel

    i think omemo needs a lot of clean up that are independend of GPL questions. like fixing that horrible namespace for one

  496. moparisthebest

    is [87, 104, 105, 115, 112, 101, 114] trademarkable/copyrightable winfried / Syndace ? :D

  497. Ge0rG

    Daniel [19:49]: > well that's why we are making NEWMEMO I vote for OLOLO or OMENNO

  498. Zash


  499. Zash


  500. adiaholic has left

  501. paul has left

  502. winfried

    moparisthebest: yes, this is a judgement by a non-lawyer, yes it is guaranteed to be wrong in at least 1 jurisdiction, no a lawyer wouldn't give more certainty, only a judge can and no that not a reason for the XSF to not make estimates on legal issues, we can't function without such estimates.

  503. Syndace

    moparisthebest: Sorry but I can only judge that as you trying to trigger us. As I said we are not sure, thus we will go down the safe road and assume that the constants in libsignal are GPL'able

  504. Zash

    Daniel: I'd be happy if the PEP interaction got an overhaul as well :)

  505. Daniel

    Zash, in more than just using multiple items in one node?

  506. winfried

    moparisthebest: [87, 104, 105, 115, 112, 101, 114] is likely copyrightable, certainly if there is no prior art...

  507. moparisthebest

    sorry Syndace , kind of a joke question, and yes I don't know enough to say if the constants can be GPL, and wouldn't even want to guess, I don't think the XSF should either

  508. Ge0rG

    winfried: trademark, not copyright

  509. Syndace

    Daniel: Thanks for saying that. OMEMO2 has become way to equivalent to OMEMO without GPL. In contrast to what Paul wrote on the mailing list, my primary goal is _not_ to get rid of GPL, my primary goal is to create an improved version of OMEMO which does not cause headaches to everybody involved.

  510. moparisthebest

    I wouldn't be at all opposed to the XSF putting something like a warning in a XEP "hey no one is really sure if the constants needed are under the GPL or not, good luck" but rejecting for that reason seems wrong to me

  511. david has left

  512. winfried

    Ge0rG: it is less likely to trademarkable because it doesn't represent a recognizable pointer for a product, not as such a list of numbers. (4711 would)

  513. Zash

    Daniel: The thing with deviceid in node is weird and causes us pain (because users look at the storage and complain). Using PEP at all allowed for quick deployment but as the thing with publish-options hints at, I don't think you should be afraid of inventing something separate from PEP. There's motivation/pressure for implementing these things as long as the current OMEMO doesn't block on account of being "good enough"

  514. Daniel

    well having multiple items in one node (one item per device) and not having the index node would get rid of that

  515. Daniel

    i think that can and should be done

  516. sonny has left

  517. Ge0rG

    winfried: http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4807:j4jxhx.2.14

  518. adiaholic has joined

  519. Syndace

    Daniel: Agreed, splitting the device list node into multiple is one of the things I want to do

  520. Daniel

    i kinda like the idea of having something that isn’t pep (because you can actually hand out just one prekey per contact); but i'm afraid of second system syndrome

  521. Daniel

    and overengineering everything

  522. Zash

    Daniel: A generic device registration thing would be handy for a number of things....

  523. Daniel

    Zash, well if we do it _that_ generic we will never be done

  524. Zash


  525. Daniel

    one of my primary goals for the sprint is to actually have something done after the 2 days

  526. david has joined

  527. Daniel

    unless maybe if we can work on 'generic device registration' during summit (which predates the sprint); but even then it feels too risky

  528. winfried

    Ge0rG: Interesting and interesting how enforceable the trademark would be when used as id string in a protocol. http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4810:4gknh0.2.2 and still all browsers claim to be 'Mozilla'...

  529. Zash

    We do have some interest in keeping track of users' devices on the server, for things like MAM.

  530. Daniel

    and pep isn’t even a bad place for omemo; and a 'get me one prekey' request could potentially be done independently of that (even if the data is actually still in PEP)

  531. Ge0rG

    winfried: I'm sure you'll want to fight that out in court if you develop a browser

  532. adiaholic has left

  533. paul has joined

  534. winfried

    Ge0rG: yeah, these are indeed cases to take to court....

  535. winfried

    BTW: https://www.ngi.eu/news/2019/08/20/user-friendly-email-encryption-possible-with-identity-based-cryptography/

  536. winfried

    (still have to see how far they really will get)

  537. moparisthebest

    > Bart Jacobs: Speaking for myself, I don’t really have the patience for standardization and arguing about details.

  538. moparisthebest


  539. vanitasvitae

    moparisthebest: > is [87, 104, 105, 115, 112, 101, 114] trademarkable/copyrightable winfried / Syndace ? :D This reminds me of the story about Oracle using lines of a poem inside the wire format of their (database?) application. The reasoning was that a protocol could be reverse engineered without breaking any copyright laws, but poems are literature and remain protected.

  540. moparisthebest

    yep I linked that the other day, also Apple did a similar thing within their... bios (not the right word)

  541. Syndace

    vanitasvitae: Look like 10 messages above :D

  542. winfried

    moparisthebest :-D but Bart is a bit a pain in the *** for Dutch governmental bodies that are implementing broken crypto....

  543. moparisthebest

    I've never heard of the guy I just thought that statement was funny

  544. adiaholic has joined

  545. winfried

    moparisthebest: he is professor in Computer Security and quite highly valued in that role. And he is not adverse from some controversy....

  546. debacle has joined

  547. winfried

    moparisthebest: he makes the news here every few weeks...

  548. sonny has joined

  549. moparisthebest

    this brings up all sorts of interesting copyright questions actually, can 24603125091427698 be copyrighted? wikipedia has a simalar-ish article https://en.wikipedia.org/wiki/Illegal_number

  550. pdurbin has joined

  551. moparisthebest

    24603125091427698 is what you get if you prepend the ASCII bytes of "Whisper" with a 0 and read it into a signed 64-bit number

  552. moparisthebest

    (and again to be clear, this kind of conjecture should be left up to implementors, not XSF)

  553. dwd


  554. dwd


  555. jonas’

    that’s a number

  556. dwd

    It is. That's the license fee Moxie asked for from Wire when they published an open source Axolotl implementation in Rust - they licensed under MPL.

  557. adiaholic has left

  558. Yagiza has left

  559. jonas’

    and did that work?

  560. Shell has joined

  561. moparisthebest

    you are saying there is a complete implementation licensed MPL that can be used?

  562. Ge0rG

    dwd: I'm sure that was just a generous consulting offer to ensure that Wire devs do it in the most secure way possible.

  563. dwd

    No. They wouldn't pay, tried counter-suing, and eventually reached a settlement wherein they refused to allow Moxie copyright, but they would change the license to GPL.

  564. moparisthebest

    was this before or after the documentation was published?

  565. Daniel

    He is just doing that to protect you

  566. winfried

    moparisthebest: no that can't be used because it is disputed because of license violation...

  567. dwd

    moparisthebest, Depends which documentation you're talking about.

  568. wurstsalat has left

  569. jonas’

    moparisthebest, according to an article, they based their implementation on, among others, the How Secure Is Textsecure paper you linked earlier

  570. jonas’


  571. moparisthebest

    Daniel, I know I feel safer

  572. dwd

    Looks like it doesn't use the same constants, either.

  573. jonas’


  574. jonas’

    so that wouldn’t be enough, and anything axolotl-ish would live under fear of Moxie

  575. flow

    > Daniel> i kinda like the idea of having something that isn’t pep (because you can actually hand out just one prekey per contact); but i'm afraid of second system syndrome I wonder if one could do both: Something like a basic pure-PEP based approach for rapid deployment and a PEP extension that allows to hand out a prekey only once

  576. jonas’

    which makes me think that the only viable way forward is reject OMEMO, publish a statement that Moxie makes the ecosystem move towards MLS, and that’ll take a while. until then, you’re bound to OX, OTR or use a GPL-licensed client with inofficial OMEMO support

  577. moparisthebest

    jonas’, anything not already GPL :)

  578. !XSF_Martin has left

  579. dwd

    My understanding is that you don't want all the prekeys / clientinitkeys visible at once anyway.

  580. winfried

    jonas’: one of the protocol descriptions linked above is 'public domain', so the pain is in the Mozie ^H^H^H^H constants

  581. dwd

    (prekeys for Axolotl/Olm, clientinitkeys for MLS)

  582. jonas’

    winfried, the article I linked earlier where the Wire folks describe their issues mentions that they were bullied by Moxie even though they based their work on that public domain paper

  583. moparisthebest

    you can be bullied even though you are legally in the clear

  584. Daniel

    flow: yes I said that a few lines down

  585. jonas’

    moparisthebest, which is an encumberence to me

  586. moparisthebest

    oh man well then you can't implement any of XMPP

  587. moparisthebest

    there probably exists a patent troll with a patent on "messages via internet"

  588. flow

    Daniel, uh, sorry, I've missed that

  589. flow

    dwd, because attachs?

  590. dwd

    flow, I have no idea, but I sat in a room full of cryptographers and one of them said so.

  591. flow

    dwd, next time, close the doors, then ask for the rationale and do not open until they provided one ;)

  592. jonas’

    and grey smoke emerges?

  593. Kev

    flow: And make sure you use a key with sufficient bits.

  594. !XSF_Martin has joined

  595. Shell has left

  596. Shell has joined

  597. dwd

    flow, I believe it's due to the same reasons as we use different {pre|clientinit}keys for each session - that is, by using a different key it makes the analysis easier.

  598. Daniel

    I've been told that reusing keys isn't the end of the world

  599. dwd

    Daniel, Indeed - better than running out of them.

  600. moparisthebest

    depends on the crypto primitive always no?

  601. Daniel

    But you know. Ask 3 cryptographers get 4 different opinions

  602. pdurbin has left

  603. dwd

    Daniel, I did float the notion of using an early reuse idea, where you become probablistically more likely to reuse a key as the server runs out, but I couldn't actually figure out a way to make it work nicely.

  604. winfried

    jonas’: I love to take Moxie head on, I had once the honer to speak right after Moxie at a conference, while I was climbing on stage, I saw half of my audience leaving. I still haven't forgiven that. (Though he did apologize for taking some of my time......) :-D

  605. dwd

    Daniel, And yes, never been in a room full of such incomprehensible arguments.

  606. pep.

    > This is an old trick that a lot of software uses. They embed some copyrightable material into their format and suddenly nobody can copy the format without violating copyrights. Wether it actually has any legal value is still to be determined, it's mostly a threat tbh. Nintendo used the same technique (the Nintendo logo at the beginning of every Gameboy game had to be part of the rom abd was verified at runtime), but I couldn't find any case. It was mostly a threat because who is going to oppose that much money..

  607. jonas’

    winfried, moohahaha

  608. Shell has left

  609. Shell has joined

  610. pep.

    (hmm, topic has changed 10 times in between)

  611. pep.

    and and you do cite Nintendo even..

  612. sonny has left

  613. wurstsalat has joined

  614. Syndace


  615. Shell has left

  616. Shell has joined

  617. Shell has left

  618. Shell has joined

  619. dwd

    Anyway, summary seemed to be that reusing keys, or publishing them openly prior to use, is probably safe but it makes the cryptanalysis harder, so please don't.

  620. moparisthebest

    makes it *easier* dwd ?

  621. jonas’

    no, the theoretical analysis (to prove things are safe) gets harder, moparisthebest

  622. moparisthebest

    ah got it, thanks

  623. sonny has joined

  624. winfried

    dwd: do I get it right that we are talking about the keys that need to be disposed of after use to get forward secrecy? Publishing them openly seems a bad idea then and keeping them on the server for a long time seems increasing the risk. (and still the idea of e2ee is that you don't trust your server...)

  625. mathijs has left

  626. mathijs has joined

  627. Daniel

    You delete your private keys

  628. winfried

    Daniel: clear, of course.... (brainfart)

  629. sonny has left

  630. moparisthebest

    "Courts have found that reverse engineering for interoperability, for example, can be a fair use." https://www.eff.org/issues/coders/reverse-engineering-faq interesting

  631. Wojtek has left

  632. Wojtek has joined

  633. Nekit has joined

  634. mathijs has left

  635. mathijs has joined

  636. sonny has joined

  637. Shell has left

  638. Shell has joined

  639. mathijs has left

  640. mathijs has joined

  641. moparisthebest

    basically all the cases there were ruled in favor of people who "had to look at the code to examine how it worked" and constants etc

  642. moparisthebest

    so in my official opinion (read: worthless) you could implement non-GPL OMEMO just fine (but still might get sued by Moxie, though you'd likely ultimitately win in court) in the USA

  643. winfried

    moparisthebest: examining it and describing the protocol is something else as reusing copyrighted keys and using trademarked names. Reverse engineering by looking at the code and then writing your own implementation would be hard to ban, but when it contains that one key....

  644. winfried

    (though it would be interesting to look if there are cases about that)

  645. moparisthebest

    winfried, isn't that exactly what those cases mention? 1. the Ninth Circuit ultimately found that Accolade’s “intermediate” copying (i.e., copying solely in order to discover functional interface specifications that were then independently implemented) was a fair use, emphasizing that disassembly was the only way to gain access to the ideas and functional elements embodied in Sega’s copyrighted computer program and that Accolade had a legitimate reason for seeking such access.

  646. moparisthebest

    2. finding that Connectix’s intermediate copying was a fair use. The court emphasized that the intermediate nature of the copying (i.e., no Sony BIOS code as included in the Virtual Game Station code), the necessity of reverse engineering, and the value of permitting consumers to play PlayStation games on new platforms

  647. jonas’

    moparisthebest, the risk of being sued is encumbarance alone

  648. Shell has left

  649. Shell has joined

  650. jonas’

    moparisthebest, the considerable risk, with precedents, of being sued is encumbarance alone

  651. moparisthebest

    and again you have that with *everything*

  652. Ge0rG

    Sega and Accolade imply that all this happened in a different epoch, long before digital copyright lobbying was a thing

  653. jonas’

    observe my edit

  654. moparisthebest

    those 2 are 1992 and 2000 respectively

  655. Dele (Mobile) has left

  656. Ge0rG

    And then the DMCA happened

  657. mathijs has left

  658. mathijs has joined

  659. moparisthebest

    > The ECPA, sections 18 U.S.C. 2510 and following, prohibit interception of electronic communications flowing over a network. Because packets are communications, network packet inspection may violate ECPA.

  660. moparisthebest

    well that one is interesting

  661. Shell has left

  662. winfried

    moparisthebest: I expect none of the implementations that resulted from the reverse engineering contained programming code that was part of the original product, but re-implementations of API's etc. If we want to make an own implementation of the SignalProtocol, we still have to literally copy the key into our code. That would be the suable infringement.

  663. andrey.g has left

  664. moparisthebest

    "intermediate copying" seems to protect you there, going from the above court cases

  665. moparisthebest

    ie "I got it from that PDF your honor"

  666. sonny has left

  667. jonas’

    do we need to fork a new xsf-legal@muc.xmpp.org room?

  668. winfried

    jonas’: :-D

  669. winfried

    I can keep that one going!

  670. moparisthebest

    ideally we never discuss legalities instead :)

  671. winfried

    I'll sue you if you never discuss legalities!

  672. moparisthebest


  673. sonny has joined

  674. Wojtek has left

  675. mathijs has left

  676. Ge0rG

    This discussion has already burned a very significant amount of resources from all of us, and we are essentially in agreement to disagree.

  677. mathijs has joined

  678. winfried

    moparisthebest: "intermediate copying" is as far as I understand it: making a copy to reverse engineer, decompile etc. Not copying the original code into a new product.

  679. Ge0rG

    So could we please stop explaining copyright, trademarks and the legal risks of life and move on?

  680. moparisthebest

    I'd like to first agree that the XSF should never explain or evaluate them, that was the intent behind my PR

  681. winfried

    Ge0rG: I think it is time indeed to let the official decision making process resolve the issues raised

  682. lovetox has joined

  683. Ge0rG

    moparisthebest: I'm speaking *especially* to you!

  684. jonas’

    seconding Ge0rG

  685. jonas’

    if this was an IRC channel, the last two days would’ve caused massive spikes in my biboumi-database-backup-size-increment-graph

  686. Ge0rG

    If I were paid by the M.A.T.R.I.X foundation to grind the XSF to a halt, this is exactly what I would do

  687. winfried

    moparisthebest: I think we need an official decision about it, it is a valid discussion but we won't resolve it here. Agree to differ I would see...

  688. winfried

    Ge0rG: LOL! I'm just investigating how to grind them to an halt. This would be a mighty good approach!

  689. moparisthebest

    Ge0rG, are you saying I could get paid for this? >:)

  690. moparisthebest

    I'm not trying to cause problems, I clearly disagree with a few of you on what one of the objectives mean, and I'd like to get it cleared up officially, that's all

  691. jonas’

    moparisthebest, in all honesty, from my perspective, if you don’t want to cause problems, let the topic rest until the next board meeting

  692. jonas’

    because you *are* causing problems

  693. jonas’

    even if it’s only me starting to actively ignore this room because it’s eating too much mental capacity for very little gain

  694. moparisthebest

    I just responded to a question about it is all

  695. moparisthebest

    you are of course free to /ignore or part the room, if this room isn't for discussing XSF policy I don't know what is

  696. jonas’

    moparisthebest, I’m not saying this is the wrong venue, I’m saying this is the wrong time

  697. moparisthebest

    we'll have to agree to disagree on that one too I'm afraid

  698. sonny has left

  699. Ge0rG

    moparisthebest: ignoring or leaving is very hard to pull off for a Council member

  700. winfried

    jonas’: a bit in defense of moparisthebest: I did flame up the discussion...

  701. jonas’

    moparisthebest, board will decide on XEP-0001. the board meeting is the best time to argue your case

  702. jonas’

    if you find that board disagrees with you, and you want to pursue this further, you can start a member vote

  703. jonas’

    but that only makes sense after the board meeting

  704. jonas’

    this was made clear last week already

  705. moparisthebest

    I was just responding to winfried, in the appropriate venue

  706. jonas’

    moparisthebest, I get that

  707. jonas’

    and I’m not arguing that

  708. Ge0rG

    Now that everything is clarified, we can move on

  709. jonas’

    all I was saying right now that this is a good time to let the topic rest, and I’m not going to cause any more noise now

  710. moparisthebest

    sure agreed

  711. jonas’

    what Ge0rG syas

  712. jonas’

    what Ge0rG says

  713. stpeter

    I know you folks were joking about grinding MATRIX to a halt, but IMHO that kind of talk is disrespectful and unproductive.

  714. jonas’

    stpeter, good point

  715. winfried

    agreed, I know what I needed to know, I have made up my mind and for me it is time to follow this up in other channels

  716. winfried

    stpeter: agreed, and my apologies for that, MATRIX deserves our respect and I think it would be good to cooperate.

  717. sonny has joined

  718. j.r has left

  719. j.r has joined

  720. sonny has left

  721. sonny has joined

  722. winfried has left

  723. winfried has joined

  724. sonny has left

  725. Dele (Mobile) has joined

  726. Nekit has left

  727. sonny has joined

  728. debacle has left

  729. winfried has left

  730. winfried has joined

  731. sonny has left

  732. lorddavidiii has left

  733. lorddavidiii has joined

  734. !XSF_Martin has left

  735. lorddavidiii has left

  736. lovetox has left

  737. lorddavidiii has joined

  738. !XSF_Martin has joined

  739. mr.fister has joined

  740. Kev has left

  741. lorddavidiii has left

  742. lorddavidiii has joined

  743. andrey.g has joined

  744. Shell has joined

  745. lorddavidiii has left

  746. lorddavidiii has joined

  747. sonny has joined

  748. lorddavidiii has left

  749. lorddavidiii has joined

  750. sonny has left

  751. pep.

    > jonas’> moparisthebest, in all honesty, from my perspective, if you don’t want to cause problems, let the topic rest until the next board meeting tbh I would have liked a discussion on list about this, on members@. I do think discussion is good. Decision without any context is less good. (all board members may be somewhat aware of the topic, even though I haven't seen Seve for a while, but members are not especially)

  752. pep.

    So telling somebody "please don't talk about this until a decision is made" is not a solution to me

  753. gav has left

  754. pep.

    Especially when other people bring the topic again in the room

  755. moparisthebest

    there are already 2 comments on the github issue, I planned on making 1 more there tonight

  756. pep.

    github is not the venue for that though..

  757. moparisthebest

    unless you want to start a members@ mail and I'll reply, or something

  758. pep.

    We have lists for that

  759. pep.

    that'd be great

  760. gav has joined

  761. moparisthebest

    if we start a list it'll just make the github convo get lost though?

  762. moparisthebest

    I don't really care, you tell me what to do :D

  763. pep.

    It should never have been

  764. moparisthebest

    can't change the past :)

  765. pep.

    You can quote from there I guess. I don't think people will hold a grudge

  766. lorddavidiii has left

  767. lorddavidiii has joined

  768. lorddavidiii has left

  769. lorddavidiii has joined

  770. Tobias has left

  771. Maranda has left

  772. Maranda has joined

  773. lorddavidiii has left

  774. lorddavidiii has joined

  775. lorddavidiii has left

  776. lorddavidiii has joined

  777. lorddavidiii has left

  778. lorddavidiii has joined

  779. sonny has joined

  780. rion has left

  781. rion has joined

  782. debacle has joined

  783. lorddavidiii has left

  784. lorddavidiii has joined

  785. sonny has left

  786. lorddavidiii has left

  787. sonny has joined

  788. lorddavidiii has joined

  789. sonny has left

  790. calvin has left

  791. Maranda has left

  792. lorddavidiii has left

  793. !XSF_Martin has left

  794. alameyo has left

  795. alameyo has joined

  796. sonny has joined

  797. !XSF_Martin has joined

  798. sonny has left

  799. emus has left

  800. pdurbin has joined

  801. Arc has joined

  802. sonny has joined

  803. pdurbin has left

  804. stpeter has left

  805. sonny has left

  806. debacle has left

  807. neshtaxmpp has left