4 ms·

Honestly, I think it's time to reconsider the wisdom of allowing arbitrary untrustable third party executable code to run instantly in the form of things like J

Honestly, I think it's time to reconsider the wisdom of allowing arbitrary untrustable third party executable code to run instantly in the form of things like JavaScript on web pages, instead of just nerf everyone's computer into molasses to prop up an idea that's been bad for the web anyways. I've been of this opinion for a while now, not just because of performance slowdowns and security issues, but also just because of the way JS on web sites has been reducing usability in the form of popups, bitcoin miners, playing videos, sudden redirects to phishing sites and whatever crazy things are out there now. I'm not saying get rid of JS, but treat it like it is - running code you can't trust. Web sites should start as largely static HTML documents that you read, and then if they need to use JS then they should be required to ask permission to do so, the same way any other executable code is managed in any other computing environment. That seems wild, but I think it's far less crazy than taking away a decade of performance improvements to the entire computing ecosystem by default so a broken security model can continue unquestioned.

nhumrich 5y ago
[Deleted]
- staticassertion 5y ago
  I think virtually every Spectrev1 POC is browser based Javascript.
staticassertion 5y ago
You're basically saying "let's consider reinventing the internet", which I think is not reasonable or a good idea. I think one problem with the comments about this post is that they doesn't emphasize enough that the hit is to system call heavy workloads. This is NOT a global slowdown of all compute. The hit is to system call performance, and it's big, no question, but I don't think we need to throw out the internet's structure in order to address that. One option is to make fewer system calls. For a program that is basically scanning a file system that might be harder to do today, but for tons of other programs it isn't, and with iouring we have a very reasonable escape hatch for optimizing syscall heavy workloads. This might sound silly, but this sort of thing is constantly happening - programs are optimized for thinking something is fast and something else is slow. For example, if you built a program in the 2000s you'd do everything you can to avoid the disk, aggressively caching. In 2020 disks are insanely fast, and the cost of caching will be worse than just optimizing your disk usage. I don't know about the average website, but from what I can tell most sites that aren't total shit are pretty 'clean'. With an adblocker, especially so. > running code you can't trust We do that already. There's literally dozens of mitigations taken based on this.
- kyledrake 5y ago
  > You're basically saying "let's consider reinventing the internet", which I think is not reasonable or a good idea. It's absolutely reasonable to require the user to give a web page permission to start executing powerful, potentially dangerous code on their computer. Also JavaScript is not "the internet", nor is it even really "the web", which for most of its history was relatively benign HTML documents that you read, and things have frankly been on a downward trajectory in terms of safety and usability since we started changing it. Powerful JS is a relatively recent phenomenon in the history of the web, and largely under the theory that we can do it safely with correct design. As someone that has to moderate code on un-trustable web sites as part of my work, I can just say it's not working out very well, even leaving out stuff like spectre/meltdown.
  - staticassertion 5y ago
    I don't think this would solve anything. This is like putting Word macros behind a "do you want to run this macro?". Yes, yes they do want to run it. If people were willing to put every webpage behind a "do you want to run this webpage" we'd see them all using noscript already - virtually no one wants that experience. > largely under the theory that we can do it safely with correct design I blame operating systems and hardware vendors tbh. It's their job to make this safe, and they do a pretty bad job of it. Browser vendors have had to pick up a massive amount of slack to try to compensate, to the extent that browser teams have to make major patches to the Linux kernel.
slver 5y ago
JS is already treated like code you can’t trust. Adjustments will be needed from time to time. A full block would not be for engineering reasons, but for ideological reasons.
- kyledrake 5y ago
  "Strong JavaScript" continues to fail this trust model even with very careful design, leading to (among other things) mitigations in the form of multiple double digit performance hits to all computing. That seems more like an engineering reason to re-evaluate the status quo to me. "Web sites should be allowed to run untrustable executable code because we can manage it" feels far more ideological to me, because it's based on a belief that is becoming increasingly unfounded by the accumulating evidence.
  - slver 5y ago
    When you talk about performance hit, are you under the impression that moving this to the server side would be faster? No. So what is the alternative? If you move everything to apps, apps become the vector. If you ask for explicit ok online, it becomes like the cookie dialog. Pointless. Offer an alternative.
