User.js: sticky: unofficial: the extension csp header modification game [1462989 + 1635781 resolved 78 / ESR78.1]

[Thorin-Oakenpants]

Anyone want a game of craps?

• required reading: #265
• bugzillas: 1421725, 1417249 marked duplicate of 1477696, and 1462989
• short description: when two or more extensions use CSP injection to modify headers on the same page, only one wins. It doesn't matter who: first loaded, first modified - don't care: the fact is only one extension will achieve what it is meant to, the other(s) will fail
• FYI: The wiki page for extensions has been updated to reflect just how dangerous this is (such as JS blocking not getting blocked), but is by no means definitive

Use this sticky to report where settings use CSP: especially in our recommended extensions - outside of those, I don't really care, but it would be interesting, for example, to know that other popular extensions such as ABP or even Chameleon cause issues

:star: CSP header injection is used extensively in uBlock Origin, for example (see gwarser's comment four posts down). The entries below are some features you could consider disabling (or achieving another way) to reduce CSP header injection issues, depending on what extensions you use. It is up to you to determine what mix you want

template

- extension: 
- setting:
   * comment
- solution:

TIP from gwarser :kiss: CRX viewer and search for !content-security-policy. (! means scan all files.) If they touch this header, they are potentially unsafe.

[Thorin-Oakenpants]

• extension: uBlock Origin
• setting: uncheck Dashboard>Settings>Block remote fonts
  
  
  
  • This sets a font rule and font rules use CSP header modification [no word from gorhill if font filters are an issue, asked twice, I guess he's busy - @gwarser then]
  
  
• solution: use Request Control (or maybe font filters in uBO? there's a uBO wiki page about that - if I can find it and it's relevant)

[Thorin-Oakenpants]

• extension: Canvas Blocker
• setting: Misc > Block data URL pages
• solution: uncheck it. Not sure if RFP covers this, but it certainly causes blockage failure as seen in multiple issues raised at CB's repo

[Thorin-Oakenpants]

• extension: HTTPS-Everywhere
• setting: uncheck toolbar icon dropdown> Encrypt All Sites Eligible (EASE)
  
  
  
  • by default this is unchecked
  
  
• solution: make sure any bookmarked URLs are HTTPS and disable any mixed content. Maybe use a different extension like HTTPZ - disclaimer: you will need to check any extension yourself to make sure it does not use CSP header injections

[gwarser]

This will not be so easy in uBO. I don't think CSP can be safely disabled without modifying uBO code. Also, disabling CSP filtering will cripple uBO a lot. uBO will need to be the one extension with CSP enabled.

Starting from here: https://github.com/gorhill/uBlock/blob/87feb47b51202cb8464eab91597b706965a224f3/src/js/traffic.js#L764

• Inline script filtering is powered by CSP (except for HTML filtering - ##^, but this will not work for all scripts)
  
  
  
  • dynamic filtering - example: example.com * inline-script block
  
  
  • static filtering - ||example.com^$inline-script (over 100 filters total)
  
  
  • "no scripting" feature - no-scripting: * true
  
  
• Inline fonts:
  
  
  
  • "Block remote fonts" feature - no-remote-fonts: example.com true. Related code: 1 (called for main_frame), 2, 3 (Not related to $font network filtering option)
  
  
  • $inline-font static filter option, but I cannot find even one in my dump of uBO compatible filters from filterlists.com
  
  
• Any filter list can use $csp= filters, and there are lot of them. ~400 in uBO "Filter lists", over 800 total.

[tartpvule]

• extension: uMatrix
• settings:
  
  
  
  • Inline script blocking
  
  
  • Inline style blocking
  
  
  • "Forbid web workers"
  
  
• solution: just be aware that these features use CSP header injection, so perhaps to reduce the possibility of conflicts, depending on your extensions and their settings, set per scope if possible?

FYI, if it is ever used by security extensions, Feature-Policy will have much of the same problems as today's CSP.

[curiosity-seeker]

* solution: use Request Control (or maybe font filters in uBO? there's a uBO wiki page about that - if I can find it and it's relevant)

I think you mean this one. It doesn't answer the question if font filters cause this problem as well or not, though.

[gwarser]

About "font" blocking:

CSP is used only for blocking inline fonts (base64 encoded). Inline fonts are blocked only when "No remote fonts" popup switch is used, or if specified in static filter option $inline-font. $font option block by _classic_ web request blocking.

[curiosity-seeker]

@gwarser : Just to make this perfectly clear: $font does not use CSP, and $inline-font does not use CSP, either. Correct?

[atomGit]

not correct - gwarser is saying that $inline-font when used in a static filter, such as the filter subscriptions, DOES use CSP - i just checked some of the bigger filter lists (easy, adguard, fanboy and the uBlock filters) and none use $inline-font

[curiosity-seeker]

not correct - gwarser is saying that $inline-font when used in a static filter, such as the filter subscriptions, DOES use CSP - i just checked some of the bigger filter lists (easy, adguard, fanboy and the uBlock filters) and none use $inline-font

Yes, you're right. According to this wiki site $inline-font uses CSP.

[atomGit]

WTF went wrong with github's clock

nothing, why? we posted those comments about 7 hrs. ago, honest - you know, they say people who've been abducted by aliens experience missing time

[claustromaniac]

[Aeriem]

Hello there,

I'm sorry for the months of silence, life found its way to catch up to me and stomp me hard.
HTTPS-Everwhere's team is now aware of the CSP issue (HTTPS-E conflicts with NoScript in Tor Browser at Safest security setting when the EASE mode is enabled #17735).
I'm hoping that since this affects TBB, Firefox's developers will see how critical this issue actually is.
Much luv' and congrats on the spring cleaning! It was so easy to get back in the privacy game thanks to your efforts on the documentation and pref cleaning, I'm baffled. Overrides also are much fewer than they used to be. :D

claustromaniac's edit: The creepy stalker is back! (you didn't think I would forget about that, did ya?)
Aeriem's edit: Oh for Pants' sake, why did it have to stick? cries in stalker Still, it's heart-warming to see you haven't forgotten me despite my long absence! :heart:

[pipboy96]

This is why there should be an official way to apply CSP and FP to web pages that's standardised, instead of current hackish way.

[Aeriem]

I completely agree.
Hopefully this will be resolved in the near future.
Can anything be done to help?

[Aeriem]

Imma scared, did you infiltrate Mozilla's headquarters? 😱
Blink twice if you need us to exfiltrate you quickly!

I'm curious though, are you working with the devs from the Bugzilla tickets you linked? Because that'd be super cool.

[pipboy96]

@Thorin-Oakenpants Um, everything's fine? Should we be scared?

[Aeriem]

Must admit I had to reread some sentences to fully get you haha!
But I'm no better with mine, so who am I to judge? 🤷

I feel like the conversation is getting a bit personal and out of the scope of this git issue, but I'd love to carry it on somewhere else (if you don't mind).
Hit me up if you want to.
Still, I'm sorry for your loss and your work is appreciated. I learned so much from this repo.

@pipboy96 Thank you again for taking the time to review this issue, and sorry for the flood. Also, Pants quirky personality is one of the reasons this repo is quite fun to read.

[crssi]

Yeah, maybe @Thorin-Oakenpants is not aware of, but a most of times the writing is real fun to read.
Sorry for the loss.

[pipboy96]

@Thorin-Oakenpants I'm sorry for your loss. May your friend rest in peace.

[atomGit]

sorry about your loss Pants - wish i had some magic words that would help, but i never know what to say in circumstances like this

Can anything be done to help?

vote for 1421725

[atomGit]

what happens if content_security_policy is contained in the manifest of an add-on, but content-security-policy isn't contained anywhere?

"content_security_policy": "default-src 'self'; connect-src ws:; style-src 'self' 'unsafe-inline'"

[gwarser]

This key in manifest applies only to extension https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/content_security_policy

Your example is bit unusual with (not encrypted) websocket and inline stylesheets.

[atomGit]

ok, i understand now - Echo for Kodi is the ext. i'm referring to btw

[WellOrientedLlama]

Just for the record, it seems that the last add-on to be loaded by Firefox wins the race and gets its HTTP header changes through, crushing other extensions' tweaks.

So my Firefox starts with the page about:addons, and on each startup and each add-on update, I disable uMatrix and reenable it again, so it is always the last add-on to be loaded by the Fox. Then it wins against uBlock Origin's relevant features which is what I wanted.

This bug really cries for people not to install many add-ons, it sucks. And Kris Maglione's stance bah, it's okay, let's say there's nothing to do also sucks.

Additionally I...don't think it's limited to CSP ? Shouldn't any HTTP header be affected ? uBO's blob: or data: filters are also affected, if I recall correctly (been a while), though I don't know how uBO translates them internally.

[Atavic]

Additionally I...don't think it's limited to CSP ? Shouldn't any HTTP header be affected ?

Any addon race that's conflicting on the same header's modification acts the same.

[earthlng]

Additionally I...don't think it's limited to CSP

no it's not limited to CSP but CSP is the most important one if you care about reliably blocking inline Javascript.

Shouldn't any HTTP header be affected

yes any HTTP header is affected if 2 or more addons try to modify the same header

uBO's blob: or data: filters are also affected

yes but AFAIK uBO blocks or limits those by using a CSP header

[kah0922]

Well, it seems like shit is actually being worked on now in bug 1262989.

[travankor]

Alternatively, recompile Firefox with the patch from this repo https://github.com/tartpvule/my-firefox-patches (see #265, except it's closed)

I'm disappointed that neither Tor nor mozilla care about this issue -- maybe it's an intentional loophole to make it easier to identify Tor browser users?

[andretiagogr]

I'm disappointed that neither Tor nor mozilla care about this issue -- maybe it's an intentional loophole to make it easier to identify Tor browser users?

Tor doesn't recommend installing extensions and NoScript and HTTPS Everywhere won't conflict with each other because EASE is disabled by default. That's probably why Tor doesn't care

[KOLANICH]

EASE is disabled by default

That's shit.

[rusty-snake]

EASE is disabled by default

That's shit.

Default security level: Standart
Reason: compatibility

[atomGit]

just a heads up on the CSP issue :)

