On Thu, 17 Oct 2019 at 13:34, JC Brand <li...@opkode.com> wrote:
>
> On Thu, Oct 17, 2019 at 01:23:18PM +0200, Marvin W wrote:
>

> > - 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.

They are effectively arbitrary. When you upload you upload to your own
host, right. But when you receive an jabber:x:oob stanza, the URL can
be absolutely anything (HTML, 50GB JPEG, "pixel tracker").

> > 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?

You are providing the user's IP address, user agent, etc. to a third
party. IANAL and I'm not saying that I buy the GDPR argument in this
case, but there *is* a case for privacy here.

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

Reality check: Third-party assets (images, scripts, etc.) are exactly
how the majority of tracking happens online today.

> > 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.

Right. There are other reasons too, including spam and many other
categories of media (some illegal) that I don't want my device
automatically downloading and displaying. And don't forget data usage.

> > - 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?

It's part of the identifier, e.g.
'cid:sha1+8f35fef110ffc5df08d579a50083ff9308fb6242@bob.xmpp.org'

> 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.

They are not. But BoB is 95% there IMHO, has desirable properties for
this use case, and we already have implementations.

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

Obviously we don't have anything widespread except for jabber:x:oob
right now (which is not suitable as it stands). I don't think pushing
a BoB solution over the finish line by filling in the gaps with a
'stickers' XEP would be infeasible or more work than standardizing a
HTTP-based solution.

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

Reply via email to