[Standards] LAST CALL: XEP-0398 (User Avatar to vCard-Based Avatars Conversion)
zash at zash.se
Tue Feb 25 19:56:15 UTC 2020
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) . 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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the Standards