XSF Discussion - 2022-04-26

jonas’: is that new XEP ephemeral itself, or is it just a broken link?

ralphm, thanks for pointing it out, I fixed it

(I had forgotten to actually deploy the new stuff to the server)

😉

FWIW: I think that the concept of ephemeral messages, with all the caveats in the spec, is a mis-feature.

why do you think so?

I think it's stupid too but you know it's the next "one thing (tm)" that XMPP is missing

i dont see this working ..

whats with the negotiation .. why?

it's ok all it needs to do is give people a false sense of security

every user should just choose when his messages going to be removed

signal has it after all

why negotiate something

lovetox: because any participant's message could incriminate any other participant (even without considering >quoting)

The falseness of security sense is up to client UI designers to dispell, I'd hope :)

No need to follow misleading ui of $super_recure_messenger

pep.: some wording feedback, I guess... Better late than never, lol > Provide a way to specify a timer value after which message contents must be deleted from user devices. 'Must' seems a bit too strong here, even not in all-caps. I think something along the lines of 'expected to be' or 'agreed to be' would convey the intention more precisely. > A way to securely ensure that logs won’t be kept by parties included in chats. I'd emphasize that _untrusted_ parties are meant here (iiuc)

mjk, that non-binding must is clarified in the implementation notes

Ok, I'll take a look

Or was it business rules

« Discarded messages shall be removed from memory and disk on a best effort basis. Timers do not have to be exactly exact, the definition of "seen" or "read" not being consistent, and clock issues might also be a thing (use NTP?). This is also a best effort basis. »

As for your second comment, hmm.

« § Security Considerations Ephemeral messages are not to be considered "secure" in any way. Even within well-meaning entities, requiring that messages be discarded and made impossible to retrieve, requires a lot more scrutiny in the specification and in implementations, and even then, is a really technically challenging task, to say the least. »

should you mention annoying things like apps preventing screenshots from being taken of them etc ?

I think that summarizes it

Yeah, so best effort. I just think it would be better to pre-iterate that in sect. 2, it being read one of the first

moparisthebest, no it's exactly what I don't want this spec to be

I think that's what "the signal" does

Read the security considerations

oh, well then that can be the next "one thing (tm)" preventing xmpp adoption

Yeah I'm not worried about that, there's always something :)

I guess I should put security considerations as the first section really.

:D ✏

With a "I read and it's ok I'm willing to continue" before the rest shows up

Put it in abstract!

who reads *that*?

The difference with Signal and WhatsApp are that they are controlled environments. And even then there are cases where a request to delete a message may fail to be honored. I really dislike the false sense of security it gives to the user. Federation, as with the open XMPP network makes this even less useful. ✏

But sure it checks a box 🤷

is this the right place to point out that not all XMPP deployments are federated or with free choice of apps used?

ralphm: I don't fully agree. There is nothing that prevents you to use XMPP in a controlled environment.

^5 Guus

we're on a roll today, jonas’

Isnt the "false sense of security" up to the client? No user is gonna read the XEP. So its up to the client to make it clear. And implement it or not. I mean clients choose to implement or not XEP all the time. Plus there are a lot of XEPs that are tricky to implement due to the extensibility of the protocol like MIX or the new OMEMO. Doesnt mean its not worthwhile

Yes, iff you have a fully controlled environment, including the federation part, then yes it may work. I still think it is not great. Screenshots, photos of screens, etc.

right, but *that* is definitely outside the XSF' scope

(screenshots etc.)

so I'd say we go for a spec even if it never ends up in the compliance suites or somesuch because of the inherent issues with federation

I think it is much more useful to tell users: as soon as you hit enter, you can no longer trust that your message will not end up in places you don't want them.

I don't agree

But having a single spec for the intent is better than everyone reinventing the wheel, badly.

I get what you're saying, but I have issues with so-called secure messaging systems. They generally fail to communicate the full picture. Whether something is secure depends on your threat model.

Then again all I'm reading here is "I haven't read security considerations"

Scroll back to my first message

"I still think it is not great. Screenshots, photos of screens, etc."

:/

(19:18 UTC)

Yeah but you're still talking about screenshots, and that's not related to this spec

It is, people generally don't understand technology. If you present them with a feature that says that says 'delete for all users', or 'this message will self-destruct in 10 seconds', it makes a promise you can't keep.

Anyway if this doesn't go through with the XSF, again, I'll host it somewhere else so that it can be implemented anyway because yes that's a feature people want so maybe someday we can answer the demand instead of staying in our little enterprisy world

My context also includes vulnerable users. Like young teens.

pep.: I'm not objecting to the spec, I'm objecting to the feature. That's not on you. Again, having a spec for a feature I don't like is better than not.

Sorry this wasn't really clear because it's been rejected for this exact reason before as well

ralphm: re. false sense if security. What sense of security is meant here, exactly? When you trust your contact and their opsec practices, trust the client software used by both of you and use verified-key e2e encryption, what remains to trust here? Security of secure deletion implementation? I think this is a (major) point that should be conveyed clearly by client devs in the ui. Like, what exactly is the deletion impl. ✏

But anyway, I'm happy with the feature as it is now. I mean there,s lots of technical holes that I'd like filled, and I need feedback on this, but otherwise I'd be happy that progressively people stop logging stuff forever

Maybe the issue is the name, because there are expectations from other messengers

mjk, a very common usecase is to think you can trust your contact but then it turns out they were the attacker all along.

(Even though a client doesn't have to reuse this name obviously)

mjk: my PoV includes people that cannot make such determinations, because they are a-technical or don't have a developed pre-frontal cortex.

Link Mauve, in this case it's not a technical problem it's a social problem and no amount of technicality is going to fix this

Link Mauve: that shoud apply to communications in general, not deletion specifically :)

Yes to both.

But when you make automated deletion an advertised feature, people will tend to use it in cases where it is ill-suited.

"don't have a developed pre-frontal cortex" what

The usual nude that will be deleted ten seconds later, which then gets posted widely to the Internet.

ralphm: fair. :) A sufficient barrier to entry might mitigate this concern, like having to go install a plugin or enable a well-hidden feature...

Link Mauve, where is it ill-suited to ask the other client to delete your nude? It's only unfortunate that the other client doesn't ""support"" it

You may have done it anyway if deletion wasn't advertized

Ask kids who use snapchat

I only know dealers who use snapchat. ^^'

"hey kid, wanna see some real free software?"

Anyway, of course UX is important, and I'm not sure why I'm answering on security concerns here when the whole point of this spec is privacy. Have the client find a way to present it to the user as a non-security feature

Even just to have all your clients follow the same logging policy I think it's worth it

Couldn’t that be a PEP node which configures that, if you want to change the logging policy?

I don't want to change just mine

Or pretty much any policy which should be synchronised between clients.

> Have the client find a way to present it to the user as a non-security feature Like, e.g., Conversations does for years in file deletion modal dialog

im on the side that XSF should not care about "Users"

What does this mean exactly? Even though I don't think I agree whatever this means :P

The way should be Users tells client dev wishes -> Client dev tells XSF protocol needs

XSF is not here for Users, and is not there to shild and protected users from bad client devs

otherwise you need to remove all XEPs ever

It's not here to "shield users from bad client devs" no, whatever that means, but it's here to answer user's expectations. When something is wanted by users in the community, the XSF should probably get onto it

Users = Users of Clients

Sure

no, sorry, they dont usually come here and tell what they want

The XSF doesn't live in a vacuum

they create issues on client developer issue trackers

Users dont care about xml which is sent here and there

Many users gravitate around here, and many people gravitating aroudn the XSF are devs and are able to report user expectations. And I think the XSF should hear this and react.

no pep. there is handfull of users of thousands here in the chat

"and many people gravitating around the XSF [..] are able to report user expectations"

correct, client / server devs report users expectations for features, and XSF makes protocol

So we're saying the same thing?

I do think the XSF should care about users. Of course users don't care about the ways it goes on the wire and that's fine

the job is to make a protocol, maybe write down common pitfalls and requirements

