[darkwater]

Everyone fixing on the UTF RTL character but Meta should have at least acknowledged the issue with the preview URL that can be different from the message URL. I understand that this is probably to unfurl shortened URLs, but there has to be some clever workaround that Meta & Whatsapp can implement

[amadeuspagel]

No. End-to-end encryption means that the preview has to be generated either by the sender or the receiver. Having the receiver generate the preview would leak his IP. They have to remove the preview feature.

[darkwater]

Yes, preview is generated by the sender to avoid receiver's address leak to a sender-controlled host, but what I'm saying is that WA should enforce on the receiver side that both point to the same URL. As said initially, they are most certainly doing it this way to unfurl URL shorteners, which would other be the easiest way to phish people. At the same time it's also noteworthy that the preview can fail to be generated on the sender side and the message will be send out anyway, so yeah, I agree with you that they could just remove the preview feature. Probably in their opinion the trade-offs are worth, I guess.

[chimeracoder]

> Yes, preview is generated by the sender to avoid receiver's address leak to a sender-controlled host, but what I'm saying is that WA should enforce on the receiver side that both point to the same URL.

How do you do that without having the receiver make an HTTP request to that address, in order to follow all redirects?

[o11c]

The receiver can do the verification while clicking (which would make the request anyway).

[darkwater]

Exactly, that's why I say that they chose the trade-off of easy-to-send shortener over more complicated/manually crafted attacks like the one in the article.

[josu]

> They have to remove the preview feature.

They can just disable it for contacts that you don't have on your contact list.