XSF Discussion - 2020-01-09

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

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

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.

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.

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

?OTRv?

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

I thought you cannot purge them? flow

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

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

#Conversations

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

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

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

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

pep., but evil servers!

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

We're not talking about this now :)

Well I wasn't

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

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

Yeah that works

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

ahh right

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.

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

that potentially

which works only when you have an e2ee-aware client

for this mechanism

dwd, true

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

I’d publish that once and be done with it

That might be something I can support in poezio :x

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

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

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

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

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

sorry, that’s over my head

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

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?

Oh, OCSP over XMPP?

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

Zash, Yeah, why not?

dwd, "you" as in, the client?

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

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

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

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

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

jonas’, Indeed.

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

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(?)

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

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

and the IQ would have a signed statement in it

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

So we're introducing "another" third-party

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

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

but, uh, why are we talking about this?

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

and edhelas as well

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

pep., 1w expiry interval is probably ok

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

dwd, you’re a sadist

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

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

pep., wfm too

no, the server would just swallow that ;)

(evil server!)

hmm.

Then you might want to leave your server

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

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

don't ask me :p

dwd, true

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.

that ... makes sense

so much

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

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

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

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.

so cloud is now non-persistently backed persistent storage?

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

redundant array of inexpensive DRAMs

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

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

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

also could easily encrypt all of MAM

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.

Uh, where did this discussion go?

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

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

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

HWHAT

I presume it's Hybrid Public Key Encryption

Indeed.

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

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

roster groups and names can be encrypted as well

PEP obviously can't

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

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

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

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

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.

s/SHA-2/hash function/

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

jonas’, Potentially.

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

s/hash function/cryptographic hash function/

(where cryptographic implies obviously >= 32 bits)

ohh, I read bits instead of bytes

that makes it much less confusing

and scary

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

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

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

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

jonas’, But otherwise, yes.

neat

no more gambling with primes, eh?

Though I Am Not A Cryptographer.

IANAC :)

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

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

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)?

That doesn't sound right

But maybe it is

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

Yep. That's how it reads to me.

(punnycode/ACE)

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

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

Ge0rG: Fab, ta.

flow: Thanks.

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

Unsure if I can ask for proper unicode

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

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

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

MattJ: you are not the only one

maybe it's a change of the XMPP domain?

He's joined from the same JID here though

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

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.

MattJ: my s2s still works

I'll check logs

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

Oh, may be an IPv6 thing

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

Interestingly, I seem to have lost everyone running Prosody.

Oh, maybe it's not my issue

Is your inbound IPv6 working?

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

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

Isn't that prosody not doing happy eyeballs?

Oh!

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

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

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

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

I wonder how I can fix this...

My server doesn't do v6 ...

This is why IPv6 is terrible

I've got machines only reachable over IPv6

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

"Network unreachable"

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

s2s is still timing out

Timing out? Over IPv6 or IPv4?

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

Fixed that, at least.

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

dwd: so :-(

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

Probably have to, yes.

But I need things to connect first. :-/

of course

Still not connecting for me

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

Might work now.

Sent a ping

There we go!

Well, that works now.

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

Tried that too.

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

ralphm, Seems to have worked.

Not seeing your presence, yet.

Probably because OF think it's sent it already.

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 :)

Well, that helped a bit.

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.

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

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

I should say: 804 counts, not people.

> reacji

reac字? :)

Please tell me that's a typo

Zash, it come from emo字（絵文字） or bakemo字（バケ文字） etc..

probably

pep., I doubt it

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

Test what, exactly?

Ideally, XMPP connectivity.

But even just a websocket CLI tool would be handy.

reconfigure your favorite web client to use it?

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

I was hoping for something slightly less intensive...

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

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

can you react to reactions? reactionception

reacjiji

heh

!

0. Welcome

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

Had an emergency work meeting come up at the last minute

so that's 20% here

If it ends early, I'll hop in though

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

