re-enable viewing remote images in signed/encrypted messages

[tomholub]

... (edited - see below) ...

[tomholub]

Ok, so remote images were disabled earlier because our CSP forbids them anyway, see #4759

@rrrooommmaaa if we wanted to allow displaying such images, what options do we have, in order to work around the CSP? I'm thinking of three options:

• Instead of letting the browser display the image with <img src="https://..." /> which triggers CSP, we could download the image using AJAX and render <img src="data:image/png;base64,..." />. - will this work? Or will CSP block it just the same? Suppose we make the request from Gmail content script code?
• change CSP to allow arbitrary locations, but only for image types - is this possible?
• turn it into a link that will open the image in new browser tab (this will work for sure but makes it inconvenient for users - it's much better to be able to see the image in the context of the email, as there may be several of them. Without having them right where the text is, it's hard to match the text surrounding the image to the image if it's a separate tab. So I'd like to avoid this.

[tomholub]

alternatively @sosnovsky if you have ideas

[tomholub]

A separate step after that will be #4956 in follow up version update

[sosnovsky]

I think we should try this way first, to see if it works:

Instead of letting the browser display the image with which triggers CSP, we could download the image using AJAX and render . - will this work? Or will CSP block it just the same? Suppose we make the request from Gmail content script code?

If no, maybe it's possible to be secure even with less strict CSP for img-src? As with current restrictions it will be difficult to have ability for viewing inline email images.

change CSP to allow arbitrary locations, but only for image types - is this possible?

It should be possible, as CSP allows to configure img-src per domain. But this way we can list only a limited number of domains, so not all remote images will be loaded.

[rrrooommmaaa]

But this way we can list only a limited number of domains, so not all remote images will be loaded.

img-src * isn't supported by Chrome?

img-src data: should be supported

[tomholub]

It should be possible, as CSP allows to configure img-src per domain. But this way we can list only a limited number of domains, so not all remote images will be loaded.

yes, if we went with this, we'd have to allow all, but only for images

so, we'll try the ajax request first. ok

[sosnovsky]

img-src * isn't supported by Chrome?

It's supported, but previously loading all images was disabled for security reasons - #3534

[rrrooommmaaa]

change CSP to allow arbitrary locations, but only for image types - is this possible?

So this option is insecure? If so, we're not considering it anymore?

[rrrooommmaaa]

There is also a feature of "sandboxed" extension pages with less limitations

https://developer.chrome.com/docs/extensions/mv3/mv3-migration/#content-security-policy

[rrrooommmaaa]

Also see #1509

[tomholub]

change CSP to allow arbitrary locations, but only for image types - is this possible?

So this option is insecure? If so, we're not considering it anymore?

I wouldn't say it's insecure to allow CSP for any image source, but it does remove some security barrier. There are other barriers in place. Of course, best would be to retain them all, if we can.

The reason to disable CSP for images from arbitrary sources is mostly so that if our HTML sanitizing code fails, an image doesn't slip in where it shouldn't. Mostly this means, we are trying to prevent tracking pixels and similar web nuisance that may show up in your email.

What can a tracking pixel collect? I suppose the IP o the user and their user agent. Which is the same exact information that they can collect when they send our user an email, and the client app tries to fetch a public key of the sender when verifying the message. Which will make request to sender.domain/(wkd url here), which gives them the IP and the user agent just the same.

The other reason we don't want images uncontrollably popping up in the encrypted message is so that the sender couldn't fake the "signed" green badge. But they could have as well sent an unencrypted message that is fake-signed, as far as current UI is concerned. So that really doesn't make much difference either atm.

So, enabling any source of img-src in the CSP doesn't seem that much of a difference in this context.

Still, it would be better to try the ajax approach first.