21: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
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.
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.
sonnyhas joined
mukt2has joined
goffihas joined
edhelas
damn 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
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?
COM8has joined
Zashhas joined
eevvoor
I thought you cannot purge them? flow
dwd
You 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
Zash
It 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"
flow
So 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 ✏
flow
ahh 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.
dwd
You could, though, have your E2EE-aware clients make the stipulation in a secure method.
flow
that 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
dwd
pep., 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
dwd
jonas’, 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)
dwd
jonas’, Sure, but with X.509 AC you can have OCSP.
jonas’
sorry, that’s over my head
dwd
Attribute 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?
Zash
Oh, OCSP over XMPP?
dwd
pep., It requires, in this case, the attribute authority to indicate the current status. But the attribute authority could be you, of course.
dwd
Zash, Yeah, why not?
pep.
dwd, "you" as in, the client?
dwd
I 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?
dwd
pep., No, you as in you, and it'd be signed statements by your personal key.
dwd
pep., 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. ✏
dwd
jonas’, Indeed.
dwdcries quietly.
Ge0rG
can'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
dwd
pep., 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
dwd
jonas’, 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
dwd
jonas’, 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 :)
dwd
In 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
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.
jonas’
that ... makes sense
jonas’
so much
pep.
As a provider I'd be happy to encourage (any kind of) e2ee. Not just OMEMO
dwd
The problem for users is that this pushes the archive onto their device, and radically alters their risk profile.
dwd
Not that, of course, they're aware of this in any real sense.
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.
Ge0rG
so cloud is now non-persistently backed persistent storage?
jonas’goes and subpoenes them for their swapfiles
dwd
I mean, they explicitly keep user keys unencrypted in RAM on their servers. Or were discussing it, anyway.
Ge0rG
redundant array of inexpensive DRAMs
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
pep.
dwd, fwiw I had no doubt that their interest wasn't with their users
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
Ge0rG
also could easily encrypt all of MAM
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.
Zash
Uh, where did this discussion go?
Ge0rG
dwd: the compliance use case is at least orthogonal to the public-server use case, but more probably it's even the opposite
dwd
Ge0rG, But yes, in other cases you could use [H]PKE when writing to the archive I think. To some degree.
dwd
Zash, Around and around. Where it stops, nobody knows.
Zash
HWHAT
Ge0rG
I presume it's Hybrid Public Key Encryption
dwd
Indeed.
Ge0rG
Zash: that ugly RSA based PoC you once wrote for me, that I was too scared to deploy
Zash
MAM can be encrypted yes, I did some such experiment once.
Ge0rG
roster groups and names can be encrypted as well
Ge0rG
PEP obviously can't
dwd
HPKE is a public key crypto system based around a Key Encaspulation Mechanism and a symmetric cipher.
Zash
Private RSA key encrypted with some stuff extracted out of SCRAM and only available during login
dwd
Ge0rG, PEP can't be encrypted unilaterally, at least.
Ge0rG
roster JIDs can be encrypted as well if you ensure some additional one-way-hashed-JIDs store for authentication purposes
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.
jonas’
s/SHA-2/hash function/
jonas’
let’s maybe not get too excited about any specific one ;)
dwd
jonas’, Potentially.
Ge0rG
dwd: I'm in absolute love with 25519 after I used sodium in a Bluetooth LE mobile payment system
Ooooh... One of the OpenVPN devs is considering a multicast/broadcast VPN using MLS as the key agreement protocol. Nifty idea!
dwd
Means 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
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)?
Zash
That doesn't sound right
Zash
But maybe it is
kifterzhas joined
sonnyhas left
sonnyhas joined
kifterzhas left
flow
Kev, are you asking if the x509 cert SAN is in punnycode?
Kev
Yep. That's how it reads to me.
flow
(punnycode/ACE)
adiaholichas left
Ge0rG
looks like that in my real-life LE cert...
X509v3 Subject Alternative Name:
DNS:xn--bdk.op-co.de
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
Kev
Ge0rG: Fab, ta.
Kev
flow: 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
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
sonnyhas left
flow
(I do not guarantee that the code is complete nor correct)
pdurbinhas left
pdurbinhas joined
dwdhas joined
MattJ
dwd, looks like I lost s2s with you, and received unsubscribe/d - are we still friends?
Ge0rG
MattJ: you are not the only one
Ge0rG
maybe it's a change of the XMPP domain?
MattJ
He's joined from the same JID here though
pep.
Quick we need a crypto identity to make sure it's him
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.
Ge0rG
MattJ: my s2s still works
MattJ
I'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.
MattJ
Oh, may be an IPv6 thing
MattJ
My outgoing IPv6 appears to be broken, and Prosody doesn't know. Pretty sure it used to work...
dwd
Interestingly, I seem to have lost everyone running Prosody.
MattJ
Oh, maybe it's not my issue
MattJ
Is your inbound IPv6 working?
Holger
dwd: You also unsubscribed from me. No Prosody involved :-)
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...
pep.
Isn't that prosody not doing happy eyeballs?
dwd
Oh!
dwd
No, this *is* IPv6. I forgot to firewall that...
pep.
"There's an IPv6 record. IPv6 is not actually working. Prosody confused"?
Ge0rG
MattJ: so when are you going to fix v6 in prosody?
dwd
So yeah, everything that connected to me over IPv6 saw the point in time when my user didn't exist.
betahas left
dwd
I wonder how I can fix this...
Holger
My server doesn't do v6 ...
debaclehas joined
sonnyhas joined
betahas joined
MattJ
This is why IPv6 is terrible
Shellhas joined
MattJhides from Zash
Zashgets out the pitchfork
Zash
I'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
dwd
MattJ, If you resubscribe to me, does that work?
MattJ
s2s is still timing out
dwd
Timing out? Over IPv6 or IPv4?
dwd
Ah, IPv6 not routed on that machine for some reason.
dwd
Fixed that, at least.
sonnyhas left
ralphm
ik.nu doesn't seem to be able to connect either
ralphm
dwd: so :-(
ralphm
dwd: you could script to send resubscribes for all your contacts?
dwd
Probably have to, yes.
dwd
But I need things to connect first. :-/
ralphm
of course
MattJ
Still not connecting for me
mathijshas left
mathijshas joined
ralphm
I 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
dwd
Might work now.
Zashhas joined
ralphm
Sent a ping
ralphm
There we go!
dwd
Well, that works now.
dwd
Lovely. So people are more than welcome to re-add me (or just add me) at dwd@dave.cridland.net
ralphm
Tried that too.
dwd
And I'll have to write a script, I suppose.
dwd
ralphm, Seems to have worked.
ralphm
Not seeing your presence, yet.
dwd
Probably because OF think it's sent it already.
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 :)
Lancehas joined
betahas joined
intosihas left
ralphmhas left
betahas left
sonnyhas joined
intosihas joined
taohas left
ralphmhas joined
Lancehas left
betahas joined
dwd
Well, that helped a bit.
betahas left
mukt2has joined
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.
ralphm
It also turns out there's a cap on how many different reactions a single person can react with: 23.
(I've just slightly covered that on the newsletter)
ralphm
I saw some movement on this. Anything Board can / needs to do here?
nyco
knight Flow once again?
pep.
We have volunteers to admin, I think we're good
ralphm
FWIW I like how pep refers to himself in the 3rd person in Trello.
dwd
I think blessing what flow is doing would be sensible.
Guus
Can 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)
ralphm
ah!
ralphm
Guus: I think we can.
Guus
I'd like that.
ralphm
There's still some time to expand the projects
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.
neshtaxmpphas left
pep.
Unsure if poezio is going to participate this year, maybe. In any case we already have 3 projects interested
ralphm
dwd: that's a good point
dwd
pep., Four, I think - Prosody, Smack, Dino, Openfire.
neshtaxmpphas joined
Kev
I don't think Flow can reasonably go ahead without Board appointing him.
Kev
Right, 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
ralphm
Kev: I know this, but do we also have to appoint them, as Board?
Kev
In the past it's usually been someone on Board, so haven't needed to.
ralphm
ah
ralphmamends his motion to include Marvin Wissfeld as co-admin.
ralphm
+1
Guus
+1
mukt2has joined
pep.
+1
ralphm
Motion (including amendment) carries.
ralphm
Yay
nyco
(hey MattJ if you want to vote, do that before I send the minutes)
ralphm
3. OMEMO
ralphm
I would like to briefly touch upon this discussion in Council and here.
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.
MattJ
+1 to Marvin as co-admin
UṣLhas left
nyco
MattJ : +1 for both motions?
pep.
ralphm, I'd like to note that the author hasn't asked to move it.
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.
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
ralphm
pep., I am aware, please be patient.
ralphm
The above concerns me, as Board runs the XSF, and me personally as part of (and only member of) the Executive Committee.
ralphm
I wanted to make note of this, and why I am arguing against any action that might cause this to be the case.
Guus
Is 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.
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.
Kev
Roughly.
Guus
Ah, Dave's mail of a while ago.
Kev
It's all much more complicated than a one-line summary will give credit to, but that's the headline.
Daniel
OMEMO was then reverted to the state Council rejected with approval of council
Guus
so council contradicted itself?
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.
MattJ
nyco, +1 to both, yes
nyco
thx
Daniel
it's not like i snug into the server overnight and pushed the current xep
Kev
Guus: As I say, more complicated. Council was persuaded that the new form didn't need libsignal.
MattJ
My meeting is over now, I'll try to pretend I was always paying attention
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.
Kev
Daniel: Well, indeed, although that does sound exciting.
Daniel
not that i'm super happy with how that all went; and i'm sorry
ralphm
This is not about pointing fingers, of course.
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?
jonas’
Guus, unlikely to happen
Kev
Guus: That's Ralph's (1) isn't it?
ralphm
Guus: well, if we're going to have a discussion with them, then the outcome should be 1)
betahas joined
sonnyhas joined
ralphm
I don't want to be in the business of chasing their changes.
ralphm
pep. also raised a point:
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?
ralphm
He says we might send a bad signal when we reject OMEMO.
ralphm
I've thought about this and came to the following:
MattJ
bad signal...
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.
pep.
MattJ, ! :)
ralphm
Like the formation of an E2EE SIG, and maybe work individuals are doing within / in collaboration with MLS WG at IETF>
MattJ
I would prefer not to reject OMEMO until we have exhausted possibilities for saving it
Zashhas joined
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.
Guus
You'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.
Kev
High praise.
MattJ
For me that means at least reaching out to the libsignal folks (officially, as the XSF) and asking for a more permissive license
ralphm
Kev: :-)
MattJ
or 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.
ralphm
jonas’, and I don't think we have the capacity to verify that something was indeed reverse engineered in a cleanroom fashion.
dwd
MattJ, Is it a permissive license we need, or a clear specification?
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
ralphm
I wouldn't want to burn my fingers on it, anyway.
Guus
I 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.
MattJ
dwd, whatever
Kev
I think it needs both, doesn't it?
MattJ
We basically have everything we need apart from some magic values, right?
ralphm
pep., 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.
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.
dwd
MattJ, I don't think there's a specification for the wire protocol (message formats etc) or the constants in use.
MattJ
Guus, same
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.
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
Guus
Kev which basically means: work together with Signal on this, right?
pep.
jonas’, I know, I was thinking about him
ralphm
But 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)
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.
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.
ralphm
pep., 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)
MattJ
and so does what we're discussing also apply to Olm?
MattJ
Thanks nyco!
dwd
MattJ, 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)
dwd
That 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)
larma
dwd, do you know of documentation which constants have been changed?
ralphm
So hey, Matrix is in the same boat as we. I don't see why we couldn't make a statement like this.
Guus
I've skimmed the article
Guus
What I read is that they asked for federation
mukt2has left
Guus
that'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)
ralphm
Well, I'd be happy to discuss this with Matthew at FOSDEM.
Guus
We should talk to Moxie et. al.
ralphm
I think there's a reason why Matrix does not use libsignal
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"
Guus
Sure, but a) we're not sure, and b) time has passed.
dwd
Talking with Matthew at FOSDEM does sound snesible.
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)
Well, I'm always happy to talk to Matthew - but he can't speak for Signal
Guus
he 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
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.✎
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.
MattJ
Can't be assumed, I'm sure he's pretty busy with other things to focus on
dwd
pep., But everyone's implementing using libsignal, so those issues don't exist.
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. ✏
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!"
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"
ralphm
pep., 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
ralphm
There might be patent issues always, but I think that's different from the current topic
Guus
Let's finish the topic at hand first, before addressing new topics please.
Guus
also: i need to go.
pep.
So no action?
MattJ
Same here, new meeting
ralphm
Ok. We can carry this forward to next week.
pep.
Ok
ralphm
Council can still make a decision from their perspective.
Guus
I'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
Guus
if that's that's the case, I think we should obtain explicit approval from Signal.
ralphm
Feel free to discuss further after the meeting
ralphm
4. AOB
ralphm
?
Guus
if we dont get it, we should consider burying the XEP>
Guus
no AOB.
ralphm
5. Date of Next
ralphm
+1W
ralphm
6. Close
ralphm
Thanks all!
ralphmbangs gavel
pep.
+1 wfm. Thanks
Guus
wfm
Guus
Thanks
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
ralphm
Right, OMEMO-right-now is what's been implemented.
jonas’
the discussion is complex and confusing enough already
ralphm
Changing 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?
larma
jonas’, 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.
ralphm
pep., https://xmpp.org/about/xsf/ipr-policy
ralphm
we 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)
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.
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)
larma
jonas’, the wire format is protobuf, the specification of protobuf is under CC-BY (from Google)
Kev
We have actually removed some XEPs (ok, JEPs) from existence in the past, as much as possible.
Although I don't think that would be helpful here.
ralphm
Kev: at least one, yes. But I don't remember why.
larma
jonas’, the .proto files are not needed to read protobuf
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.
larma
.proto files are like xml schemas
jonas’
dwd, awful.
larma
you can perfectly work without a schema
dwd
jonas’, Well, it's their call, of course.
rionhas joined
lorddavidiiihas left
dwd
But, 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
eevvoor
a constant can stand under copyright? interesting.
ralphm
Kev: XEP-0028
Kev
ralphm: Indeed.
dwd
eevvoor, 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. ✏
eevvoor
I see, dwd.
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.
pep.
I don't know if there is any such case though yes (Nintendo)
stpeterhas joined
lorddavidiiihas joined
eevvoor
open source lawyers would be fine ...
ralphm
WIthout the history of the actions of Moxie and/or OWS, I would make such a fuss about it.
eevvoor
plus libre of course
ralphm
would not
ralphm
Now, I'm not that willing to take a guess.
mimi89999has left
mukt2has left
eevvoor
Unfortunately courts are often unlocial expecially concerning topics were you need some expertise in, like SW.✎
eevvoor
Unfortunately 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
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?
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.
moparisthebest
I still think that's utterly meaningless without defining a jurisdiction
dwd
larma, 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
moparisthebest
doesn't look like that document says that
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)
andrey.ghas left
larma
*handle from legal perspective
dwd
larma, Yes.
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
jonas’
moparisthebest, delawere is where the XSF is constituted✎
jonas’
moparisthebest, delaware is where the XSF is constituted ✏
moparisthebest
jonas’, 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?) ✏
moparisthebest
and 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
moparisthebest
this kind of thing is always ambiguous, which is why I don't think the XSF should even attempt it
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
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?
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.
mukt2has left
larma
moparisthebest, 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
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.
debaclehas left
serge90has joined
moparisthebest
he wouldn't be legally liable, the person that used them would
larma
moparisthebest, you sure? How can the person know that I don't have license to publish them?
moparisthebest
exactly
larma
well that would be the case for everything then
moparisthebest
consider a recent real world example, how many of you use nginx ? are you legally allowed to?
moparisthebest
russian govt claims you are not
larma
I think they claim the author was not allowed to relicense it
moparisthebest
they 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
larma
moparisthebest, that might be technically correct, the question is who is liable for that
sonnyhas left
Marandahas left
Marandahas joined
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
sonnyhas joined
emushas joined
lovetoxhas joined
taohas joined
debaclehas joined
moparisthebest
if you do something illegal, you can't get out of it by saying "well that guy over there told me to"
moparisthebest
you 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
larma
and you can probably sue that person that was lying for damage
larma
like if your businnes relies on the fact that it was under that license but it isn't
moparisthebest
probably would have needed to pay him for it in that case, otherwise you don't have a business relationship or contract
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