Status: NEW → ASSIGNED

[Thorin-Oakenpants]

I know. I've kept a close eye on it since day 1. I've actually met Shane (mixedpuppy). Anyway, I created a new label to apply to #265 and this ticket when it gets done

It's also going to get used on #448 because a solution for that is actually already available, it just needs some perf work before it lands gets flipped on (not going to say anymore since the tickets are access denied)

[atomGit]

support merging content-security-policy headers provided by multiple extensions
Status: RESOLVED FIXED
Milestone: mozilla77

anybody know what "fixed" means? i looked at the latest activity and i have no idea how this was fixed or what the fix translates to in terms of how extensions are affected

[gwarser]

Previously, when original response had CSP header and extensions tried to set another, extension api had knowledge of original (from server) header and was able to set headersAlreadySet flag which instruct Firefox to merge headers.

When original response did not had CSP header, extensions running in different _threads_ "at once" did not have chance to read headersAlreadySet set by other extension, so all extensions thought that they have only header and they do not instruct Firefox to merge headers - only one "win".

Now headersAlreadySet for CSP is pre-set / hardcoded, so extensions headers will always be merged.

[atomGit]

thank you for that explanation, but it's a bit over my head technically

currently i have 3 extensions that make use of CSP, one being uMatrix

in order to ensure that uM takes precedence, every time i start FF i must disable, then enable uM so that it becomes the last (or first?) in the chain, else in-line JS may not be blocked

