labdsfI 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
flowlabdsf, if you find the time, then maybe present an htmldiff
jubalhhas joined
flowfor 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
labdsfOk
labdsfI am afk now, will make a diff later
labdsfI 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.
SamWhitedThat seems like a premature optimization for a very niche use case; unless you know of a service that does this?
labdsfMaybe remove it completely
labdsfIt may be useful for MUC on a non-federated server
labdsfWhen you don't want to setup OMEMO MUC (which requires members-only chat)
j.rhas joined
SamWhitedah sorry, I see; I misunderstood what you were saying anyways
SamWhitedGoing 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
SamWhitedEphemeral 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
labdsfIn 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).
labdsfWith OTR, chats are full JID to full JID only, so you can ask the client whether it supports ephemeral messages or not.
marmistrzhas joined
labdsfWith 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
labdsfOTR 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).
labdsfSo there are two use cases.
kasper.dementhas joined
labdsfOne 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
labdsfThe 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
KevSorry, what is the issue with gpg and ephemeral messages in the device loss scenario?
KevClearly 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
labdsfMessage 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
labdsfIn the "open network" use case no server is trusted, so forward secrecy is required to have truly ephemeral messages.
SamWhitedThat 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
labdsfIt is a security feature as long as you trust your contact.
Neustradamushas left
Neustradamushas joined
pep.hmm, trust and security..
labdsfpep.: when you use OMEMO, you trust your contact not to leak the message contents by publishing it on twitter
pep.I don't use OMEMO
Link Mauvelabdsf, do you?
pep.labdsf, and mostly not I don't
SamWhitedIt's not though, if you trust clients not to ignore your pep feature advertisement you have to do that regardless of whether there's encryption or not
jubalhhas left
rionhas left
pep.labdsf, and mostly no I don't
j.rhas joined
Link Mauvelabdsf, encryption and recipient behaviour are two orthogonal concepts, one is technical while the other is social.
labdsfSamWhited: I trust clients that specifically indicate that they support the feature, the problem is legacy clients
labdsfWhen 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 MauveI 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.
labdsfSnapchat is not my usecase, I think I stated it at the beginning of the first discussion in standards ML.
marmistrzhas left
labdsfBecause in MUC that is not members-only users are not trusted.
pep.That was an example on social behaviour
labdsfOk, threat model for "open network" use case: contact is trusted, server is not.
waqasNote 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.
labdsfBut contact has a legacy client.
labdsfwaqas: if you want to log all messages, just disable ephemeral messages
Link MauveOr still log them, despite what the other party may want.
pep.But what happens when your contact sends you an ephemeral message
waqasYep, it's more fun to log them while having you think that we are not logging them
waqasAt the end of the day, you are trusting remote entities to not lie
labdsfpep.: if you have not indicated that you support it, the message is not ephemeral
pep.labdsf, that's the thing
labdsfpep.: 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
labdsfwaqas: lying contacts is not a part of the threat model
waqaslabdsf: lying servers aren't either?
labdsfwaqas: in "open network" use case the server is malicious
waqasThe server can always log without telling you
labdsfwaqas: that is why I say OTR and OMEMO must be used
Link Mauvelabdsf, 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.
labdsfLink Mauve: lying client is not a part of threat model
valohas joined
labdsfI do not consider lying clients
Link MauveThe server and the client can be considered a same entity in this model.
j.rhas joined
waqasI 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
waqaspep.: It's protecting against a future search warrant, where clients currently are considered uncompromised
danielIt'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
labdsfpep.: 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
labdsfpep.: 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"
danielpep., as the recipient you know that a certain messages is worth deleting at some point
danielfor example the sender slaps the delete hint on a password or something
labdsfSee, 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
labdsfAnd then, the server admin may be malicious and so on
pep.yes
pep.I agree OMEMO is just smoke and mirrors for most people
labdsfLets switch to twitter/mastodon and exchange messages in public only?
Kevdaniel: I don't think "It's not a security feature" is consistent with what labdsf is saying here.
KevIf 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.
danielKev, i’m not agreeing with labdsf
labdsfIt is a security feature that protects messages against future device compromise.
danieli think the hint should be agnostic of what kind of messages you send
Kevdaniel: ok.
waqasThe 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
waqasGPG is mostly about trust/authentication.
labdsfwaqas: it is not about deniability. Though deniability and authentication are compatible, OTR does this.
waqasTrusting 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.
danieli haven’t seen a compeling argument against a simple `<you-might-want-to-delete-me seconds="60"/>`
labdsfdaniel: consider legacy clients.
labdsfI want to be able to avoid sending ephemeral messages to legacy clients.
SamWhitedso check if they support it and if so send to the full jid
danieli don’t think you can be reasonably sure that the recipient will obey that hint no matter what you do
labdsfThat is the reason for OTR/OMEMO requirement and encrypting only for clients that indicate feature support.
labdsfdaniel: the recipient is trusted in my threat model.
SamWhitedEither 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.
labdsfBut it has a legacy client
SamWhitedThen it won't advertise support
labdsfSamWhited: that is what I do for OTR
SamWhitedI know, I'm saying you have to do it either way, OTR doesn't add anything.
labdsfWith OMEMO, I can't map device keys to resources
labdsfAnd full JID may be offline
pep.labdsf> With OMEMO, I can't map device keys to resources
Yeah that's something I'd like
labdsfpep.: 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
labdsfSamWhited: do you propose to ask all full JIDd for support of ephemeral messages and send them plaintext ephemeral messages directly if they indicate support?
labdsfI think we are mostly moving to sending to bare JID only in chat clients. OTR is an exception, but is is mostly obsolete now.
SamWhitedNot 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
SamWhitedBut yes, checking for support and only sending to full JIDs that support it is one way of doing that
SamWhitedBut yah, mostly I think clients should just do what daniel and pep. just said.
labdsfpep.: and some will not support it, so it will be no more useful than snapchat
pep.labdsf, sure
SamWhitedDefine "useful"?
labdsf"Can work reliably in at least on use case"
SamWhitedGood, 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.
SamWhitednon-legacy, even.
labdsfSamWhited: but some will always have legacy clients
pep.I'm not sure why you worry about those here
SamWhitedlabdsf: yes, and that will be fine since it's not a security feature.
labdsfBecause I want a security feature, not funny snapchat-like feature
pep.Good luck :x
SamWhitedThat is the problem I have with this. This is not a security feature and never can be; at best it's security theater.
danielthere 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
labdsfSamWhited: it is in a scenario where you have two users that trust each other.
SamWhitedlabdsf: 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.
SamWhitedOr you don't need this at all because you can just trust that they'll clear their history afterwards.
labdsfdaniel: i have defined these two use cases above. My XEP supports both. Your proposal is for walled gardens.
labdsfIf it is a walled garden, server advertises thst it supports ephemeral messages.
labdsfIt only federates with such servers.
labdsfAnd only accepts clients that support this feature.
labdsfThat is a way to create a corporate network or snapchat.
Nekithas joined
labdsfThen you can exchange plaintext messages with a hint.
labdsfIf you connect to the federated open network, this feature is enabled for OTR and OMEMO only.
labdsfSamWhited: 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.
SamWhitedlabdsf: that's fine; if servers are not trusted individual users can use OMEMO. If they are trusted, they don't. Just like normal messages.
SamWhitedThat doesn't really have anything to do with ephemeral messages.
edhelashas left
edhelashas joined
labdsfSamWhited: 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.
labdsfOk, 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
SamWhitedJust 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.
labdsfpep.: they will not receive message
pep.labdsf, they'll receive it when they reconnect
labdsfpep.: no, if you sent to full JIDs
labdsfSamWhited: 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
labdsfAnd 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
labdsfpep.: 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
labdsfpep.: clientA and clientB have different keys
labdsfclientA 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
labdsfpep.: in my proposal you encrypt ephemeral messages only for devices that support them
pep.So you also need changes in 0384?
labdsfNo
Chobbeshas joined
labdsfIt is published in a separate item
pep.What is?
labdsfThe indication of ephemeral message support
pep.How do you associate deviceid to resource
andyhas left
labdsfpep., I don't. I publish an item that says "the device 12345 supports ephemeral messages"
pep.:/
labdsfjust like XEP 0384 publishes a Bundle
j.rhas joined
labdsfwell, the problem with XMPP is that offline clients are not registered in any way and you can't ask their capabilities and so on
labdsfthat is why OMEMO added its own devices that register in PEP
labdsfthat is why I have to build on top of OMEMO
labdsfOTR 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
labdsfpep., yes
labdsfonly 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 NenakhovI'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 NenakhovGlanced it briefly.
labdsfAndrew Nenakhov, just don't implement it in Xabber and no valid client will send ephemeral messages to it
Andrew NenakhovRemote party should not dictate me how I use my archive and device history.
Andrew Nenakhovlabdsf, 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
labdsfAndrew 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
labdsfI trust my contacts not to install malicious clients
pep.Yeah, that's a bit far fetched, but ok
Andrew NenakhovSuch features make no sense in an open environment.
labdsfAndrew Nenakhov, that is why I changed the XEP to only work over OTR and OMEMO
labdsfit makes it a "closed environment", because XMPP is just a transport in this case
labdsfit does not store message contents etc.
Andrew NenakhovIf you trust your contacts, why run the hoops with e2ee pfs and all other fancy buzzwords?
Andrew NenakhovIf you make something a XEP you are no longer talking about something you can use with your trusted contacts.
labdsfbecause 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
labdsfno need to agree verbally and delete manually
Andrew NenakhovAnd if you are pushing it to become a standard, you can't protect yourself from 'malicios clients'.
labdsfAndrew Nenakhov, malicious clients are *not part of the threat model*, I don't want to protect against them
labdsffeel free to implement one
labdsfthis 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
labdsftelegram even has multiple alternative clients in Google Play, maybe some of them have this option to keep messages
MattJhas left
Andrew NenakhovWhy push it as standard then? Just use some form of custom made client and be happy with it
labdsfAndrew Nenakhov, I think it may be useful to someone else
Andrew NenakhovDaniel has said he did such forks several times
labdsfAndrew Nenakhov, I think he did it for "walled gardens"
labdsfAlso, if nobody noticed, I have modified XEP to have a simple <ephemeral timer="..."/> element without contents.
labdsfSo it is not really different from what Daniel proposes
labdsf(for the walled garden use case)
Andrew NenakhovIf 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
labdsfmalicious clients are not part of the threat model of GPG, for example
labdsfencryption is not broken because someone implements a client that twits every encrypted email it receives
Andrew NenakhovBecause gpg does what it does and nothing else.
Andrew NenakhovYou are trying to mix two things of different nature into one flawed protocol.
labdsfAlso, 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."
labdsfno need to implement an option to log messages, everyone can just copy all messages into text file
labdsfAndrew Nenakhov, how is it flawed?
Andrew NenakhovIt is flawed because it mixes ephemeral messages with e2ee
labdsfAndrew Nenakhov, that is the way to avoid sending messages to legacy clients
Andrew NenakhovThey are orthogonal, and has been said
labdsfIn walled-garden use case plaintext messages are allowed
labdsfAndrew Nenakhov, they are, but OMEMO is the only possible way to send messages to a subset of offline clients supporting this feature
Andrew Nenakhovlabdsf, just say 'legacy clients are not part of a threat model' and 'i trust my contacts not to send messages to legacy clients' :)
labdsfi can't trust my contacts not to send messages to legacy clients because it is not implementable
labdsfXMPP has no way to send messages to a subset of offline clients
labdsfSignal has, for example
Andrew NenakhovSignal is a centralized proprietary shit and they can do whatever they please
labdsfit may be, I just say protocol-wise
Andrew NenakhovYou 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 )
labdsfXMPP has no way to ask remote bare JID to get a list of devices
Dave Cridlandhas left
Dave Cridlandhas joined
labdsfit has nothing to do with it being centralized or decentralized
labdsfAndrew Nenakhov, also, Signal is not proprietary
Andrew NenakhovIt is.
labdsfin what sense?
labdsfall clients and the server are actually open source and source code is even updated frequently
labdsfit is just centralized
Dave Cridlandhas left
Dave Cridlandhas joined
labdsfhttps://github.com/signalapp/Signal-Server <- server
labdsfdaniel, > 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 NenakhovCan you build signal server and send messages to signal users? No?
labdsfThe only question is how to avoid sending ephemeral messages to legacy (not actively malicious) clients
labdsfAndrew Nenakhov, no, because it is centralized
Andrew Nenakhov*build from source
labdsfbut not proprietary
Andrew Nenakhovlabdsf, and is owned by Signal. That makes it proprietary.
labdsf:/
labdsfnot sure what is your definition of proprietary, the software is free
Andrew NenakhovYou can license code under AGPL or whatever, but your own installation remains your own
labdsfthe infrastructure is "proprietary", ok
Andrew NenakhovSignal messenger is proprietary.
labdsfok ok
Andrew NenakhovBecause it does not work without central infrastructure.
labdsfit is federated inside btw
lskdjfhas joined
Andrew NenakhovOk, almost 4am here
Andrew NenakhovBye
marmistrzhas left
lskdjfhas joined
labdsfI 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
XSF Discussion - 2018-06-17