XSF logo 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 I'm probably failing at being clear, we SHOULD NOT BE TRYING TO JUDGE THE LEGALITY/LICENSE SITUATION OF A XEP
  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. haha
  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 probably
  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 MLEMOS
  499. Zash MLSEMO
  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 Heh
  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 hahahaha
  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 $2,500,00.
  554. dwd $2,500,000.
  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’ https://medium.com/@wireapp/axolotl-and-proteus-788519b186a7
  571. moparisthebest Daniel, I know I feel safer
  572. dwd Looks like it doesn't use the same constants, either.
  573. jonas’ indeed
  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 :D
  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 touche
  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