3 ms·

Isn't this the same crap that affects most messengers at one point? You send a link, the receiving client tries to do a link preview so a request is made to th

Isn't this the same crap that affects most messengers at one point? You send a link, the receiving client tries to do a link preview so a request is made to the link exposing the receiver's IP address?

CharlieDigital 3y ago
Yes, I was thinking the same thing. This seems like it would also hold true for Slack, Teams, Discord -- any app that would make another request to render the "card" for the URL unless those apps are proxying those requests.
- consoomer 3y ago
  Most of those apps already had this issue raised/exposed and fixed. It seems to be a very common security measure that is overlooked.
- orf 3y ago
  If you send a message to a channel with 5k people in it, would you expect 5k requests to go to the page in a short interval? How would that work with custom unfurl extensions? It’s all proxies and unfurled on the server, once. Anything else is madness.
  - numpad0 3y ago
    Does that madness help measuring CTR?
  - mh- 3y ago
    Agreed. And iMessage actually has the sender client generate the link preview and bundles that with the message. This sounds weird, but with end-to-end encrypted conversations, it's basically that or have it generated by the recipient. (or have one of the receiving client send it to a service out-of-band, but that "defeats" the end-to-end encryption.)
    - mikepurvis 3y ago
      Having the sender do it also makes sense from an auth point of view— thinking of like a private Github repo, or something like Jira running on your corporate VPN. Presumably the sender intended to share the contents with every recipient anyway and any that don't have access still of course won't be able to click through. But it would be pretty bad UX if the card was just blank in these cases because the messaging server didn't have access.
shortrounddev2 3y ago
Line previews the URL remotely. You can verify this because Line's servers are in Japan and the preview will show Japanese text for sites that offer a Japanese version
waihtis 3y ago
surely the request should'nt come from the client but a separate server? I presume the reason link checking exists is that the URL is reviewed for maliciousness, and that isn't likely to be done locally
- thakoppno 3y ago
  > surely the request should'nt come from the client Maybe this problem is intractable logically? The preview needs to be accurate from the perspective of the client. The only way to guarantee that seems to me sending the request from client.
  - waihtis 3y ago
    I think most of the "malicious URL check" solutions literally compare the url string to a large, known bad address database
betaby 3y ago
Slack and Telegram use their respective infra to fetch the URL for the preview - not your local IP.
zoomablemind 3y ago
> ...receiving client tries to do a link preview I understood that the link in question was to some google.com, not a 'hacker' controlled URL. [ ...Yossi sent me a link via Skype text chat to google.com. The link was to the real Google site, and not an imposter. ] It may be something which is kept in the app's db following the generation of a preview. Would it make sense to restrict the chats to only 'address book' contacts, supposedly trusted?

CharlieDigital 3y ago

Yes, I was thinking the same thing. This seems like it would also hold true for Slack, Teams, Discord -- any app that would make another request to render the "card" for the URL unless those apps are proxying those requests.

consoomer 3y ago
Most of those apps already had this issue raised/exposed and fixed. It seems to be a very common security measure that is overlooked.
orf 3y ago
If you send a message to a channel with 5k people in it, would you expect 5k requests to go to the page in a short interval? How would that work with custom unfurl extensions? It’s all proxies and unfurled on the server, once. Anything else is madness.
- numpad0 3y ago
  Does that madness help measuring CTR?
- mh- 3y ago
  Agreed. And iMessage actually has the sender client generate the link preview and bundles that with the message. This sounds weird, but with end-to-end encrypted conversations, it's basically that or have it generated by the recipient. (or have one of the receiving client send it to a service out-of-band, but that "defeats" the end-to-end encryption.)
  - mikepurvis 3y ago
    Having the sender do it also makes sense from an auth point of view— thinking of like a private Github repo, or something like Jira running on your corporate VPN. Presumably the sender intended to share the contents with every recipient anyway and any that don't have access still of course won't be able to click through. But it would be pretty bad UX if the card was just blank in these cases because the messaging server didn't have access.

shortrounddev2 3y ago

Line previews the URL remotely. You can verify this because Line's servers are in Japan and the preview will show Japanese text for sites that offer a Japanese version

waihtis 3y ago

surely the request should'nt come from the client but a separate server? I presume the reason link checking exists is that the URL is reviewed for maliciousness, and that isn't likely to be done locally

thakoppno 3y ago
> surely the request should'nt come from the client Maybe this problem is intractable logically? The preview needs to be accurate from the perspective of the client. The only way to guarantee that seems to me sending the request from client.
- waihtis 3y ago
  I think most of the "malicious URL check" solutions literally compare the url string to a large, known bad address database

betaby 3y ago

Slack and Telegram use their respective infra to fetch the URL for the preview - not your local IP.

zoomablemind 3y ago

> ...receiving client tries to do a link preview I understood that the link in question was to some google.com, not a 'hacker' controlled URL. [ ...Yossi sent me a link via Skype text chat to google.com. The link was to the real Google site, and not an imposter. ] It may be something which is kept in the app's db following the generation of a preview. Would it make sense to restrict the chats to only 'address book' contacts, supposedly trusted?