Hi, Remember that URLs are not guaranteed to be globally reachable (examples: restricted to company network or requiring authentication). For most users it's not easily understandable if a URL can be reached by the recipient client or not. Thus sending an URL of funnypics.com instead of downloading that file and uploading it can lead to unexpected behavior.
Fetching files from untrusted third-party servers is a privacy nightmare. We already have this issue with oob file sharing and I remember a proposal to restrict automatic fetching to known-good servers or if the domain of the URL matches the domainpart of the JID (or is a subdomain thereof). This wouldn't work when we want to accept sending URLs from funnypics.com. When doing inline sharing, the sending client would want to display the media inline as well. For this it also needs to fetch the media anyway and thus calculating the hash would be easy. Also, especially when sharing image files, it would be great to have a thumbnail so that you don't have to fetch the full (maybe high quality) image when not explicitly needed, i.e. on mobile. To generate a thumbnail, the sending client has to first download the image. Providing the hash of the file is a good way to allow caching. Thus if you receive the same meme several times, but from different URLs, the hash will allow you to only download it once. This is not possible via ETag, due to ETags not following a common generation scheme. When receiving a file via SIMS, the URL to the file is typically not going to be exposed to the end user (instead the inline media or thumbnail and maybe filename are displayed). Thus when forwarding the file to another contact, users will typically want to do this directly instead of through copying the URL. In that case, all the details from SIMS can be just forwarded as is. I'd also like to mention that it probably is a rare case (although it may happen from time to time) where you forward a file without downloading it first. I don't know any instant messaging client that would have the equivalent of sharing a URL using SIMS. Some clients do allow sending a URL as a message and then have the server attach some SIMS-like metadata to that message. There's also client side generated link previews, but these are typically not the same as I'd expect SIMS to be used, because links don't necessarily qualify as media (although I agree media is a very broad term and thus probably most things that URLs point to are actually somewhat media). Currently, when I share an image from my browser on Android, I can just use the browsers "share image" feature (long press on the image) and select Conversations. The browser will transfer the image to Conversations without the need to download it again (might also actually do another download, but that's another story) and Conversations uploads it using HTTP file upload as usual. This works great for me and I wonder what would be wrong with this approach? Marvin On 02.07.21 12:15, JC Brand wrote: > Hi everyone > > > I've been reading XEP-0385 SIMS with an eye towards potentially > implementing it, when I noticed that a XEP-0300 hash is required, in > order to allow integrity checking and caching. > > In the introduction of SIMS, the following is written: > "This proposal aims to provide a protocol that will enable XMPP clients > to implement a great user experience (UX) around the process of sharing > media in conversations." > > I think making inclusion of the file hash mandatory is at odds with that > goal, the reason being that a lot of the media being shared in chats is > shared as URLs to 3rd parties where the media is hosted. > In other words, the sharer of the media doesn't necessarily know the > hash of the media because it was never on their own machine to begin with. > > Here's the use-case I have in mind: > > Romeo sees a funny picture on funnypics.com. He right-clicks on the > picture, copies the URL and sends it to Juliet. Before the message is > sent, Romeo's client does an HTTP HEAD request, to get information on > the URL, and learns that its an image. > > Here's the response: > > HTTP/2 200 > last-modified: Fri, 02 Jul 2021 02:46:55 GMT > etag: "a1d5ea7e796f5da6980bed86a8396664" > content-type: image/jpeg > cache-control: public, max-age=31536000 > accept-ranges: bytes > date: Fri, 02 Jul 2021 06:44:39 GMT > access-control-allow-methods: GET, OPTIONS > access-control-allow-origin: * > content-length: 110220 > > The "content-type" header can be used for the SIMS <media-type> tag and > the "content-length" header for the <size>. > > The server also responds with an "etag" header, which can be used for > caching, but unfortunately not for integrity checking, since the method > by which it's generated is not specified. > If the etag is passed along via SIMS (instead of the hash), the > receiving client could also check whether it matches what's returned by > the webserver, although I'm not sure what conclusions can be drawn if > they don't match. > > Before someone says that this scenario is not relevant to what SIMS is > trying to do, please note that this problem also occurs when someone > shares a file via HTTP upload and then the receiving party copies and > pastes that URL in a message to someone else. Perhaps an intelligent > enough client might go and get the hash from the original SIMS data and > then add that to the newly sent message, but that seems a bit contrived > to me and might not always be feasible. > > So... back to the scenario. After Romeo's client has received the HEAD > headers, it can then construct a SIMS element with it. > > > <messageto='jul...@shakespeare.lit'from='ro...@montague.lit'><body>Look > at this funny cat > picture</body><referencexmlns='urn:xmpp:reference:0'begin='17'end='20'type='data'><media-sharingxmlns='urn:xmpp:sims:1'><filexmlns='urn:xmpp:jingle:apps:file-transfer:5'><media-type>image/jpeg</media-type><name>icanhazcheeseburger.jpg</name><size>110220</size><headersxmlns='http://jabber.org/protocol/shim'><headername='ETag'>some-long-opaque-string</header></headers><desc>Fat > cat that looks like it wants a > cheeseburger</desc></file><sources><referencexmlns='urn:xmpp:reference:0'type='data'uri='https://funnypics.com/icanhazcheeseburger.jpg'/></sources></media-sharing></reference></message> > > > > Note the inclusion of the ETag header (as defined in "XEP-0150: Use of > Entity Tags in XMPP Extensions") and the omission of a XEP-0300 hash > element. > > If, for some reason the content-type and content-length headers can't be > used for the <size> and <media-type> tags, then they can also be > included as XEP-0131 headers (like the Etag). > > So, my proposal is that XEP-0385 be updated so that the XEP-0300 hash > requirement gets relaxed to a SHOULD and that the inclusion of the Etag > header be documented as an alternative in case a hash is not feasible. > There might also be cases where neither a hash or an Etag header is > available. > > I'd be happy to make the necessary changes and submit a pull request. > > 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 _______________________________________________
