For centralized public services the server can just retrieve the preview and serve it. But for decentralized services like Mastodon either every server has to fetch the preview on its own leading to lots of traffic and potential discrepancies between the previews served by different servers or the origin home server sends the preview but now everyone has to trust that it is authentic. The home server to which a link gets posted could place anything as its preview and thereby indirectly impersonate the URL and fake its content.
For E2EE messengers things are even more annoying because you do not want the servers to see the URL at all. So either all parties have to retrieve the preview on their own meaning they have to connect to a random, potentially malicious URL or only the sender does and everyone has to trust the sender that the preview is authentic which is a great opportunity for scams.^1
The perfect solution would be a standard for web servers to sign URL previews with their CA issued certificate. So that you can always proof that a preview is authentic. RFC 9421 already standardizes this. But this will not happen. There is virtually no chance of widespread adoption.
So my idea is:
You retrieve a webpage and record the whole TLS session including certificates, MACs and your key material like nonce and client random from the handshake. Now you use this as the basis for the URL preview. When you include your secret material from the TLS handshake anyone should be able to verify that the content is authentic from the server serving the URL due to the CA certificate and authentication of TLS traffic.
Standardize the request headers and limit the response length. Just cut off everything after the limit. Define some algorithm for computing the preview that ever recipient can verify. If you want to include linked images in the preview that increases complexity but should be doable. Repeat the whole thing with the linked image and create a bundle from all requests that authenticates the preview.
The downside I see is complexity and the need for the receiver to parse the preview bundle which might be attack surface.
Does anything similar already exist? Am I missing something or do you think this might be feasible to implement?
[1] Many messengers solve this by providing a URL preview service on the server. The client sends the URL to the messenger service which retrieves (and signs I hope) a URL preview which the client then includes in the message. This has the advantage that none of the parties of the conversation has to directly connect to an untrusted UTL. This bypasses E2EE for URLs. You can usually opt of this by disabling previews. Consider this if you did not know about this.