On Thu, Oct 17, 2019 at 01:23:18PM +0200, Marvin W wrote:
> Hi,

> Regarding your proposal:
> - You should still add a hash in the reference somehow so that clients *can*
> cache entries (even if you won't do it in Converse)

Sure.

> - I already dislike the fact that we do HTTP requests to arbitrary servers
> for file transfers, as we might be leaking IP addresses in such cases.

The file servers are usually not arbitrary but are hosted by your XMPP host.

> In the case of Converse, you are likely to get into GDPR issues when doing so
> without explicit user consent (and you don't want explicit user consent for
> every emoji).

Why would you need user consent to show remote images?

The GDPR makes provision for data capturing that's needed to provide the
actual service. I think that applies in this case.

Otherwise any website that has user accounts and which links to 3rd party
images would need user consent for each particular image.

> There is a reason why many e-Mail-Clients don't render remote
> content in e-Mails...

And that's not GDPR, right?

AFAIK it's to avoid pixel tracking and IP address leakage.

> - When this is combined with body-only e2e-encryption, you are leaking
> information as I guess you don't envision the emoji to be encrypted for each
> e2e session individually.

This is a general problem with body-only E2EE and a good example of
why we need full-stanza encryption.

> You can probably solve the second issue mentioned above and the issue with
> http files by proxying the image request through the server hosting Converse
> (which is what other popular sites that allow arbitrary http links like
> GitHub do). But I guess you don't want to do that.

Depends on the deployment, but no, not really.

> Regarding your issues with using BOB:
> - BOB does not depend on XHTML-IM. 0231 §2.2 specifically says that "any
> appropriate format can be used" to share the CID. This means it is also
> possible to use it in 0372 references (as you suggest to do just without
> http).

Yeah, the thought of doing that did cross my mind, I forgot to mention it in my
post though.

Then there are still the caching issues.

> - BOB does not require the sender to provide the file referenced by the CID
> 0231 §2.1 says that you can send the IQ to request the bytes to "potentially
> some other entity". If you don't expect the sending client to provide the
> file, it doesn't need to cache all stickers and it doesn't need to be
> online.

"some other entity" isn't terribly well defined. How do I (or the
recipient of my stickers) know what other entity to ask?

How are stickers added to the entity's cache? How does the client know which
stickers it can send, i.e. which stickers are contained in the cache?

These are all things not spec'd in BOB.

Ideally I'd like to implement something that works in 2019/2020.


> Marvin
> 
> On 10/17/19 12:07 PM, JC Brand wrote:
> > Hello
> > 
> > I'm currently working on adding support for non-unicode emojis to 
> > Converse.js.
> > 
> > Currently, users can't upload their own images to be used for custom emojis,
> > mostly because Converse is a thin client with no backend support for it.
> > 
> > So to add custom emojis, the web host needs to edit a emojis.json file
> > to add new entries with URLs pointing to the actual images.
> > 
> > Concerning compatibility with other clients, I've discussed it with edhelas
> > and he told me he uses XEP-0231 BOB for sending stickers.
> > 
> > There are a few reasons why I'm not keen on using BOB:
> > 
> > - BOB depends on XHTML-IM which is deprecated. Converse.js doesn't support 
> > it
> >    and I'm reluctant to add support just for this.
> > - BOB mentions that binary data should be smaller than 1KB. Not sure how
> >    relevant that still is, but it discourages me from sending larger 
> > amounts.
> > - The sending client needs to maintain a cache of all sent stickers.
> > - AFAICT, when receiving an uncached BOB message via MAM and the sending 
> > client
> >    is offline, then you can't get the image data.
> > 
> > Instead, I propose that we use XEP-0372 references to indicate that a
> > particular shortname (e.g. :dancingpanda:) should be replaced with an image.
> > 
> > For example:
> > 
> >      <message type="chat" from="t...@chat.org" to="m...@chat.org"
> >          <body>I feel like dancing! :dancingpanda:</body>
> >          <reference xmlnx="urn:xmpp:reference:0"
> >                  begin="21"
> >                  end="35"
> >                  type="data"
> >                  uri="https://images.com/dancingpanda"/>
> >      </message>
> > 
> > I'm not sure whether "type" should be "data", seems a bit too generic for 
> > me,
> > perhaps it could be something else?
> > 
> > Some criticisms of this approach from edhelas:
> > 
> > - HTTP images can be sent to a webchat client served over HTTPS
> > - There's no size limit, so users can send links to very large stickers
> > 
> > Concerning the first criticism, a client can choose to not render HTTP
> > images inline and instead make the shortname a link which opens the image 
> > in a
> > new tab. Not ideal, but a compromise for the privacy and security conscious.
> > 
> > For the second I don't have a good answer.
> > 
> > That said, I currently still prefer my suggestion to using BOB. I'd be
> > interested to hear your feedback and suggestions.
> > 
> > Regards
> > JC
> > 
> > 
> > _______________________________________________
> > Standards mailing list
> > Info: https://mail.jabber.org/mailman/listinfo/standards
> > Unsubscribe: standards-unsubscr...@xmpp.org
> > _______________________________________________
> > 
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> _______________________________________________

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________

Reply via email to