> im on the side that XSF should not care about "Users" If anything, I think this is rather an argument _for_ not against the advancement of the xep at hand :3

but not to say: Uh we are federated, im not sure 100% of devs implement this 100% secure

so lets not even start to make a protocol

lovetox, yeah but XEPs aren't made in vacuum either. They answer a demand

yeah for sending xml over networks, not to make sure users are not mislead by clientand serve rdevelopers

I don't understand what you're answering to here

to the common answer about epheral messages: Uh but what if client X does not delete the message

I guess I understand you're defending the spec? But it's still a weird position to me

yeah its none of your business

*XSF

because what if servers store messages although user deactivated it in archiving preferences?

what if server routes message wrong altough RFC says otherwise

what if client does encryption wrong, altough XEP says otherwise

like i can make a million errors as developer

for none of them any one in the XSF would held be responsible

Well again, no. The XSF isn't of course responsible of everything devs do, but it should ensure the document it produces are understandable and warn users about common pitfalls, as you said above. And if it's still not clear / hard to do, I'd say the XSF could point to example / reusable implementations

yes, describe whatever is needed

Great we agree about this. I still don't agree that the XSF shouldn't care about users. Of course it should. XEPs aren't written just to be pretty (at least I'm not hanging any framed on my walls), they're written to serve a purpose and answer users demand.

with care about users i meant, caring in a way parents care, "i will not publish this XEP because i fear you are not able to comprehend the implications"

the argument against this XEP is always the same, BUT what if one client does not respect the deletion wish"

and i think its not really a useful argument

Note that I'm not trying to argue against my own spec here. I think the spec AND the feature are fine as it is and it's possible to implement it in such a way that it's not misleading. PLUS, users are demanding such feature so it's about time we start doing something about it

well said

As council I'll pass the spec if it's sound from a technical perspective

As moparisthebest I'm definitely publishing patches for all clients that implement this to claim to implement it but never actually delete anything >:)

pep.: the brains of kids till the age of 23 are not fully developed. This causes them to generally be unable to properly oversee the outcomes of their actions.

ralphm, so we should be good parents and prevent them from using their phone? instead of telling them it has to be used with caution?

pep.: correct

..

Yes, children should not have phones.

And teach them that once you send anything over the internet there is no pulling it back

What have I started

Ok so I guess we should also remove old people's phones because they don't know how to use them

pep.: I don't know if you have kids yourself or in your extended family, but yes this is a difficult trade-off.

And maybe we should also remove poor people's phones because they've got less time to fiddle with them and they are less used to them, they're not getting much training

What else

If you don't know how to use something you should indeed not use it

moparisthebest, I disagree

You should be able to receive proper training

Absolutely, gotta take the initiative and time to learn though

"don't let kids into the internet, they make it dumb!"

(-er)

moparisthebest, I agree it's really hard nowadays when all we're doing is work in bs jobs..

Folks, is fine to review user expierence but I dont think such a meta discussion helps this topic

Internet has many bad ibfluences to people. lets stop with real-time communciation?

Disagree

emus, yeah definitely, way to go :)

^^

I don't think anyone said that, my point was simply that people should understand the tools they use, it's dangerous not to

I think people should be given the chance to learn the tools they use, rather. I prefer this wording because yours dangerously makes me think that you'd want to limit people who have access to these tools

Nope I fully agree with you

Encourage them to learn their tools even

I tend to think the same

And we're back to good (=educational) UI :)

That's prerequisite yeah (though my comment was a lot more general about society :P)

I think it is very useful to discuss these things in this forum. And yes, the world isn't perfect. I personally have tried to teach my teen daughter about the dangers of putting information out there, e.g. on Instagram, Snapchat, etc. She generally understands, but also it is very hard, if not impossible, to make the 'right' judgement calls. Besides lacking the part of their brain responsible for such choices, there are also things like peer pressure and what is considered 'normal'. So she will get it wrong sometimes and I just hope that it'll work out reasonably well. That all said, this doesn't mean that we should just throw up our hands and blindly implement things. Having an opinion on whether a feature is the right thing to do, is just ok. And we can disagree. But the discussion itself is useful.

