Hacker News Reader

Try running the modern web without a supported GPU (eg through VNC on a VM with a vesa video card).

Even trivial sites will knock over the fastest Xeon available. I can't imagine how much worse it would be if you also disabled the JS JIT.

> it would be possible to browse the web using a slow-but-'safe' browser. Some pages (e.g. SPAs) really depend on all that Javascript and as such won't be useable withour 'modern' JS engines but there is no reason for e.g. your bank or payment processor's pages to depend on near-native speed Javascript engines.

I don't plan on my bank trying to 0day my browser. If anything, I trust them not to do anything malicious more than the sites that actually need to go fast.

You don't seem to understand what I wrote so I'll explain it:

- imagine a slow-but-secure browser, 10 to 100 times as slow and using 10 times as much memory as stated by the parent poster

- imagine your bank and payment processor using a minimal amount of Javascript on their sites to make it possible to use that secure-but-slow browser without incurring too big a performance penalty

Do you now see what I mean? It is not that your financial institutions would zero-day you, it is that you'd use the secure-but-slow browser (or browser mode) to access those sites. Secure, because you're dealing with financial data. Slow because that is what the parent poster stated as the price he'd be willing to pay for a secure browser.

You can you your insecure-but-speedy browser to watch cat videos where the H4CkZ0Rz can try to zero-day you to their hearts content because that browser does not have access to sensitive data. You could try to watch those cat videos with the secure-but-slow browser but that'd transport you back to the late 90's with single-digit frame rates (cat slide shows?).

The dangerous assumption here is that whatever sandbox you put the bad browser in actually contains it.

Particularly given the Project Zero KVM vulnerability published a couple of days ago. It was suitable to achieve a full VM escape. https://googleprojectzero.blogspot.com/2021/06/an-epyc-escap...

> Do you now see what I mean? It is not that your financial institutions would zero-day you, it is that you'd use the secure-but-slow browser (or browser mode) to access those sites. Secure, because you're dealing with financial data. Slow because that is what the parent poster stated as the price he'd be willing to pay for a secure browser.

I understood what you meant the first time. Again, the risk you're mitigating is one that simply doesn't exist. A slow but hardened engine protects against attacks that simply don't happen for the sites you're talking about.

The threat here is abuse of the JS engine. If you're on my bank website origin running slow JavaScript you can already steal all of my money. Hardening the JS engine for that site is pointless because any bad JS running on the page already has the literal most valuable thing I have: access to all of my money. Having a provably not-zero-day-able browser does nothing to mitigate an attack if there's bad code running on the page.

Even bank pages contain a lot of analytics, and any of those sites could be used against you.

All of those analytics would already have the ability to run in the bank's origin and steal my money. What threat model are you operating under where malicious code running on your bank's website is trying to do something other than steal all of your money (which they're already able to do if they're executing on the bank's origin)?

The threat model where the analytics company is hacked. I don't know why you would trust your bank to never let that happen.

There are some APIs on the bank site you need to conduct your business, and there are also some extraneous APIs. Yeah, sure, you tell the bank it's their fault clickwatcher.js got hacked, and maybe they give you your money back, but it seems like unnecessary exposure to unnecessary hassle to leave all that crap running fully trusted.

But having a more hardened browser literally does nothing to protect you. If your bank's website is hacked because of a third party API, the most well-hardened browser (as the commenter that I replied to describes) in the world will happily allow all of your money to be stolen. A slow-but-secure JS engine does not protect you from JS that's doing things it's allowed to do.

Oh, oh, oh. I thought this was the thread where we turned javascript off or used adblock or some such. Yeah, secure vs insecure jit engine isn't going to help here.

I've been waiting for the arguments against Flash and Java applets (constant vulnerabilities + sites clogged with bad code) to finally become the argument against Javascript. Still waiting. The only reason it hasn't seems to me the massive investment by Google in speeding up the engine to the point where something even slower and more full of crud can seem relatively snappy on a mobile device.

whenever someone says "the solution is" and then says something that depends on a bunch of individual actors acting of their own accord rather than something systemic, it's hard to take them seriously. in a hypothetical dream world that might be a solution.