so my question is, would one still need to do this in FF 77?

given your explanation, i'm guessing the answer is 'no', but i'm not sure

[Thorin-Oakenpants]

I'll await anointing any jesus was listening labels until it's all been tested. My understanding is that there are still potential issues e.g. if two headers clash- but IANAE

[uBlock-user]

That bug specifically fixes CSP header clashes with a force merge, nothing else. All other headers may still clash.

[travankor]

Is there a tl;dr of what we need for a comprehensive fix (ie: what's left to do)?

[Thorin-Oakenpants]

Is there a tl;dr of what we need for a comprehensive fix (ie: what's left to do)?

• test: assigning gorhill, gwarser, earthlng, and uBlock-user : feel free to participate
• investigate (for peace of mind), update documents: e.g.
  
  
  
  • I for one would like to know how this compares to header merging pre-WebExt
  
  
  • what pitfalls still exist (maybe they always existed)
  
  
• wait for it to land in stable
• assign jesus was listening label
• get naked and drink beersies (optional)

[curiosityseeker]

That bug specifically fixes CSP header clashes with a force merge, nothing else. All other headers may still clash.

Okay - but since the problem we're discussing here is about CSP headers (and not about other headers) it should be fixed now, shouldn't it?

[uBlock-user]

Fixed in Nightly yes.

[girst]

Hi, I'm the guy who wrote the patch. Oof, what a journey! If you want a
pracical easy-to-repeat test, try this:

1. install uBlock Origin (optional, for 2nd and 3rd tests)
2. install uMatrix
3. install HTTPS Everywhere (order matters!)
   alternatively, disable and reenable the extensions in the above order
   to make sure their CSPs have the expected precedence
4. navigate to http://girst.2ix.at/tmp/webfont.html
   observe:
   
   
   
   • it will not redirect to https://...
   
   
   • "Javascript is enabled"
   
   
   • "Webfonts are [][][][][][][][]" (enabled)
   
   
5. block javascript using umatrix and refresh page
   observe:
   
   
   
   • "Javascript is disabled"
   
   
6. enable "encrypt all sites" in https everywhere and refresh page
   observe in nightly:
   
   
   
   • you are redirected to https://...
   
   
   • "Javascript is disabled"
     
     observe in release:
   
   
   • you are redirected to https://...
   
   
   • "Javascript is enabled" (!!!)
   
   

optional 2nd test:

1. enable font-blocking in uBlockO
2. using ctrl-f5, clear the cache and refresh the page
   observe in nightly:
   
   
   
   • "Webfonts are disabled"
     
     observe in release:
   
   
   • "Webfonts are [][][][][][][][]" (enabled) (!!!)
   
   

optional 3rd test:

1. disable and reenable uMatrix
2. disable and reenable uBlockO
3. reload page
   observe in nightly:
   
   
   
   • everything still works
     
     observe in release:
   
   
   • "Javascript is enabled" (!!!)
   
   
   • "Webfonts are disabled"
   
   
   • unexpectedly, upgrade-insecure-requests still works (maybe some
     
     browser caching going on?)
   
   

[uBlock-user]

@girst Thanks, without you, this bug would have never been fixed. Does this issue still exist for lets say Feature-Policy or any other header ?

[girst]

On Thu, Apr 16, 2020 at 07:09:11AM -0700, Saitama wrote:

Does this issue still exist for lets say Feature-Policy or any other
header ?

yes. i submitted 2 variations of the patch, one that would apply to all
headers, and one that only applies to c-s-p. mozilla/mixedpuppy went
with the second one.

however, adding Feature-Policy to the exception "must-merge" list would
be pretty easy: just add it to the headersAlreadySet set (and add a
test, of course).

[travankor]

According to security expert Daniel Micay, firefox "fails open" when it comes to web extensions.

@uBlock-user @girst

Is this relevant to the discussion? If UBO dies from OOM or a malicious adversary, will firefox allow arbitrary connections?

[girst]

On Sun, May 24, 2020 at 03:09:23AM -0700, travankor wrote:

According to security expert Daniel
Micay,
firefox "fails open" when it comes to web extensions?

did some tests: yes that seems to be the case D:

i do understand why firefox does it this way (not every extension is
designed to block requests, and the browser would be completely unusable
if it were to block all network requests when an extension dies)

Is this relevant to the discussion?

well, not directly to the topic of this thread

If UBO dies from OOM, will firefox allow arbitrary connections?

yes. there are some steps to reproduce, with today's nightly:

1. install umatrix and ublocko
2. navigate to https://gir.st/tmp/webfont.html
3. in ublock, block remote fonts. in umatrix block javascript
4. reload with ctrl-f5 and notice requests are blocked
5. in a seperate tab, go to about:memory and hit "Measure"
   on the right, you'll see a list of all of fx's processes. note the
   one called "WebExtensions" and its process id.
6. open a terminal and issue kill $PID_OF_WEBEXTENSION_PROCESS
7. click on Measure again. the WebExtensions process should be gone. (if
   it isn't, kill -9 it, maybe)
8. reload with ctrl-f5 and notice requests are now going through.
   the browser console / terminal i started fx from will also fill with
   errors.

as far as i can tell, the webextension process is _not_ restarted
automatically. after a few minutes, i restarted the browser to get it
back.

in my opinion, that last part, is the actual bug: if the webextension
process dies, it should restart automatically, or at the very least warn
the user. right now, the extension icons still show in the chrome, and
only when clicking on them you'll notice that the extension doesn't
respond.

looking at BMO, this appears to already be tracked:
https://bugzilla.mozilla.org/show_bug.cgi?id=1355239 -- and it even has
an assignee since a few days :D

[girst]

digging around in the bugs mentioned in the one from the last email:
this comment[1] mentions extensions.webextensions.remote. setting it
to false runs webextensions from "the parent/main process"[2].
there also appears to be a
extensions.webextensions.background-delayed-startup pref that might be
interesting[3] to some of you (i haven't found much documentation, other
than a note that it is not going to stick around forever).

[girst]

apologies for the spam (last one, i promise).

some caveats regarding webextensins.remote:

As Andrew noted, extensions.webextensions.remote is not really
supported. Its removal was planned in bug 1613141, but I'll hold off
from doing so until we have a decent recovery strategy for extension
process crashes (especially since we cannot remove all related code
until we support out-of-process extensions on mobile).

https://bugzilla.mozilla.org/show_bug.cgi?id=1627139#c10

[Thorin-Oakenpants]

indeed .... https://github.com/uBlockOrigin/uMatrix-issues/issues/231#issuecomment-596062505

[curiosityseeker]

yes. there are some steps to reproduce, with today's nightly: 1. install umatrix and ublocko 2. navigate to https://gir.st/tmp/webfont.html 3. in ublock, block remote fonts. in umatrix block javascript 4. reload with ctrl-f5 and notice requests are blocked 5. in a seperate tab, go to about:memory and hit "Measure" on the right, you'll see a list of all of fx's processes. note the one called "WebExtensions" and its process id. 6. open a terminal and issue kill $PID_OF_WEBEXTENSION_PROCESS 7. click on Measure again. the WebExtensions process should be gone. (if it isn't, kill -9 it, maybe) 8. reload with ctrl-f5 and notice requests are now going through. the browser console / terminal i started fx from will also fill with errors. as far as i can tell, the webextension process is _not_ restarted automatically.

Thanks, I could reproduce. This should not happen. However, the question is: how relevant is this in practice? I've never seen my extensions dying. But obviously it does happen according to the uMatrix issue mentioned by Pants.

looking at BMO, this appears to already be tracked: https://bugzilla.mozilla.org/show_bug.cgi?id=1355239 -- and it even has an assignee since a few days :D

Good. If Rob Wu takes care of it a solution should not be far away.

[girst]

On Sun, May 24, 2020 at 07:43:09AM -0700, curiosityseeker wrote:

Thanks, I could reproduce. This should not happen. However, the
question is: how relevant is this in practice? I've never seen my
extensions dying. But obviously it does happen according to the uMatrix
issue mentioned by Pants.

I guess you have to be both a tab hoarder and only limited amount of
memory available. I can't say I personally seen it happen on any of my
machines.

If you're worried you might be affected, I cobbled together a small
shell script that can warn you whenever the process dies.

 tail --pid=`grep -H WebExtensions /proc/*/comm | awk -F/ '{print $3}'` -f /dev/null &&
   zenity --info --text 'WebExtension process died!'

It's a bit dense, but here's how it works:

• we search all available processes' comm file for the name of the
  process, "WebExtensions", and extract the PID (grep -H includes the
  path in the output, which we split on '/' and extract the PID w/ awk)
• tail --pid (another gnuism) waits for a process with said pid to exit
• once tail exits, pop up a info box using zenity. this could of course
  be replaced by anything you'd want to do when this happens (e.g. kill
  firefox).

[Thorin-Oakenpants]

This OOM / extention-hard-fail is OT, but I thought I would share, because sharing is caring - anyone want a hug? I haven't broken my solitude or left my shack in the remote woods for eight weeks, and I promise to shower with lots of soap first. Any takers? I'll be gentle.

@geeknik mentioned, in a now deleted post (why do you keep deleting posts right after you make them), defense in depth, about using something like PiHole on the router. Sure. You could also use the OS level.

Now I was thinking about Tor Browser users, and how TB doesn't ship with any adblocking (except tails). And this can be detected, indeed, even specific rules. All TB users on Tails should look the same in this regard, assuming that the default lists are static, lists used are not changed, custom filters/rules aren't added, etc.

IANAE on this: Does PiHole or similar affect your Tor Browser fingerprint. I mean, you're not the one making the final request for the content, so does it still come through, or is it blocked?

Besides that: when/if TB ships with some sort of adblocker (needs a lot of work, investigating: but gk is totally against blocking ads since it enables content: i.e it would also hurt the little guys): imagine the savings on the Tor network :)