I missed the beginning. but as there is a proto-xep people can implement it regardless of our discussion right?

emus: https://xmpp.org/extensions/inbox/ephemeral-messages-v2.html

The great thing about XMPP is that yes you can generally do what you want

There is a protoxep. People can't implement it just yet because it's not technically complete and I was hoping for this step to get feedback, because I haven't managed to get technical feedback on this before.

moparisthebest: yes I know the xep, but thanns

pep.: ok

(That is, I actually got feedback nowhere.)

pep.: Technical wise I'm not sure the reason for https://xmpp.org/extensions/inbox/ephemeral-messages-v2.html#example-3

understood

Sorry I didn't really get into the protocol itself. I hope you can appreciate my input anyway.

Or the "they will expire in X from now on" language

thx, but gn8

Shouldn't each message just have it's own individual timer and that's it?

moparisthebest, it's to reflect changes when there's an action in the UI. userX configures it as timeX and userY sends new message with timeX

Also makes the strange <i-want-out/> thing go away, but I might be missing a reason?

The time is per message though? Shouldn't each message just have a timer?

i-want-out is because I have no clue how to do, see the TODO

Please help.

Imho get rid of all that and simply send an "expires after" per message?

Getting rid of the negociation is kinda changing the idea of the spec isn't it

I want to implicate users around me when I do this

I'm not doing this in isolation. I don't just want my messages to be erased, I want my circles to also benefit from this

Unclear what you mean

hmm, which part

What are you missing simply by saying "please delete this message after X" sent per message?

Is it still about the implicit timer thing?

And, maybe something in disco hinting they might do it

Yea that part is confusing to me, seems needlessly complicated

Ok remove the implicit timer thing, I feel there's something more that bothers you but I'm not sure what

