XSF Discussion - 2020-01-13


  1. vanitasvitae

    :D that deascalated quickly.

  2. lovetox

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

  3. pep.

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

  4. 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

  5. flow

    *libsignal wire-protocol compatible library

  6. Zash

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

  7. Zash

    or something

  8. moparisthebest

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

  9. moparisthebest

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

  10. 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.

  11. winfried

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

  12. Zash

    Is an implementation a derivative work of the specification?

  13. winfried

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

  14. Zash

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

  15. flow

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

  16. 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

  17. moparisthebest

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

  18. 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.

  19. flow

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

  20. moparisthebest

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

  21. moparisthebest

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

  22. 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)

  23. 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....

  24. dwd

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

  25. 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.

  26. Kev

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

  27. moparisthebest

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

  28. moparisthebest

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

  29. moparisthebest

    what's the difference?

  30. dwd

    moparisthebest, What's the similarity?

  31. moparisthebest

    both of them are implementable given certain decisions and constraints

  32. dwd

    moparisthebest, What decision and constraint for XEP-0365?

  33. moparisthebest

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

  34. dwd

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

  35. moparisthebest

    and you can test omemo without distributing it

  36. winfried

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

  37. dwd

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

  38. moparisthebest

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

  39. moparisthebest

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

  40. 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.

  41. 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...

  42. 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

  43. dwd

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

  44. moparisthebest

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

  45. jonas’

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

  46. jonas’

    which is it?

  47. moparisthebest

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

  48. moparisthebest

    jonas’, the first being true because of the second

  49. dwd

    moparisthebest, Why is that relevant?

  50. moparisthebest

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

  51. moparisthebest

    are we policing the legality of XEPs or not

  52. dwd

    moparisthebest, No.

  53. 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).

  54. 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.

  55. moparisthebest

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

  56. 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.

  57. moparisthebest

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

  58. 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

  59. jonas’

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

  60. 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

  61. 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

  62. 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

  63. 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

  64. moparisthebest

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

  65. winfried

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

  66. moparisthebest

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

  67. jonas’

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

  68. jonas’

    winfried, you may want to ping Syndace about the details

  69. jonas’

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

  70. pep.

    jonas’, isn't everybody here?

  71. pep.

    That's what started this whole thing

  72. moparisthebest

    I'm probably failing at being clear, we SHOULD NOT BE TRYING TO JUDGE THE LEGALITY/LICENSE SITUATION OF A XEP

  73. pep.

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

  74. moparisthebest

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

  75. moparisthebest

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

  76. jonas’

    pep., I stopped trying, really

  77. winfried

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

  78. pep.

    haha

  79. moparisthebest

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

  80. pep.

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

  81. 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"

  82. moparisthebest

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

  83. jonas’

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

  84. 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?

  85. jonas’

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

  86. 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.

  87. Kev

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

  88. moparisthebest

    probably

  89. moparisthebest

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

  90. 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....)

  91. Kev

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

  92. jonas’

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

  93. jonas’

    which is his right to do

  94. jonas’

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

  95. winfried

    jonas’: true

  96. 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

  97. dwd

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

  98. Syndace

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

  99. winfried

    Syndace: great!

  100. Syndace

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

  101. Syndace

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

  102. winfried

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

  103. 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?

  104. 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.

  105. 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.

  106. Syndace

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

  107. Syndace

    It was not easy to split these parts cleanly.

  108. Syndace

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

  109. Syndace

    winfried: Did that answer your questions?

  110. moparisthebest

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

  111. 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.

  112. moparisthebest

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

  113. Syndace

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

  114. 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.

  115. moparisthebest

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

  116. moparisthebest

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

  117. moparisthebest

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

  118. moparisthebest

    again depends on a lot of things, including jurisdiction

  119. 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.

  120. Ge0rG

    Trademark, not copyright

  121. Syndace

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

  122. 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.

  123. winfried

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

  124. Daniel

    well that's why we are making NEWMEMO

  125. Daniel

    (working title)

  126. winfried

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

  127. Syndace

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

  128. 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

  129. Daniel

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

  130. Syndace

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

  131. Syndace

    But yes, the conclusion should not talk in absolutes

  132. 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

  133. Syndace

    safe for everybody who doesn't know better :D

  134. Daniel

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

  135. moparisthebest

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

  136. Ge0rG

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

  137. Zash

    MLEMOS

  138. Zash

    MLSEMO

  139. 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.

  140. 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

  141. Zash

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

  142. Daniel

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

  143. winfried

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

  144. 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

  145. Ge0rG

    winfried: trademark, not copyright

  146. 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.

  147. 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

  148. 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)

  149. 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"

  150. Daniel

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

  151. Daniel

    i think that can and should be done

  152. Ge0rG

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

  153. Syndace

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

  154. 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

  155. Daniel

    and overengineering everything

  156. Zash

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

  157. Daniel

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

  158. Zash

    Heh

  159. Daniel

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

  160. Daniel

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

  161. 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'...

  162. Zash

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

  163. 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)

  164. Ge0rG

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

  165. winfried

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

  166. winfried

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

  167. winfried

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

  168. moparisthebest

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

  169. moparisthebest

    hahahaha

  170. 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.

  171. moparisthebest

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

  172. Syndace

    vanitasvitae: Look like 10 messages above :D

  173. winfried

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

  174. moparisthebest

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

  175. winfried

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

  176. winfried

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

  177. 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

  178. 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

  179. moparisthebest

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

  180. dwd

    $2,500,00.

  181. dwd

    $2,500,000.

  182. jonas’

    that’s a number

  183. 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.

  184. jonas’

    and did that work?

  185. moparisthebest

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

  186. 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.

  187. 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.

  188. moparisthebest

    was this before or after the documentation was published?

  189. Daniel

    He is just doing that to protect you

  190. winfried

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

  191. dwd

    moparisthebest, Depends which documentation you're talking about.

  192. jonas’

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

  193. jonas’

    https://medium.com/@wireapp/axolotl-and-proteus-788519b186a7

  194. moparisthebest

    Daniel, I know I feel safer

  195. dwd

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

  196. jonas’

    indeed

  197. jonas’

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

  198. 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

  199. 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

  200. moparisthebest

    jonas’, anything not already GPL :)

  201. dwd

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

  202. winfried

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

  203. dwd

    (prekeys for Axolotl/Olm, clientinitkeys for MLS)

  204. 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

  205. moparisthebest

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

  206. Daniel

    flow: yes I said that a few lines down

  207. jonas’

    moparisthebest, which is an encumberence to me

  208. moparisthebest

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

  209. moparisthebest

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

  210. flow

    Daniel, uh, sorry, I've missed that

  211. flow

    dwd, because attachs?

  212. dwd

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

  213. flow

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

  214. jonas’

    and grey smoke emerges?

  215. Kev

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

  216. 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.

  217. Daniel

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

  218. dwd

    Daniel, Indeed - better than running out of them.

  219. moparisthebest

    depends on the crypto primitive always no?

  220. Daniel

    But you know. Ask 3 cryptographers get 4 different opinions

  221. 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.

  222. 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

  223. dwd

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

  224. 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..

  225. jonas’

    winfried, moohahaha

  226. pep.

    (hmm, topic has changed 10 times in between)

  227. pep.

    and and you do cite Nintendo even..

  228. Syndace

    :D

  229. 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.

  230. moparisthebest

    makes it *easier* dwd ?

  231. jonas’

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

  232. moparisthebest

    ah got it, thanks

  233. 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...)

  234. Daniel

    You delete your private keys

  235. winfried

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

  236. 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

  237. 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

  238. 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

  239. 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....

  240. winfried

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

  241. 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.

  242. 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

  243. jonas’

    moparisthebest, the risk of being sued is encumbarance alone

  244. jonas’

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

  245. moparisthebest

    and again you have that with *everything*

  246. Ge0rG

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

  247. jonas’

    observe my edit

  248. moparisthebest

    those 2 are 1992 and 2000 respectively

  249. Ge0rG

    And then the DMCA happened

  250. 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.

  251. moparisthebest

    well that one is interesting

  252. 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.

  253. moparisthebest

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

  254. moparisthebest

    ie "I got it from that PDF your honor"

  255. jonas’

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

  256. winfried

    jonas’: :-D

  257. winfried

    I can keep that one going!

  258. moparisthebest

    ideally we never discuss legalities instead :)

  259. winfried

    I'll sue you if you never discuss legalities!

  260. moparisthebest

    touche

  261. Ge0rG

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

  262. 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.

  263. Ge0rG

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

  264. moparisthebest

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

  265. winfried

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

  266. Ge0rG

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

  267. jonas’

    seconding Ge0rG

  268. jonas’

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

  269. 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

  270. 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...

  271. winfried

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

  272. moparisthebest

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

  273. 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

  274. 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

  275. jonas’

    because you *are* causing problems

  276. 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

  277. moparisthebest

    I just responded to a question about it is all

  278. 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

  279. jonas’

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

  280. moparisthebest

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

  281. Ge0rG

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

  282. winfried

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

  283. jonas’

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

  284. jonas’

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

  285. jonas’

    but that only makes sense after the board meeting

  286. jonas’

    this was made clear last week already

  287. moparisthebest

    I was just responding to winfried, in the appropriate venue

  288. jonas’

    moparisthebest, I get that

  289. jonas’

    and I’m not arguing that

  290. Ge0rG

    Now that everything is clarified, we can move on

  291. 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

  292. moparisthebest

    sure agreed

  293. jonas’

    what Ge0rG syas

  294. jonas’

    what Ge0rG says

  295. stpeter

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

  296. jonas’

    stpeter, good point

  297. 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

  298. winfried

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

  299. 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)

  300. pep.

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

  301. pep.

    Especially when other people bring the topic again in the room

  302. moparisthebest

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

  303. pep.

    github is not the venue for that though..

  304. moparisthebest

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

  305. pep.

    We have lists for that

  306. pep.

    that'd be great

  307. moparisthebest

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

  308. moparisthebest

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

  309. pep.

    It should never have been

  310. moparisthebest

    can't change the past :)

  311. pep.

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