Re: [Standards] Thoughts on XEP-0385 Stateless Inline Media Sharing

[Marvin W]

On 03.07.21 20:35, JC Brand wrote:
> If you're behind a corporate firewall, [...]

I was rather thinking of company internal servers that are only
reachable from within the local network.

> Given that users already share URLs, I would like to have better
> metadata so that I can provide a better UX.

I was under the assumption that SIMS is not about adding metadata, but
about displaying media inline. Sharing an URL to a (media) file does not
imply that it should be displayed inline.

>> Fetching files from untrusted third-party servers is a privacy
>> nightmare. [...]
> Sounds like configuration, and not something that would ever be universal.

I think this is something we should make an effort to solve, not just
with configuration, but at the protocol level. "By using this software,
you agree that your personal data (IP address) is shared with arbitrary
unknown third parties, who, under their respective privacy policy, may
process that personal data as they please" doesn't really sound great.
We already have an issue here and I'm not very keen to make it even bigger.

> Also, at least in my web client, the images are shown asynchronously
> after the message has been sent, and they're shown via  tags, so
> the browser is responsible for fetching the image and caching it, not my
> client.

Just to get the message across: I am not against lifting the requirement
to have the file hash in here, I just fear the UX this might result in.
I totally understand that as a web client you may not be able to
actually fetch and compute the hash of the media due to cross-origin
restrictions - however the same probably applies to HTTP headers.

Web currently is in the process of receiving a proper system for sharing
files across apps (both web and native). See
https://web.dev/web-share-target/. This currently is not available on
most Desktop OS, just because those OS don't have a proper system yet
(whereas mobile OS are typically much more modern and thus do support
such system).

Also, I kinda feel that we are talking about users with different
expertise levels here: I'm thinking of the people that ask to search an
event on Facebook rather than sending a link to the Facebook event page.
I also hardly see video files being linked directly outside my tech
bubble (instead links are to YouTube, Dropbox or Google Drive with their
web video player). But, I also agree that, especially within tech
people, sharing an URL is common, thus what you propose may make sense
for those.


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

Re: [Standards] Thoughts on XEP-0385 Stateless Inline Media Sharing

[JC Brand]

On 03.07.21 17:44, Linus Jahn wrote:

Hello,

I just wanted to note that there's also XEP-0447: Stateless file sharing [1] 
which has some
improvements over SIMS (like multiple files in one message and a little simpler 
API (no need to
use character counting / the References XEP) and later attaching of additional 
sources).

Not sure if I've missed something, but I thought there're no reasons to use 
SIMS anymore, right?

Anyway, I guess making checksums OPTIONAL/RECOMMENDED is probably also a good 
idea for SFS.

Thanks, I wasn't aware of this XEP.

I had a look and it's not fit for what I have in mind.

Not using references is a drawback for me, since Converse already 
supports and uses references.


Not supporting mixed content is a deal breaker, since I'm interested in 
the case where users write messages containing URLs pointing to media, 
not just sharing files.

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

Re: [Standards] Thoughts on XEP-0385 Stateless Inline Media Sharing

[JC Brand]

Hi Marvin

On 03.07.21 17:01, Marvin W wrote:

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.


If you're behind a corporate firewall, then you're probably already 
aware that certain sites are blocked, so the behavior isn't necessarily 
that unexpected.


I'm happy to leave the decision to the user whether they want to share a 
URL or a file. Not all servers support HTTP file upload and not all 
clients support Jingle, so sharing via 3rd party URL is the only option 
some people have.


Given that users already share URLs, I would like to have better 
metadata so that I can provide a better UX.



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.

Sounds like configuration, and not something that would ever be universal.


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.


I don't see this as simply "inline sharing" and I don't share the 
assumption that you'll always show the image to yourself when you're 
sharing the URL.


Also, at least in my web client, the images are shown asynchronously 
after the message has been sent, and they're shown via  tags, so 
the browser is responsible for fetching the image and caching it, not my 
client.




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.

Nice to have, but not essential.


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.
Indeed, I'm however dealing with the case where it's not deemed 
desirable to first download the entire file in order to generate a hash.

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 read a lot of assumptions in this last paragraph that don't match up 
to the use-case that I have and seem to come from the perspective of a 
desktop or perhaps mobile client developer.


