[Standards] LAST CALL: XEP-0398 (User Avatar to vCard-Based Avatars Conversion)
jonas at wielicki.name
Tue Feb 25 20:08:35 UTC 2020
On Dienstag, 25. Februar 2020 20:56:15 CET Kim Alvefur wrote:
> 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
> > 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.
I like how this elegantly allows different permissions on the avatar (which
one may reasonably want to have in semianon MUCs) and all the other personal
information in the vCard.
Are there other opinions on this? Otherwise I’d suggest that we get this
written down and re-LC the document.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards