Posted Nov 29, 2019, 12:59 AM UTC
This to me reads like one of those bugs that's really hard to track down the root cause of. I think a huge majority of Firefox users also don't use more than a single content blocker, which would make this low priority.
It's bad that it's gone unfixed for so long but saying that they're wilfully ignoring it due to some vague political reason feels like a stretch.
The problem with this is that it can cause issues with any addon that use CSP injection to modifies headers.
I think at one point Mozilla should freeze development for a few months and completely focus on fixing bugs. Start with the oldest ones and work yourself forward.
That already happens, when a build moves from Nightly to Beta it is frozen and only bug fixes occur, once key bugs are fixed it moves to Stable.
once key bugs are fixed it moves to Stable.
I know. They won't release a complete mess and even the beta is very stable in my experience.
I'm a layperson so I won't pretend to know if they are having the right priorities but from the outside it looks like there are a lot of issues like "yeah we should fix that but don't have the resources right now".
There is an external patch for it available: https://github.com/tartpvule/my-firefox-patches/
if you don't want to compile firefox yourself, you can also apply it at runtime using autoconfig: https://github.com/tartpvule/my-firefox-patches/issues/2#issue-481998289
(incidentally, autoconfig is also on the chopping block: Bug 1514451)
Why not submit these patches to get merged? That's how it should work, no?
the patch was declined as it apparently caused (unspecified) performance regressions. which, well, "duh", of course correctly merging headers takes more cycles than just discarding some of them.
So if you only use one blocking extension (uBlock Origin) then you are fine?
Yes
or only set CSP header via uBO
IIRC Raymond or someone has mentioned that it gets complicated if the original response already contains CSP header.
it gets complicated if the original response already contains CSP header
It's the opposite
[deleted]
I'm guessing this is too complex an issue to do what I'm about to suggest (Else it would have already been patched internally by the official devs), but if it is feasible for an individual or small group to do, given that Firefox is an open-source project, could a patch be designed and offered to Mozilla from the outside on a silver platter?
At that point, it would either be accepted or rejected with an explanation. If its a good patch, it'd probably be accepted. Maybe the official devs would need some time to spruce it up and make it better, and to make sure it fits in with all the other moving parts of the code on various platforms and long-term development plans, but ultimately, one would think it would be adopted.
There are enough stakeholders who know how to code- the devs of every CSP related extension, for starters, plus probably some Linux distro people and others who depend on Firefox, plus various closely forked browser devs, that some sort of collaborative effort might be able to provide a solution.
The problem is, not all developers are interchangeable. For starters, extension developers work in JavaScript, which is very different from the programming languages used to build Firefox (mainly, C++ and Rust). Even within that, familiarity with the build process and code structure takes time. A bug like this sounds like it would require deeper knowledge into the code itself, which takes time to build, and usually requires doing smaller, easier tasks to build (and takes away time from other tasks). All of this together limits who can and will work on these bugs.
I’m using both ublock origin and https everywhere currently. Should I stop using https everywhere completely? Or is there a way to partially disable things so there is no longer conflict?
Just don't use HTTPS Everywhere in EASE mode with uBo, as I believe that's where the CSP issue may occur.
Thanks!
one of the discussions on r/firefox was at one point temporarily shadowbanned
Nice one.
Oh, that's great to know...
I sent feedback to them and mentioned that this bug makes me _feel_ less secure - hopefully to elicit a response to the emotion. If people feel less secure using Firefox, they will stop using it.
If there are technical, human resource, or software development priority related issues that are going to delay a fix to this issue indefinitely, there is something Mozilla could do that would be useful:
Find a way to clearly label extensions that modify CSP headers so that people who feel they need limit themselves to only one as a workaround can do so knowledgeably, without uninstalling a lot of things just because they think they might trigger this bug.
Another thought would be to let users prioritize or select which extension(s) is/are given CSP header modification access, so that users can make sure their favorite extension is what's running at 100%, and other extensions are limited to only those features that won't step on its toes.
That would be a nice feature to have.