Who else do we have

I wouldn't be so sure :)

Guus was here a few minutes ago

Seve ?

I"m here

talking to a customer, but will lurk

Ok, so maybe we have quorum :/

I'm brushing off the customer 🙂

well, no

but that conversation is at an end.

heh

1. Minute taker

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

Yay

2. GSoC 2020

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

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

knight Flow once again?

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

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

I think blessing what flow is doing would be sensible.

Can we commit?

Thanks flow, and larma as backup

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

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

ah!

Guus: I think we can.

I'd like that.

There's still some time to expand the projects

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.

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

dwd: that's a good point

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

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

Right, what Dave says.

+1

+1

(He also needs co-admins)

larma volunteered, as mentioned above

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

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

ah

+1

+1

+1

Motion (including amendment) carries.

Yay

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

3. OMEMO

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

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.

+1 to Marvin as co-admin

MattJ : +1 for both motions?

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

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.

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

pep., I am aware, please be patient.

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

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

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

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

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

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

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.

Roughly.

Ah, Dave's mail of a while ago.

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

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

so council contradicted itself?

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.

nyco, +1 to both, yes

thx

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

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

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

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.

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

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

This is not about pointing fingers, of course.

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?

Guus, unlikely to happen

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

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

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

pep. also raised a point:

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?

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

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

bad signal...

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.

MattJ, ! :)

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

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

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.

You're slowly turning into Kev there...

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

High praise.

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

Kev: :-)

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

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

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

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

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

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

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

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

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

dwd, whatever

I think it needs both, doesn't it?

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

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

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.

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.

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

Guus, same

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.

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

engineered*

pep., Syndace has it

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

jonas’, I know, I was thinking about him

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

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

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

that link was here a week ago

(jk)

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.

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.

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

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

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

Thanks nyco!

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

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

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

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

(iirc)

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

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

I've skimmed the article

What I read is that they asked for federation

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

Guus, hmm, correct

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

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

We should talk to Moxie et. al.

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

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"

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

Talking with Matthew at FOSDEM does sound snesible.

Indeed

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)

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

And reaching out to Moxie, as Guus says. ✏

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

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

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

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.

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

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

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

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!"

Let's bring this meeting to an end

Any action to take away from this then?

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

nyco: thanks

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?

Re "Objective 4"

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

Our protocols may include patents only active in some legislations

Do we even know

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

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

also: i need to go.

So no action?

Same here, new meeting

Ok. We can carry this forward to next week.

Ok

Council can still make a decision from their perspective.

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

> 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

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

Feel free to discuss further after the meeting

4. AOB

?

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

no AOB.

5. Date of Next

+1W

6. Close

Thanks all!

+1 wfm. Thanks

wfm

Thanks

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

and anything beyond that isn’t OMEMO but OMEMO’

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

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

the discussion is complex and confusing enough already

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

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?

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

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

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.

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

we don't knowingly accept XEPs with such problems

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

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.

(depending on what state it currently has)

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

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

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

Haven't we?

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

larma, but the .proto files may be under GPL ✏

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

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

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

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.

.proto files are like xml schemas

dwd, awful.

you can perfectly work without a schema

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

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

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

a constant can stand under copyright? interesting.

Kev: XEP-0028

ralphm: Indeed.

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

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

I see, 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.

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

open source lawyers would be fine ...

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

plus libre of course

would not

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

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

bonus if you’re in juryland

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?

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

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

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

moparisthebest, Delaware by default I assume?

I'd also be interested to know the answer though

doesn't look like that document says that

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)

*handle from legal perspective

larma, Yes.

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

moparisthebest, delaware is where the XSF is constituted ✏

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

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?) ✏

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

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

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

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

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

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

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.

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

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

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

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.

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

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

exactly

well that would be the case for everything then

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

russian govt claims you are not

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

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

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

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

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

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

moparisthebest, I’m not so sure about that.

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.

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

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

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

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

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

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