31–40 of 51 posts
Sending the requests from the client is probably not the most secure idea. Requests should be proxied through a cloud server on Apple's end to reduce the security risk of these previews.
As has been pointed out below, iMessages are end-to-end encrypted so Apple has no way to read the URL to proxy it.
Sending the requests from the client is probably not the most secure idea. Requests should be proxied through a cloud server on Apple's end to reduce the security risk of these previews.
As has been pointed out below, iMessages are end-to-end encrypted so Apple has no way to read the URL to proxy it.
imessage won't auto-load previews until you ask it to do it the first time.
But there is no way to disable this once you have accepted it. I do not actually remember having been given the choice but it has been some time so I probably just do not remember. Ideally one could enable previews only from contacts.
Sending the requests from the client is probably not the most secure idea. Requests should be proxied through a cloud server on Apple's end to reduce the security risk of these previews.
As has been pointed out below, iMessages are end-to-end encrypted so Apple has no way to read the URL to proxy it.
Earlier quoted context omitted.
Messages are end-to-end encrypted in iMessage, meaning Apple cannot read the message contents. This solution would require Apple to bypass that encryption for URLs (which are often privacy-sensitive). A good approach would be for the sender to fetch the URL and embed the preview as metadata along with the message. The only downside is that the sender could spoof the preview, but I think that's an acceptable trade-off…
No need to do in transit. I mean iMessage could simply proxy all http/https requests post decryption in iMessage, pre-request. At the end of the day this privacy trade off (apple gets your browsing info) is probably more secure than an embedded webview that could potentially be exploited and is auto-loaded. Similar to how Chrome alerts of malicious sites...I see this as a long term larger attack vector than privacy l…
Earlier quoted context omitted.
As has been pointed out below, iMessages are end-to-end encrypted so Apple has no way to read the URL to proxy it.
You could still have the client use Apple as a proxy. This would reduce the privacy of the message but only the URL and only exposing it to specific service at Apple. If it is a SOCKS proxy, you could reduce the exposure to just the IP address and some amount of leakage to whatever DNS server the phone is using.
Earlier quoted context omitted.
You could still have the client use Apple as a proxy. This would reduce the privacy of the message but only the URL and only exposing it to specific service at Apple. If it is a SOCKS proxy, you could reduce the exposure to just the IP address and some amount of leakage to whatever DNS server the phone is using.
Why not have the sender do that work so Apple can just stay out of it?
Earlier quoted context omitted.
As has been pointed out below, iMessages are end-to-end encrypted so Apple has no way to read the URL to proxy it.
The client could send the request to Apple though, and pass the URL through that way, instead of requesting the actual URL. There's a trade-off there though that Apple gets to see all the links being sent over iMessage.
Exactly, this is what all the other replies saying 'just proxy the client URL call through Apple' are missing. It's not just that the iMessage was encrypted. There's also _why_ it is encrypted in the first place.