5 ms·

> I feel like, in most cases, I could make due with JavaScript being 10x or even 100x slower, taking up 10x the RAM, lacking some uncommon features, and so fort

by Ourgon 5y ago

> I feel like, in most cases, I could make due with JavaScript being 10x or even 100x slower, taking up 10x the RAM, lacking some uncommon features, and so forth -- if it meant being able to enable it without needing to worry about new zero-days. Not on the "modern web" you wouldn't, even the current speedy versions of V8 and ${whatever}monkey now used by Firefox the thing often is brought to a crawl by the deluge of Javascript. Imagine your current browser, only 100 times slower and 10 times more memory-hungry. Nope, the solution lies in getting rid of most of the Javascript on most pages. uBlock and uMatrix can help a bit but the real solution lies with web developers. If and when that goal is achieved 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.

bastawhiz 5y ago
> 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.
- Ourgon 5y ago
  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?).
  - tedunangst 5y ago
    The dangerous assumption here is that whatever sandbox you put the bad browser in actually contains it.
    - d110af5ccf 5y ago
      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-escape-case-study-of-kvm.html https://googleprojectzero.blogspot.com/2021/06/an-epyc-escap...
  - bastawhiz 5y ago
    > 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.
- tedunangst 5y ago
  Even bank pages contain a lot of analytics, and any of those sites could be used against you.
  - bastawhiz 5y ago
    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)?
    - tedunangst 5y ago
      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.
      - bastawhiz 5y ago
        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.
        tedunangst 5y ago
        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.
asddubs 5y ago
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.
hedora 5y ago
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.
noduerme 5y ago
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.

by Ourgon 5y ago

bastawhiz 5y ago

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

Ourgon 5y ago
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?).
- tedunangst 5y ago
  The dangerous assumption here is that whatever sandbox you put the bad browser in actually contains it.
  - d110af5ccf 5y ago
    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-escape-case-study-of-kvm.html https://googleprojectzero.blogspot.com/2021/06/an-epyc-escap...
- bastawhiz 5y ago
  > 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.
tedunangst 5y ago
Even bank pages contain a lot of analytics, and any of those sites could be used against you.
- bastawhiz 5y ago
  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)?
  - tedunangst 5y ago
    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.
    - bastawhiz 5y ago
      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.
      - tedunangst 5y ago
        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.

asddubs 5y ago

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.

hedora 5y ago

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.

noduerme 5y ago

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.