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