I have update Ephemeral Messages XEP: https://github.com/xsf/xeps/pull/666
muppethhas joined
Tobiashas left
Tobiashas joined
tahas left
tahas joined
jubalhhas joined
danielhas left
danielhas left
flow
labdsf, if you find the time, then maybe present an htmldiff
jubalhhas joined
flow
for example by using https://github.com/cygri/htmldiff
pep.has left
Kevhas left
alacerhas left
labdsfhas left
kasper.dementhas joined
tuxhas joined
tuxhas joined
danielhas left
Valerianhas left
Valerianhas joined
Timhas joined
la|r|mahas joined
kasper.dementhas left
marchas left
labdsf
Ok
labdsf
I am afk now, will make a diff later
labdsf
I have mostly removed support for plaintext ephemeral messages, but the ability to implement them is left for "controlled environments", where servers only federate with servers that support ephemeral messages and only accept messages from clients that support ephemeral messages.
SamWhited
That seems like a premature optimization for a very niche use case; unless you know of a service that does this?
labdsf
Maybe remove it completely
labdsf
It may be useful for MUC on a non-federated server
labdsf
When you don't want to setup OMEMO MUC (which requires members-only chat)
j.rhas joined
SamWhited
ah sorry, I see; I misunderstood what you were saying anyways
SamWhited
Going to re-read this with your new changes now to make sure; but tying this to OMEMO or OTR at all feels wrong to me. I don't understand why there is a distinction between plaintext and OMEMO or whatever in a XEP about something that has nothing to do with encryption
SamWhited
Ephemeral messages feel completely orthogonal to what goes in the body or to the wire format of the message to me.
Seve/SouLhas joined
la|r|mahas joined
labdsf
In an open environment, where messages you send to bare JID or MUC may be delivered to clients that don't support ephemeral messages, OTR and OMEMO can be used to only encrypt messages for clients that have explicitly indicated support for them, as with OTR and OMEMO each device has its own private key (in contrast to OpenPGP, for example).
labdsf
With OTR, chats are full JID to full JID only, so you can ask the client whether it supports ephemeral messages or not.
marmistrzhas joined
labdsf
With OMEMO I add a PubSub item to show that device supports ephemeral messages.
la|r|mahas joined
kasper.dementhas joined
la|r|mahas joined
la|r|mahas joined
goffihas left
kasper.dementhas left
Chobbeshas joined
labdsf
OTR and OMEMO are the only ways to have E2E forward secrecy in XMPP now. Using OpenPGP with ephemeral messages is a bad idea, because if the device is lost (the only considered scenario), the key is also compromised in most cases (unless you set a passphrase on it).
labdsf
So there are two use cases.
kasper.dementhas joined
labdsf
One is the open network, where you use ephemeral messages only over OTR and OMEMO with contacts that have installed
labdsf
..clients with ephemeral message support.
j.rhas joined
rishiraj22has left
labdsf
The second use case is when there is a trusted "corporate" server network, all servers have forward secrecy on transport level and all clients enable plaintext ephemeral messages.
goffihas joined
labdsfhas left
vanitasvitaehas left
la|r|mahas left
la|r|mahas joined
la|r|mahas joined
j.rhas joined
Valerianhas left
valohas joined
Kev
Sorry, what is the issue with gpg and ephemeral messages in the device loss scenario?
Kev
Clearly losing your key is a Bad Thing, but I don't see how that's related to ephemeral messages particularly.
la|r|mahas joined
doshas left
doshas joined
lorddavidiiihas left
lnjhas left
SamWhitedhas left
labdsf
Message copies are left on the server, so they can be downloaded again and decrypted with the key.
la|r|mahas joined
mimi89999has joined
mimi89999has left
mimi89999has joined
mimi89999has joined
mimi89999has joined
labdsf
In the "open network" use case no server is trusted, so forward secrecy is required to have truly ephemeral messages.
SamWhited
That all seems like unnecessary complexity that's just going to make people think this is a security feature; you can't enforce this sort of thing so adding security theater on top of it doesn't seem helpful to me.
zakhas left
SamWhitedhas left
labdsf
It is a security feature as long as you trust your contact.
Neustradamushas left
Neustradamushas joined
pep.
hmm, trust and security..
labdsf
pep.: when you use OMEMO, you trust your contact not to leak the message contents by publishing it on twitter
labdsf, encryption and recipient behaviour are two orthogonal concepts, one is technical while the other is social.
labdsf
SamWhited: I trust clients that specifically indicate that they support the feature, the problem is legacy clients
labdsf
When a contact has two clients, one is, lets say, Gajim with ephemeral message support added, and the other is Conversations, I want only Gajim to receive ephemeral message.
Link Mauve
I remember when people from a MUC I used to frequent started using Snapchat, soon enough someone started using a way to save the dickpics^Wfiles exchanged permanently, despite that being the main “feature” of the service.
labdsf
Snapchat is not my usecase, I think I stated it at the beginning of the first discussion in standards ML.
marmistrzhas left
labdsf
Because in MUC that is not members-only users are not trusted.
pep.
That was an example on social behaviour
labdsf
Ok, threat model for "open network" use case: contact is trusted, server is not.
waqas
Note that you are in any case trusting remote entities, e.g., I'd find it desirable to force logs in my client even if the remote party doesn't want them. GPG is about trust, while you are focusing on deniability.
labdsf
But contact has a legacy client.
labdsf
waqas: if you want to log all messages, just disable ephemeral messages
Link Mauve
Or still log them, despite what the other party may want.
pep.
But what happens when your contact sends you an ephemeral message
waqas
Yep, it's more fun to log them while having you think that we are not logging them
waqas
At the end of the day, you are trusting remote entities to not lie
labdsf
pep.: if you have not indicated that you support it, the message is not ephemeral
pep.
labdsf, that's the thing
labdsf
pep.: your contact knows it
pep.
So you won't send this kind of message if your contact doesn't support it? Or will you do it either way?
marchas left
labdsf
waqas: lying contacts is not a part of the threat model
waqas
labdsf: lying servers aren't either?
labdsf
waqas: in "open network" use case the server is malicious
waqas
The server can always log without telling you
labdsf
waqas: that is why I say OTR and OMEMO must be used
Link Mauve
labdsf, I highly disagree on this point, in my open network use case, servers are often controlled by their user, if someone would lie they would have control over both their client and their server.
labdsf
Link Mauve: lying client is not a part of threat model
valohas joined
labdsf
I do not consider lying clients
Link Mauve
The server and the client can be considered a same entity in this model.
j.rhas joined
waqas
I do see labdsf's point though. It's largely a case of protecting against current server and future client compromise, if I understand the argument correctly.
pep.
labdsf, how do you not consider lying clients, I'm not sure I see it
pep.
If a contact tells me it's supporting ephemeral, I might send what I consider a bit more private messages, assuming they're going to be deleted.
pep.
Where is that not an issue
waqas
pep.: It's protecting against a future search warrant, where clients currently are considered uncompromised
daniel
It's not a security feature. It's a friendly reminder to maybe to some house cleaning after you read the message
pep.
daniel, yeah I know it's not a security feature
pep.
So what does it bring to me as a user, really
labdsf
pep.: it is ok to send more private messages if you trust your contact not to install malicious client
pep.
UX fun?
pep.
labdsf, my contact might not know
labdsf
pep.: what your contact might not know? Thst it installed a malicious client?
pep.
Yes?
pep.
Took the first client, "hah it looks like conversations, it's green like conversations, must be conversations"
daniel
pep., as the recipient you know that a certain messages is worth deleting at some point
daniel
for example the sender slaps the delete hint on a password or something
labdsf
See, all your arguments that it is not a security feature because a trusted contact may install a malicious client also make OMEMO, OpenPGP and OTR useless.
pep.
labdsf, oh I agree
labdsf
And then, the server admin may be malicious and so on
pep.
yes
pep.
I agree OMEMO is just smoke and mirrors for most people
labdsf
Lets switch to twitter/mastodon and exchange messages in public only?
Kev
daniel: I don't think "It's not a security feature" is consistent with what labdsf is saying here.
Kev
If you're saying only omemo and otr as good enough, because gpg doesn't offer PFS, that sounds a lot like you're talking about security features.
daniel
Kev, i’m not agreeing with labdsf
labdsf
It is a security feature that protects messages against future device compromise.
daniel
i think the hint should be agnostic of what kind of messages you send
Kev
daniel: ok.
waqas
The problem here is that plausible deniability/ephemeral messages is not compatible with message authentication.
pep.
I also see that just as a UI/UX thing
pep.
Definitely no security involved here
waqas
GPG is mostly about trust/authentication.
labdsf
waqas: it is not about deniability. Though deniability and authentication are compatible, OTR does this.
waqas
Trusting end clients in the present (but not the future!) is a reasonable position to have, because you really can't do better if there is to be any trust/auth.
daniel
i haven’t seen a compeling argument against a simple `<you-might-want-to-delete-me seconds="60"/>`
labdsf
daniel: consider legacy clients.
labdsf
I want to be able to avoid sending ephemeral messages to legacy clients.
SamWhited
so check if they support it and if so send to the full jid
daniel
i don’t think you can be reasonably sure that the recipient will obey that hint no matter what you do
labdsf
That is the reason for OTR/OMEMO requirement and encrypting only for clients that indicate feature support.
labdsf
daniel: the recipient is trusted in my threat model.
SamWhited
Either way, with OMEMO or without, you have to check for support and send only to that client. You can do that with or without OMEMO.
labdsf
But it has a legacy client
SamWhited
Then it won't advertise support
labdsf
SamWhited: that is what I do for OTR
SamWhited
I know, I'm saying you have to do it either way, OTR doesn't add anything.
labdsf
With OMEMO, I can't map device keys to resources
labdsf
And full JID may be offline
pep.
labdsf> With OMEMO, I can't map device keys to resources
Yeah that's something I'd like
labdsf
pep.: it is impossible, device may connect with another resource next time
pep.
hmm, wait, no actually I don't need this
la|r|mahas joined
Nekithas left
labdsf
SamWhited: do you propose to ask all full JIDd for support of ephemeral messages and send them plaintext ephemeral messages directly if they indicate support?
labdsf
I think we are mostly moving to sending to bare JID only in chat clients. OTR is an exception, but is is mostly obsolete now.
SamWhited
Not really; I propose just making it a hint and letting clients and services deal with legacy clients however they see fit and maybe documenting some of these ideas
pep.
I'd just do like daniel says, send to all resources <please-delete-me seconds="60"/>, and if some support it, cool
SamWhited
But yes, checking for support and only sending to full JIDs that support it is one way of doing that
SamWhited
But yah, mostly I think clients should just do what daniel and pep. just said.
labdsf
pep.: and some will not support it, so it will be no more useful than snapchat
pep.
labdsf, sure
SamWhited
Define "useful"?
labdsf
"Can work reliably in at least on use case"
SamWhited
Good, then what pep. just said works reliably in the use case where this is not a security feature, it's just a fun convenience that lets you clear up messages that don't have any long term benefit if the users haven on-legacy clients.
SamWhited
non-legacy, even.
labdsf
SamWhited: but some will always have legacy clients
pep.
I'm not sure why you worry about those here
SamWhited
labdsf: yes, and that will be fine since it's not a security feature.
labdsf
Because I want a security feature, not funny snapchat-like feature
pep.
Good luck :x
SamWhited
That is the problem I have with this. This is not a security feature and never can be; at best it's security theater.
daniel
there are two use cases here. a) people building walled gardens on top of xmpp. b) jabber as the federated public ecosystem. in a) you are fine with a hint since you control all clients and servers anyways b) i expect only a tiny fraction of client implementing that. so if you limit this to clients that advertise support you probably wont be able to use that feature very often
labdsf
SamWhited: it is in a scenario where you have two users that trust each other.
SamWhited
labdsf: if you have two users that trust each other you don't need OMEMO because they can just trust that both are using clients that will support it.
SamWhited
Or you don't need this at all because you can just trust that they'll clear their history afterwards.
labdsf
daniel: i have defined these two use cases above. My XEP supports both. Your proposal is for walled gardens.
labdsf
If it is a walled garden, server advertises thst it supports ephemeral messages.
labdsf
It only federates with such servers.
labdsf
And only accepts clients that support this feature.
labdsf
That is a way to create a corporate network or snapchat.
Nekithas joined
labdsf
Then you can exchange plaintext messages with a hint.
labdsf
If you connect to the federated open network, this feature is enabled for OTR and OMEMO only.
labdsf
SamWhited: you need OMEMO in this case, because servers are not trusted.
pep.
Why? I trust my server because I'm running it, and my mom is on my server.
SamWhited
labdsf: that's fine; if servers are not trusted individual users can use OMEMO. If they are trusted, they don't. Just like normal messages.
SamWhited
That doesn't really have anything to do with ephemeral messages.
edhelashas left
edhelashas joined
labdsf
SamWhited: we can extend the spec with the ability to send plaintext ephemeral messages to full JIDs, but it will only work for online clients and require trusted servers.
labdsf
Ok, maybe you trust the servers and want to send ephemeral message protected with TLS only. Maybe if the user sees timer but no padlock, it is clear enough and nobody makes wrong assumptions. But what about offline clients?
j.rhas joined
pep.
what about them
SamWhited
Just let the server store it in MAM like normal. If you trust the client to do what's right then when it comes back online and fetches them it sees that it's expired and doesn't show it.
labdsf
pep.: they will not receive message
pep.
labdsf, they'll receive it when they reconnect
labdsf
pep.: no, if you sent to full JIDs
labdsf
SamWhited: MAM will not store them if you send to full JID
pep.
on prosody atm if you send to an offline fulljid, it'll be sent to other resources iirc
labdsf
And if you send to bare JID legacy clients receive it
pep.
labdsf, you really can't avoid legacy clients
pep.
One way or another they'll get the messages
labdsf
pep.: no if I use OMEMO
Chobbeshas joined
pep.
So.. legacy clientA suports OMEMO message, you send to clientB that supports OMEMO and ephemeral, clientB goes offline, gets to clientA, oops.✎
pep.
So.. legacy clientA suports OMEMO, you send to clientB that supports OMEMO and ephemeral, clientB goes offline, gets to clientA, oops. ✏
danielhas left
jjrhhas left
SamWhitedhas left
la|r|mahas joined
labdsfhas left
labdsf
pep.: clientA and clientB have different keys
labdsf
clientA will not be able to decrypt
pep.
When you encrypt with OMEMO you encrypt for every devices right
pep.
and since you can't associate deviceid to resource atm, you don't have a choice
labdsf
pep.: in my proposal you encrypt ephemeral messages only for devices that support them
pep.
So you also need changes in 0384?
labdsf
No
Chobbeshas joined
labdsf
It is published in a separate item
pep.
What is?
labdsf
The indication of ephemeral message support
pep.
How do you associate deviceid to resource
andyhas left
labdsf
pep., I don't. I publish an item that says "the device 12345 supports ephemeral messages"
pep.
:/
labdsf
just like XEP 0384 publishes a Bundle
j.rhas joined
labdsf
well, the problem with XMPP is that offline clients are not registered in any way and you can't ask their capabilities and so on
labdsf
that is why OMEMO added its own devices that register in PEP
labdsf
that is why I have to build on top of OMEMO
labdsf
OTR is possible to support only because it already requires both clients to be offline, but I would say it is pretty much unusable
pep.
So you'll never want to support OX
labdsf
pep., yes
labdsf
only in "walled garden" scenario
pep.
meh
pep.
But well I don't think there's a big use-case for this feature anyway
pep.
The way you want it
Andrew Nenakhov
I'm a bit late to the party, but my take on this is simple: ephemeral messages are a joke, I'd want an option to keep them even if remote party thinks not, e2ee has nothing to do with ephemeral messages and PFS is also silly and not needed
pep.
Andrew Nenakhov, yes, do read above for more context
doshas left
doshas joined
Andrew Nenakhov
Glanced it briefly.
labdsf
Andrew Nenakhov, just don't implement it in Xabber and no valid client will send ephemeral messages to it
Andrew Nenakhov
Remote party should not dictate me how I use my archive and device history.
Andrew Nenakhov
labdsf, if it comes to that I'll probably implement it to show support and let user choose to keep it anyway. 😈
pep.
Andrew Nenakhov, just to prove a point that's dumb :/
pep.
Even if I agree it's useless in the first place
labdsf
Andrew Nenakhov, ok, malicious clients are not part of my threat model
kasper.dementhas joined
pep.
labdsf, I'm still not sure how you'll distinguish between malicious and not
labdsf
I trust my contacts not to install malicious clients
pep.
Yeah, that's a bit far fetched, but ok
Andrew Nenakhov
Such features make no sense in an open environment.
labdsf
Andrew Nenakhov, that is why I changed the XEP to only work over OTR and OMEMO
labdsf
it makes it a "closed environment", because XMPP is just a transport in this case
labdsf
it does not store message contents etc.
Andrew Nenakhov
If you trust your contacts, why run the hoops with e2ee pfs and all other fancy buzzwords?
Andrew Nenakhov
If you make something a XEP you are no longer talking about something you can use with your trusted contacts.
labdsf
because I want to be able to tick the "keep messages in this conversation for 1 week", and if my contact agrees and does not revert it, then we are sure that messages are removed after one week
labdsf
no need to agree verbally and delete manually
Andrew Nenakhov
And if you are pushing it to become a standard, you can't protect yourself from 'malicios clients'.
labdsf
Andrew Nenakhov, malicious clients are *not part of the threat model*, I don't want to protect against them
labdsf
feel free to implement one
labdsf
this feature already works in Wire, Signal and telegram "secret chats", everyone is free to modify the client to keep messages
Yagizahas left
j.rhas joined
labdsf
telegram even has multiple alternative clients in Google Play, maybe some of them have this option to keep messages
MattJhas left
Andrew Nenakhov
Why push it as standard then? Just use some form of custom made client and be happy with it
labdsf
Andrew Nenakhov, I think it may be useful to someone else
Andrew Nenakhov
Daniel has said he did such forks several times
labdsf
Andrew Nenakhov, I think he did it for "walled gardens"
labdsf
Also, if nobody noticed, I have modified XEP to have a simple <ephemeral timer="..."/> element without contents.
labdsf
So it is not really different from what Daniel proposes
labdsf
(for the walled garden use case)
Andrew Nenakhov
If you want it to me useful for someone else then you can't dismiss security threats by simply saying 'they are not part of a threat model'
Andrew Nenakhov
*to be useful
labdsf
malicious clients are not part of the threat model of GPG, for example
labdsf
encryption is not broken because someone implements a client that twits every encrypted email it receives
Andrew Nenakhov
Because gpg does what it does and nothing else.
Andrew Nenakhov
You are trying to mix two things of different nature into one flawed protocol.
labdsf
Also, from XEP: "An XMPP client SHOULD NOT try to restrict the ability of the user to copy and forward ephemeral messages. Any such measures will give the user a false sense of security, but can be easily circumvented by using a modified XMPP client."
labdsf
no need to implement an option to log messages, everyone can just copy all messages into text file
labdsf
Andrew Nenakhov, how is it flawed?
Andrew Nenakhov
It is flawed because it mixes ephemeral messages with e2ee
labdsf
Andrew Nenakhov, that is the way to avoid sending messages to legacy clients
Andrew Nenakhov
They are orthogonal, and has been said
labdsf
In walled-garden use case plaintext messages are allowed
labdsf
Andrew Nenakhov, they are, but OMEMO is the only possible way to send messages to a subset of offline clients supporting this feature
Andrew Nenakhov
labdsf, just say 'legacy clients are not part of a threat model' and 'i trust my contacts not to send messages to legacy clients' :)
labdsf
i can't trust my contacts not to send messages to legacy clients because it is not implementable
labdsf
XMPP has no way to send messages to a subset of offline clients
labdsf
Signal has, for example
Andrew Nenakhov
Signal is a centralized proprietary shit and they can do whatever they please
labdsf
it may be, I just say protocol-wise
Andrew Nenakhov
You can do same within your own domain and own client
Andrew Nenakhov
> it may be, I just say protocol-wise
It is only possible because it is centralized proprietary shit )
labdsf
XMPP has no way to ask remote bare JID to get a list of devices
Dave Cridlandhas left
Dave Cridlandhas joined
labdsf
it has nothing to do with it being centralized or decentralized
labdsf
Andrew Nenakhov, also, Signal is not proprietary
Andrew Nenakhov
It is.
labdsf
in what sense?
labdsf
all clients and the server are actually open source and source code is even updated frequently
labdsf
it is just centralized
Dave Cridlandhas left
Dave Cridlandhas joined
labdsf
https://github.com/signalapp/Signal-Server <- server
labdsf
https://github.com/signalapp <- everything else
labdsf
AGPLv3 everything
labdsf
daniel, > i haven’t seen a compeling argument against a simple `<you-might-want-to-delete-me seconds="60"/>`
I have modified it in https://github.com/xsf/xeps/pull/666 to be basically a simple <ephemeral timer="..."/>
Andrew Nenakhov
Can you build signal server and send messages to signal users? No?
labdsf
The only question is how to avoid sending ephemeral messages to legacy (not actively malicious) clients
labdsf
Andrew Nenakhov, no, because it is centralized
Andrew Nenakhov
*build from source
labdsf
but not proprietary
Andrew Nenakhov
labdsf, and is owned by Signal. That makes it proprietary.
labdsf
:/
labdsf
not sure what is your definition of proprietary, the software is free
Andrew Nenakhov
You can license code under AGPL or whatever, but your own installation remains your own
labdsf
the infrastructure is "proprietary", ok
Andrew Nenakhov
Signal messenger is proprietary.
labdsf
ok ok
Andrew Nenakhov
Because it does not work without central infrastructure.
labdsf
it is federated inside btw
lskdjfhas joined
Andrew Nenakhov
Ok, almost 4am here
Andrew Nenakhov
Bye
marmistrzhas left
lskdjfhas joined
labdsf
I should probably remove "plaintext/encrypted" distinction where possible and make it more clear that OMEMO is just a way to avoid sending to legacy clients