XSF Discussion - 2018-06-12

https://www.schneier.com/blog/archives/2018/01/detecting_drone.html another nail in the coffin of stream compression. I totally missed that back in January

awesome

can we use that to decrypt and de-DRM HDMI streams?

"In other words, they can see what the drone sees," - seems like total bullshit

They can detect patterns within compressed stream (idle/rapidly changing), not the stream itself.

TLDR: If you suspect that drone is filming you, move rapidly and see if it transmits more

daniel, why do you say Conversations resources are not permanent?

when are they changed?

I am thinking about how to fix it in Gajim and it seems just writing permanent resource in config is not a good idea, because configs may be synchronized

labdsf: when a server provides me with a different one or if I'm logged out because of duplicate resource or not permitted to bind

that seems like a solution, thanks

just regenerate resource if it is duplicate

yupp

Except that a *sane* server will assume that the second bind is the same client, coming from a network change, and kill the old session.

I've seen plenty of server that will prevent your bind

Jabberd maybe?

daniel: yes, there are some servers that do that. No, it doesn't make it a good idea.

i think there is also an ejabberd config that will just give you a new random resource

at least i have seen that behaviour in the wild

there is also a prosody module for that.

In the Age Of MAM, this is not as bad as it used to be.

FWIW although I now favour clients requesting per-client static resources, I didn't mention what the server actually assigns them :)

is "there is a prosody module for that" the new "the simpsons did it"?

Old tho

MattJ: I'm interested in how you imagine the whole process to play out, then.

Is there any more to it than that?

Client should request a resource of <some installation-unique string>, it doesn't need to be what the server actually uses as the public resource for that session

MattJ: so you do assign another resource to the client? Do you expect the client to request the newly-assigned resource on next connection then? And re-assign again?

No, why would it do that?

I expect the client to always request the same resource

MattJ, if the server gives me a different resource in the bind response, I think I’ll use that resource from then onwards ...

Why?

See, you don't even have a coherent image of your idea.

Consider that the server's logic (as it typically is today) when that happens is "override the client's resource with a random one"

Why should that be a good idea, again?

Requesting the one the server assigns you will just get you a new different random one?

s/?$//

so why would you bother? Just request the one you want

MattJ, yeah, in that case, it doesn’t matter whether I try my configured resource all over again

but if a server allows me to stay consistent, I can have that

hm

I kinda see your point

I don't.

If the server overrides your resource once, it will again :)

why go through the hassle of updating the stored resource when it won’t work anyways

It *could* work if the server had a list of well-known resources for that account, and checked that for matches.

It needs that list anyway to kill your stale session on a reconnect.

You know, like above: Replaced by new connection (conflict)

It makes no sense to me that a client would store the resource beyond the lifetime of a single session

MattJ, yeah, nevermind on that one

Ge0rG, that old thing :)

re-rolling a new resource on <conflict/> makes sense though

except that <conflict/> doesn't make sense.

why not?

Ge0rG, if somebody copied their JabberCat config to a new machine and they connect it while the other machine is connected too, I get a <conflict/>

I need to handel that and re-roll the resource

jonasw: wait, your *old* session gets a conflict?

yes

Aaah!

(it doesn’t matter though)

(even if the new session gets a conflict)

jonasw: it does make a difference.

(A server could for example decide to let the new session conflict if it received a ping-pong just now)

jonasw: if your *new* session gets a conflict, it might be because the server still hangs on your old session.

but it's dead for all practical matters.

sure, but what am I supposed to do?

not connect until that session dies?

call the server hotline

or roll a new resource and be able to connect?

Hmm.... hide the error or show the error.

tricky question indeed

Somebody should re-do https://wiki.xmpp.org/web/XMPP_IM_Client_Design_Guidelines#Do_not_to_encode_any_semantics_into_the_resource.2C_let_the_server_generate_a_resource_for_you

Ge0rG: I think I've actually followed this page, and today people have a different song

goffi: I have hated that section, with a passion, for a long time.

But I'm not here for wiki editing wars, so I always hoped the original author would become convinced and change it.

Ge0rG, modify it!

that's why a XEP (or better a new version of the RFC) should be clear on the subject.

who is the origina lauthor

I thought it was MattJ, but it looks like not.

with a XEP there is a debate on standard, and council will arbitrate if there is any conflict.

goffi: there was a debate on standards, and we went home with multiple strong opinions.

*.xmpp *.split

so can somebody write some official proposal? As a client dev I don't really care which way is chosen to generate resource, but I would like to have a clear way and if possible some rationale to explain why.

I think jonasw volunteers for that 😁

goffi: the XSF traditionally isn't very strong at putting the rationale for protocols into its protocol specifications, and this one is 95% rationale.

Ge0rG, EBUSY

well the important is not the tradition here, the important is to simplify life for everybody. And I don't think it worth spending time and energy to know how to generate resource

goffi: the point is: this is not protocol, this is best-practices.

there are several XEPS for best practice already

so it might be a good informational XEP indeed.

yep

but then, as there is no consensus, and there are conflicting opinions, it's hard.

**on beatles music** All we need is specs, tadalala

Ge0rG: the council is here to arbitrate once all opinions have been exposed.

goffi: what if the conflict is among council members?

well let's solve problem when they come?

https://wiki.xmpp.org/web/XEP-Remarks/XEP-0045:_Multi-User_Chat#Matching_Your_Reflected_Message would also make a great informational XEP

And https://wiki.xmpp.org/web/XEP-Remarks/XEP-0045:_Multi-User_Chat#Am_I_still_there.3F as well

Also somebody should walk the wiki for all ML references made before 2016 and update the links

It may already help if a wiki page would list all competing proposals regarding resource handling. we may find out that there is in fact a way to reach consensus. (I thought we have consensus FWIW)

there is bind2.

And there is Zuul.

Zuul?

There is no Dana, only Zuul!

hehe, and the hidden Mozilla egg: http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul

https://twitter.com/w3cdevs/status/1006544269149077504 -- might be relevant for some european folks here

Yes, let's get some money to create more APIs to track web victims.

heh :-)

Ge0rG, I have found your slides btw: https://wiki.xmpp.org/web/Georg%27s_Talk_on_Message_routing

labdsf: yay! Feel free to give feedback

Or to feel embarrassed about it

via https://dev.gajim.org/gajim/gajim/issues/8971

Am I supposed to defend my position in there?

6121 also doesn't know about carbons, MAM, and four hundred other protocol extensions

Persistent resources in Gajim seem to be already fixed, just need to wait for it to hit the repos, closed the bug: https://dev.gajim.org/gajim/gajim/issues/9193

cloned the master, started testing and found that it wrote the random part into config

yeah gajim is improving a lot recently

Link Mauve: https://wiki.xmpp.org/web/Membership_Applications_Q3_2018

Ok, let’s do that now.

https://wiki.xmpp.org/web/Membership_Applications_Q3_2018#Applicants

Link Mauve: great :)

wooh

Q3 already..

Time flies

Yes :(

I will have to find my application

Or do a new one, wonder what...

But yeah, a year already!

damn me too