5 ms·

What does trusted really mean? If you use node (or other JS packaging systems), you are running code that someone else wrote, that almost certainly you didn’t r

What does trusted really mean? If you use node (or other JS packaging systems), you are running code that someone else wrote, that almost certainly you didn’t review as it’s huge, changing, etc. How about companies that use v8 to run JavaScript extensions to their app that their customers wrote. This is many apps. Are you saying they are all vulnerable? The answer is they are all vulnerable, just because of problems like this. Any user code (js in this case) is untrustworthy, and everything has js extensions. What’s the safe way to run user JS? Running v8 in its own somehow separately limited process maybe is what I think people do.

Spivak 3y ago
Whether or not you review your deps code is on you, it doesn't make it untrusted. You're trusting them whether you do the due diligence to see if that trust is warranted or not. Untrusted means code that comes from outside your system, like 3rd party extensions to your app and is presumed to be completely broken and actively malicious and nonetheless shouldn't crash your own program or reveal sensitive data.
Dalewyn 3y ago
>What does trusted really mean? I agree; "trusting" third-party/remote code or not frankly went out the window with the bathwater including baby when we moved on to Web "JavaShit" 2.0, or was it 3.0. Feels like we're in a worse security hellhole than we ever were with Flash or ActiveX back in the day, frankly.
- refulgentis 3y ago
  For context, assuming by JavaShit Web 3.0 you meant JavaScript: Flash and ActiveX were proprietary technologies that often required users to install plugins or additional software on their devices. These plugins operated with high levels of access to the system, which made them a significant security risk. They were notorious for being frequently exploited by attackers as a way to run malicious code on users' machines. In contrast, JavaScript is a core part of the web and is executed within the browser in a sandboxed environment. This means that JavaScript operates with limited access to the system's resources, reducing the risk of system-level security breaches.
  - bee_rider 3y ago
    Either “sandbox” was the funniest and most appropriate name ever chosen in tech, or the person who came up with it has never actually seen a sandbox.
  - Amigo5862 3y ago
    > In contrast, JavaScript is a core part of the web and is executed within the browser in a sandboxed environment. This means that JavaScript operates with limited access to the system's resources, reducing the risk of system-level security breaches. Flash (and probably ActiveX) were also executed in a "sandboxed environment", including "limited access to the system's resources". All 3 have (or well, had, in the case of Flash and ActiveX) regular vulnerabilities - including JavaScript. JavaScript is not any better than Flash or ActiveX and I really don't understand why people pretend it is. BTW, Flash was definitely a core part of the web in its heyday, too. ETA: Oh, and Java was also executed in a sandbox (and a virtual machine!) and had plenty of vulnerabilities back when applets were a thing. At least with Flash, ActiveX, and Java you could choose not to install them and most sites would continue working. For JavaScript you have to install (and trust) some third party extension to block it and then no sites work...
    - cesarb 3y ago
      > Flash (and probably ActiveX) were also executed in a "sandboxed environment", including "limited access to the system's resources". IIRC, the main issue with ActiveX was that it did not execute in a sandboxed environment, unlike Flash and Java. With ActiveX, all you had was a cryptographic signature saying it came from a trusted publisher; past that, the full Win32 API was available, with complete access to the operating system.
      - Amigo5862 3y ago
        That wouldn't particularly surprise me. I never used ActiveX, so I can't really speak to that one. But then, there also weren't many (public) websites that I ever ran into that wanted to use it.
rezonant 3y ago
There is a massive difference between the supply chain risks of open source packages and actively fetching and executing remote code provided as user input like the browser inherently does. The case of user provided extensions definitely falls a lot closer to the supply chain threat model.

Spivak 3y ago

Whether or not you review your deps code is on you, it doesn't make it untrusted. You're trusting them whether you do the due diligence to see if that trust is warranted or not. Untrusted means code that comes from outside your system, like 3rd party extensions to your app and is presumed to be completely broken and actively malicious and nonetheless shouldn't crash your own program or reveal sensitive data.

Dalewyn 3y ago

>What does trusted really mean? I agree; "trusting" third-party/remote code or not frankly went out the window with the bathwater including baby when we moved on to Web "JavaShit" 2.0, or was it 3.0. Feels like we're in a worse security hellhole than we ever were with Flash or ActiveX back in the day, frankly.

refulgentis 3y ago
For context, assuming by JavaShit Web 3.0 you meant JavaScript: Flash and ActiveX were proprietary technologies that often required users to install plugins or additional software on their devices. These plugins operated with high levels of access to the system, which made them a significant security risk. They were notorious for being frequently exploited by attackers as a way to run malicious code on users' machines. In contrast, JavaScript is a core part of the web and is executed within the browser in a sandboxed environment. This means that JavaScript operates with limited access to the system's resources, reducing the risk of system-level security breaches.
- bee_rider 3y ago
  Either “sandbox” was the funniest and most appropriate name ever chosen in tech, or the person who came up with it has never actually seen a sandbox.
- Amigo5862 3y ago
  > In contrast, JavaScript is a core part of the web and is executed within the browser in a sandboxed environment. This means that JavaScript operates with limited access to the system's resources, reducing the risk of system-level security breaches. Flash (and probably ActiveX) were also executed in a "sandboxed environment", including "limited access to the system's resources". All 3 have (or well, had, in the case of Flash and ActiveX) regular vulnerabilities - including JavaScript. JavaScript is not any better than Flash or ActiveX and I really don't understand why people pretend it is. BTW, Flash was definitely a core part of the web in its heyday, too. ETA: Oh, and Java was also executed in a sandbox (and a virtual machine!) and had plenty of vulnerabilities back when applets were a thing. At least with Flash, ActiveX, and Java you could choose not to install them and most sites would continue working. For JavaScript you have to install (and trust) some third party extension to block it and then no sites work...
  - cesarb 3y ago
    > Flash (and probably ActiveX) were also executed in a "sandboxed environment", including "limited access to the system's resources". IIRC, the main issue with ActiveX was that it did not execute in a sandboxed environment, unlike Flash and Java. With ActiveX, all you had was a cryptographic signature saying it came from a trusted publisher; past that, the full Win32 API was available, with complete access to the operating system.
    - Amigo5862 3y ago
      That wouldn't particularly surprise me. I never used ActiveX, so I can't really speak to that one. But then, there also weren't many (public) websites that I ever ran into that wanted to use it.

rezonant 3y ago

There is a massive difference between the supply chain risks of open source packages and actively fetching and executing remote code provided as user input like the browser inherently does. The case of user provided extensions definitely falls a lot closer to the supply chain threat model.