XSF Discussion - 2024-03-07


  1. Daniel

    What's the process for becoming editor again? Do I need board approval?

  2. Daniel

    @board please decide on me becoming an Editor

  3. Guus brings out the moose antlers, honey and oven gloves.

  4. Daniel

    > You could mention occupant-id Done. https://gultsch.de/files/xep-0333.html

  5. lovetox

    👍 great thanks

  6. lovetox

    Daniel: about avatar conversion. Why open?

  7. Daniel

    lovetox: because vcard is open

  8. lovetox

    Ah I thought for a moment my roster contacts cannot get it then if it's not open

  9. lovetox

    But they would use pub anyway

  10. lovetox

    But would it not anyway simply better to write into the exp that pubusb model needs to be taken into consideration

  11. lovetox

    Then fixing it to open

  12. lovetox

    Than fixing it to open

  13. Daniel

    I mean it kinda said that. 'clients should put up appropriate warnings' or something. But that didn't pass Last Call

  14. Daniel

    Fwiw conversion only if access model is open is what prosody has been doing since always

  15. lovetox

    What I mean is that a legacy client which supports only vcard can not get my vcard anymore

  16. lovetox

    Because you forbid the conversion with this xep

  17. lovetox

    Although he is in my roster

  18. lovetox

    And has subscription

  19. Daniel

    Yes and no. It means that if you don't want to make your pep node open you can not use the xep

  20. Daniel

    And have to publish your vcard separately

  21. lovetox

    I see no reason for this limitation

  22. lovetox

    It's also not implemented in servers that way I'm pretty sure

  23. lovetox

    Servers take into consideration the pubusb access model. And I see no reason why this is something bad.

  24. Daniel

    What you are describing means that I'm denying access to the vcard for people who have previously been able to access the vcard

  25. Daniel

    Just because this conversation xep is active (and my avatar Pep node is not open)

  26. Daniel

    I find that odd. That's not something the xep should just be able to do

  27. lovetox

    i thought thats exactly what you do here with that open clause

  28. lovetox

    i have a roster contact, with a legacy client, he is able to view my vcard, furhter he is able to see my pep avatar because it set to "presence"

  29. Daniel

    There are two possible approaches. A) Check on access of the vcard b) check when uploading the pep avatar

  30. lovetox

    now i activate this XEP on the server, suddenly all my legacy roster contact lose access to the vcard

  31. Daniel

    No what ever has been in the vcard before stays there

  32. Daniel

    It's just that the conversion isn't happening

  33. lovetox

    thats madness in my opinion

  34. lovetox

    like .. no indication for the client if a conversation on the server happens or not

  35. lovetox

    did you talk with server implementations if this is really implemented that way?

  36. lovetox

    that they have two storages and have conversion process going

  37. lovetox

    as i understood it they store the pep avatar in pep storage, and convert on demand and checking the pubsub access model

  38. lovetox

    there is no second storage, which means this XEP would force them to add a second storage, and then different things could end up in both storages?

  39. lovetox

    maybe some server implementors can give a feedback here, but sounds all very not nice to me

  40. Daniel

    > there is no second storage, which means this XEP would force them to add a second storage, and then different things could end up in both storages? Im under the impression that this is pretty much what is currently happening

  41. MattJ

    IIRC we just have one storage, yeah (PEP)

  42. MattJ

    I can check in a bit when I'm at my laptop

  43. lovetox

    ok, so what the XEP says MattJ, is now you need a second storage, because the conversion is only allowed under certain conditions, and Daniel exepcts clients to publish a avatar separatley to the vcard storage in these cases

  44. lovetox

    My opinion is the XEp should simply say "When answering Vcard Avatar requests, the pubsub model must be taken into consideration"

  45. lovetox

    it bolts basically a access model on top of the avatar field inside a vcard

  46. pep.

    Well there's a single storage if you use the vcard4 and vcard_legacy modules because that's what they use? the "vcard" module used something else right?

  47. MattJ

    Right. There is no conversion at all then, though.

  48. Daniel

    > My opinion is the XEp should simply say "When answering Vcard Avatar requests, the pubsub model must be taken into consideration" I think that's a valid approach. However it's not the approach this XEP has taken (which I belive reflected what implementations have been doing)

  49. Daniel

    In that case the xep needs to be retracted

  50. Daniel

    In favor of a 'answer vcard requests by mixing in PEP information' xep

  51. lovetox

    is this not an overreaction? the xep does not mention pubsub model in its current form, now server implementations added the sensible privacy feature that if a client publishes to PEP, the vcard request adhears to PEP access model rules, As the client and user would expect when setting the PEP access model.

  52. lovetox

    why would this not fine with the current form of the XEP?

  53. Daniel

    What I can tell you is that the xep in the current form didn't pass Last Call

  54. lovetox

    ah ok it was rejected, and they wanted you to add this?

  55. lovetox

    sorry didnt get the history

  56. lovetox

    anyway i think i said enough, i give others the possibility to state their opinion

  57. Daniel

    I think both 'copy' and 'feed from the same source' are valid approaches. This xep is build around the copy idea

  58. lovetox

    last sentence from me: The implementations currently in the wild work *good* as a client dev i didnt waste time on this topic in a long time, it simply works. Please lets not make it worse

  59. edhelas

    https://github.com/fabiang/sasl/issues/12#issuecomment-1983224432

  60. edhelas

    The last question is actually valid, the "ordering" of the list is I assume alphabetically ?

  61. MattJ

    https://xmpp.org/extensions/xep-0474.html#hash

  62. MattJ

    > Note: All sorting operations MUST be performed using "i;octet" collation as specified in Section 9.3 of RFC 4790 [9].

  63. singpolyma

    If i understand correctly i agree with lovetox vcard conversion with single storage and you get whichever things access model says you can get. But also it's all for legacy anyway so I'm not super worried since the only place i still use vcard anything is much avatars

  64. singpolyma

    If i understand correctly i agree with lovetox vcard conversion with single storage and you get whichever things access model says you can get. But also it's all for legacy anyway so I'm not super worried since the only place i still use vcard anything is muc avatars

  65. Daniel

    I should point out that, even though both approaches are valid, they both have their own quirks. If you suddenly start doing access checks on vcard access - and leave your pep access model at default - you will break vcard access through muc

  66. Daniel

    Which is as you correctly point out the primary place where vcard is still used

  67. singpolyma

    Is that not true either way? If avatar is not open MUC should not see it. Unless you simehow have presence sub with a MUC 😉

  68. Daniel

    there are minor differences between the two

  69. moparisthebest

    That's solved by the "set a different vcard per muc" XEP that someone still has to write

  70. MSavoritias fae.ve

    why does it have to be that specific and we cant have instead a generic permission model that you can pick the entity to expose a specific vcard to?

  71. MSavoritias fae.ve

    or wait this is another limitation of vcard?

  72. moparisthebest

    Write it and find out! 😁

  73. MSavoritias fae.ve

    lol if nobody else gets around to that by the time i need to implement profiles in my library/app sure :P

  74. Daniel

    fwiw my goal is to get a XEP that is seemingly widely deployed https://compliance.conversations.im/test/xep0398/ and part of the compliance suite out of the deferred state. not write a different xep that fixes all of our avatar related issues

  75. moparisthebest

    For sure, that's what I meant with my comment, other avatar problems are better solved with other XEPs

  76. singpolyma

    I think the only concern is speccing what is deployed and not something incompatible

  77. Daniel

    yes I think we need clarification on what servers are doing. I was under the impression that prosody is doing what the new draft of the XEP says. due to comments like this: https://github.com/iNPUTmice/Conversations/issues/3289#issuecomment-441433477

  78. Daniel

    OK. I read some source code and I guess I was mistaken

  79. Daniel

    Probably best to retract the xep then

  80. singpolyma

    Why not just edit it?

  81. Daniel

    I think the entire premise is different to what prosody implements

  82. singpolyma

    I doubt it's entirely different, but even if so can we not just make it say the ridht thing instead of having yet another dead duplicate numberM

  83. singpolyma

    I doubt it's entirely different, but even if so can we not just make it say the ridht thing instead of having yet another dead duplicate number?

  84. singpolyma

    Are we not just talking about wording for security considerations? I'm not sure how it's so different

  85. Daniel

    I don't think we are just talking about security considerations

  86. MattJ

    My understanding is that the main purpose of the XEP, like the bookmark conversion ones, is to define a feature so that the client knows if the server implements automatic conversion

  87. MattJ

    Otherwise the client might decide to duplicate info between vcard/PEP "manually" to keep them in sync

  88. singpolyma

    Does any client actually do that?

  89. Zash

    or use only the older thing

  90. MattJ

    No idea. Servers have implemented conversion for some time AFAIK, so it may be deemed unnecessary these days for sure.

  91. Kev

    Pretty sure Swift is still doing vcard.

  92. Kev

    (Just as an answer to Zash)

  93. Daniel

    Btw MattJ since I was reading to source code shouldn't https://hg.prosody.im/trunk/file/tip/plugins/mod_vcard_legacy.lua#l329 do access control too?

  94. Daniel

    Otherwise you leak the hash to parties who shouldn't have access to the avatar

  95. Zash

    Daniel, that's a one-time check prior to broadcast. is the hash sensitive enough that it's worth doing the access check n=roster items times?

  96. Daniel

    Zash: depends. I guess if you already know the user you can confirm it's the same user that's in a muc

  97. Daniel

    And or track users across mucs

  98. Daniel

    I mean the premise of the module is that avatars are sensitive enough to be hidden behind access control. If one agrees with that premise that surely also involves the hash

  99. Daniel

    You could do the presence injection only if the node is open. If you wanted to keep a one time look up

  100. Zash

    I'm not sure I would call that the premise of the module. It just seemed natural to respect the PEP access controls, but for that hash it's messy

  101. singpolyma

    Messier than access control on pep notifications?

  102. Zash

    Because the presence is constructed ahead of time

  103. lovetox

    I just read the introduction of XEP 0398, and as i understand it now the only goal of this XEP was that we dont have to upload avatars into two storages because XEP0084 is not retriveable via MUC.

  104. lovetox

    So to edit it now and add a sentence that essentially means, if you dont want to use "open" on your PEP node, then you still have to use 2 storages, goes against the initial intended goal of the XEP

  105. lovetox

    Main Goal is, Use 0084 for upload, use 0153 to retrieve

  106. singpolyma

    Surely you can fetch pep via MUC. But you don't get +notify to know about changes which is the main thing still uring vcard-temp avatar for

  107. lovetox

    what was exactly the problem why this did not go through last call, last time?

  108. stpeter

    ding ding ding

  109. Zash

    As I see it, the goal of mod_vcard_legacy is to become obsolete and get deleted.

  110. lovetox

    "If a user uploads his avatar via PEP with a access model X, this access model is to be respected when serving avatars via VCard" I dont see how this sentence breaks something for anyone

  111. MattJ waves

  112. stpeter

    Which Board members do we have online for the meeting right now?

  113. stpeter

    https://wiki.xmpp.org/web/Board-Meeting-2024-03-07

  114. stpeter

    @emus @nicola are you here?

  115. stpeter

    I would not be surprised if @ralphm is not able to join.

  116. pep.

    You know the "@" is likely not to make mentions work right :P

  117. pep.

    Depending on how regex are written

  118. pep.

    (Also why we need that mentions spec..)

  119. nicola

    > @emus @nicola are you here? Yes, I am

  120. stpeter

    OK, we have a quorum then.

  121. stpeter

    pep.: :shrug:

  122. stpeter

    Matt J: would you like to run the meeting or shall I?

  123. MattJ

    If you would please, I'm on mobile so typing will be less efficient than usual

  124. stpeter

    OK!

  125. stpeter bangs the gavel

  126. stpeter

    Call to order! :-) We have Matthew, Nicola, and Peter here. Eddie and Ralph absent at least to start.

  127. stpeter

    Returning business….

  128. stpeter

    (a) Anything new about the editor role, related tooling, etc.?

  129. MattJ

    No news from the tooling side that I'm aware of, though there were recent discussions about the future of the Deferred status

  130. MattJ

    I think that just needs someone to write up a proposal if we want to consider it

  131. singpolyma

    > @board please decide on me becoming an Editor Said Daniel

  132. MattJ

    Oh yes

  133. stpeter

    It seems we go back and forth on Deferred, with no significant energy either way.

  134. stpeter

    +1 to Daniel!

  135. nicola

    +1

  136. MattJ

    The most interesting thing to me would be removal of the automatic transition, because it impacts (specifically, simplifies) tooling

  137. MattJ

    +1 to Daniel

  138. emus

    sorry, I missed the meeting

  139. singpolyma

    I had a PR about editor tooling open durng summit I don't know if that needs review still or what

  140. stpeter

    emus: we’re just starting

  141. nicola

    > The most interesting thing to me would be removal of the automatic transition, because it impacts (specifically, simplifies) tooling I agree

  142. MattJ

    singpolyma: ah, missed that

  143. stpeter

    MattJ: ah, interesting. Simplify, simplify! ;-)

  144. emus

    Im not sure if I can participate. i have one or two aob

  145. stpeter

    The challenge in the past was that we had more XEPs seemingly under active consideration than was really the case.

  146. stpeter

    emus: please mention your AOBs and we’ll add them at the end

  147. singpolyma

    I just made tne script able to auto do actions, with the idea that editor can run that like the do the current script and if all goes well it's trivial to make a GitHub action (which im willing to write

  148. MattJ

    Basically we have a bunch of stuff marked as deferred that is actually in active use. Sometimes we have reasons for that, sometimes we've just not been on the ball about advancing them. There was a suggestion that making "deferred" a conscious move would be better.

  149. emus

    stpeter: ok

  150. MattJ

    Daniel has been doing some work to get some of those XEPs advanced, which is great

  151. stpeter

    Excellent. Thanks, Daniel!

  152. stpeter

    MattJ: I see. I have no objections to that.

  153. stpeter

    So we need to find someone who can be “voluntold” to write up a proposal. 😊

  154. MattJ

    🙂

  155. stpeter

    Likely we were following IETF practice, but they have way more Internet-Drafts than we have XEPs.

  156. pep.

    What to do of currently Deferred documents? Leave them as is?

  157. stpeter

    I will look at it and think about writing the XEP.

  158. pep.

    Fix typos for those we care about?

  159. emus

    - Topic 1: Paying two twitter accounts or deprecate. I vote for deprecate. on the other side we have new money - Topic 2: Trello --> Github projects function? - Info: Outreachy does not accept umbrella organisations

  160. stpeter

    pep. not sure - let’s see what the proposal looks like, but that’s something that needs to be considered.

  161. stpeter

    emus: OK

  162. stpeter

    moving on to the next item then? Daniel is on the Editor team, I might write the Deferred proposal

  163. stpeter

    (b) infrastructure situation

  164. stpeter

    Any news here?

  165. MattJ

    No news since last month

  166. stpeter

    OK

  167. stpeter

    moving on then 😊

  168. stpeter

    (c) sponsors

  169. stpeter

    We’ve done a great job of getting more sponsors on board, thanks to everyone who has helped with that!

  170. stpeter

    A few of them are still in progress.

  171. stpeter

    And big thanks to Isode for sponsoring the Summit.

  172. emus

    👍👍

  173. nicola

    Great!

  174. stpeter

    If we can keep up this level of sponsorship (with annual renewals) then your Treasurer will be much more comfortable. :-)

  175. stpeter

    Moving on again, then, to New Business.

  176. stpeter

    (a) GSOC

  177. stpeter

    Thanks to Eddie for getting us into GSOC again.

  178. emus

    Accepted, 7 ideas, 3 clients

  179. stpeter

    emus: is there anything you need from us?

  180. nicola

    > Accepted, 7 ideas, 3 clients 👍

  181. emus

    stpeter: just advertise where you can, also offlie

  182. emus

    offlline

  183. stpeter

    OK

  184. stpeter

    emus: what is the deadline?

  185. stpeter

    (our internal deadline for people to submit ideas)

  186. emus

    16th

  187. emus

    ahh 16th +1w

  188. stpeter

    OK, thanks.

  189. emus

    i think

  190. stpeter

    So folks should poke their developer friends.

  191. stpeter

    Moving on again. I like short meetings. ;-)

  192. stpeter

    New (b) explicitly pseudonymous authors of XEPs

  193. emus

    https://jabbers.one:5281/file_share/YWWvBsXyX_4wa5U4WSAA5hTF/zb2rhYPCCQJLjAUnC6Uox3iDHuzXf7gbCD4Jz2yvarG2WQw6n.jpg

  194. stpeter

    The Editor team has received a new XEP contribution from someone who explicitly told us he operates under a pseudonym.

  195. stpeter

    We don’t actually check people’s legal status / name when they contribute a spec.

  196. stpeter

    e.g., for IPR assignment

  197. stpeter

    And we’ve never done that.

  198. stpeter

    It’s not as if there is a legal contract involved.

  199. stpeter

    The author merely says “here, it’s now the XSF’s IPR”

  200. Kev

    That's not exactly true.

  201. Kev

    There is an explicit IP grant step.

  202. stpeter

    So I don’t have a problem accepting this contribution.

  203. Kev

    That GitHub checks for us, and when it's not received via GitHub that the Editor does manually by mail.

  204. stpeter

    Right, but the author doesn’t sign a contract with their legal name with notarization and all that.

  205. Kev

    Because Board decided that doing what you describe wasn't sufficient a couple of years ago.

  206. Kev

    IIRC

  207. stpeter

    Yes, there is an explicit grant, but we don’t check the person’s identity.

  208. stpeter

    And we never have.

  209. MattJ

    I'm fine to continue with that

  210. pep.

    IP grant steps are done everyday with CLAs or DCOs without any means of legal identity verification

  211. Kev

    No, indeed, but I've been told in the past (by lawyers) that email is fine to be considered a contract-in-writing.

  212. Kev

    At least, that was what I understood from it.

  213. nicola

    > No, indeed, but I've been told in the past (by lawyers) that email is fine to be considered a contract-in-writing. I agree 😀

  214. stpeter

    pep.: yes, most open-source projects do it that way, there are all sorts of nicks/handles/ contributing.

  215. pep.

    As long as the author is reachable..

  216. pep.

    (which isn't the case of some of the XEPs' authors, note)

  217. pep.

    (which isn't the case of some of the XEPs' authors, note, even though they may have used their legal names)

  218. stpeter

    Kev mentioned another potential concern, which is that a pseudonymous author might be less reachable or less inclined to move the document forward, but we have other ways of handling that situation (e.g., assign co-author).

  219. stpeter

    Right.

  220. Kev

    > mentioned another potential concern, which is that a pseudonymous author might be less reachable or less inclined to move the document forward, but we have other ways of handling that situation (e.g., assign co-author). Did I? I thought that was someone else, but maybe it was me.

  221. stpeter

    Can’t recall. Could have been someone else.

  222. Kev

    (I have to duck out again now. I don't care which way it goes, but I'm noting that we *do* require people to grant IP explicitly, and so what I was mostly wanting was that Board was happy/not happy that that was still valid when it happens under a pseudonym, in whichever legal regions we have to care about)

  223. Kev

    Answers on a post card to Editor please :)

  224. stpeter

    In any case, what I’m seeing is that Nicola and I are fine with accepting this XEP. And I think Matthew as well if I understand the reference of his statement above “I’m fine to continue with that.”

  225. stpeter

    Kev: yep, will do, thanks. :-)

  226. nicola

    > In any case, what I’m seeing is that Nicola and I are fine with accepting this XEP. And I think Matthew as well if I understand the reference of his statement above “I’m fine to continue with that.” Yes

  227. MattJ

    Yes, happy to accept this XEP and pseudonymous authors

  228. stpeter

    OK!

  229. emus

    It would be one step towards being more open

  230. stpeter

    We have quorum, decision made, I’ll post something about this somewhere to memorialize it.

  231. stpeter

    emus: are you OK with this, too?

  232. stpeter

    Moving along to “Any Other Business”…

  233. stpeter

    emus raised the following AOBs above: - Topic 1: Paying two twitter accounts or deprecate. I vote for deprecate. on the other side we have new money - Topic 2: Trello --> Github projects function? - Info: Outreachy does not accept umbrella organisations

  234. emus

    > emus: are you OK with this, too? yes

  235. stpeter

    (1) I thought we had decided to pay for 12 months while we sort out where to move our social media presence.

  236. nicola

    > emus raised the following AOBs above: > > - Topic 1: Paying two twitter accounts or deprecate. I vote for deprecate. on the other side we have new money > - Topic 2: Trello --> Github projects function? > - Info: Outreachy does not accept umbrella organisations I agree with Topic1 and 2

  237. stpeter

    emus: read, thanks.

  238. stpeter

    s/read/great/

  239. emus

    > (1) I thought we had decided to pay for 12 months while we sort out where to move our social media presence. Yes, but according to twitter I must pay my remote account as well

  240. stpeter

    ah

  241. nicola

    Sorry I meant that I prefer to deprecate

  242. emus

    we can test and kev starts to party for the main one and see if it requires me to pay as well

  243. stpeter

    I’m fine with deprecating, personally! But then I got off Twitter in 2016. Ten years was enough for me. ;-)

  244. stpeter

    emus: sure, whatever you think makes sense is fine with me.

  245. nicola

    > I’m fine with deprecating, personally! But then I got off Twitter in 2016. Ten years was enough for me. ;-) I see 😀

  246. MattJ

    As before, my preference is to deprecate that account, but ralphm felt strongly about this in the past so it might be worth discussing when he is around

  247. stpeter

    MattJ: noted

  248. MattJ

    Or we just abandon the tweetdeck approach

  249. stpeter

    Let’s discuss via email or in next month’s meeting. I don’t see a hurry here, unless emus says our access will be cut off.

  250. stpeter

    nod

  251. stpeter

    As to Trello->GitHub, that seems sensible (this way we don’t have things spread around on different services).

  252. emus

    On twitter: Just saying its unmaintainable.this way. I cannot do reach out to Kev all the time and its quite a burden

  253. nicola

    > As to Trello->GitHub, that seems sensible (this way we don’t have things spread around on different services). If we use it ok, otherwise …

  254. MattJ

    I'm fine with that, but we haven't really been using Trello for years

  255. stpeter

    emus: Yes, that’s crazy. 😊

  256. stpeter

    MattJ: true, so this is perhaps a non-decision.

  257. stpeter

    But we might want to remove the Trello board to reduce confusion (I don’t even know who controls it now).

  258. emus

    +1 but extract if there are still valid topics listed

  259. nicola

    Shall we think about it and postpone the decision to the next board?

  260. stpeter

    emus: what I see is, let us know what you need/want re Twitter/X and we’ll support you - but before turning off the account we should talk with Ralph.

  261. stpeter

    nicola: yes

  262. stpeter

    emus: please send a note to the board@ or members@ list about Trello so we can have a look (I don’t recall what the URL is for our board there).

  263. stpeter

    OK, any other AOBs?

  264. MattJ

    None here

  265. stpeter

    Date of Next Meeting. This should be 2024-04-04 (the first Thursday in April). I can create a wiki page with the agenda.

  266. nicola

    > Date of Next Meeting. This should be 2024-04-04 (the first Thursday in April). I can create a wiki page with the agenda. Ok. Thank you everyone

  267. stpeter

    Hearing no more agenda items, I move that we adjourn. Second?

  268. MattJ

    Seconded

  269. stpeter bangs the gavel

  270. stpeter

    Thanks, all!

  271. MattJ

    Thanks stpeter 🙂

  272. stpeter

    My pleasure!

  273. nicola

    Thank stpeter

  274. stpeter

    Now back to our regularly scheduled technical programming… ;-)

  275. Daniel

    Btw I just checked the ejabberd source code and I'm pretty sure it copies the avatar on write from one storage to another. Which is different to what prosody is doing. (which is synthesizing the vcard on access). So I'm not sure I'm comfortable rewriting the xep to what prosody is doing

  276. emus

    thanks all

  277. MattJ

    One reason we did it the way we do is to honour access control on the vcard info, even if you have clients supporting only legacy vcard

  278. MattJ

    Otherwise it's weird, and having two copies of the same data (that can get out of sync, sometimes) is also weird

  279. Daniel

    It's not that I dislike prosodys approach. But I think the difference (essentially when access control happens) is more than just an implementaional difference

  280. MattJ

    For Snikket we expose the access control, and I don't want to have to explain to users that it only affects the visibility of their profile to *some* other entities

  281. MattJ

    Neither do I particularly want to just remove vcard-temp (for interop)

  282. Daniel

    And the xep was certainly written with the intent to spec out what ejabberd is doing.

  283. MattJ

    Can the XEP cover both use cases? As I said earlier, I thought the main value was the client knowing it didn't need to publish the data twiilce

  284. Daniel

    Not saying it's good that the xep is that way. But that makes me uncomfortable changing the xep

  285. MattJ

    "If the server stores the data in both places separately, here's how"

  286. MattJ

    We did that with 0191/0016

  287. Daniel

    > Can the XEP cover both use cases? As I said earlier, I thought the main value was the client knowing it didn't need to publish the data twiilce Not with providing clear and accurate security considerations I think

  288. MattJ

    So should Prosody not advertise the feature?

  289. MattJ

    That seems like a step backwards

  290. Daniel

    Idk if you think you currently implemt 0398 we can also publish it as is

  291. Daniel

    And only slightly modify the existing security considerations to remove the 'in the future' wording and replace it with 'services may'

  292. MattJ

    As lovetox said, from a client perspective, "it works"

  293. Zash

    I wonder when we can sunset vcard-temp completely

  294. stpeter

    Hey, it was always supposed to be “temp”

  295. MattJ

    At least it wasn't called simple-vcard-temp

  296. Zash

    temporary the way the earth is?

  297. Zash

    https://xkcd.com/1606/

  298. MSavoritias fae.ve

    we can depreceate it and then its done :)

  299. MSavoritias fae.ve

    deprecate*

  300. Daniel

    see the new 5.2 section and the slightly updated security considerations https://gultsch.de/files/xep-0398.html

  301. lovetox

    sounds good, so does ejabberd check the pep access? or does it simply serve the avatar to everyone that requests vcard

  302. lovetox

    because i would consider this a leak

  303. lovetox

    this XEP introduced a privacy leak when not correctly implemented, clients who always only published to PEP with access presence, suddenly would have there avatar public when requested via vcard. I think Daniels intention with the XEP edit now, was to make it clear to servers that this leak must not happen. Thas why he added the rule, that avatar must only be sent via vcard if model is "open". what i proposed is simply to make it not stricly open, rather say "honor the pep access model". I still dont understand how "open" can be ok with the XEP intention but "honor the pep access model" is not

  304. lovetox

    it was not my intention to get everything out of the XEP about the access model, there is a privacy leak risk here which should be mitigated with wording in the XEP

  305. lovetox

    Now your proposal talks about different ways to implement the storage, and now we have different rules per storage? why would it be allowed for ejabberd to have this privacy leak, just because they decided to copy avatars around

  306. Daniel

    We have two very different implementations that both claim to be compatible. I can't write security considerations that are strict and keep both implementions in compliance

  307. moparisthebest

    Write them strict then fix the ejabberd impl

  308. lovetox

    just so it be noted, i never checked the ejabberd impl, and dont know if they consider the access model

  309. lovetox

    Daniel checked the code, and i asked if he saw something

  310. Daniel

    > this XEP introduced a privacy leak The xep (as published on xmpp.org) says so

  311. singpolyma

    I think maybe security considerations can say "note that many vcard-temp implementations historically have not used any access control, so care should be taken if the pep node access model is not open" or such?

  312. Zash

    I would note that the Prosody module defaults to open, so it would behave as with the old vcard module until the user interacts directly with PEP and sets some other access model, which is then respected. Seemed the sensible thing to do back then.

  313. Daniel

    If the xep has no clear security considerations and is written broadly enough to allow for both the prosody and the ejabberd approach then I'm not really sure what we need the xep for

  314. Zash

    It's a transition helper, ultimately it should all become obsolete and leave us in a glorious PEP-only paradise, right? :)

  315. Zash

    So maybe we don't need to worry too much about it

  316. Daniel

    Right. Servers do _something sensible_ no xep required

  317. Zash

    The XEP doesn't say anything about merging in other PEP nodes like vcard4 or nickname, right? Only avatar?

  318. Daniel

    Yes only avatar

  319. Daniel

    I don't dislike the idea of writing down what prosody does in xep form

  320. Daniel

    Like a 'virtual vcard' xep

  321. Zash

    Tho parts of it can be squint-derived from the vcard4 xep.

  322. Daniel

    Which two parts?

  323. Zash

    https://xmpp.org/extensions/xep-0292.html#mapping

  324. Zash

    But not in the same way of 398

  325. Zash

    ('Tho' = 'Although')

  326. Zash

    Reading 398 and going with a single source of truth method where data is stored in a canonical form in PEP, moving out the rest of the vcard data into vcard4 seemed sensible, but we never got around to a XEP about that.

  327. Daniel

    Zash: if I publish a vcard4 with a photo will it store that in the avatar node (and remove it from vcard4)

  328. Zash

    if you publish to vcard4 then it's just regular pubsub

  329. Zash

    I would recommend against putting a photo in vcard4, since we have the separate pep node for that

  330. Daniel

    Well yes but vcard4 can have a photo (and nicks) so you'd be duplicating information again

  331. Zash

    having a public avatar but contact-only profile details was a thing I personally wanted

  332. singpolyma

    > Zash: if I publish a vcard4 with a photo will it store that in the avatar node (and remove it from vcard4) Would be nice

  333. singpolyma

    Pep nick has always felt redundant to me

  334. Zash

    I think it would be nice if we just offer generic PEP and don't have to do anything special

  335. Zash

    Hence the module translating to/from vcard-temp but storing vcard4+pep avatar (and also mod_bookmarks doing a similar thing)

  336. Zash

    So when all the clients have moved to the PEP native method, these translation layers can be turned off.

  337. lovetox

    > Well yes but vcard4 can have a photo (and nicks) so you'd be duplicating information again i dont think we need to think about that, a client is not forced to do this at all

  338. lovetox

    vcard is vcard, we didnt invent it, and it has a million things in it, no problem with that

  339. lovetox

    we have a better way to store avatars, and client devs know about it, really there own problem if they decide they need to put it into vcard

  340. lovetox

    same with nickname, we have different nodes on pubsub for different kind of data, everything is nicely separated with the additional nice thing, that we can also use different access model on different data

  341. lovetox

    i really see no problem we need to solve here that merges server side different data into one

  342. lovetox

    XEP0398 was a helper so we can transition to pubsub with avatar, without losing avatar in MUCs

  343. lovetox

    thats about it, im not aware of another problem which needs solving in that regard (vcard/nickname/avatar)

  344. Zash

    Sorry I never finished the vcard4 PR adding some words of discourangement for including pictures.

  345. lovetox

    no need really, every developer will get it rather fast

  346. lovetox

    we have compliance specs ect, and they probably all mention avatars

  347. goffi

    https://vin01.github.io/piptagole/security-tools/soar/urlscan/hybrid-analysis/data-leaks/urlscan.io/cloudflare-radar%22/2024/03/07/url-database-leaks-private-urls.html ==> could this affect HTTP Upload links? Those links are not supposed to be handled outside of chat room by XMPP clients, but how can we be sure that there is not a proxy or whatever CDN somewhere in the middle? When e2ee is used, it should not be a problem though.

  348. lovetox

    yes if e2e is not used, middleman can steal your data, i dont think we can do something about it

  349. goffi

    We could add a password in HTTP header (or use Jingle).

  350. moparisthebest

    Is that about people being surprised that when they send links to 3rd party services that the 3rd party services have the links then? Yikes... Stop hitting yourself

  351. moparisthebest

    goffi: http has user/pass auth standardized, but also this isn't a problem unless clients are sending URLs to third parties and then no amount of passwords will help e2e uploads are protected from CDNs/middleboxes at least

  352. goffi

    moparisthebest: my concern is more about not being aware of third party being used (your XMPP provider use a CDN, your web client does URL analysis, or whatever). But I realise that there is authorization header already in HTTP Upload, I remembered it wrongly as not allowed. So this is fine.

  353. singpolyma

    assuming you don't also expose that header to whatever third party :)

  354. goffi

    yeah sure. Anyway if you really want your file to be safe, use proper e2ee. I was mostly concerned about the file link shared on the casual unencrypted private conversation being accidentally exposed.

  355. goffi

    And if we can't totally avoid that, we can at least add some foolproof.

  356. Daniel

    You can also send the encryption key to third parties if you want to

  357. singpolyma

    so many options!