dr|z3d
finally got around to html e-mail in susimail, zzz.
zzz
yay? nay?
dr|z3d
some issues.
dr|z3d
it appears that when you're viewing html mails, the csp is being applied to the parent frame, not the iframe.
dr|z3d
I say not the iframe, it's being applied *both* to the parent window and the iframe.
dr|z3d
we're better off just using the sandbox tag on the <iframe>
dr|z3d
(maybe)
zzz
the iframe CSP is different from the parent CSP. The browser does not apply one to the other.
dr|z3d
it is here.
zzz
what browser
dr|z3d
firefox (librewolf)
zzz
that doesn't align with my testing or my understanding of the specs
dr|z3d
* The entry point for all web page loads
zzz
// very strict CSP for HTML emails in iframes
dr|z3d
it's testung based on the request parameter. are you sure that can't be called from the parent window?
zzz
the req param tells you what is being requested, e.g. iframe or not
dr|z3d
right, so if an iframe is requested, then the csp is being applied to the parent window it looks like to me.
dr|z3d
or I might be totally wrong. looking again.
zzz
look in network inspector
zzz
or just verify that imgs aren't loaded in iframe but are in the parent
dr|z3d
yeah, ok, I think it's me, I had the parent window csp too tight for what Im trying to do. my bad.
dr|z3d
that said, font-src 'none' is probably a bit too tight on the iframe content.
zzz
why? we can't allow remote fonts, and an email isn't ever going to try to load a font from localhost
dr|z3d
sure it is, html e-mails will more often than not have embedded css with a font-family: rule.
zzz
font family is fine, but specifying a URL to load the font is not
dr|z3d
indeed. we don't want remote fonts, but font-src 'self' is fine.
zzz
I believe self would allow a localhost URL. without a URL, it can still load fonts the browser has natively
zzz
font-src is about explicit fetching
dr|z3d
> If font-src 'none' is specified in a CSP policy, it will prevent locally hosted fonts from loading via font-family. This directive restricts the sources from which the browser can load fonts, and setting it to 'none' means that no font sources are allowed. This includes locally hosted fonts and fonts referenced in the CSS using @font-face.
dr|z3d
so maybe we're ok with font-family then.
zzz
right. "hosted" != browser native fonts
zzz
we aren't shipping and hosting any fonts in the console
dr|z3d
ok, well other than those 2 non-issues, "yay!" from me.
dr|z3d
plus ships with fonts, but I can't see that I'd want to use those for html mail, so no issue.
dr|z3d
the sandbox tag you might want to look at for extra peace of mind.
dr|z3d
I'm using that on the iframe in combination with a csp nonce for scripts.
zzz
not familiar w/ sandbox, but 'peace of mind' isn't usually our standard for doing something
dr|z3d
let me rephrase. for even more security hardening, I recommend you look at the sandbox iframe tag :)
Snowflakes
iframe is legal?
Snowflakes
is an ifrmame legal*?
Snowflakes
iframe
dr|z3d
not in your jurisdiction, Snowflakes :)
dr|z3d
and it's probably not a bad idea to add nonces to the scripts.
dr|z3d
ok, finally have the iframe embedding working as intended. after some UI work, I think the next stage is a toggle to enable inline images.
dr|z3d
ok, some suggestions re UI, zzz. the Display as HTML / Plain Text button could go in the top navigation with the main buttons.
dr|z3d
and the "We're protecting you from remote content" warning could sit immediately underneath the nav when in HTML mode.
dr|z3d
in the warning div, a toggle button to "Load remote images" could reload the page with a different csp that enables remote images to load.
dr|z3d
if you do decide you want to enable remote images on a toggle, it's might be an idea to strip any request parameters from images that look like trackers, or continue to block obvious tracking images eg: those with height="1" width="1" or similar tags.
dr|z3d
in the email I tested with html view, looking at something along the lines of: <img src="https://foo.com/track/open.php?u=8237423h4kjhkdfjhskfd34&id=897349237492&e=87832482d" height="1" width="1" alt="">
zzz
there won't be much room at the top after search box goes in
dr|z3d
sorry, not right at the top, underneath the mail header, before the mail body.
zzz
oh yeah no search box on mail view
dr|z3d
yeah, you want the toggle html/plain button to be separate from the main nav.. makes sense to put it underneath the main header.
zzz
but try testing 1000 emails like I have, not just one ))
dr|z3d
and then at the top of the mail body underneath the header would be the "blocked content" warning.
dr|z3d
:)
dr|z3d
give me a minute or 2.
dr|z3d
a very hacky fix for white e-mails in the dark theme is an invert filter on the iframe.
dr|z3d
ok, further testing reveals that for e-mails that rely on default browser colors ie they don't set any, possible issues in dark theme.
zzz
i tested dark theme for readability. if the "issue" is just that the email doesn't respect the default, that's not much of one
dr|z3d
black text on black background is the issue.
zzz
I flopped the background in the dark css iirc
dr|z3d
flopped? is that a technical term? :)
zzz
we'll see what the users have to say about it all in a few weeks. In the meantime, what's on the list is search.
dr|z3d
if I sound overly critical, not meant to be. it works well enough, minor css issues aside.
dr|z3d
so, you know, good work, soldier! :)
zzz
no, my only issue is you've diverged so far it's hard to put much stock in the specifics, esp. when you're giving feedback before you've fully merged, thats all
dr|z3d
I'm merged, I'm just working on cosmetics now. anyways, search. what's the plan now? did you get around to looking at that more compact db backend?
zzz
basic search MR up for a month
zzz
my enthusiasm for cached full-text search index is nowhere near the amount of work it would be