[Standards] LAST CALL: XEP-0398 (User Avatar to vCard-Based Avatars Conversion)

Kim Alvefur 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) [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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200225/4600597b/attachment.sig>


More information about the Standards mailing list