4 ms·

Hey, why stop there? Dig deeper! Thanks to internet and computers turning the web into a platform for adware and spyware. No, actually, thank electricity. It's

Hey, why stop there? Dig deeper! Thanks to internet and computers turning the web into a platform for adware and spyware. No, actually, thank electricity. It's a stupid point of view, where people blame some tech for problems created by those very people. It's not javascript that makes web slightly slow, but incompetent developers driven by business. If it wasn't javascript, it would be something else that allows you to run some computations on client side. And it would be the same if not worse. There's a reason web was won by JS, not java or COM or flash. Hell, there just was a post no NY that demonstrated that fonts are potentially turing-complete. Our behaviour, economy, law, customs, complete lack of culture and education causes slow web, privacy problems and de-decentralisation of internet. Fundamentally, bug is outside of computer, it's just us.

JohnFen 8y ago
> If it wasn't javascript, it would be something else that allows you to run some computations on client side. I agree that blaming Javascript the language is incorrect. One of the major problems is that websites are able to run code client-side at all.
- lyxsus1 8y ago
  Well, we really need to do some client-side computations for really good reasons. And if we hadn't, it would be reinvented pretty quickly. What we need right now (IMHO): 1. Some easy-to-use on/off capping button for code size, memory consumed, cpu used, resources loaded per tab. Enabled by default, shipped in each major browser, including mobile 2. Cruelly penalise links that abuse client resources in search results of all major platforms 3. Give it a year and watch them raging, but slowly adjusting to new requirements 4. Repeat with lower caps until it's good enough That's all we realistically can and should do: impose some universal limits and require user conscious action to bypass per webapp. It must be job, which W3C should be doing already, probably with joint efforts of Google, Microsoft and Apple. If they managed to enforce CORS, they'll be able to that also.
  - JohnFen 8y ago
    I 100% understand the use case for running code client-side. Personally, though, I disallow it for exactly the same reason why I don't download and execute any programs from random websites -- it presents a security risk that is unacceptable to me. That limits functionality, of course, but so be it.
    - lyxsus1 8y ago
      In that case use should understand, that you need to find a way to disable all browser media, css and html rendering. Because they all process data from untrusted source. The thing is, executing javascript is not that much different from rendering all those things, and anytime you allow your computer to do some computations using any program on data from untrusted source, it's a risk. There might be even bugs in decompression library, so let's not download anything. There were plenty exploits that used html/css parser bugs with no JS at all. I think I even heard about case where guys hacked into car using radio and a bug in mp3 decoder. And it won't get any better unless we maybe start writing on something more safe, like Rust instead of c/cpp. The way JS engines are implemented and used makes it an easier and more obvious target, but not really enough to just turn it off by default. Doing so is just a superstition, we could make just a little step further and rip off all our computers IO to be safe. Running browser in VM might be a better idea, but again, in theory one could escape VM. Sadly, it feels like we're at least a couple decades away from owning secure systems, if that's even possible. Ha, I just thought, that we might get strong AI before that :)
      - JohnFen 8y ago
        > In that case use should understand, that you need to find a way to disable all browser media, css and html rendering. Because they all process data from untrusted source There's a big difference between processing data from an untrusted source and allowing active code from an untrusted source to execute. > There were plenty exploits that used html/css parser bugs with no JS at all. True, but I'm not talking about exploits. I'm talking about code running as intended by the authors. Tracking and telemetry scripts are prime examples of what I'm talking about. > Running browser in VM might be a better idea That's a larger pain than simply disallowing scripting, and does nothing about things like tracking.

JohnFen 8y ago

> If it wasn't javascript, it would be something else that allows you to run some computations on client side. I agree that blaming Javascript the language is incorrect. One of the major problems is that websites are able to run code client-side at all.

lyxsus1 8y ago
Well, we really need to do some client-side computations for really good reasons. And if we hadn't, it would be reinvented pretty quickly. What we need right now (IMHO): 1. Some easy-to-use on/off capping button for code size, memory consumed, cpu used, resources loaded per tab. Enabled by default, shipped in each major browser, including mobile 2. Cruelly penalise links that abuse client resources in search results of all major platforms 3. Give it a year and watch them raging, but slowly adjusting to new requirements 4. Repeat with lower caps until it's good enough That's all we realistically can and should do: impose some universal limits and require user conscious action to bypass per webapp. It must be job, which W3C should be doing already, probably with joint efforts of Google, Microsoft and Apple. If they managed to enforce CORS, they'll be able to that also.
- JohnFen 8y ago
  I 100% understand the use case for running code client-side. Personally, though, I disallow it for exactly the same reason why I don't download and execute any programs from random websites -- it presents a security risk that is unacceptable to me. That limits functionality, of course, but so be it.
  - lyxsus1 8y ago
    In that case use should understand, that you need to find a way to disable all browser media, css and html rendering. Because they all process data from untrusted source. The thing is, executing javascript is not that much different from rendering all those things, and anytime you allow your computer to do some computations using any program on data from untrusted source, it's a risk. There might be even bugs in decompression library, so let's not download anything. There were plenty exploits that used html/css parser bugs with no JS at all. I think I even heard about case where guys hacked into car using radio and a bug in mp3 decoder. And it won't get any better unless we maybe start writing on something more safe, like Rust instead of c/cpp. The way JS engines are implemented and used makes it an easier and more obvious target, but not really enough to just turn it off by default. Doing so is just a superstition, we could make just a little step further and rip off all our computers IO to be safe. Running browser in VM might be a better idea, but again, in theory one could escape VM. Sadly, it feels like we're at least a couple decades away from owning secure systems, if that's even possible. Ha, I just thought, that we might get strong AI before that :)
    - JohnFen 8y ago
      > In that case use should understand, that you need to find a way to disable all browser media, css and html rendering. Because they all process data from untrusted source There's a big difference between processing data from an untrusted source and allowing active code from an untrusted source to execute. > There were plenty exploits that used html/css parser bugs with no JS at all. True, but I'm not talking about exploits. I'm talking about code running as intended by the authors. Tracking and telemetry scripts are prime examples of what I'm talking about. > Running browser in VM might be a better idea That's a larger pain than simply disallowing scripting, and does nothing about things like tracking.