[curiosityseeker]

I guess you have to be both a tab hoarder and only limited amount of memory available.

Indeed, I don't belong to that group.

tail --pid=grep -H WebExtensions /proc/*/comm | awk -F/ '{print $3}' -f /dev/null && zenity --info --text 'WebExtension process died!'

Cool ! I don't think that I need it - but I've learned something new from it. Thanks!

[curiosityseeker]

Does PiHole or similar affect your Tor Browser fingerprint. I mean, you're not the one making the final request for the content, so does it still come through, or is it blocked?

It is blocked. FWIW, I'm not using PiHole but dnscrypt-proxy with a huge blocklist. I've just tested it on https://browserleaks.com/proxy with uBO disabled. It didn't detect any content filters or filter subscriptions (which it does if uBO is enabled). Hence, the TB fingerprint should not be affected. Although that's certainly not a guarantee: If something is blocked by that blocklist which is also blocked by one of the well-known filterlists, it might be misinterpreted by the code running on such sites.

However, needless to say that solutions like PiHole, dnscrypt-proxy or AdGuardHome block adservers and tracking/malware domains on the DNS level very efficiently. But they are not able to block something like, e.g.,

https://a.nytimes.com/svc/nyt/data-layer?sourceApp=nyt-vi&referrer=&assetUrl=https%3A%2F%2Fwww.nytimes.com%2F&

which is blocked in uBO by the following rule: ||nytimes.com^*/data-layer? So both blocking approaches are not really comparable.

