4 ms·

This is exactly right. Hypercard and HTML started the problem from opposite ends. Hypercard being a GUI app development tool and HTML being a way of joining t

This is exactly right. Hypercard and HTML started the problem from opposite ends. Hypercard being a GUI app development tool and HTML being a way of joining together text documents. That said, a network enabled Hypercard would have been a security nightmare. It was way too complex to secure given coding practices of the time. Heck, even "simple" web browsers had a reputation as a security weak point in the early days. There were no end to people who thought integrating the web browser with the OS was pure lunacy that was going to result in an endless string of compromised machines. Luckily "live desktop" and the like ended up being such weak features that they didn't have quite that much impact.

theGnuMe 4y ago
Right but with "containerization" it could have been secured earlier.
- jandrese 4y ago
  Containerization is easier said than done, especially with no hardware support. Ultimately you have to make compromises to keep it performant (remember this is on 386/68030 class hardware) and those compromises come back to bite you. Containerization also has a memory penalty, and memory was precious back in those days. Remember that early web browsers were heavy criticized for running poorly on less than 8MB of RAM.
  - musicale 4y ago
    This exactly. Isolation is a very hard problem, and it's even harder when you're running on top of hardware and operating systems that prioritized features and speed over security for decades - certainly due in part to users who had similar priorities and/or were unwilling to pay more for security and reliability.
musicale 4y ago
> There were no end to people who thought integrating the web browser with the OS was pure lunacy that was going to result in an endless string of compromised machines Fortunately OS and web browser developers didn't really consider that to be a big problem so they did it anyway and implemented a system that downloaded random code from the internet and happily executed it in a non-secure sandbox on top of an OS filled with exploitable security flaws. See: Java, Flash, JavaScript, webasm, PDF, canvas, etc.. Not that it mattered too much anyway since media and HTML renderers were already exploitable.

theGnuMe 4y ago

Right but with "containerization" it could have been secured earlier.

jandrese 4y ago
Containerization is easier said than done, especially with no hardware support. Ultimately you have to make compromises to keep it performant (remember this is on 386/68030 class hardware) and those compromises come back to bite you. Containerization also has a memory penalty, and memory was precious back in those days. Remember that early web browsers were heavy criticized for running poorly on less than 8MB of RAM.
- musicale 4y ago
  This exactly. Isolation is a very hard problem, and it's even harder when you're running on top of hardware and operating systems that prioritized features and speed over security for decades - certainly due in part to users who had similar priorities and/or were unwilling to pay more for security and reliability.

musicale 4y ago

> There were no end to people who thought integrating the web browser with the OS was pure lunacy that was going to result in an endless string of compromised machines Fortunately OS and web browser developers didn't really consider that to be a big problem so they did it anyway and implemented a system that downloaded random code from the internet and happily executed it in a non-secure sandbox on top of an OS filled with exploitable security flaws. See: Java, Flash, JavaScript, webasm, PDF, canvas, etc.. Not that it mattered too much anyway since media and HTML renderers were already exploitable.