4 ms·

Well, this steps up the game quite a lot. I’d considered the CPU attacks relatively unconcerning because it required executing code locally. Bring able execute

Well, this steps up the game quite a lot. I’d considered the CPU attacks relatively unconcerning because it required executing code locally. Bring able execute from a web page makes for a broader attack vector.

gbrown_ 6y ago
JavaScript based examples are shown in the Spectre paper.
anyfoo 6y ago
You have to specify a whole lot more context if you talk about executing code "locally" vs. executing "from a web page". JavaScript usually gets JIT'ed into machine language code. That code gets executed locally. There are usually a bunch of differences in terms of form and restrictions around that code, but this might well be a case where most of those differences don't matter. Or in other words, browsers are just compilers/interpreters like any other, albeit very hardened ones because of the large exposure of untrustworthy code they are subject to. But if an attack fundamentally skirts around sandboxes, the browser sandbox won't help. It's Turing machines all the way down.
swiley 6y ago
This is not new and it's half the reason I browse the web in icecat/elinks. The other half being that most of the javascript out there is written without regard for resource consumption.
- paulryanrogers 6y ago
  What protections are unique to IceCat?
  - saagarjha 6y ago
    Presumably the different kind of "security by obscurity" that comes with using software that nobody else uses and thus nobody will spend resources targeting
    - warkdarrior 6y ago
      As far as I can tell, IceCat uses the same rendering and Javascript engines as Firefox, so it'll have the same security issues as Firefox.
  - swiley 6y ago
    IceCat disables JavaScript that it doesn't have in a database or isn't written in a non-recursive subset of the language. Each chunk of JavaScript has to be reviewed and explicitly enabled by the user before executing.
- forgotmypw17 6y ago
  i,ve also found that accessibility and content quality are strongly correlated, saving me reading time.

gbrown_ 6y ago

JavaScript based examples are shown in the Spectre paper.

anyfoo 6y ago

You have to specify a whole lot more context if you talk about executing code "locally" vs. executing "from a web page". JavaScript usually gets JIT'ed into machine language code. That code gets executed locally. There are usually a bunch of differences in terms of form and restrictions around that code, but this might well be a case where most of those differences don't matter. Or in other words, browsers are just compilers/interpreters like any other, albeit very hardened ones because of the large exposure of untrustworthy code they are subject to. But if an attack fundamentally skirts around sandboxes, the browser sandbox won't help. It's Turing machines all the way down.

swiley 6y ago

This is not new and it's half the reason I browse the web in icecat/elinks. The other half being that most of the javascript out there is written without regard for resource consumption.

paulryanrogers 6y ago
What protections are unique to IceCat?
- saagarjha 6y ago
  Presumably the different kind of "security by obscurity" that comes with using software that nobody else uses and thus nobody will spend resources targeting
  - warkdarrior 6y ago
    As far as I can tell, IceCat uses the same rendering and Javascript engines as Firefox, so it'll have the same security issues as Firefox.
- swiley 6y ago
  IceCat disables JavaScript that it doesn't have in a database or isn't written in a non-recursive subset of the language. Each chunk of JavaScript has to be reviewed and explicitly enabled by the user before executing.
forgotmypw17 6y ago
i,ve also found that accessibility and content quality are strongly correlated, saving me reading time.