Images are by default not loaded in HTML views. The views are iFrames where we insert srcdoc. When the images need to be loaded however, on click, we proxy them through the app, so alps fetches them from remote and serves them from the webmail server. This hides the user's IP as well avoids HTTPS warnings.
In Firefox this does not work, it seems because of the sameSite policy Firefox has now:
Content Security Policy: The page’s settings blocked the loading of a resource at http://localhost:1323/proxy?src=https%3A%2F%2Fwww.post.ch%2Fstatic%2FNotifica%2F%2Fcicd%2Fpost-logo-de.png (“default-src”).
Iframe domain has to match the one of the app. I think the issue may be in the Content-Security-Policy given in server.go
What happens here is that the cookie in the proxy request does not get sent and the proxying request gets redirected to the login page.
We obviously need that cookie sent or else the server will become an open proxy.
Adding the explicit app domain to the Content Security Policy removes the Firefox errors. Setting the SameSite attribute to None allows the cookie to be sent. Based on these, I suspect that the issue comes from a mismatching iFrame domain instead of the CSP policy.
We cannot add the domain, as alps may be run with many different domains (cnamed host). Strangely, the document domain in the iframe matches the parent. It could be an issue while running in localhost though.
I believe this is the relevant firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1741489
I am not a security expert on cookies, but I assume setting SameSite to None (even with Secure) is too lax of a policy?
A workaround would be to pass some kind of token in the proxied URL.
I have a local workaround that uses the src attribute instead of srcdoc and serves the source HTML separately: https://paste.sr.ht/~koukas/3b0b417a4960e5caf49d9228d618d73e26648913 However, this adds an extra pass over the message and does not fit well the design of the viewer.
Separately from the proxy, for images with Content-ID source, the request for the message part is also sent without a cookie. The request requires authentication, so the token would act like a short-lived version of the session token.
