-
tmolitor
how to proceed regarding pr 1248? https://github.com/xsf/xeps/pull/1248
-
tmolitor
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?
-
pep.
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
-
singpolyma
I don't think not recommended is it so much as not common
-
flow
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
-
pep.
singpolyma: and yet it was extremely common in the past no? But there's been a change in the last few years
-
singpolyma
Manually assigned resources are fine, but users don't really want to make up unique names for their devices usually
-
pep.
flow: makes sense
-
pep.
When do you know you can drop the resource? After SM timeout?
-
flow
pep., why drop the resource at all?
-
pep.
Ah wait
-
pep.
Ok I misread
-
pep.
And yeah I remember we do store the generated resource
-
flow
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
-
Zash
Is it best practice if all current clients pick something "Client.HCcg" and then use that forever?
-
MattJ
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
-
MattJ
Then there are conflict issues, which are thankfully less common these days
-
MattJ
But previously it was super common for people to have two clients kicking each other off in a loop
-
singpolyma
How do they guess your presence using only your resource?
-
Zash
singpolyma, `<presence type=probe to=fulljid>`
-
MattJ
Just iq or anything
-
tmolitor
does the server answer the probe on behalf of the client or the client itself?
-
singpolyma
Zash: and the server won't block that?
-
MattJ
I actually can't recall what full JID probes do, but an iq ping works just as well
-
singpolyma
MattJ: shouldn't inbound iq from non roster usually get a generic error that doesn't confirm or deny presence?
-
MattJ
Who should send that error?
-
singpolyma
I guess maybe not always
-
singpolyma
The client
-
MattJ
Timing makes it trivial to detect then
-
singpolyma
🤔
-
MattJ
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
-
flow
+ sometimes there may be good reasons an entity without presence subscription or in your roster send you an IQ
-
singpolyma
flow: but then you should know this good reason to allow it
-
MattJ
Sure, though usually the client should be able to determine that
-
flow
singpolyma, maybe. but it's easy to get this wrong
-
flow
how many implementations do consider roster/subscription state when doing message delivery receipts?
-
MattJ
This is a good question for someone to explore 🙂
- flow goes on an explores his bed instead :)