curryst 5y ago
I don't think we need to go quite that far. I think one of the issues is that browsers tend to entirely neglect the context of Javascript. They treat a complex webapp the same as they treat a simple website that has jQuery for drop down menus, despite the fact that the expectations should be substantially different. The former should absolutely have some kind of security notification similar to installing an app: "this page wants permissions X, Y and Z". You can either accept those permissions and use the app, or decline them and the app can decide whether to just not work or to disable some features that rely on those permissions. The latter should have an extremely minimal set of features. Probably just the ability to manipulate the DOM. The second it crosses into something as basic as AJAX requests, it now needs a different security context and the user should approve that. It now has the ability to exfiltrate data from your PC. The blurring of lines between a web page and a web app has been great in many ways, but security on that front just doesn't seem to have moved much.

nhumrich 5y ago

[Deleted]

staticassertion 5y ago
I think virtually every Spectrev1 POC is browser based Javascript.

staticassertion 5y ago

You're basically saying "let's consider reinventing the internet", which I think is not reasonable or a good idea. I think one problem with the comments about this post is that they doesn't emphasize enough that the hit is to system call heavy workloads. This is NOT a global slowdown of all compute. The hit is to system call performance, and it's big, no question, but I don't think we need to throw out the internet's structure in order to address that. One option is to make fewer system calls. For a program that is basically scanning a file system that might be harder to do today, but for tons of other programs it isn't, and with iouring we have a very reasonable escape hatch for optimizing syscall heavy workloads. This might sound silly, but this sort of thing is constantly happening - programs are optimized for thinking something is fast and something else is slow. For example, if you built a program in the 2000s you'd do everything you can to avoid the disk, aggressively caching. In 2020 disks are insanely fast, and the cost of caching will be worse than just optimizing your disk usage. I don't know about the average website, but from what I can tell most sites that aren't total shit are pretty 'clean'. With an adblocker, especially so. > running code you can't trust We do that already. There's literally dozens of mitigations taken based on this.

kyledrake 5y ago
> You're basically saying "let's consider reinventing the internet", which I think is not reasonable or a good idea. It's absolutely reasonable to require the user to give a web page permission to start executing powerful, potentially dangerous code on their computer. Also JavaScript is not "the internet", nor is it even really "the web", which for most of its history was relatively benign HTML documents that you read, and things have frankly been on a downward trajectory in terms of safety and usability since we started changing it. Powerful JS is a relatively recent phenomenon in the history of the web, and largely under the theory that we can do it safely with correct design. As someone that has to moderate code on un-trustable web sites as part of my work, I can just say it's not working out very well, even leaving out stuff like spectre/meltdown.
- staticassertion 5y ago
  I don't think this would solve anything. This is like putting Word macros behind a "do you want to run this macro?". Yes, yes they do want to run it. If people were willing to put every webpage behind a "do you want to run this webpage" we'd see them all using noscript already - virtually no one wants that experience. > largely under the theory that we can do it safely with correct design I blame operating systems and hardware vendors tbh. It's their job to make this safe, and they do a pretty bad job of it. Browser vendors have had to pick up a massive amount of slack to try to compensate, to the extent that browser teams have to make major patches to the Linux kernel.

slver 5y ago

JS is already treated like code you can’t trust. Adjustments will be needed from time to time. A full block would not be for engineering reasons, but for ideological reasons.

kyledrake 5y ago
"Strong JavaScript" continues to fail this trust model even with very careful design, leading to (among other things) mitigations in the form of multiple double digit performance hits to all computing. That seems more like an engineering reason to re-evaluate the status quo to me. "Web sites should be allowed to run untrustable executable code because we can manage it" feels far more ideological to me, because it's based on a belief that is becoming increasingly unfounded by the accumulating evidence.
- slver 5y ago
  When you talk about performance hit, are you under the impression that moving this to the server side would be faster? No. So what is the alternative? If you move everything to apps, apps become the vector. If you ask for explicit ok online, it becomes like the cookie dialog. Pointless. Offer an alternative.

curryst 5y ago

I don't think we need to go quite that far. I think one of the issues is that browsers tend to entirely neglect the context of Javascript. They treat a complex webapp the same as they treat a simple website that has jQuery for drop down menus, despite the fact that the expectations should be substantially different. The former should absolutely have some kind of security notification similar to installing an app: "this page wants permissions X, Y and Z". You can either accept those permissions and use the app, or decline them and the app can decide whether to just not work or to disable some features that rely on those permissions. The latter should have an extremely minimal set of features. Probably just the ability to manipulate the DOM. The second it crosses into something as basic as AJAX requests, it now needs a different security context and the user should approve that. It now has the ability to exfiltrate data from your PC. The blurring of lines between a web page and a web app has been great in many ways, but security on that front just doesn't seem to have moved much.