[travankor]

I'm on FF 77.0.1 and the parent issue is still there. I'm using an old profile and disabled and re-enabled all extensions. I will try this on a new profile later on.

[girst]

On Fri, Jun 05, 2020 at 05:54:42AM -0700, travankor wrote:

I'm on FF 77.0.1 and the parent issue is still there. I'm using an old

How did you determine if it's still broken? If you can give me your STR
and list of extensions I'll have a look.

[travankor]

I tried the test you added here on a clean profile (no user.js) and it fails everything.

In the console, I have TypeError: setting getter-only property "suspended".

I think this might be unrelated to the bug in this thread.

[girst]

On Fri, Jun 05, 2020 at 08:12:58AM -0700, travankor wrote:

I tried the test you added here on a clean profile (no user.js)
and it fails everything.

I just re-did the test. After you deactivate and reactivate the addons,
you'll need to re-disable webfonts/javascript. It looks like, if you
don't save those changes, they get reset when you disable the addon
(which makes sense, in hindsight).

In the console, I have TypeError: setting getter-only property "suspended".
I think this might be unrelated to the bug in this thread.

can't reproduce this.

[travankor]

This took an embarrasingly long time to figure out (although I realized as soon as I took a break and came back to this), but I had an obsolete autoconfig.js file in my firefox root directory.