When sharing video URLs on the web, the browser is not going to download 
the entire video before starting to show it to you in a  tag.



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.


Yes, and that's another use-case where it might be preferable to simply 
do a HEAD request and use the headers rather than downloading the whole 
file.



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

When they link directly to media they do qualify as media in my opinion.


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?


Nothing, but I'm working on a web client, not a mobile client.

- JC


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 

Re: [Standards] Thoughts on XEP-0385 Stateless Inline Media Sharing

[Marvin W]

Hi,

XEP-0447 currently lacks a content-disposition information to clarify if
a (media) file should be displayed inline or not. This is on my TODO.

XEP-0447 does not allow for mixed content which XEP-0385 supports.

Including the hash is already "only" RECOMMENDED for XEP-0447. However
it is required for making use of source attaching (3.3), as otherwise
the integrity of attached sources cannot be verified.

Marvin

On 03.07.21 17:44, Linus Jahn wrote:
> Hello,
> 
> I just wanted to note that there's also XEP-0447: Stateless file sharing [1] 
> which has some
> improvements over SIMS (like multiple files in one message and a little 
> simpler API (no need to
> use character counting / the References XEP) and later attaching of 
> additional sources).
> 
> Not sure if I've missed something, but I thought there're no reasons to use 
> SIMS anymore, right?
> 
> Anyway, I guess making checksums OPTIONAL/RECOMMENDED is probably also a good 
> idea for SFS.
> 
> Cheers
> 
> 
> [1]: https://xmpp.org/extensions/xep-0447.html
> ___
> 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
___

Re: [Standards] Thoughts on XEP-0385 Stateless Inline Media Sharing

[Linus Jahn]

Hello,

I just wanted to note that there's also XEP-0447: Stateless file sharing [1] 
which has some
improvements over SIMS (like multiple files in one message and a little simpler 
API (no need to
use character counting / the References XEP) and later attaching of additional 
sources).

Not sure if I've missed something, but I thought there're no reasons to use 
SIMS anymore, right?

Anyway, I guess making checksums OPTIONAL/RECOMMENDED is probably also a good 
idea for SFS.

Cheers


[1]: https://xmpp.org/extensions/xep-0447.html
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Thoughts on XEP-0385 Stateless Inline Media Sharing

[Marvin W]

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  tag and
> the "content-length" header for the .
> 
> 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
> 

Re: [Standards] Thoughts on XEP-0385 Stateless Inline Media Sharing

[Tobias Markmann]

On Fri, Jul 2, 2021 at 1:22 PM Florian Schmaus  wrote:

> On 02.07.21 12:15, JC Brand wrote:
> > So, my proposal is that XEP-0385 be updated so that the XEP-0300 hash
> > requirement gets relaxed to a SHOULD
>
> +1. I would even make the hash OPTIONAL as SHOULD is already pretty strong.
>
>
I'd be fine with making that OPTIONAL.

If HTTP server would support the HTTP Digest header you wouldn't need to
download the complete file as
the HTTP server would provide you with the hash upfront. But obviously it's
rarely provided by servers.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Digest

Cheers,
Tobi
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Thoughts on XEP-0385 Stateless Inline Media Sharing

[JC Brand]

Am 2. Juli 2021 13:41:26 MESZ schrieb Tobias Markmann 
:
>On Fri, Jul 2, 2021 at 1:22 PM Florian Schmaus 
>wrote:
>
>> On 02.07.21 12:15, JC Brand wrote:
>> > So, my proposal is that XEP-0385 be updated so that the XEP-0300
>hash
>> > requirement gets relaxed to a SHOULD
>>
>> +1. I would even make the hash OPTIONAL as SHOULD is already pretty
>strong.
>>
>>
>I'd be fine with making that OPTIONAL.
>
>If HTTP server would support the HTTP Digest header you wouldn't need
>to
>download the complete file as
>the HTTP server would provide you with the hash upfront. But obviously
>it's
>rarely provided by servers.
>
>https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Digest


Thanks, I'll prepare a pull request.



-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Thoughts on XEP-0385 Stateless Inline Media Sharing

[Florian Schmaus]

