flow21:32:39 Zash> What came first, the spec or the implementation?
IMHO spec and implementation are ideally developed together
mimi89999has left
sonnyhas joined
mimi89999has joined
mukt2has left
Lancehas left
eevvoorhas joined
mukt2has joined
betahas joined
mathijshas left
mathijshas joined
sonnyhas left
sonnyhas joined
Lancehas joined
sonnyhas left
karoshihas joined
sonnyhas joined
mathijshas left
mathijshas joined
UṣLhas joined
sonnyhas left
mathijshas left
mathijshas joined
mukt2has left
mukt2has joined
COM8has joined
sonnyhas joined
Lancehas left
waqashas left
mukt2has left
mukt2has joined
Lancehas joined
derdanielhas joined
mukt2has left
mukt2has joined
adiaholichas left
adiaholichas joined
Danielhas left
Danielhas joined
sonnyhas left
derdanielhas left
Lancehas left
Maxhas left
Maxhas joined
mukt2has left
pep."dwd> moparisthebest, I've implemented MIX twice." are these implementations published anywhere? I'm sure that would help the "situation" a bit.
Zashhas left
dwdOne 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.
dwdCurrently, 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.
sonnyhas joined
mukt2has joined
goffihas joined
edhelasdamn I'm tired of asking my contacts to disable OMEMO to talk with me
karoshihas left
karoshihas joined
dwd?OTRv?
mukt2has left
COM8has left
COM8has joined
Steve Killehas left
eevvoorhas left
mukt2has joined
pdurbinhas left
sonnyhas left
COM8has left
eevvoorhas joined
flowedhelas, if ppl send you omemo encrypted messages, doesn't that mean that you have omemo pep nodes that you may want to purge?
COM8has joined
Zashhas joined
eevvoorI thought you cannot purge them? flow
dwdYou certainly *can*, I mean according to the PEP protocol. Whether your client lets you is a different matter.
mukt2has left
mukt2has joined
jonas’and whether your client silently re-uploads your keys when you did that is yet another question
jonas’#Conversations
pep.yeah.. you do need something server-side for that.
debaclehas joined
Steve Killehas joined
sonnyhas joined
ZashIt takes week(s?) for clients to forget keys after you remove them
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"
sonnyhas left
pep.(only check the devicelist, *and download missing bundles)
jonas’pep., but evil servers!
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..
pep.We're not talking about this now :)
pep.Well I wasn't
jonas’pep., to be fair, sometimes people are "I use e2ee because I don’t trust that other guy’s server"
flowSo the leason here is probably that every xmpp e2ee scheme should have an easy and reliable way out
pep.Yeah that works
sonnyhas joined
jonas’flow, that’s not possible without:
- having to use the E2EE scheme, or
- trusting servers
COM8has left
jonas’flow, that’s not possible without:
- having to use the E2EE scheme, or
- trusting servers, or
- accepting downgrade attacks
flowahh right
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.
dwdYou could, though, have your E2EE-aware clients make the stipulation in a secure method.
flowthat potentially
pep.which works only when you have an e2ee-aware client
pep.for this mechanism
jonas’dwd, true
jonas’pep., but then you only need one of them. If Conversations supported that type of statement, I’d be happier.
jonas’I’d publish that once and be done with it
pep.That might be something I can support in poezio :x
dwdpep., Right, but if you have none, you have no keying material.
jonas’though such a statement needs to have a time limit, otherwise a sevrer can use it against you forever
dwdjonas’, Indeed, timestamped, expiry, a bit like a certificate.
dwdsuggests X.509 Attribute Certificates.
jonas’(revocation is not enough, because a server could decide not to publish the revocation of that statement)
dwdjonas’, Sure, but with X.509 AC you can have OCSP.
jonas’sorry, that’s over my head
dwdAttribute Certificates are like normal certs, but without a public key.
Dele (Mobile)has joined
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?
ZashOh, OCSP over XMPP?
dwdpep., It requires, in this case, the attribute authority to indicate the current status. But the attribute authority could be you, of course.
dwdZash, Yeah, why not?
pep.dwd, "you" as in, the client?
dwdI should probably stress now that I'm only half-serious at best.
pep.So that means my server could lie for it just as much as revocation?
dwdpep., No, you as in you, and it'd be signed statements by your personal key.
dwdpep., Or one you delegate, since OCSP and CRLs support that too.
jonas’generic reminder that there is no "personal" key in OMEMO, only device kyes.
jonas’generic reminder that there is no "personal" key in OMEMO, only device keys.
dwdjonas’, Indeed.
dwdcries quietly.
Ge0rGcan't we just do S/MIME and dump everything into CT?
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(?)
sonnyhas left
dwdpep., Only if you like reinventing wheels, basically.
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
jonas’and the IQ would have a signed statement in it
jonas’if there’s no signed statement in that IQ, tampering is obvious
pep.So we're introducing "another" third-party
dwdjonas’, OCSP is transport independent and is itself signed, so you'd be OK there.
jonas’no, my interpretation would be that such IQs would be replied to e.g. by Conversations
jonas’but, uh, why are we talking about this?
pep.jonas’, so that you can be free of "I sent you an OMEMO message" messages :)
pep.and edhelas as well
dwdjonas’, Because I like to get people discussing the intricacies of X.509 for my personal amusement.
jonas’pep., 1w expiry interval is probably ok
jonas’I need to put Conversations online once per week either way so that it takes just an hour to sync, not multiple hours.
jonas’dwd, you’re a sadist
pep.jonas’, I'd set it slightly longer, like 2-3 weeks. Holidays are a thing :p
pep.Then if you really want to use OMEMO again you can publish devicelist/bundle and the other would fetch them
jonas’pep., wfm too
jonas’no, the server would just swallow that ;)
jonas’(evil server!)
pep.hmm.
pep.Then you might want to leave your server
jonas’sure, and then you can also drop e2ee and make my life easier :)
dwdIn general, it's possble to trust your server to work honestly, but also not trust it with the content of your messages.
pep.don't ask me :p
jonas’dwd, true
dwdBut also, it's possible for a service provider to manage risk by enforcing E2EE, which is what WhatsApp et al are doing it for.
jonas’that ... makes sense
jonas’so much
pep.As a provider I'd be happy to encourage (any kind of) e2ee. Not just OMEMO
dwdThe problem for users is that this pushes the archive onto their device, and radically alters their risk profile.
dwdNot that, of course, they're aware of this in any real sense.
dwdBut 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.
Ge0rGso cloud is now non-persistently backed persistent storage?
jonas’goes and subpoenes them for their swapfiles
dwdI mean, they explicitly keep user keys unencrypted in RAM on their servers. Or were discussing it, anyway.
Ge0rGredundant array of inexpensive DRAMs
Ge0rGdwd: 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
pep.dwd, fwiw I had no doubt that their interest wasn't with their users
Ge0rGI'm pretty confident that we can encrypt most of the roster, and maybe have some kind of JID hashing for presence probing purposes
Ge0rGalso could easily encrypt all of MAM
dwdGe0rG, 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.
ZashUh, where did this discussion go?
Ge0rGdwd: the compliance use case is at least orthogonal to the public-server use case, but more probably it's even the opposite
dwdGe0rG, But yes, in other cases you could use [H]PKE when writing to the archive I think. To some degree.
dwdZash, Around and around. Where it stops, nobody knows.
ZashHWHAT
Ge0rGI presume it's Hybrid Public Key Encryption
dwdIndeed.
Ge0rGZash: that ugly RSA based PoC you once wrote for me, that I was too scared to deploy
ZashMAM can be encrypted yes, I did some such experiment once.
Ge0rGroster groups and names can be encrypted as well
Ge0rGPEP obviously can't
dwdHPKE is a public key crypto system based around a Key Encaspulation Mechanism and a symmetric cipher.
ZashPrivate RSA key encrypted with some stuff extracted out of SCRAM and only available during login
dwdGe0rG, PEP can't be encrypted unilaterally, at least.
Ge0rGroster JIDs can be encrypted as well if you ensure some additional one-way-hashed-JIDs store for authentication purposes
dwdZash, 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.
jonas’s/SHA-2/hash function/
jonas’let’s maybe not get too excited about any specific one ;)
dwdjonas’, Potentially.
Ge0rGdwd: I'm in absolute love with 25519 after I used sodium in a Bluetooth LE mobile payment system
dwdOoooh... One of the OpenVPN devs is considering a multicast/broadcast VPN using MLS as the key agreement protocol. Nifty idea!
dwdMeans that the VPN server itself can't decrypt the packets.
Lancehas joined
ajhas joined
sonnyhas joined
adiaholichas left
adiaholichas joined
Lancehas left
sonnyhas left
Wojtekhas joined
dwdhas left
adiaholichas left
adiaholichas joined
sonnyhas joined
sonnyhas left
debaclehas left
sonnyhas joined
eevvoorhas left
mukt2has left
lskdjfhas joined
vanitasvitaehas left
vanitasvitaehas joined
pdurbinhas joined
taohas joined
KevCheck 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)?
ZashThat doesn't sound right
ZashBut maybe it is
kifterzhas joined
sonnyhas left
sonnyhas joined
kifterzhas left
flowKev, are you asking if the x509 cert SAN is in punnycode?
KevYep. That's how it reads to me.
flow(punnycode/ACE)
adiaholichas left
Ge0rGlooks like that in my real-life LE cert...
X509v3 Subject Alternative Name:
DNS:xn--bdk.op-co.de
flowKev, Smack currently does this https://github.com/igniterealtime/Smack/blob/9d626bf787dc3e0e0a4399cef429285b22744d73/smack-tcp/src/main/java/org/jivesoftware/smack/tcp/XMPPTCPConnection.java#L719
KevGe0rG: Fab, ta.
Kevflow: Thanks.
pep.hmm, I also have punnycode in my cert, but then I did ask for punnycode when generating my cert
pep.Unsure if I can ask for proper unicode
adiaholichas joined
mukt2has joined
flowKev, 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
sonnyhas left
flow(I do not guarantee that the code is complete nor correct)
pdurbinhas left
pdurbinhas joined
dwdhas joined
MattJdwd, looks like I lost s2s with you, and received unsubscribe/d - are we still friends?
Ge0rGMattJ: you are not the only one
Ge0rGmaybe it's a change of the XMPP domain?
MattJHe's joined from the same JID here though
pep.Quick we need a crypto identity to make sure it's him
dwdI'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.
Ge0rGMattJ: my s2s still works
MattJI'll check logs
pdurbinhas left
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.
MattJOh, may be an IPv6 thing
MattJMy outgoing IPv6 appears to be broken, and Prosody doesn't know. Pretty sure it used to work...
dwdInterestingly, I seem to have lost everyone running Prosody.
MattJOh, maybe it's not my issue
MattJIs your inbound IPv6 working?
Holgerdwd: You also unsubscribed from me. No Prosody involved :-)
dwdI 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...
pep.Isn't that prosody not doing happy eyeballs?
dwdOh!
dwdNo, this *is* IPv6. I forgot to firewall that...
pep."There's an IPv6 record. IPv6 is not actually working. Prosody confused"?
Ge0rGMattJ: so when are you going to fix v6 in prosody?
dwdSo yeah, everything that connected to me over IPv6 saw the point in time when my user didn't exist.
betahas left
dwdI wonder how I can fix this...
HolgerMy server doesn't do v6 ...
debaclehas joined
sonnyhas joined
betahas joined
MattJThis is why IPv6 is terrible
Shellhas joined
MattJhides from Zash
Zashgets out the pitchfork
ZashI've got machines only reachable over IPv6
betahas left
mukt2has left
betahas joined
jonas’me too. I always get reminded when I try to wget something off github.com
jonas’"Network unreachable"
dwdhas left
Vaulorhas left
Vaulorhas joined
mathijshas left
mathijshas joined
dwdhas joined
betahas left
dwdMattJ, If you resubscribe to me, does that work?
MattJs2s is still timing out
dwdTiming out? Over IPv6 or IPv4?
dwdAh, IPv6 not routed on that machine for some reason.
dwdFixed that, at least.
sonnyhas left
ralphmik.nu doesn't seem to be able to connect either
ralphmdwd: so :-(
ralphmdwd: you could script to send resubscribes for all your contacts?
dwdProbably have to, yes.
dwdBut I need things to connect first. :-/
ralphmof course
MattJStill not connecting for me
mathijshas left
mathijshas joined
ralphmI tried manually, but indeed, I cannot establish a TCP connection to peirce.dave.cridland.net (2a02:8010:800b::2).
adiaholichas left
adiaholichas joined
Zashhas left
dwdMight work now.
Zashhas joined
ralphmSent a ping
ralphmThere we go!
dwdWell, that works now.
dwdLovely. So people are more than welcome to re-add me (or just add me) at dwd@dave.cridland.net
ralphmTried that too.
dwdAnd I'll have to write a script, I suppose.
dwdralphm, Seems to have worked.
ralphmNot seeing your presence, yet.
dwdProbably because OF think it's sent it already.
Kevflow: I meant to say that each entry check is a case insensitive ascii match. I realise there are several checks involved, but yes, thanks :)
Lancehas joined
betahas joined
intosihas left
ralphmhas left
betahas left
sonnyhas joined
intosihas joined
taohas left
ralphmhas joined
Lancehas left
betahas joined
dwdWell, that helped a bit.
betahas left
mukt2has joined
ralphmAs 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.
ralphmIt also turns out there's a cap on how many different reactions a single person can react with: 23.
nyco(I've just slightly covered that on the newsletter)
ralphmI saw some movement on this. Anything Board can / needs to do here?
nycoknight Flow once again?
pep.We have volunteers to admin, I think we're good
ralphmFWIW I like how pep refers to himself in the 3rd person in Trello.
dwdI think blessing what flow is doing would be sensible.
GuusCan we commit?
pep.Thanks flow, and larma as backup
pep.ralphm, I'm happy to take in comments, I'm not a native :p
pep.And I copied that from a description (where it wasn't especially obvious that I was the author of the text)
ralphmah!
ralphmGuus: I think we can.
GuusI'd like that.
ralphmThere's still some time to expand the projects
dwdBy 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.
neshtaxmpphas left
pep.Unsure if poezio is going to participate this year, maybe. In any case we already have 3 projects interested
ralphmdwd: that's a good point
dwdpep., Four, I think - Prosody, Smack, Dino, Openfire.
neshtaxmpphas joined
KevI don't think Flow can reasonably go ahead without Board appointing him.
KevRight, what Dave says.
ralphmmoves that Florian Schmaus can go ahead to apply for GSoC 2020 and be the XSF's admin to that end.
ralphm+1
Guusmotions that board approve... scratch that, +1
pep.+1
Kev(He also needs co-admins)
mukt2has left
pep.larma volunteered, as mentioned above
ralphmKev: I know this, but do we also have to appoint them, as Board?
KevIn the past it's usually been someone on Board, so haven't needed to.
ralphmah
ralphmamends his motion to include Marvin Wissfeld as co-admin.
ralphm+1
Guus+1
mukt2has joined
pep.+1
ralphmMotion (including amendment) carries.
ralphmYay
nyco(hey MattJ if you want to vote, do that before I send the minutes)
ralphm3. OMEMO
ralphmI would like to briefly touch upon this discussion in Council and here.
ralphmIn 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.
MattJ+1 to Marvin as co-admin
UṣLhas left
nycoMattJ : +1 for both motions?
pep.ralphm, I'd like to note that the author hasn't asked to move it.
ralphmOne 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.
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
ralphmpep., I am aware, please be patient.
ralphmThe above concerns me, as Board runs the XSF, and me personally as part of (and only member of) the Executive Committee.
ralphmI wanted to make note of this, and why I am arguing against any action that might cause this to be the case.
GuusIs there something that you'd explicitly want board to discuss on this now?
Kev(I note that Council voted against accepting OMEMO if it depended on libsignal, with these issues)
Kev(There was something of a bait-and-switch in order to get the libsignal dependency in there)
Guus> (I note that Council voted against accepting OMEMO if it depended on libsignal, with these issues)
Then I don't understand the issue.
KevGuus: 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.
KevRoughly.
GuusAh, Dave's mail of a while ago.
KevIt's all much more complicated than a one-line summary will give credit to, but that's the headline.
DanielOMEMO was then reverted to the state Council rejected with approval of council
Guusso council contradicted itself?
ralphmWell, 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.
MattJnyco, +1 to both, yes
nycothx
Danielit's not like i snug into the server overnight and pushed the current xep
KevGuus: As I say, more complicated. Council was persuaded that the new form didn't need libsignal.
MattJMy meeting is over now, I'll try to pretend I was always paying attention
Guusright, 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.
KevDaniel: Well, indeed, although that does sound exciting.
Danielnot that i'm super happy with how that all went; and i'm sorry
ralphmThis is not about pointing fingers, of course.
Guusralphm 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?
jonas’Guus, unlikely to happen
KevGuus: That's Ralph's (1) isn't it?
ralphmGuus: well, if we're going to have a discussion with them, then the outcome should be 1)
betahas joined
sonnyhas joined
ralphmI don't want to be in the business of chasing their changes.
ralphmpep. also raised a point:
GuusI'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?
ralphmHe says we might send a bad signal when we reject OMEMO.
ralphmI've thought about this and came to the following:
MattJbad signal...
ralphmIf 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.
pep.MattJ, ! :)
ralphmLike the formation of an E2EE SIG, and maybe work individuals are doing within / in collaboration with MLS WG at IETF>
MattJI would prefer not to reject OMEMO until we have exhausted possibilities for saving it
Zashhas joined
ralphmMattJ: 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.
GuusYou're slowly turning into Kev there...
jonas’MattJ, in my eyes, the only way to make OMEMO acceptable is to provably cleanroom-reverse-engineer the signal protocol and publish that.
KevHigh praise.
MattJFor me that means at least reaching out to the libsignal folks (officially, as the XSF) and asking for a more permissive license
ralphmKev: :-)
MattJor clean-room, but I personally feel less like I understand the legal basis of such an approach
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.
ralphmjonas’, and I don't think we have the capacity to verify that something was indeed reverse engineered in a cleanroom fashion.
dwdMattJ, Is it a permissive license we need, or a clear specification?
MattJA 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
ralphmI wouldn't want to burn my fingers on it, anyway.
GuusI agree with MattJ that we should at least try to work with Signal, before abandoning the XEP, if it comes to that.
pep.ralphm, but you can blame that on people who claim it's be done that way.
jonas’ralphm, with provably I mean with a legal advisor overseeing the process.
MattJdwd, whatever
KevI think it needs both, doesn't it?
MattJWe basically have everything we need apart from some magic values, right?
ralphmpep., I don't want to blame anybody, and don't want to be involved in that legal mess
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.
GuusI'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.
dwdMattJ, I don't think there's a specification for the wire protocol (message formats etc) or the constants in use.
MattJGuus, same
KevGuus: 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.
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
pep.engineered*
jonas’pep., Syndace has it
GuusKev which basically means: work together with Signal on this, right?
pep.jonas’, I know, I was thinking about him
ralphmBut this is not a technical challenge, it is a legal one.
jonas’specifically this part: https://github.com/Syndace/python-omemo-backend-signal
pep.Now you just spoiled everybody who wanted to do clean-room :P
jonas’that link was here a week ago
pep.(jk)
GuusIf 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.
dwdThe original reason for moving to "Olm" was that Olm had everything fully specified - but they had to use different constants under pressure from Moxie.
ralphmpep., you kid, but this is actually a problem indeed
nyco(I fail to understand this OMEMO discussion here, I'll need your input for the minutes)
(and I'll have to go soon)
MattJand so does what we're discussing also apply to Olm?
MattJThanks nyco!
dwdMattJ, As I understand it, no, but an Olm-based OMEMO would not be compatible with the current spec because the constants differ.
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)
dwdThat said, Olm is only in use by Matrix, and Matrix are themselves starting to work on moving to MLS.
pep.Also re Matrix, https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom/ this says they did ask
pep.(iirc)
larmadwd, do you know of documentation which constants have been changed?
ralphmSo hey, Matrix is in the same boat as we. I don't see why we couldn't make a statement like this.
GuusI've skimmed the article
GuusWhat I read is that they asked for federation
mukt2has left
Guusthat's different than asking if it's permissible to use the signal double-ratched protocol as part of their protocol
pep.Guus, hmm, correct
Guus(although I might simply not have read that bit yet)
ralphmWell, I'd be happy to discuss this with Matthew at FOSDEM.
GuusWe should talk to Moxie et. al.
ralphmI think there's a reason why Matrix does not use libsignal
Guusit'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"
GuusSure, but a) we're not sure, and b) time has passed.
dwdTalking with Matthew at FOSDEM does sound snesible.
MattJIndeed
pep.And reaching out Moxie, as Guus says.
GuusI 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)
Guusif we do, let's try to work together with Signal.
pep.And reaching out to Moxie, as Guus says.
GuusWell, I'm always happy to talk to Matthew - but he can't speak for Signal
Guushe can only tell us what Signal at some point in the past told Matrix (or how he understood their remarks).
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
GuusSo 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.
ralphmWell, 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.
MattJCan't be assumed, I'm sure he's pretty busy with other things to focus on
dwdpep., But everyone's implementing using libsignal, so those issues don't exist.
GuusSo 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.
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!"
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?
sonnyhas joined
pep.Re "Objective 4"
ralphmpep., most of our protocols don't depend on other protocols like this
pep.Our protocols may include patents only active in some legislations
pep.Do we even know
ralphmThere might be patent issues always, but I think that's different from the current topic
GuusLet's finish the topic at hand first, before addressing new topics please.
Guusalso: i need to go.
pep.So no action?
MattJSame here, new meeting
ralphmOk. We can carry this forward to next week.
pep.Ok
ralphmCouncil can still make a decision from their perspective.
GuusI'd first like to know if the XSF moving ahead hinges on Signals implicit approval.
pdurbinhas joined
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
mukt2has joined
rionhas left
Guusif that's that's the case, I think we should obtain explicit approval from Signal.
ralphmFeel free to discuss further after the meeting
ralphm4. AOB
ralphm?
Guusif we dont get it, we should consider burying the XEP>
Guusno AOB.
ralphm5. Date of Next
ralphm+1W
ralphm6. Close
ralphmThanks all!
ralphmbangs gavel
pep.+1 wfm. Thanks
Guuswfm
GuusThanks
jonas’flow, I think for the simplicity of discussion, we should assume that the term OMEMO means OMEMO-as-currently-written-in-XEP-0384
jonas’and anything beyond that isn’t OMEMO but OMEMO’
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
ralphmRight, OMEMO-right-now is what's been implemented.
jonas’the discussion is complex and confusing enough already
ralphmChanging the spec to be incompatible with that is fine, in principle, but confusing.
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?
larmajonas’, it's still up for discussion if OMEMO’ is necessarily incompatible to OMEMO
pep.At least, I guess the answer currently is "we don't know"
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.
ralphmpep., https://xmpp.org/about/xsf/ipr-policy
ralphmwe don't knowingly accept XEPs with such problems
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)
ralphmpep., 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.
ralphm(depending on what state it currently has)
jonas’I think if the spec has IPR issues, it needs to be removed altogether (akin to Retraction)
larmajonas’, the wire format is protobuf, the specification of protobuf is under CC-BY (from Google)
KevWe have actually removed some XEPs (ok, JEPs) from existence in the past, as much as possible.
KevHaven't we?
jonas’larma, but the protobuf files may be under GPL
flowguess it is really sensible to simplly ask OWS if they would put the libsignal wireformat also in the public domain
jonas’larma, but the .proto files may be under GPL
KevAlthough I don't think that would be helpful here.
ralphmKev: at least one, yes. But I don't remember why.
larmajonas’, the .proto files are not needed to read protobuf
dwdjonas’, 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.
larma.proto files are like xml schemas
jonas’dwd, awful.
larmayou can perfectly work without a schema
dwdjonas’, Well, it's their call, of course.
rionhas joined
lorddavidiiihas left
dwdBut, FWIW, see the info value for the HKDF here: https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/olm.md
jonas’larma, then replace "wire format" with "constants which influence the output" in my statement
eevvoora constant can stand under copyright? interesting.
ralphmKev: XEP-0028
Kevralphm: Indeed.
dwdeevvoor, My understanding is that court action has been threatened on that basis, at least.
betahas left
pdurbinhas left
pep.I guess "a constant can stand under copyright" is provided by the Game Boy and Nintendo.
pep.I guess "a constant can stand under copyright" is proved by the Game Boy and Nintendo.
eevvoorI see, dwd.
dwdeevvoor, I'm not convinced I agree, but that's somewhat moot unless I have a shitload of money and some very good lawyers.
pep.I don't know if there is any such case though yes (Nintendo)
stpeterhas joined
lorddavidiiihas joined
eevvooropen source lawyers would be fine ...
ralphmWIthout the history of the actions of Moxie and/or OWS, I would make such a fuss about it.
eevvoorplus libre of course
ralphmwould not
ralphmNow, I'm not that willing to take a guess.
mimi89999has left
mukt2has left
eevvoorUnfortunately courts are often unlocial expecially concerning topics were you need some expertise in, like SW.
eevvoorUnfortunately courts are often unlocial especially concerning topics were you need some expertise in, like SW.
betahas joined
mukt2has joined
adiaholichas left
jonas’bonus if you’re in juryland
mimi89999has joined
adiaholichas joined
taohas joined
stpeterhas left
emushas joined
adiaholichas left
sonnyhas left
sonnyhas joined
Yagizahas left
Lancehas joined
mukt2has left
lorddavidiiihas left
mathijshas left
mathijshas joined
lorddavidiiihas joined
Alexhas left
eevvoorhas left
Lancehas left
adiaholichas joined
mukt2has joined
taohas left
taohas joined
taohas left
taohas joined
Alexhas joined
mathijshas left
mathijshas joined
sonnyhas left
mukt2has left
sonnyhas joined
mathijshas left
mathijshas joined
calvinhas left
larmaSo 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?
mukt2has joined
Steve Killehas left
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.
moparisthebestI still think that's utterly meaningless without defining a jurisdiction
dwdlarma, Well, we'd need to actually specify the protobuf stuff at some point too, but yes.
pep.moparisthebest, Delaware by default I assume?
pep.I'd also be interested to know the answer though
moparisthebestdoesn't look like that document says that
larmadwd, 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)
andrey.ghas left
larma*handle from legal perspective
dwdlarma, Yes.
moparisthebestre: 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
jonas’moparisthebest, delawere is where the XSF is constituted
jonas’moparisthebest, delaware is where the XSF is constituted
moparisthebestjonas’, sure but that says "by any interested party" not "by any interested party in delaware"
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?)
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?)
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?)
moparisthebestand the lawyer on staff that tries to interpret this stuff is who exactly?
eevvoorhas joined
jonas’there isn’t any on staff, but I guess the Board would consult one if they wanted to be sure
jonas’in this case I think that the ambiguity alone is reason enough to see it as a problem
Nekithas left
pdurbinhas joined
moparisthebestthis kind of thing is always ambiguous, which is why I don't think the XSF should even attempt it
moparisthebestany 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
larmaAssuming I publish a document with those constants under the public domain, can the XSF use those constants referencing my document as a source?
moparisthebestre 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.
mukt2has left
larmamoparisthebest, there even is a law in the EU that explicitly allows reverse engineering
sonnyhas left
jonas’larma, maybe, but you will be liable if those constants are in fact under GPL and you republished them in the public domain.
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
mukt2has joined
serge90has left
pdurbinhas left
Steve Killehas joined
larmajonas’, 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.
debaclehas left
serge90has joined
moparisthebesthe wouldn't be legally liable, the person that used them would
larmamoparisthebest, you sure? How can the person know that I don't have license to publish them?
moparisthebestexactly
larmawell that would be the case for everything then
moparisthebestconsider a recent real world example, how many of you use nginx ? are you legally allowed to?
moparisthebestrussian govt claims you are not
larmaI think they claim the author was not allowed to relicense it
moparisthebestthey claim no one was ever legally allowed to use it from the beginning
sonnyhas joined
waqashas joined
calvinhas joined
andrey.ghas joined
eevvoorhas left
Wojtekhas joined
lovetoxhas joined
taohas left
mathijshas left
mathijshas joined
eevvoorhas joined
Lancehas joined
mathijshas left
mathijshas joined
emushas left
eevvoorhas left
Lancehas left
mathijshas left
mathijshas joined
mathijshas left
mathijshas joined
lovetoxhas left
larmamoparisthebest, that might be technically correct, the question is who is liable for that
sonnyhas left
Marandahas left
Marandahas joined
larmaI 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
sonnyhas joined
emushas joined
lovetoxhas joined
taohas joined
debaclehas joined
moparisthebestif you do something illegal, you can't get out of it by saying "well that guy over there told me to"
moparisthebestyou are liable, and then maybe you can sue that guy over there for your damages, maybe
mathijshas left
mathijshas joined
calvinhas left
calvinhas joined
lovetoxhas left
pdurbinhas joined
jonas’moparisthebest, I’m not so sure about that.
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.
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
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
APachhas left
APachhas joined
pdurbinhas left
Nekithas joined
Danielhas left
Danielhas joined
calvinhas left
calvinhas joined
Nekithas left
Nekithas joined
mukt2has left
Lancehas joined
sonnyhas left
mukt2has joined
sonnyhas joined
j.rhas joined
larmaand you can probably sue that person that was lying for damage
larmalike if your businnes relies on the fact that it was under that license but it isn't
moparisthebestprobably would have needed to pay him for it in that case, otherwise you don't have a business relationship or contract
moparisthebestbottom line it's always on the person/business actually distributing the code, the XSF shouldn't even be trying to interepret/enforce anything imho
XSF Discussion - 2020-01-09