Custom CSS does not apply to kernel.org main page feeds, regardless of bypass CSP preference

[mmkthecoolest]

Feeds used in the main Linux kernel site do not use the custom CSS with the extension (examples: https://www.kernel.org/feeds/all.atom.xml and https://www.kernel.org/feeds/kdist.xml), regardless of the bypass CSP setting. I double checked with #69 and lore.kernel.org still works.

Custom CSS to test with

#feedBody {
 max-width: 1100px;
 border: 0px;
 border-radius: 10px;
}
body {
 font-family: sans-serif;
}
video {
 max-width: 100%;
 border-radius: 5px;
}
img {
 border-radius: 5px;
}
.enclosures {
 border: 0px;
 border-radius: 5px;
}
h1 {
 font-size: 200%;
 border-bottom: 0px;
}
@media (prefers-color-scheme: dark){
  #feedBody {
   background-color: #222222;
  }
  
  #rsspreviewBody {
  background-color: black;
  
  }
  h2, #feedLastUpdate {
   color: #aaaaaa;
  }
  a {
   color: #aaaaff;
  }
  
  a:active {
   color: #ff5555;
  }
  .enclosures {
   background-color: #333333;
  }
  html {
   color: #eeeeee;
   background-color: black;
  }
}

[aureliendavid]

Hello,

Sorry for the very late response, I haven't had a lot of time to work on the extension in a while.

tl;dr: it should now work on v3.32 for https://www.kernel.org/feeds/all.atom.xml but not for https://www.kernel.org/feeds/kdist.xml

Some details:

the extension works in two passes:

1. first, we only look at the headers to try to detect feeds to patch stuff before the body of the page is received and handled by firefox (e.g.: force displaying the page instead of downloading it, and patch CSP header if needed)
2. once this is done we look at the body of the page to actually check if it's a feed (based on the root element) and do all the displaying

To do the first part, we mostly look at the Content-Type header. The correct mime types for feeds are supposed to be application/rss+xml or application/atom+xml.

The problem is that a lot of websites are serving their feeds with the (incorrect) text/xml mime-type.

I don't want to treat any xml document as a feed and mess with the headers if we're not sure this is actually a feed. I don't want the extension to be intrusive and step on documents that has noting to do with rss.

So a text/xml will not be seen as a feed on the first pass, which is where the CSP bypass occurs to allow for custom CSS on some pages.

But in the second pass it will be recognized as a feed if the content of the document matches. So it will be displayed, the custom css will be injected, but firefox will refuse to apply its rules if the unpatch CSP header disallows it.

---

In v3.32 I added a check in the first pass to handle text/xml documents whose url end with .rss, .rss.xml, .atom, .atom.xml. In this case we now do the header stuff like CSP bypass. So https://www.kernel.org/feeds/all.atom.xml will work.

So for the custom css not to work, a page will now have to:

1. send its feed as text/xml
2. AND send a CSP header that disallows inline styling
3. AND have a url not ending in .rss, .rss.xml, .atom, OR .atom.xml

e.g.:

• https://www.kernel.org/feeds/kdist.xml does 1, 2, and 3 so it doesn't work
• https://www.kernel.org/feeds/all.atom.xml does 1 and 2 only so it works
• https://lore.kernel.org/lkml/new.atom does only 2 so it works
• https://rss.nytimes.com/services/xml/rss/nyt/HomePage.xml does 1 and 3 only so it works

If we find lots of feeds that do all three I might add more rules to try to detect feeds based on the url (like matching /feeds?/ or something) but I'm reluctant to do so for now to avoid false positives.

Ideally websites would just send the correct content-type.

Hope this helps, thanks for reporting.