On Tue, Feb 25, 2020 at 05:14:57PM +0100, Jonas Schäfer wrote: > > 4. Do you have any security concerns related to this specification? > > There is the obvious issue that the vCard is world-readable, which has > in the past caused surprise with XMPP users from the instant messaging > world. Moving the data to PEP allows the user to control who is able to > read it. > > The document currently states that: > > > In the future services MAY decide to perform PEP to vCard conversion > only if the access model of the 'urn:xmpp:avatar:data' node has been set > to 'open' as described in Publish-Subscribe (XEP-0060) [5]. However the > ability to change the access model of nodes isn’t widely implemented yet > and thus this paragraph exists only to act as a reminder that the > privacy implications described in the previous paragraph can be avoided > > I don’t think this is necessarily true anymore. I’d love to get feedback > from server developers on this one, so that we can get the rules changed > before moving on to Draft. > > Specifically, I would prefer if we could get this changed so that the > server always does the conversion, but uses the access model from the > PEP node to answer vCard requests. I.e. if the PEP node is set to > `whitelist` or `presence`, it should only answer vCard requests based on > that.
The implementation included with Prosody works by mapping vcard-temp writes to vCard4 with avatars extracted into the two XEP-0084 nodes, all stored in PEP and vcard-temp queries compose a legacy vcard from those three PEP nodes on the fly. Prosody's PEP implementation supports the full PubSub permission model and the XEP-0398 code respects this when composing the vcard-temp. This allows nice things such as: > And maybe re-define XEP-0292 to use PEP as backing storage so that users > (clients) can control the vCard permissions independently from the > avatar permissions. If you configure the vcard4 node as private (`presence` or such) and the avatar nodes as public then a vcard-temp query from someone on your roster gets the full thing but others only see the avatar. One thing we decided on wrt this is that since vcard-temp has historically been public, having it work differently through the XEP-0398 mechanism would be surprising for users (e.g. by their avatars not being visible in semi-anonymous group chats). Nodes created by the XEP-0398 mechanism default to public, but any existing settings are preserved, and they can be changed later by users. This gives users control without changing behavior. -- Kim "Zash" Alvefur
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
