3 ms·

> 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

> 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.

SkyMarshal 5y ago
I'm aware of all that, but it's not theater, it's just part of a defense in depth strategy. Reduces attack surface area, doesn't eliminate it, while maintaining usability of the web. If you have a better approach that accomplishes both of those objectives, do tell.
- gruez 5y ago
  I'm sure it adds some amount of security. I'm just skeptical it adds enough security to be worth the hassle. I discussed the threat model here: https://news.ycombinator.com/item?id=27564457 https://news.ycombinator.com/item?id=27564457 and came to the conclusion that it wouldn't prevent much attacks in practice.
- msbarnett 5y ago
  > 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?
  - SkyMarshal 5y ago
    >Use a browser that isolates the JS engine in its own process 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.

SkyMarshal 5y ago

I'm aware of all that, but it's not theater, it's just part of a defense in depth strategy. Reduces attack surface area, doesn't eliminate it, while maintaining usability of the web. If you have a better approach that accomplishes both of those objectives, do tell.

gruez 5y ago
I'm sure it adds some amount of security. I'm just skeptical it adds enough security to be worth the hassle. I discussed the threat model here: https://news.ycombinator.com/item?id=27564457 https://news.ycombinator.com/item?id=27564457 and came to the conclusion that it wouldn't prevent much attacks in practice.
msbarnett 5y ago
> 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?
- SkyMarshal 5y ago
  >Use a browser that isolates the JS engine in its own process 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.