XSF Discussion - 2023-02-11

how to proceed regarding pr 1248? https://github.com/xsf/xeps/pull/1248

afaic council did not vote on that because of the pending SASL2 merge, but it seems it is not yet merged into the inbox, too, right?

Is there any document explaining why it's not recommended to reuse the same resource anymore (it isn't, right?) And/or why server devs would like this to be controlled by the server

I don't think not recommended is it so much as not common

best practice is to use a randomized (or server assigned) resource, but then re-use that resource for subsequent reconnects, as it, for example, improves the chances that you get stanzas that where addressed to this resource prior the reconnect

singpolyma: and yet it was extremely common in the past no? But there's been a change in the last few years

Manually assigned resources are fine, but users don't really want to make up unique names for their devices usually

flow: makes sense

When do you know you can drop the resource? After SM timeout?

pep., why drop the resource at all?

Ah wait

Ok I misread

And yeah I remember we do store the generated resource

to answer my question: one could argue that a malicious actor may learn your resource, so you may still want to rotate it once in a while

Is it best practice if all current clients pick something "Client.HCcg" and then use that forever?

If someone knows (or can guess) your resource then they can tell when you are online, which is considered a presence leak and something we have always tried to protect against

Then there are conflict issues, which are thankfully less common these days

But previously it was super common for people to have two clients kicking each other off in a loop

How do they guess your presence using only your resource?

singpolyma, `<presence type=probe to=fulljid>`

Just iq or anything

does the server answer the probe on behalf of the client or the client itself?

Zash: and the server won't block that?

I actually can't recall what full JID probes do, but an iq ping works just as well

MattJ: shouldn't inbound iq from non roster usually get a generic error that doesn't confirm or deny presence?

Who should send that error?

I guess maybe not always

The client

Timing makes it trivial to detect then

🤔

And timing aside, the client would have to be sure to send the exact same error that the server would send if the resource was offline

+ sometimes there may be good reasons an entity without presence subscription or in your roster send you an IQ

flow: but then you should know this good reason to allow it

Sure, though usually the client should be able to determine that

singpolyma, maybe. but it's easy to get this wrong

how many implementations do consider roster/subscription state when doing message delivery receipts?

This is a good question for someone to explore 🙂