On 02.07.21 12:15, JC Brand wrote:
> So, my proposal is that XEP-0385 be updated so that the XEP-0300 hash
> requirement gets relaxed to a SHOULD

+1. I would even make the hash OPTIONAL as SHOULD is already pretty strong.


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

You wrote yourself that you don't know what to conclude from an Etag
mismatch. But it does not sound wrong to have the etag as optional
metadata for exploration reasons. Maybe someone comes up with a use case
for it.

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

Re: [Standards] Thoughts on XEP-0385 Stateless Inline Media Sharing

[JC Brand]

Sorry, I see now that Thunderbird has completely mangled the stanza that 
it showed so nicely to me in the email editor.


I guess because I have it configured to send out only plaintext.

Here it is again:


    Look at this funny cat picture
    type='data'>

        
            
                image/jpeg
                icanhazcheeseburger.jpg
                110220
                
                    some-long-opaque-string
                
                Fat cat that looks like it wants a 
cheeseburger

            
            
                uri='https://funnypics.com/icanhazcheeseburger.jpg'/>

            
        
    


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  tag 
and the "content-length" header for the .


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.



Look 
at this funny cat 
pictureimage/jpegicanhazcheeseburger.jpg110220http://jabber.org/protocol/shim'>some-long-opaque-stringFat 
cat that looks like it wants a 
cheeseburgerhttps://funnypics.com/icanhazcheeseburger.jpg'/>



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  and  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
___

Re: [Standards] Thoughts on XEP-0385 Stateless Inline Media Sharing

[JC Brand]

On 02.07.21 12:42, Sergey Ilinykh wrote:

What about a slightly different scenario?

Romeo sees a funny picture on funnypics.com , 
copies it to a messenger's input field. The messenger prefetches the 
whole picture, generates a thumbnail (at least it's impossible to have 
a thumbnail without fetching everything), computes hashes and then 
sends. Optionally the picture can be put to a local cache and also 
become available over Jingle and other transfer methods.
Now Juliet having a thumbnail knows exactly if she wants to download a 
whole size picture.


But this is just about pictures. Probably sharing a bluray video by 
the link from the web won't work this well in this case. So I tend to 
agree having alternative  integrity checks looks reasonable. Also 
sharing arbitrary files via SIMS, not just multimedia, may require 
splitting the presentation and sharing into two dedicated XEPs.


Yeah, I'd be quite annoyed if I shared a link to a video and my client 
first insists on downloading the entire file so that it can send out a 
hash to the recipient.


-JC




пт, 2 июл. 2021 г. в 13:17, JC Brand >:


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 
tag and
the "content-length" header for the .

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.


Look

at this funny cat

pictureimage/jpegicanhazcheeseburger.jpg110220http://jabber.org/protocol/shim

'>some-long-opaque-stringFat

cat that looks like it wants a

cheeseburgerhttps://funnypics.com/icanhazcheeseburger.jpg'/

>


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

Re: [Standards] Thoughts on XEP-0385 Stateless Inline Media Sharing

[Sergey Ilinykh]

What about a slightly different scenario?

Romeo sees a funny picture on funnypics.com, copies it to a messenger's
input field. The messenger prefetches the whole picture, generates a
thumbnail (at least it's impossible to have a thumbnail without fetching
everything), computes hashes and then sends. Optionally the picture can be
put to a local cache and also become available over Jingle and other
transfer methods.
Now Juliet having a thumbnail knows exactly if she wants to download a
whole size picture.

But this is just about pictures. Probably sharing a bluray video by the
link from the web won't work this well in this case. So I tend to agree
having alternative  integrity checks looks reasonable. Also sharing
arbitrary files via SIMS, not just multimedia, may require splitting the
presentation and sharing into two dedicated XEPs.

Best Regards,
Sergey


пт, 2 июл. 2021 г. в 13:17, JC Brand :

> 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  tag and
> the "content-length" header for the .
>
> 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.
>
>
> Look
> at this funny cat
>
> pictureimage/jpegicanhazcheeseburger.jpg110220 http://jabber.org/protocol/shim'>some-long-opaque-stringFat
>
> cat that looks like it wants a
>
> cheeseburger https://funnypics.com/icanhazcheeseburger.jpg'/
> >
>
>
> 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  and  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
___