I was under the impression that my package manager would have cleaned up these obsolete files a while ago, but apparently this is not the case... moral of the story: trust but verify.

[travankor]

you'll need to re-disable webfonts/javascript. It looks like, if you
don't save those changes, they get reset when you disable the addon

Note that user.js has a option that disables webfonts, too (or, at least, your test fails with this option set). However, it seems like UBo blocks more content than the native FF option.

And HTTPS Everywhere needs to be refreshed twice for it to take effect although you can use HTTPZ as an alternative

[gwarser]

https://bugzilla.mozilla.org/show_bug.cgi?id=1635781 "Cannot replace frame-ancestors directive of the Content-Security-Policy HTTP Header via the webRequest API" was fixed.

---

This commit fixes the bug by tracking the CSP status on the
ResponseHeaderChanger instance, which is shared by all webRequest
handlers of a single request.

So it was possible after all to track this between processes?

[travankor]

cc @girst

[girst]

On Thu, Jun 25, 2020 at 02:18:39AM -0700, travankor wrote:

cc @girst

no need to ping me, i'm still cc'd to this bug ;-)

it looks like this breaks the fix, according to a quick test i did. i
already commented on the ticket on bmo with a shortened version of the
str i provided to this thread earlier.

https://bugzilla.mozilla.org/show_bug.cgi?id=1635781#c18

[girst]

well, embarrassing: repeating the test made it work again. :|

(and there /is/ a regression test for it...which i wrote. and it
evidently passed that one on check-in)

[Thorin-Oakenpants]

So this is "fully" resolved now in 78+ and ESR78.1 (when it comes out)

[jawz101]

Does this mean this wiki page is no longer relevant? I'd rather not have to think about all of the factors it suggests to toggle in each extension or whether NoScript is not a recommended addon if the issue is now a non-issue.

[Thorin-Oakenpants]

if you're on stable, then the CSP stuff doesn't apply to you. Once ESR68 reached end-of-life, I will remove all the CSP warning