XSF Discussion - 2020-01-09


  1. mukt2 has left

  2. krauq has left

  3. stpeter has left

  4. krauq has joined

  5. beta has left

  6. beta has joined

  7. mukt2 has joined

  8. pdurbin has joined

  9. pdurbin has left

  10. murabito has joined

  11. lskdjf has left

  12. mukt2 has left

  13. stpeter has joined

  14. mukt2 has joined

  15. Lance has left

  16. Lance has joined

  17. mukt2 has left

  18. debacle has left

  19. mukt2 has joined

  20. emus has left

  21. emus has joined

  22. beta has left

  23. beta has joined

  24. beta has left

  25. mukt2 has left

  26. mukt2 has joined

  27. mukt2 has left

  28. krauq has left

  29. beta has joined

  30. waqas has left

  31. Shell has left

  32. waqas has joined

  33. pdurbin has joined

  34. adiaholic has joined

  35. Shell has joined

  36. waqas has left

  37. waqas has joined

  38. waqas has left

  39. waqas has joined

  40. krauq has joined

  41. waqas has left

  42. waqas has joined

  43. neshtaxmpp has left

  44. neshtaxmpp has joined

  45. waqas has left

  46. waqas has joined

  47. stpeter has left

  48. waqas has left

  49. waqas has joined

  50. waqas has left

  51. waqas has joined

  52. waqas has left

  53. waqas has joined

  54. beta has left

  55. beta has joined

  56. waqas has left

  57. waqas has joined

  58. mukt2 has joined

  59. waqas has left

  60. waqas has joined

  61. Shell has left

  62. mukt2 has left

  63. waqas has left

  64. waqas has joined

  65. mukt2 has joined

  66. waqas has left

  67. waqas has joined

  68. waqas has left

  69. waqas has joined

  70. mukt2 has left

  71. waqas has left

  72. waqas has joined

  73. waqas has left

  74. waqas has joined

  75. waqas has left

  76. waqas has joined

  77. mukt2 has joined

  78. waqas has left

  79. waqas has joined

  80. waqas has left

  81. waqas has joined

  82. waqas has left

  83. waqas has joined

  84. waqas has left

  85. waqas has joined

  86. mukt2 has left

  87. waqas has left

  88. waqas has joined

  89. waqas has left

  90. waqas has joined

  91. waqas has left

  92. waqas has joined

  93. mr.fister has left

  94. mukt2 has joined

  95. mukt2 has left

  96. mukt2 has joined

  97. andy has joined

  98. beta has left

  99. beta has joined

  100. mukt2 has left

  101. adiaholic has left

  102. adiaholic has joined

  103. Nekit has joined

  104. Yagiza has joined

  105. Yagiza has left

  106. beta has left

  107. mukt2 has joined

  108. Yagiza has joined

  109. Zash has joined

  110. adiaholic has left

  111. beta has joined

  112. adiaholic has joined

  113. beta has left

  114. mukt2 has left

  115. beta has joined

  116. mukt2 has joined

  117. Lance has left

  118. mukt2 has left

  119. Tobias has joined

  120. mukt2 has joined

  121. lovetox has joined

  122. Douglas Terabyte has left

  123. lovetox has left

  124. adiaholic has left

  125. adiaholic has joined

  126. lorddavidiii has joined

  127. mukt2 has left

  128. paul has joined

  129. mukt2 has joined

  130. Douglas Terabyte has joined

  131. Douglas Terabyte has left

  132. mukt2 has left

  133. wurstsalat has joined

  134. mukt2 has joined

  135. beta has left

  136. sonny has left

  137. Daniel has left

  138. sonny has joined

  139. adiaholic has left

  140. adiaholic has joined

  141. Daniel has joined

  142. Arc has left

  143. Lance has joined

  144. adiaholic has left

  145. adiaholic has joined

  146. madhur.garg has left

  147. mukt2 has left

  148. Daniel has left

  149. mukt2 has joined

  150. Daniel has joined

  151. sonny has left

  152. flow

    21:32:39 Zash> What came first, the spec or the implementation? IMHO spec and implementation are ideally developed together

  153. mimi89999 has left

  154. sonny has joined

  155. mimi89999 has joined

  156. mukt2 has left

  157. Lance has left

  158. eevvoor has joined

  159. mukt2 has joined

  160. beta has joined

  161. mathijs has left

  162. mathijs has joined

  163. sonny has left

  164. sonny has joined

  165. Lance has joined

  166. sonny has left

  167. karoshi has joined

  168. sonny has joined

  169. mathijs has left

  170. mathijs has joined

  171. UṣL has joined

  172. sonny has left

  173. mathijs has left

  174. mathijs has joined

  175. mukt2 has left

  176. mukt2 has joined

  177. COM8 has joined

  178. sonny has joined

  179. Lance has left

  180. waqas has left

  181. mukt2 has left

  182. mukt2 has joined

  183. Lance has joined

  184. derdaniel has joined

  185. mukt2 has left

  186. mukt2 has joined

  187. adiaholic has left

  188. adiaholic has joined

  189. Daniel has left

  190. Daniel has joined

  191. sonny has left

  192. derdaniel has left

  193. Lance has left

  194. Max has left

  195. Max has joined

  196. mukt2 has left

  197. pep.

    "dwd> moparisthebest, I've implemented MIX twice." are these implementations published anywhere? I'm sure that would help the "situation" a bit.

  198. Zash has left

  199. dwd

    One sort of is, but has "problems" - it's for Openfire, but essentially used a different database approach to the mainstream (I didn't write that bit). Genuinely can't recall if it's at all salvageable. The other was private and bespoke to specific needs, which MIX met considerably better than MUC.

  200. dwd

    Currently, I'm using MUC Light for work - I inherited it, but still, as I said before it works well, it's just a dead-end in terms of standardisation.

  201. sonny has joined

  202. mukt2 has joined

  203. goffi has joined

  204. edhelas

    damn I'm tired of asking my contacts to disable OMEMO to talk with me

  205. karoshi has left

  206. karoshi has joined

  207. dwd

    ?OTRv?

  208. mukt2 has left

  209. COM8 has left

  210. COM8 has joined

  211. Steve Kille has left

  212. eevvoor has left

  213. mukt2 has joined

  214. pdurbin has left

  215. sonny has left

  216. COM8 has left

  217. eevvoor has joined

  218. flow

    edhelas, if ppl send you omemo encrypted messages, doesn't that mean that you have omemo pep nodes that you may want to purge?

  219. COM8 has joined

  220. Zash has joined

  221. eevvoor

    I thought you cannot purge them? flow

  222. dwd

    You certainly *can*, I mean according to the PEP protocol. Whether your client lets you is a different matter.

  223. mukt2 has left

  224. mukt2 has joined

  225. jonas’

    and whether your client silently re-uploads your keys when you did that is yet another question

  226. jonas’

    #Conversations

  227. pep.

    yeah.. you do need something server-side for that.

  228. debacle has joined

  229. Steve Kille has joined

  230. sonny has joined

  231. Zash

    It takes week(s?) for clients to forget keys after you remove them

  232. pep.

    I guess seeing bundles removed could be a sign indeed. Generally clients only check the devicelist though, and getting off the devicelist is "easy"

  233. sonny has left

  234. pep.

    (only check the devicelist, *and download missing bundles)

  235. jonas’

    pep., but evil servers!

  236. pep.

    Yep, lots of people don't care about that (which goes clearly against "I don't trust the server so I use e2ee", and "I don't verify fingerprints"), and to a point it's fine..

  237. pep.

    We're not talking about this now :)

  238. pep.

    Well I wasn't

  239. jonas’

    pep., to be fair, sometimes people are "I use e2ee because I don’t trust that other guy’s server"

  240. flow

    So the leason here is probably that every xmpp e2ee scheme should have an easy and reliable way out

  241. pep.

    Yeah that works

  242. sonny has joined

  243. jonas’

    flow, that’s not possible without: - having to use the E2EE scheme, or - trusting servers

  244. COM8 has left

  245. jonas’

    flow, that’s not possible without: - having to use the E2EE scheme, or - trusting servers, or - accepting downgrade attacks

  246. flow

    ahh right

  247. jonas’

    for example, one could post a signed "I don’t want to use OMEMO" thing in the PEP node, but if it’s unsigned, that can clealy be spoofed by the server. If it’s signed, you need to partake in OMEMO key verification madness.

  248. dwd

    You could, though, have your E2EE-aware clients make the stipulation in a secure method.

  249. flow

    that potentially

  250. pep.

    which works only when you have an e2ee-aware client

  251. pep.

    for this mechanism

  252. jonas’

    dwd, true

  253. jonas’

    pep., but then you only need one of them. If Conversations supported that type of statement, I’d be happier.

  254. jonas’

    I’d publish that once and be done with it

  255. pep.

    That might be something I can support in poezio :x

  256. dwd

    pep., Right, but if you have none, you have no keying material.

  257. jonas’

    though such a statement needs to have a time limit, otherwise a sevrer can use it against you forever

  258. dwd

    jonas’, Indeed, timestamped, expiry, a bit like a certificate.

  259. dwd suggests X.509 Attribute Certificates.

  260. jonas’

    (revocation is not enough, because a server could decide not to publish the revocation of that statement)

  261. dwd

    jonas’, Sure, but with X.509 AC you can have OCSP.

  262. jonas’

    sorry, that’s over my head

  263. dwd

    Attribute Certificates are like normal certs, but without a public key.

  264. Dele (Mobile) has joined

  265. pep.

    dwd, I also don't understand OCSP very much, but that requires a third-party to say if your cert is expired or not right?

  266. Zash

    Oh, OCSP over XMPP?

  267. dwd

    pep., It requires, in this case, the attribute authority to indicate the current status. But the attribute authority could be you, of course.

  268. dwd

    Zash, Yeah, why not?

  269. pep.

    dwd, "you" as in, the client?

  270. dwd

    I should probably stress now that I'm only half-serious at best.

  271. pep.

    So that means my server could lie for it just as much as revocation?

  272. dwd

    pep., No, you as in you, and it'd be signed statements by your personal key.

  273. dwd

    pep., Or one you delegate, since OCSP and CRLs support that too.

  274. jonas’

    generic reminder that there is no "personal" key in OMEMO, only device kyes.

  275. jonas’

    generic reminder that there is no "personal" key in OMEMO, only device keys.

  276. dwd

    jonas’, Indeed.

  277. dwd cries quietly.

  278. Ge0rG

    can't we just do S/MIME and dump everything into CT?

  279. pep.

    dwd, but then it's "the same thing" right? (again I'm missing knowledge of OCSP). You'd sign a statement that says "It expires on the XXXX"? Might as well avoid this indirection then no(?)

  280. sonny has left

  281. dwd

    pep., Only if you like reinventing wheels, basically.

  282. jonas’

    pep., OCSP is directly with the CA, in this case, your client. You wouldn’t publish that in PEP, you’d have an IQ or something

  283. jonas’

    and the IQ would have a signed statement in it

  284. jonas’

    if there’s no signed statement in that IQ, tampering is obvious

  285. pep.

    So we're introducing "another" third-party

  286. dwd

    jonas’, OCSP is transport independent and is itself signed, so you'd be OK there.

  287. jonas’

    no, my interpretation would be that such IQs would be replied to e.g. by Conversations

  288. jonas’

    but, uh, why are we talking about this?

  289. pep.

    jonas’, so that you can be free of "I sent you an OMEMO message" messages :)

  290. pep.

    and edhelas as well

  291. dwd

    jonas’, Because I like to get people discussing the intricacies of X.509 for my personal amusement.

  292. jonas’

    pep., 1w expiry interval is probably ok

  293. jonas’

    I need to put Conversations online once per week either way so that it takes just an hour to sync, not multiple hours.

  294. jonas’

    dwd, you’re a sadist

  295. pep.

    jonas’, I'd set it slightly longer, like 2-3 weeks. Holidays are a thing :p

  296. pep.

    Then if you really want to use OMEMO again you can publish devicelist/bundle and the other would fetch them

  297. jonas’

    pep., wfm too

  298. jonas’

    no, the server would just swallow that ;)

  299. jonas’

    (evil server!)

  300. pep.

    hmm.

  301. pep.

    Then you might want to leave your server

  302. jonas’

    sure, and then you can also drop e2ee and make my life easier :)

  303. dwd

    In general, it's possble to trust your server to work honestly, but also not trust it with the content of your messages.

  304. pep.

    don't ask me :p

  305. jonas’

    dwd, true

  306. dwd

    But also, it's possible for a service provider to manage risk by enforcing E2EE, which is what WhatsApp et al are doing it for.

  307. jonas’

    that ... makes sense

  308. jonas’

    so much

  309. pep.

    As a provider I'd be happy to encourage (any kind of) e2ee. Not just OMEMO

  310. dwd

    The problem for users is that this pushes the archive onto their device, and radically alters their risk profile.

  311. dwd

    Not that, of course, they're aware of this in any real sense.

  312. dwd

    But I';ve been in rooms with FB and other "secure" IM service providers and they've cheerfully discussed holding keying material in the cloud "because unless it's written to disk we can't be subpeoned", so I've a pretty reasonable conclusion to what their threat model actually is.

  313. Ge0rG

    so cloud is now non-persistently backed persistent storage?

  314. jonas’ goes and subpoenes them for their swapfiles

  315. dwd

    I mean, they explicitly keep user keys unencrypted in RAM on their servers. Or were discussing it, anyway.

  316. Ge0rG

    redundant array of inexpensive DRAMs

  317. Ge0rG

    dwd: that reminds me that we need an xmpp server that will use asymmetric crypto to encrypt all of a user's (meta)data on disk and only unlock the decryption key on a user login / during sessions

  318. pep.

    dwd, fwiw I had no doubt that their interest wasn't with their users

  319. Ge0rG

    I'm pretty confident that we can encrypt most of the roster, and maybe have some kind of JID hashing for presence probing purposes

  320. Ge0rG

    also could easily encrypt all of MAM

  321. dwd

    Ge0rG, Well, in my case, I need that metadata, and moreover so do the NHS trusts we hold the data for. Indeed, they need the content too for audit cases.

  322. Zash

    Uh, where did this discussion go?

  323. Ge0rG

    dwd: the compliance use case is at least orthogonal to the public-server use case, but more probably it's even the opposite

  324. dwd

    Ge0rG, But yes, in other cases you could use [H]PKE when writing to the archive I think. To some degree.

  325. dwd

    Zash, Around and around. Where it stops, nobody knows.

  326. Zash

    HWHAT

  327. Ge0rG

    I presume it's Hybrid Public Key Encryption

  328. dwd

    Indeed.

  329. Ge0rG

    Zash: that ugly RSA based PoC you once wrote for me, that I was too scared to deploy

  330. Zash

    MAM can be encrypted yes, I did some such experiment once.

  331. Ge0rG

    roster groups and names can be encrypted as well

  332. Ge0rG

    PEP obviously can't

  333. dwd

    HPKE is a public key crypto system based around a Key Encaspulation Mechanism and a symmetric cipher.

  334. Zash

    Private RSA key encrypted with some stuff extracted out of SCRAM and only available during login

  335. dwd

    Ge0rG, PEP can't be encrypted unilaterally, at least.

  336. Ge0rG

    roster JIDs can be encrypted as well if you ensure some additional one-way-hashed-JIDs store for authentication purposes

  337. dwd

    Zash, You might enjoy HPKE with 25519, that uses a 32-byte integer as the private key with is nicely derivable from almost anything using a SHA-2.

  338. jonas’

    s/SHA-2/hash function/

  339. jonas’

    let’s maybe not get too excited about any specific one ;)

  340. dwd

    jonas’, Potentially.

  341. Ge0rG

    dwd: I'm in absolute love with 25519 after I used sodium in a Bluetooth LE mobile payment system

  342. jonas’

    s/hash function/cryptographic hash function/

  343. jonas’

    (where cryptographic implies obviously >= 32 bits)

  344. jonas’

    ohh, I read bits instead of bytes

  345. jonas’

    that makes it much less confusing

  346. jonas’

    and scary

  347. Zash

    Well a key that unlocked another asymetric key that was used to decrypt MAM

  348. jonas’

    dwd, also, is every 32 byte integer a valid 25519 private key?

  349. Ge0rG

    jonas’: https://libsodium.gitbook.io/doc/key_derivation#key-derivation-with-libsodium-greater-than-1-0-12

  350. dwd

    jonas’, I can't remember if all 0's is.

  351. dwd

    jonas’, But otherwise, yes.

  352. jonas’

    neat

  353. jonas’

    no more gambling with primes, eh?

  354. dwd

    Though I Am Not A Cryptographer.

  355. jonas’

    IANAC :)

  356. dwd

    Ooooh... One of the OpenVPN devs is considering a multicast/broadcast VPN using MLS as the key agreement protocol. Nifty idea!

  357. dwd

    Means that the VPN server itself can't decrypt the packets.

  358. Lance has joined

  359. aj has joined

  360. sonny has joined

  361. adiaholic has left

  362. adiaholic has joined

  363. Lance has left

  364. sonny has left

  365. Wojtek has joined

  366. dwd has left

  367. adiaholic has left

  368. adiaholic has joined

  369. sonny has joined

  370. sonny has left

  371. debacle has left

  372. sonny has joined

  373. eevvoor has left

  374. mukt2 has left

  375. lskdjf has joined

  376. vanitasvitae has left

  377. vanitasvitae has joined

  378. pdurbin has joined

  379. tao has joined

  380. Kev

    Check I'm reading things properly, does anyone have a different understanding for cert checking than that you convert the reference identifier (what you want to find) into punycode and expect what's in the certificate to also be punycoded already (and then do a case insensitive match)?

  381. Zash

    That doesn't sound right

  382. Zash

    But maybe it is

  383. kifterz has joined

  384. sonny has left

  385. sonny has joined

  386. kifterz has left

  387. flow

    Kev, are you asking if the x509 cert SAN is in punnycode?

  388. Kev

    Yep. That's how it reads to me.

  389. flow

    (punnycode/ACE)

  390. adiaholic has left

  391. Ge0rG

    looks like that in my real-life LE cert... X509v3 Subject Alternative Name: DNS:xn--bdk.op-co.de

  392. flow

    Kev, Smack currently does this https://github.com/igniterealtime/Smack/blob/9d626bf787dc3e0e0a4399cef429285b22744d73/smack-tcp/src/main/java/org/jivesoftware/smack/tcp/XMPPTCPConnection.java#L719

  393. Kev

    Ge0rG: Fab, ta.

  394. Kev

    flow: Thanks.

  395. pep.

    hmm, I also have punnycode in my cert, but then I did ask for punnycode when generating my cert

  396. pep.

    Unsure if I can ask for proper unicode

  397. adiaholic has joined

  398. mukt2 has joined

  399. flow

    Kev, besides that, proper verificaiton is more than just a "case insensitive match": https://github.com/igniterealtime/Smack/blob/9d626bf787dc3e0e0a4399cef429285b22744d73/smack-java7/src/main/java/org/jivesoftware/smack/java7/XmppHostnameVerifier.java#L135

  400. sonny has left

  401. flow

    (I do not guarantee that the code is complete nor correct)

  402. pdurbin has left

  403. pdurbin has joined

  404. dwd has joined

  405. MattJ

    dwd, looks like I lost s2s with you, and received unsubscribe/d - are we still friends?

  406. Ge0rG

    MattJ: you are not the only one

  407. Ge0rG

    maybe it's a change of the XMPP domain?

  408. MattJ

    He's joined from the same JID here though

  409. pep.

    Quick we need a crypto identity to make sure it's him

  410. dwd

    I've just reinstalled Openfire, and did a thorough roster clean - but I don't *think* I deleted you. OTOH, I've not seen either you or Ge0rG online in my roster for some time, and various other things have been broken, so maybe this is things catching up.

  411. Ge0rG

    MattJ: my s2s still works

  412. MattJ

    I'll check logs

  413. pdurbin has left

  414. Ge0rG

    > 12:05:17 Roster> dwd does not want to receive your status anymore. > 12:05:17 Roster> dwd does not want you to receive their/its status anymore.

  415. MattJ

    Oh, may be an IPv6 thing

  416. MattJ

    My outgoing IPv6 appears to be broken, and Prosody doesn't know. Pretty sure it used to work...

  417. dwd

    Interestingly, I seem to have lost everyone running Prosody.

  418. MattJ

    Oh, maybe it's not my issue

  419. MattJ

    Is your inbound IPv6 working?

  420. Holger

    dwd: You also unsubscribed from me. No Prosody involved :-)

  421. dwd

    I firewalled the S2S ports briefly, reinstalled the server from scratch, and reimported my user (with lots of cruft removed from the roster). You're still there with subscription=both at my end...

  422. pep.

    Isn't that prosody not doing happy eyeballs?

  423. dwd

    Oh!

  424. dwd

    No, this *is* IPv6. I forgot to firewall that...

  425. pep.

    "There's an IPv6 record. IPv6 is not actually working. Prosody confused"?

  426. Ge0rG

    MattJ: so when are you going to fix v6 in prosody?

  427. dwd

    So yeah, everything that connected to me over IPv6 saw the point in time when my user didn't exist.

  428. beta has left

  429. dwd

    I wonder how I can fix this...

  430. Holger

    My server doesn't do v6 ...

  431. debacle has joined

  432. sonny has joined

  433. beta has joined

  434. MattJ

    This is why IPv6 is terrible

  435. Shell has joined

  436. MattJ hides from Zash

  437. Zash gets out the pitchfork

  438. Zash

    I've got machines only reachable over IPv6

  439. beta has left

  440. mukt2 has left

  441. beta has joined

  442. jonas’

    me too. I always get reminded when I try to wget something off github.com

  443. jonas’

    "Network unreachable"

  444. dwd has left

  445. Vaulor has left

  446. Vaulor has joined

  447. mathijs has left

  448. mathijs has joined

  449. dwd has joined

  450. beta has left

  451. dwd

    MattJ, If you resubscribe to me, does that work?

  452. MattJ

    s2s is still timing out

  453. dwd

    Timing out? Over IPv6 or IPv4?

  454. dwd

    Ah, IPv6 not routed on that machine for some reason.

  455. dwd

    Fixed that, at least.

  456. sonny has left

  457. ralphm

    ik.nu doesn't seem to be able to connect either

  458. ralphm

    dwd: so :-(

  459. ralphm

    dwd: you could script to send resubscribes for all your contacts?

  460. dwd

    Probably have to, yes.

  461. dwd

    But I need things to connect first. :-/

  462. ralphm

    of course

  463. MattJ

    Still not connecting for me

  464. mathijs has left

  465. mathijs has joined

  466. ralphm

    I tried manually, but indeed, I cannot establish a TCP connection to peirce.dave.cridland.net (2a02:8010:800b::2).

  467. adiaholic has left

  468. adiaholic has joined

  469. Zash has left

  470. dwd

    Might work now.

  471. Zash has joined

  472. ralphm

    Sent a ping

  473. ralphm

    There we go!

  474. dwd

    Well, that works now.

  475. dwd

    Lovely. So people are more than welcome to re-add me (or just add me) at dwd@dave.cridland.net

  476. ralphm

    Tried that too.

  477. dwd

    And I'll have to write a script, I suppose.

  478. dwd

    ralphm, Seems to have worked.

  479. ralphm

    Not seeing your presence, yet.

  480. dwd

    Probably because OF think it's sent it already.

  481. Kev

    flow: I meant to say that each entry check is a case insensitive ascii match. I realise there are several checks involved, but yes, thanks :)

  482. Lance has joined

  483. beta has joined

  484. intosi has left

  485. ralphm has left

  486. beta has left

  487. sonny has joined

  488. intosi has joined

  489. tao has left

  490. ralphm has joined

  491. Lance has left

  492. beta has joined

  493. dwd

    Well, that helped a bit.

  494. beta has left

  495. mukt2 has joined

  496. ralphm

    As a follow-up on yesterday's screenshot of Slack reactions: that message eventually got 45 different reactions, by 804 people. The largest count for one reaction was 106.

  497. ralphm

    It also turns out there's a cap on how many different reactions a single person can react with: 23.

  498. ralphm

    https://upload.ik.nu/upload/1SjqYFQc3mADqO3N/reactions_cap.png

  499. ralphm

    I should say: 804 counts, not people.

  500. Alex has left

  501. Alex has joined

  502. mukt2 has left

  503. mukt2 has joined

  504. Douglas Terabyte has joined

  505. mukt2 has left

  506. mukt2 has joined

  507. pdurbin has joined

  508. eevvoor has joined

  509. jonas’

    > reacji

  510. pep.

    reac字? :)

  511. Zash

    Please tell me that's a typo

  512. pep.

    Zash, it come from emo字(絵文字) or bakemo字(バケ文字) etc..

  513. pep.

    probably

  514. jonas’

    pep., I doubt it

  515. pdurbin has left

  516. calvin has joined

  517. calvin has left

  518. calvin has joined

  519. calvin has left

  520. calvin has joined

  521. paul has left

  522. paul has joined

  523. calvin has left

  524. Lance has joined

  525. dwd

    Anyone any ideas on the best way to test a websocket connection?

  526. sonny has left

  527. mathijs has left

  528. mathijs has joined

  529. Zash

    Test what, exactly?

  530. dwd

    Ideally, XMPP connectivity.

  531. Zash has left

  532. dwd

    But even just a websocket CLI tool would be handy.

  533. Guus

    reconfigure your favorite web client to use it?

  534. ralphm

    Zash: I am sure they call it reacji internally and slipped out this way.

  535. dwd

    I was hoping for something slightly less intensive...

  536. edhelas

    ralphm "reacji" so there's a name for those things 🤔

  537. ralphm

    But see also https://indieweb.org/reacji

  538. Lance has left

  539. Nekit has left

  540. nyco

    can you react to reactions? reactionception

  541. stpeter has joined

  542. Nekit has joined

  543. Wojtek has left

  544. edhelas

    reacjiji

  545. ralphm bangs gavel

  546. pep.

    heh

  547. pep.

    !

  548. ralphm

    0. Welcome

  549. MattJ

    I'm unfortunately probably going to be 80% not here :/

  550. stpeter has left

  551. MattJ

    Had an emergency work meeting come up at the last minute

  552. nyco

    so that's 20% here

  553. MattJ

    If it ends early, I'll hop in though

  554. ralphm

    MattJ, surely 20% of your brain capacity is sufficient :-D

  555. emus has left

  556. ralphm

    Who else do we have

  557. MattJ

    I wouldn't be so sure :)

  558. pep.

    Guus was here a few minutes ago

  559. pep.

    Seve ?

  560. adiaholic has left

  561. adiaholic has joined

  562. Guus

    I"m here

  563. Guus

    talking to a customer, but will lurk

  564. ralphm

    Ok, so maybe we have quorum :/

  565. Guus

    I'm brushing off the customer 🙂

  566. Guus

    well, no

  567. Guus

    but that conversation is at an end.

  568. ralphm

    heh

  569. ralphm

    1. Minute taker

  570. nyco

    https://mensuel.framapad.org/p/9ece-xsf-board-weekly-meeting-2020-01-09 please contribute!

  571. ralphm

    Yay

  572. ralphm

    2. GSoC 2020

  573. nyco

    (I've just slightly covered that on the newsletter)

  574. ralphm

    I saw some movement on this. Anything Board can / needs to do here?

  575. nyco

    knight Flow once again?

  576. pep.

    We have volunteers to admin, I think we're good

  577. ralphm

    FWIW I like how pep refers to himself in the 3rd person in Trello.

  578. dwd

    I think blessing what flow is doing would be sensible.

  579. Guus

    Can we commit?

  580. pep.

    Thanks flow, and larma as backup

  581. pep.

    ralphm, I'm happy to take in comments, I'm not a native :p

  582. pep.

    And I copied that from a description (where it wasn't especially obvious that I was the author of the text)

  583. ralphm

    ah!

  584. ralphm

    Guus: I think we can.

  585. Guus

    I'd like that.

  586. ralphm

    There's still some time to expand the projects

  587. dwd

    By the above, I mean that technically, flow ought to have formal go-ahead from the Board, since he's probably entering into agreements with Google's GSoC organisation.

  588. neshtaxmpp has left

  589. pep.

    Unsure if poezio is going to participate this year, maybe. In any case we already have 3 projects interested

  590. ralphm

    dwd: that's a good point

  591. dwd

    pep., Four, I think - Prosody, Smack, Dino, Openfire.

  592. neshtaxmpp has joined

  593. Kev

    I don't think Flow can reasonably go ahead without Board appointing him.

  594. Kev

    Right, what Dave says.

  595. ralphm moves that Florian Schmaus can go ahead to apply for GSoC 2020 and be the XSF's admin to that end.

  596. ralphm

    +1

  597. Guus motions that board approve... scratch that, +1

  598. pep.

    +1

  599. Kev

    (He also needs co-admins)

  600. mukt2 has left

  601. pep.

    larma volunteered, as mentioned above

  602. ralphm

    Kev: I know this, but do we also have to appoint them, as Board?

  603. Kev

    In the past it's usually been someone on Board, so haven't needed to.

  604. ralphm

    ah

  605. ralphm amends his motion to include Marvin Wissfeld as co-admin.

  606. ralphm

    +1

  607. Guus

    +1

  608. mukt2 has joined

  609. pep.

    +1

  610. ralphm

    Motion (including amendment) carries.

  611. ralphm

    Yay

  612. nyco

    (hey MattJ if you want to vote, do that before I send the minutes)

  613. ralphm

    3. OMEMO

  614. ralphm

    I would like to briefly touch upon this discussion in Council and here.

  615. ralphm

    In short the discussion is about whether or not XEP-384 can move ahead in our process, as in its current state implementing it depends on libsignal.

  616. MattJ

    +1 to Marvin as co-admin

  617. UṣL has left

  618. nyco

    MattJ : +1 for both motions?

  619. pep.

    ralphm, I'd like to note that the author hasn't asked to move it.

  620. ralphm

    One of the things raised yesterday, is that the XSF might be liable for incorporating the signal protocol, if it is determined that the way we got to the protocol description is deemed a derivative of libsignal.

  621. jonas’

    ralphm, or, to take that edge off, it is highly unclear if it can be implemented without using libsignal or a derivate of it

  622. ralphm

    pep., I am aware, please be patient.

  623. ralphm

    The above concerns me, as Board runs the XSF, and me personally as part of (and only member of) the Executive Committee.

  624. ralphm

    I wanted to make note of this, and why I am arguing against any action that might cause this to be the case.

  625. Guus

    Is there something that you'd explicitly want board to discuss on this now?

  626. Kev

    (I note that Council voted against accepting OMEMO if it depended on libsignal, with these issues)

  627. Kev

    (There was something of a bait-and-switch in order to get the libsignal dependency in there)

  628. Guus

    > (I note that Council voted against accepting OMEMO if it depended on libsignal, with these issues) Then I don't understand the issue.

  629. Kev

    Guus: OMEMO was proposed with libsignal. Council vetod. OMEMO was proposed again in a different form. Council accepted. OMEMO was then reverted to the state Council rejected.

  630. Kev

    Roughly.

  631. Guus

    Ah, Dave's mail of a while ago.

  632. Kev

    It's all much more complicated than a one-line summary will give credit to, but that's the headline.

  633. Daniel

    OMEMO was then reverted to the state Council rejected with approval of council

  634. Guus

    so council contradicted itself?

  635. ralphm

    Well, I'd love some response. I also don't think we want to be in a position where we need to find out how a description of the protocol came to be and if it would indeed be considered a derivative work. My preferred outcomes are 1) The Signal Foundation releases a spec and we can depend on it, 2) we advice Council to reject the specification, 3) this XEP stops depending on libsignal or its protocol.

  636. MattJ

    nyco, +1 to both, yes

  637. nyco

    thx

  638. Daniel

    it's not like i snug into the server overnight and pushed the current xep

  639. Kev

    Guus: As I say, more complicated. Council was persuaded that the new form didn't need libsignal.

  640. MattJ

    My meeting is over now, I'll try to pretend I was always paying attention

  641. Guus

    right, we're not going to conclude a discussion on how this XEP came to be now. Fact is, that it is there in its current form now.

  642. Kev

    Daniel: Well, indeed, although that does sound exciting.

  643. Daniel

    not that i'm super happy with how that all went; and i'm sorry

  644. ralphm

    This is not about pointing fingers, of course.

  645. Guus

    ralphm as a 4th option: discuss this with the people behind libsignal, and have them put to paper that we can either release specifications, or not?

  646. jonas’

    Guus, unlikely to happen

  647. Kev

    Guus: That's Ralph's (1) isn't it?

  648. ralphm

    Guus: well, if we're going to have a discussion with them, then the outcome should be 1)

  649. beta has joined

  650. sonny has joined

  651. ralphm

    I don't want to be in the business of chasing their changes.

  652. ralphm

    pep. also raised a point:

  653. Guus

    I'm unsure if 4 == 1. Could be some middle ground in us defining a spec that refers to theirs, keeping their provisions on implementations in place?

  654. ralphm

    He says we might send a bad signal when we reject OMEMO.

  655. ralphm

    I've thought about this and came to the following:

  656. MattJ

    bad signal...

  657. ralphm

    If we (the XSF, Board, Council or both) decide to reject OMEMO, we should write a blog post pointing out why, and combine that other efforts.

  658. pep.

    MattJ, ! :)

  659. ralphm

    Like the formation of an E2EE SIG, and maybe work individuals are doing within / in collaboration with MLS WG at IETF>

  660. MattJ

    I would prefer not to reject OMEMO until we have exhausted possibilities for saving it

  661. Zash has joined

  662. ralphm

    MattJ: I am open to suggestions. OMEMO hasn't moved for a while, and I don't think it would be wise to /not/ do something.

  663. Guus

    You're slowly turning into Kev there...

  664. jonas’

    MattJ, in my eyes, the only way to make OMEMO acceptable is to provably cleanroom-reverse-engineer the signal protocol and publish that.

  665. Kev

    High praise.

  666. MattJ

    For me that means at least reaching out to the libsignal folks (officially, as the XSF) and asking for a more permissive license

  667. ralphm

    Kev: :-)

  668. MattJ

    or clean-room, but I personally feel less like I understand the legal basis of such an approach

  669. jonas’

    MattJ, we can do that, but I doubt this is going to happen, given the money Moxie likely makes off commercial licenses for libsignal.

  670. ralphm

    jonas’, and I don't think we have the capacity to verify that something was indeed reverse engineered in a cleanroom fashion.

  671. dwd

    MattJ, Is it a permissive license we need, or a clear specification?

  672. MattJ

    A clean room implementation is still open to a challenge, whereas an explicit "it's ok to do what you're doing" is less likely to end that way

  673. ralphm

    I wouldn't want to burn my fingers on it, anyway.

  674. Guus

    I agree with MattJ that we should at least try to work with Signal, before abandoning the XEP, if it comes to that.

  675. pep.

    ralphm, but you can blame that on people who claim it's be done that way.

  676. jonas’

    ralphm, with provably I mean with a legal advisor overseeing the process.

  677. MattJ

    dwd, whatever

  678. Kev

    I think it needs both, doesn't it?

  679. MattJ

    We basically have everything we need apart from some magic values, right?

  680. ralphm

    pep., I don't want to blame anybody, and don't want to be involved in that legal mess

  681. jonas’

    in any case, if Board wants to go ahead contacting libsignal, then please motion that and do that, because Council has motioned to tihnk about how to reject OMEMO in the next session.

  682. Guus

    I'm concerned that going down the clean room solution would still open us up for a costly challenge (even if we'd win it). I'd like to avoid that.

  683. dwd

    MattJ, I don't think there's a specification for the wire protocol (message formats etc) or the constants in use.

  684. MattJ

    Guus, same

  685. Kev

    Guus: I think we both need to be able to clean room *and* it to be clear that it's acceptable to do so. If you can't clean room, the spec doesn't work.

  686. pep.

    I guess board can officially ask implementors what exactly is covered by GPL that would need to be reversed engineer. So we stop speculating

  687. pep.

    engineered*

  688. jonas’

    pep., Syndace has it

  689. Guus

    Kev which basically means: work together with Signal on this, right?

  690. pep.

    jonas’, I know, I was thinking about him

  691. ralphm

    But this is not a technical challenge, it is a legal one.

  692. jonas’

    specifically this part: https://github.com/Syndace/python-omemo-backend-signal

  693. pep.

    Now you just spoiled everybody who wanted to do clean-room :P

  694. jonas’

    that link was here a week ago

  695. pep.

    (jk)

  696. Guus

    If they make it clear that they don't like others to provide implementations, then I wonder if we should continue to work on the XEP in this form.

  697. dwd

    The original reason for moving to "Olm" was that Olm had everything fully specified - but they had to use different constants under pressure from Moxie.

  698. ralphm

    pep., you kid, but this is actually a problem indeed

  699. nyco

    (I fail to understand this OMEMO discussion here, I'll need your input for the minutes) (and I'll have to go soon)

  700. MattJ

    and so does what we're discussing also apply to Olm?

  701. MattJ

    Thanks nyco!

  702. dwd

    MattJ, As I understand it, no, but an Olm-based OMEMO would not be compatible with the current spec because the constants differ.

  703. pep.

    MattJ, I would assume so tbh. "We don't know as long as it hasn't passed a judge" (in every single jurisdiction? :x)

  704. dwd

    That said, Olm is only in use by Matrix, and Matrix are themselves starting to work on moving to MLS.

  705. pep.

    Also re Matrix, https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom/ this says they did ask

  706. pep.

    (iirc)

  707. larma

    dwd, do you know of documentation which constants have been changed?

  708. ralphm

    So hey, Matrix is in the same boat as we. I don't see why we couldn't make a statement like this.

  709. Guus

    I've skimmed the article

  710. Guus

    What I read is that they asked for federation

  711. mukt2 has left

  712. Guus

    that's different than asking if it's permissible to use the signal double-ratched protocol as part of their protocol

  713. pep.

    Guus, hmm, correct

  714. Guus

    (although I might simply not have read that bit yet)

  715. ralphm

    Well, I'd be happy to discuss this with Matthew at FOSDEM.

  716. Guus

    We should talk to Moxie et. al.

  717. ralphm

    I think there's a reason why Matrix does not use libsignal

  718. Guus

    it'd be super silly if we now chose to abandon OMEMO because of this, only for them to go : "ah, you didn't have to do that"

  719. Guus

    Sure, but a) we're not sure, and b) time has passed.

  720. dwd

    Talking with Matthew at FOSDEM does sound snesible.

  721. MattJ

    Indeed

  722. pep.

    And reaching out Moxie, as Guus says.

  723. Guus

    I think the XSF should first decide if we want to move forward with OMEMO, or not (I've heard talk of a replacement, which makes this discussion pointless)

  724. Guus

    if we do, let's try to work together with Signal.

  725. pep.

    And reaching out to Moxie, as Guus says.

  726. Guus

    Well, I'm always happy to talk to Matthew - but he can't speak for Signal

  727. Guus

    he can only tell us what Signal at some point in the past told Matrix (or how he understood their remarks).

  728. pep.

    I am sure Moxie is well aware of the OMEMO situation in XMPP, and he would have probably poked us if there were obvious issues

  729. Guus

    So Matthew can have useful information, but if we want to go ahead with OMEMO, we'll have to talk to Signal eventually - also if we want to abandon it only for the reason of Singals licence seemingly incompatible with ours.

  730. ralphm

    Well, my point of view on standards development in the XSF has always been to look ahead. In that sense, I'd rather put efforts in MLS than somehow trying to save OMEMO out the legal unclarity.

  731. MattJ

    Can't be assumed, I'm sure he's pretty busy with other things to focus on

  732. dwd

    pep., But everyone's implementing using libsignal, so those issues don't exist.

  733. Guus

    So Matthew can have useful information, but if we want to go ahead with OMEMO, we'll have to talk to Signal eventually - also if we want to abandon it only for the reason of Singals licence seemingly incompatible with our goals.

  734. pep.

    dwd, just to say that asking him stuff certainly won't trigger a "hey you can't do what you're currently doing! I'm going to sue your ass!"

  735. sonny has left

  736. Guus

    Let's bring this meeting to an end

  737. pep.

    Any action to take away from this then?

  738. calvin has joined

  739. nyco

    (I'm gone, sorry, please finish https://mensuel.framapad.org/p/9ece-xsf-board-weekly-meeting-2020-01-09 )

  740. ralphm

    nyco: thanks

  741. pep.

    Also, I'd like to mention that this could happen for lots of other things, and we're mostly worried about what us EU/US can see. Are XEPs ever legally reviewed at all?

  742. sonny has joined

  743. pep.

    Re "Objective 4"

  744. ralphm

    pep., most of our protocols don't depend on other protocols like this

  745. pep.

    Our protocols may include patents only active in some legislations

  746. pep.

    Do we even know

  747. ralphm

    There might be patent issues always, but I think that's different from the current topic

  748. Guus

    Let's finish the topic at hand first, before addressing new topics please.

  749. Guus

    also: i need to go.

  750. pep.

    So no action?

  751. MattJ

    Same here, new meeting

  752. ralphm

    Ok. We can carry this forward to next week.

  753. pep.

    Ok

  754. ralphm

    Council can still make a decision from their perspective.

  755. Guus

    I'd first like to know if the XSF moving ahead hinges on Signals implicit approval.

  756. pdurbin has joined

  757. flow

    > but if we want to go ahead with OMEMO, we'll have to talk to Signal eventually I do not think this is strictly true: if we want to go ahead with OMEMO depending on libsignal, then yes. But the doubleratched and x3dh are open standards on which OMEMO could depend on. It is important in this discussion to differentiate between libsignal (the implementation) and doubleratched/x3dh (the specification). The issue we have with OMEMO is that it depends on libsignal, i.e. an (GPLed) implementation, when it should depend on an open standard

  758. mukt2 has joined

  759. rion has left

  760. Guus

    if that's that's the case, I think we should obtain explicit approval from Signal.

  761. ralphm

    Feel free to discuss further after the meeting

  762. ralphm

    4. AOB

  763. ralphm

    ?

  764. Guus

    if we dont get it, we should consider burying the XEP>

  765. Guus

    no AOB.

  766. ralphm

    5. Date of Next

  767. ralphm

    +1W

  768. ralphm

    6. Close

  769. ralphm

    Thanks all!

  770. ralphm bangs gavel

  771. pep.

    +1 wfm. Thanks

  772. Guus

    wfm

  773. Guus

    Thanks

  774. jonas’

    flow, I think for the simplicity of discussion, we should assume that the term OMEMO means OMEMO-as-currently-written-in-XEP-0384

  775. jonas’

    and anything beyond that isn’t OMEMO but OMEMO’

  776. jonas’

    suggesting that we don’t have to bury OMEMO because we could transform it to an incompatible OMEMO’ isn’t helpful and only distracting

  777. ralphm

    Right, OMEMO-right-now is what's been implemented.

  778. jonas’

    the discussion is complex and confusing enough already

  779. ralphm

    Changing the spec to be incompatible with that is fine, in principle, but confusing.

  780. pep.

    To come back to objective 4, I'm really curious if anybody ever thought outside of their own jurisdiction. I'm sure at least one of our XEP (that isn't OMEMO) is infriging patents somewhere in some jurisdiction. Does Objective 4 care for this?

  781. larma

    jonas’, it's still up for discussion if OMEMO’ is necessarily incompatible to OMEMO

  782. pep.

    At least, I guess the answer currently is "we don't know"

  783. jonas’

    also, I today realised that I should probably attend Board meetings more regularly as Council chair, but the time slot won’t work for me in the general case. Just FYI.

  784. ralphm

    pep., https://xmpp.org/about/xsf/ipr-policy

  785. ralphm

    we don't knowingly accept XEPs with such problems

  786. jonas’

    larma, it necessarily is, if we go by the assumption that the wire format is copyrighted (which is what all this discussion is about)

  787. ralphm

    pep., and if there's a current spec with IPR issues, that'd be good to know. I think the only appropriate action is to Reject and/or Obsolete it.

  788. ralphm

    (depending on what state it currently has)

  789. jonas’

    I think if the spec has IPR issues, it needs to be removed altogether (akin to Retraction)

  790. larma

    jonas’, the wire format is protobuf, the specification of protobuf is under CC-BY (from Google)

  791. Kev

    We have actually removed some XEPs (ok, JEPs) from existence in the past, as much as possible.

  792. Kev

    Haven't we?

  793. jonas’

    larma, but the protobuf files may be under GPL

  794. flow

    guess it is really sensible to simplly ask OWS if they would put the libsignal wireformat also in the public domain

  795. jonas’

    larma, but the .proto files may be under GPL

  796. Kev

    Although I don't think that would be helpful here.

  797. ralphm

    Kev: at least one, yes. But I don't remember why.

  798. larma

    jonas’, the .proto files are not needed to read protobuf

  799. dwd

    jonas’, Based on past discussions with Matthew@Matrix, it was the constants that were the problem. The wire format can be reverse engineered in principle, but the cnstants can only be obtained from th source code and are in principle copyrightable.

  800. larma

    .proto files are like xml schemas

  801. jonas’

    dwd, awful.

  802. larma

    you can perfectly work without a schema

  803. dwd

    jonas’, Well, it's their call, of course.

  804. rion has joined

  805. lorddavidiii has left

  806. dwd

    But, FWIW, see the info value for the HKDF here: https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/olm.md

  807. jonas’

    larma, then replace "wire format" with "constants which influence the output" in my statement

  808. eevvoor

    a constant can stand under copyright? interesting.

  809. ralphm

    Kev: XEP-0028

  810. Kev

    ralphm: Indeed.

  811. dwd

    eevvoor, My understanding is that court action has been threatened on that basis, at least.

  812. beta has left

  813. pdurbin has left

  814. pep.

    I guess "a constant can stand under copyright" is provided by the Game Boy and Nintendo.

  815. pep.

    I guess "a constant can stand under copyright" is proved by the Game Boy and Nintendo.

  816. eevvoor

    I see, dwd.

  817. dwd

    eevvoor, I'm not convinced I agree, but that's somewhat moot unless I have a shitload of money and some very good lawyers.

  818. pep.

    I don't know if there is any such case though yes (Nintendo)

  819. stpeter has joined

  820. lorddavidiii has joined

  821. eevvoor

    open source lawyers would be fine ...

  822. ralphm

    WIthout the history of the actions of Moxie and/or OWS, I would make such a fuss about it.

  823. eevvoor

    plus libre of course

  824. ralphm

    would not

  825. ralphm

    Now, I'm not that willing to take a guess.

  826. mimi89999 has left

  827. mukt2 has left

  828. eevvoor

    Unfortunately courts are often unlocial expecially concerning topics were you need some expertise in, like SW.

  829. eevvoor

    Unfortunately courts are often unlocial especially concerning topics were you need some expertise in, like SW.

  830. beta has joined

  831. mukt2 has joined

  832. adiaholic has left

  833. jonas’

    bonus if you’re in juryland

  834. mimi89999 has joined

  835. adiaholic has joined

  836. tao has joined

  837. stpeter has left

  838. emus has joined

  839. adiaholic has left

  840. sonny has left

  841. sonny has joined

  842. Yagiza has left

  843. Lance has joined

  844. mukt2 has left

  845. lorddavidiii has left

  846. mathijs has left

  847. mathijs has joined

  848. lorddavidiii has joined

  849. Alex has left

  850. eevvoor has left

  851. Lance has left

  852. adiaholic has joined

  853. mukt2 has joined

  854. tao has left

  855. tao has joined

  856. tao has left

  857. tao has joined

  858. Alex has joined

  859. mathijs has left

  860. mathijs has joined

  861. sonny has left

  862. mukt2 has left

  863. sonny has joined

  864. mathijs has left

  865. mathijs has joined

  866. calvin has left

  867. larma

    So the question that remains regarding OMEMO is, if we are allowed to use the 4 strings that are used as info bytes in the HKDF function and just write those strings in our specification?

  868. mukt2 has joined

  869. Steve Kille has left

  870. moparisthebest

    > No Extension shall be approved by the XSF or its constituent committees if there are Claims to the Extension itself, or any Claims that would prevent perpetual, unrestricted, royalty-free use of the Extension in a compliant Implementation or Deployment by any interested party.

  871. moparisthebest

    I still think that's utterly meaningless without defining a jurisdiction

  872. dwd

    larma, Well, we'd need to actually specify the protobuf stuff at some point too, but yes.

  873. pep.

    moparisthebest, Delaware by default I assume?

  874. pep.

    I'd also be interested to know the answer though

  875. moparisthebest

    doesn't look like that document says that

  876. larma

    dwd, but we can easily derive protobuf from the wire, so that's nothing we need to handle (yes, it's not in the XEP, but it's also not under GPL)

  877. andrey.g has left

  878. larma

    *handle from legal perspective

  879. dwd

    larma, Yes.

  880. moparisthebest

    re: the copyright-ability of strings https://dacut.blogspot.com/2008/03/oracle-poetry.html though I don't think this specifically has been tested in court

  881. jonas’

    moparisthebest, delawere is where the XSF is constituted

  882. jonas’

    moparisthebest, delaware is where the XSF is constituted

  883. moparisthebest

    jonas’, sure but that says "by any interested party" not "by any interested party in delaware"

  884. pep.

    Which might also mean that the XSF only cares about stuff that's legal in the US, as for elsewhere "it depends" (if members have incentives to push for it?)

  885. pep.

    Which might also mean that the XSF only cares about stuff that's legal in the Delaware, as for elsewhere "it depends" (if members have incentives to push for it?)

  886. pep.

    Which might also mean that the XSF only cares about stuff that's legal in Delaware, as for elsewhere "it depends" (if members have incentives to push for it?)

  887. moparisthebest

    and the lawyer on staff that tries to interpret this stuff is who exactly?

  888. eevvoor has joined

  889. jonas’

    there isn’t any on staff, but I guess the Board would consult one if they wanted to be sure

  890. jonas’

    in this case I think that the ambiguity alone is reason enough to see it as a problem

  891. Nekit has left

  892. pdurbin has joined

  893. moparisthebest

    this kind of thing is always ambiguous, which is why I don't think the XSF should even attempt it

  894. moparisthebest

    any serious company is going to have to do their own leg work here anyway, they can't trust the XSF has vetted all IPR and everything else

  895. larma

    Assuming I publish a document with those constants under the public domain, can the XSF use those constants referencing my document as a source?

  896. moparisthebest

    re protobufs and functionality in EU at least https://en.wikipedia.org/wiki/SAS_Institute_Inc_v_World_Programming_Ltd > The EU Court of Justice ruled that copyright protection does not extend to the software functionality, the programming language used and the format of the data files used by the program. It stated that there is no copyright infringement when a company which does not have access to the source code of a program studies, observes and tests that program to create another program with the same functionality.

  897. mukt2 has left

  898. larma

    moparisthebest, there even is a law in the EU that explicitly allows reverse engineering

  899. sonny has left

  900. jonas’

    larma, maybe, but you will be liable if those constants are in fact under GPL and you republished them in the public domain.

  901. jonas’

    if they cannot be reasonably found via reverse engineering, for example because they’re not part of what’s on the wire and they would have to be brute forced

  902. mukt2 has joined

  903. serge90 has left

  904. pdurbin has left

  905. Steve Kille has joined

  906. larma

    jonas’, yeah I was considering to get legal confirmation (because I am certain there are ways to extract those constants not directly from the source code). But obviously any legal advice I may get won't cover the whole world, so that's why I would just do it myself and put it under public domain so that it doesn't matter what place in the world others are situated in.

  907. debacle has left

  908. serge90 has joined

  909. moparisthebest

    he wouldn't be legally liable, the person that used them would

  910. larma

    moparisthebest, you sure? How can the person know that I don't have license to publish them?

  911. moparisthebest

    exactly

  912. larma

    well that would be the case for everything then

  913. moparisthebest

    consider a recent real world example, how many of you use nginx ? are you legally allowed to?

  914. moparisthebest

    russian govt claims you are not

  915. larma

    I think they claim the author was not allowed to relicense it

  916. moparisthebest

    they claim no one was ever legally allowed to use it from the beginning

  917. sonny has joined

  918. waqas has joined

  919. calvin has joined

  920. andrey.g has joined

  921. eevvoor has left

  922. Wojtek has joined

  923. lovetox has joined

  924. tao has left

  925. mathijs has left

  926. mathijs has joined

  927. eevvoor has joined

  928. Lance has joined

  929. mathijs has left

  930. mathijs has joined

  931. emus has left

  932. eevvoor has left

  933. Lance has left

  934. mathijs has left

  935. mathijs has joined

  936. mathijs has left

  937. mathijs has joined

  938. lovetox has left

  939. larma

    moparisthebest, that might be technically correct, the question is who is liable for that

  940. sonny has left

  941. Maranda has left

  942. Maranda has joined

  943. larma

    I haven't heard of any case where microsoft would try to sue the end user that bought an illegal license. They just get blocked from using that license in the future. Those that sell the license are sued

  944. sonny has joined

  945. emus has joined

  946. lovetox has joined

  947. tao has joined

  948. debacle has joined

  949. moparisthebest

    if you do something illegal, you can't get out of it by saying "well that guy over there told me to"

  950. moparisthebest

    you are liable, and then maybe you can sue that guy over there for your damages, maybe

  951. mathijs has left

  952. mathijs has joined

  953. calvin has left

  954. calvin has joined

  955. lovetox has left

  956. pdurbin has joined

  957. jonas’

    moparisthebest, I’m not so sure about that.

  958. jonas’

    moparisthebest, if you buy a wifi access point in a store, and that access point is misconfigured by the vendor in a way which violates radio regulation, you wouldn’t be liable for that.

  959. jonas’

    likewise I’d say if someone explicitly publishes some work under a given license, it is fair to assume that you may use that work under that license. If they are lying or incorrect about their assumption that they have the rights to publish it under that license, that’s not your fault, and you should not be liable for that

  960. jonas’

    I’d assume that you need to immediately rectify your misusage of the work as soon as it is brought to your attention though

  961. APach has left

  962. APach has joined

  963. pdurbin has left

  964. Nekit has joined

  965. Daniel has left

  966. Daniel has joined

  967. calvin has left

  968. calvin has joined

  969. Nekit has left

  970. Nekit has joined

  971. mukt2 has left

  972. Lance has joined

  973. sonny has left

  974. mukt2 has joined

  975. sonny has joined

  976. j.r has joined

  977. larma

    and you can probably sue that person that was lying for damage

  978. larma

    like if your businnes relies on the fact that it was under that license but it isn't

  979. moparisthebest

    probably would have needed to pay him for it in that case, otherwise you don't have a business relationship or contract

  980. moparisthebest

    bottom line it's always on the person/business actually distributing the code, the XSF shouldn't even be trying to interepret/enforce anything imho

  981. j.r has left

  982. j.r has joined

  983. andy has left

  984. mukt2 has left

  985. j.r has left

  986. andy has joined

  987. sonny has left

  988. Lance has left

  989. mukt2 has joined

  990. Wojtek has left

  991. mukt2 has left

  992. tao has left

  993. Nekit has left

  994. sonny has joined

  995. !XSF_Martin has left

  996. sonny has left

  997. Steve Kille has left

  998. pdurbin has joined

  999. lovetox has joined

  1000. !XSF_Martin has joined

  1001. pdurbin has left

  1002. sonny has joined

  1003. Steve Kille has joined

  1004. j.r has joined

  1005. lorddavidiii has left

  1006. sonny has left

  1007. lorddavidiii has joined

  1008. sonny has joined

  1009. moparisthebest has left

  1010. neshtaxmpp has left

  1011. goffi has left

  1012. Tobias has left

  1013. Steve Kille has left

  1014. moparisthebest has joined

  1015. sonny has left

  1016. Steve Kille has joined

  1017. wurstsalat has left

  1018. lorddavidiii has left

  1019. karoshi has left

  1020. mukt2 has joined

  1021. sonny has joined

  1022. neshtaxmpp has joined

  1023. mukt2 has left

  1024. lovetox has left

  1025. j.r has left

  1026. j.r has joined

  1027. Dele (Mobile) has left

  1028. mr.fister has joined

  1029. calvin has left

  1030. waqas has left

  1031. paul has left

  1032. mr.fister has left

  1033. sonny has left

  1034. sonny has joined

  1035. emus has left