Is it not clear why I need a way to opt-out (once I've opted-in)

I'm saying don't have a way to opt in or out

Just a TTL per message only

Maybe you're missing the point of the spec?

(naively asking)

Or maybe you're right but I don't see it

"This specification encourages a shift in privacy settings wrt. logging policies."

I might be that's what I'm asking

I'm not aiming at this being just an isolated user wanting their messages deleted

Wait is the TTL not actually per message but modifies a per conversation setting?

Yeah the TTL isn't per-message, it's per-"chat"

Well, "per-chat-from-now-on"

That sounds like it should be in pep then no?

Not sure how to call that

Which PEP?

of the two person in 1:1

Like a public user setting for their contacts?

And if they're not in my contacts

and in MUC?

Please delete all my messages after X

Read the spec, this question is already in there

This can't even work in a muc

why not

At least not a public one

If not I'll make it work

That's a social issue

technically it works

Because you are pep. Now doesn't mean the pep. Who sends the next message is you

I'm not sure what you're getting at ✏

I don't have your jid

Why is that needed

What about instead of all this complicated state management you simply send a TTL per message?

Seems like the same result, and servers could expire from mam, and you don't need to figure out opting out and all that?

Well I'm doing this, but not really. The negociation is so that all participating clients behave the same way (if possible)

Imagine I don't negociate and only I send the TTL. Does that mean I'm going to delete messages I receive from the other as well because I care? What about messages that the other sends that's logged on their device?

I mean keep the disco feature, but then simply send a TTL per message

So the disco feature would mean what

If they send a TTL then you delete it, if not, your choice

disco is just a pinky promise that you intend to honor the TTL on this client

"moparisthebest> If they send a TTL then you delete it, if not, your choice" yeah and that's not the spirit of the spec

I don't understand how that changes anything

I want this to be a timer for the conversation (on all participating-and-implementing devices), not for one message

That seems overcomplicated with no use cases not covered by per message TTL ?

Basically what I hear when you say this is that user will have to go enable the thing themselves

I mean,

They'll have to somehow learn about the thing and enable it maybe. Basically only nerds will enable it

It can be a default, or you can suggest the client sets the TTL for their outgoing messages to the first one received?

Whereas if all participants in a chat agree on it, that's all the more people that are made aware of it (dialog or status message or whatever)

I have to admit I'm also not clear on why it's best as a per-chat thing, but I think there's an important difference

To me this reads like a complicated state machine where you have to read all messages in order to figure out when to delete each message

Considering sometimes you read mam backwards or have holes, that seems bad

Where as a per message TTL gives you the same experience but is stateless

I agree that does complicate things but it's also not the same goal.

And if there's a way to answer this technically I'd be happy to know

You can keep the same goal with a per message TTL though right?

Well I'm not sure no

I *think* I understand your goal now anyway, I didn't initially

Basically keep the spec the same, but you don't store/calculate TTL seperately from the messages

Tbh if there could be like, one PEP node negociated for the current chat, that might make things a lot easier..

You can still use the last messages TTL to show the user and send in your next message etc

"You can still use the last messages TTL to show the user and send in your next message etc" well in practice that's what happens

The difference being you don't need to replay all history in order to calculate current TTL, only look at the last message

You don't "calculate" the TTL, it IS sent with every message

it is?

ATM it is yes

it is.

Anyway.. This protoxep is less of a "hey I know what I'm doing I exactly want this" it's more "I have these goals, how do I achieve them plz"

And I didn't find a way to get feedback before the protoxep so here it is..

What do you do if you send me a message with the ephemeral tag and I respond without one?

If you don't implement the feature then so be it. Otherwise you should send the same back

And "so be it" if you don't do it anyway

I can't control your client

I mean, is that your cancel mechanism?

"Well they don't want me deleting their messages now" ?

That's where I'm stuck :/

How do I opt-out once I've opted-in

I'd vote either that or a TTL of 0

But if code has to handle both the same don't bother with both

"that" isn't good I guess ✏

Because any non-implementing client would make me stop the TTL

When MAM and stuff

So there needs to be a <thing/>

And it needs to be seen.

if one of your contact's clients doesn't implement the xep, you shouldn't treat no-ttl as i-want-out, so zero ttl sounds sane

ttl=0 seems like a hack, but yeah that's the idea of the <i-want-out/>

Shouldn't non implementing clients make you stop though?

Maybe @timer should be Option<u32>

I mean UI should indicate the other client won't listen anymore

moparisthebest, no, same problem as usual

Yes

That's specified

I don't think 0 is a hack, a real TTL of 0 makes no sense

Non-implementing clients shouldn't make anybody stop from using specific features because MAM and the like

But that's annoying I get it

a hack in the sense it's a sum type? like option<u32>

If you expect your messages to me to be deleted and I suddenly tell you I won't, you certainly shouldn't keep sending assuming I will

moparisthebest, so we started chatting both with supporting clients, we agree on a ttl, you've switched clients for 2 messages and it doesn't support the spec, you afk but I keep sending you messages. What should I do?

Do I stop sending you ttl'd messages?

Do I send two different messages to your fulljids? :P

also, with mam, any non-implementing client can retrieve later and store forever. that's always a possibility

Yeah, any client you own I don't know about can read these messages. So I'd rather wait for an explicit "nope" than something that can be misunderstood for "I don't implement it"

pep.: Yea you stop sending them if you need them deleted

Well that's not my spec is about ✏

In your example in the xep they'd respond like "hey you switched to a client that won't keep this private can you switch back?"

"Abstract This specification encourages a shift in privacy settings wrt. logging policies."

It's fine if a message isn't deleted

Same as when you are having an OMEMO conversation with someone and they suddenly send a few unencrypted

This isn't a security spec

If you aren't trying this spec is useless

This isn't even some strange edge case, it needs covered

No because there's no way I know about clients you haven't even told me yet that are going to have access to MAM

And I'm not going the way "then don't store in MAM"

Because I want clients to still be usable

fwiw that's what the old version was doing

You can't because then you are back to not working on iOS

> In your example in the xep they'd respond like "hey you switched to a client that won't keep this private can you switch back?" I agree that this would be in line with 'best effort' nature of the spec

This isn't technically possible

Or it is but you're willing to go to lengths this spec isn't, because it's not the goal

i mean, it's up to implementation to notice and warn the user

If you wanted to try real hard you'd require encryption and sign the promise with keys and only encrypt to keys that promised ?

Yeah but I'm not doing that

I just want to change the default storing policies in clients but no implementation will follow me because for some reason I can't understand they all like their logs

mjk: yes exactly, and I think the implementation then has to show the same warning for "I opt out" and "they aren't sending it anymore" no pep. ?

(I also do have logs on my poezio and I don't understand why, it's useful sometimes, ok, but not really important)

You can continue sending ephemeral in your messages of course

pep.: I have the solution for that

"If this includes sending to non-supporting clients, and they can be detected, sending clients SHOULD warn the user in some way. Clients MAY warn users anyway if non-supporting clients cannot be detected (e.g., when they don’t get a directed presence)."

In the spec ^

I have my conversations set to delete all messages older than a week, not because I want to, but because the database is too slow with too many messages lol

Maybe I should change that to "You never know what new client is going to have access to MAM so you should warn anyway."

moparisthebest, :D

pep.: right so then how does "I opt out" differ from "I have a different client that won't do it" if you show the same message to the user?

I don't think it does, therefore not getting it should be your opt out message

When a client says "I opt out", the receiving client can show a status message or something

"TTL has be removed"

It should show the same if they switched to a different client?

Show the same what?

TTL hasn't be removed for a non-supporting client, it was never supported

The result is the same

The result is the same, but I'd warn in different places

In both cases they know their contact won't delete the messages

The non-supporting client might have been listening all along and that's fine

Yes

Because they've been told when activating the feature

> "If this includes sending to non-supporting clients, and they can be detected, sending clients SHOULD warn the user in some way. Clients MAY warn users anyway if non-supporting clients cannot be detected (e.g., when they don’t get a directed presence)." > In the spec ^ okay, I admit I don't usually read through the entire discussion subject :D

Then I'm back to why have an opt out at all

If you aren't going to show any special warnings

I just told you I would

(?!?!?)

> Because they've been told when activating the feature

You said one warning at the beginning is all?

And pep.> When a client says "I opt out", the receiving client can show a status message or something pep.> "TTL has be removed"

And it should show the same when receiving no TTL at all...

No

Well I don't think so

It's the same effect

In one case the user has been warned that there might be non-supporting devices receiving this. In the other case a client has explicitely asked for the feature to stop. Yes in both cases messages won't be deleted, but no it's not the same thing

> it's not the same thing because there's probably a conscious human decision behind the latter

Maybe they explicitly switched to the unsupporting client?

I don't think they have a meaningful distinction

Maybe they did, and maybe they'll tell the sending client to stop, like in human speech

That's a thing also :P

Whether the client wants to merge UI for this is ok, but protocol-wise I'll keep that different

It'd still be weird to me that these two are merged

I think it's dangerous to allow them to handle it differently

Because inevitably someone will, and that'll be wrong

Well say we handle them the same way

That means as long as not everybody implements it, we can't use the feature ✏

This is introducing a nullable Boolean into the spec

And saying "treat null the same as false"

Instead of just making it non nullable

Yeah no sorry I don't want to live in a maybe monad

> That means as long as not everybody implements it, we can't use the feature I'm not following

The client behaves the same either way

If every time you switch devices my client stops sending the TTL, I'm gonna have to reenable it when I know you're on a supporting client. That looks like a pretty shitty user experience to me

I'll probably stop using it before I even start ✏

As I said this spec isn't a security spec

> If every time you switch devices my client stops sending the TTL, I'm gonna have to reenable it when I know you're on a supporting client. Don't do that! Keep sending it

wat

Ok I didn't get what you mean then

Like you said mam and other clients might come back online etc

So what changes

Both clients might have been listening all the time. Because suddenly you decide to write from the other shouldn't change anything to me ✏

Right, other than you warn the user that they won't be deleting them now

"now"?

Both clients were listening from the start

The sending user has been warned already

Ah, the receiving client may not delete these messages though.. because they don't include the TTL.

Is that another issue or is it what you were pointing at for all this time

I mean..

The client receiving non-TTL'd messages