custom CSS doesn't work on lore.kernel.org feeds

[marlop352]

Custom CSS doesn't cause any change on the feeds on https://lore.kernel.org, example: https://lore.kernel.org/lkml/new.atom . Doesn't seem to fail on all atom feeds as this: https://github.com/aureliendavid/rsspreview/releases.atom works fine.

I'm using this CSS:

html {color: #bbbbbb; background-color: black !important;}
#feedBody {background-color: #1e1e1e;}
.enclosures {background-color: #2e2e2e;}
a {color: #8FC2EF;}
a:visited {color: #DFC2EF;}

adapted from: https://github.com/aureliendavid/rsspreview/issues/35#issuecomment-504349484

Tested on a clean profile to make sure it wasn't interference from any other add-on or Firefox config option.

Sysinfo: Windows 11 Firefox 95.0.2 x64

[aureliendavid]

Hi,

Thanks for this report.

It looks like this has something to do with the Content-Security-Policy header.

The kernel.org feed contains this header:

Content-Security-Policy: default-src 'self'

which disallow lots of things, including loading inline css.

To be compared with the github feed whose content security policy header contains:

style-src 'unsafe-inline' github.githubassets.com

which specifically allow this. (And most other feeds don't have a CSP header so it works).

I have a workaround for this, which consists in adding style-src 'unsafe-inline' to the header if we need to, but I'm not 100% sure that we should be doing this.

I'm actually not seeing what problem this could cause, but I'm also a bit uncomfortable messing security headers.

I've pushed the workaround to a branch for now, to do some tests and think about whether this should be added to the extension or not.

If anyone has an opinion about this, I'll take it.

thanks

[marlop352]

Does their HTML pages also have the same header? The Dark Reader https://addons.mozilla.org/firefox/addon/darkreader/ and Stylus https://addons.mozilla.org/firefox/addon/styl-us/ extensions both works fine on the HTML pages but for some reason don't work on the pages generated by your extension (if I enable the Stylus theme after the RSS preview is already loaded it works but as soon as I refresh the page it stops working on the refreshed page until I disable and enable the theme again, Dark Reader doesn't work even if enabled after the RSS preview is loaded). Checking how they accomplish it might be useful, also If there is a way to make them work with your extension the custom CSS would not be needed for me.

Also the default CSS for the preview page loads fine, could the custom CSS option be modified to work the same way as the default CSS of the extension? or maybe create a fixed dark mode CSS to be loaded in place of the default one? That would also eliminate my need for the custom CSS option. it could be an option or work the same as the kernel.org CSS as it changes to dark mode if it detects that Firefox is using the dark theme(or something along those lines).

Now regarding changing the header:

• If that is the method used by Stylus and/or Dark Reader then there is already precedent for it so I'm fine with it.
• If that isn't the method used by Stylus and Dark Reader:
  • if one could use that to execute any code on the page then I would ask that another method be used.
  • if one can't use that to execute any code on the page then I'm also fine with it.
  • could the method used by Stylus and/or Dark Reader be used instead?
  • I suspect that is not the method used by Stylus as there is an option on the settings for it to "Patch CSP to allow style assets", it is disabled and stylus still works on the HTML pages and I assume the server is using the same CSP header on the HTML files that it uses on the .atom files.

[aureliendavid]

Hi,

Sorry for the delay on this issue.

After running a few tests and looking at what is done elsewhere, I concluded that, to keep things simple, it would be ok to add a "bypass CSP when needed" option to resolve this issue.

The option is disabled by default so as not to change anything for people who don't have a use for it.

I've released a v3.16 on AMO with this option.

You can enable it and try to ctrl+f5 the preview to see if it works, and reopen the issue if it doesn't.

thanks for the report

[marlop352]

I enabled the option, cleaned the cache, tried using ctrl+f5 but it still didn't apply the style Getting Content Security Policy inline default-src errors on the console. Direct link to feed: https://lore.kernel.org/lkml/new.atom FF is 97.0 now, extension is v3.16 according to the extensions manager.

edit: I didn't find a way to reopen the issue

[aureliendavid]

hm that's odd, I have the same version of firefox, same version of the addon, same feed, and the same custom css in the original post, and it works for me

[marlop352]

I think I found the issue: https://addons.mozilla.org/en-US/firefox/addon/https-everywhere/ disabling it for the site makes the CSS work. And on a clean profile it also works correctly. you probably can close this.

[aureliendavid]

good catch

I haven't looked at how https everywhere works in details but they are also rewriting headers, so depending on the order firefox runs addons on a page it might mess up the bypass csp strategy

i'm closing the issue but i'll try to look into the possible conflicts with https-everywhere