I disagree. There are way too many sites that require javascript that you'll eventually get into the habit of blindly enabling scripts when a site breaks, negating any security benefits.
>you'll eventually get into the habit of blindly enabling scripts when a site breaks, negating any security benefits.
The key here is that when you're deciding whether to whitelist a JS import, and you don't know what it is and don't want to take the time to look it up, then whitelist it temporarily not permanently. It will be moved back to the blacklist the next time you restart the browser.
Only permanently whitelist JS that you know for sure isn't a tracker or malware or sketchy.
What’s the whitelist based on? URI? Or file content hash? Because today’s “criticalsitefunctunality.js” is tomorrow’s “upstream got p0wned and there’s a Bitcoin miner in there too now”.
Sites churn so often that “permanently” whitelisting hashes is probably a never ending chore, and you’re unlikely to want to constantly re-inspect minimized JS, so this eventually turns into semi-blind faith.
And permanently whitelisting URIs is pure security theatre; that file could contain anything, next request.
If you have a better approach that accomplishes both of those objectives, do tell.
Use a browser that isolates the JS engine in its own process and leave spectre mitigations enabled rather than try to play kid-plugging-holes-in-dike-with-finger by auditing all the world’s constantly-changing JS for spectre/meltdown gadgets?
Definitely. All for that.
>and leave spectre mitigations enabled
I do that anyway. The performance cost is unnoticeable to my normal workloads.
>rather than try to play kid-plugging-holes-in-dike-with-finger by auditing all the world’s constantly-changing JS for spectre/meltdown gadgets?
I'll continue doing this too, largely because I want to see what's going on behind the scenes on all the websites I visit. Useful for me to see it all, especially as it changes over time as you observe.
That said, Easylist and Privacylist are also great if you'd rather crowd-source the finger-in-dike-hole-plugging.
Yeah I went through this too, figuring out all the CC purchase redirects. Some are just idiotic to the point I wish govts would pass a law mandating zero redirects for online purchases. Stripe, Paypal, Square, Braintree and a few others do payments just fine without the redirects so it's clearly possible.
But eventually even that gets solved and the redirects get whitelisted. Haven't encountered this problem for a long time.
That said, when there's something old, important, and/or dumb looking, I usually spawn a new Firefox container (using Multi-Account Container plugin) and use NoScript's temporary bypass function.
Security is only part of my motivation, though, and not the main part -- I mostly do it because it protects me by default from all the pop-up type crap that so many websites foist on you. Yes, it's a pain to un-break sites sometimes. But I resent it less than going through the equivalent pain in "privacy settings" popups, wriggling chat widgets, "ate you sure you don't want to sign up for our newsletter?" nags, etc. Websites are already broken; as long as that's true, I'd rather be in control of why.
Which is why I just use basic ublock origin and regulary wipe the browser cache.
What's the difference between that and just using the standard easylist/easyprivacy filter? I suppose there's a small chance that a third party site went rogue and isn't on the default lists, but I'm skeptical how many attacks that would thrawt in reality. The attacks I heard of tend to be first party/supply chain (would be white listed by you), or delivered through an ad network (probably already be on a blacklist).
It's not that hard, nor time consuming. Again, my wife can do it and she's not a developer.
Still though. There are sites that would not work at all until everything is enabled, including ads. Imagine not being able to buy a plane ticket because wizzair wants to serve you ads