3 ms·

Technically nothing can be trusted e.g. can anyone trust their silicon, wires, device drivers, compilers, OS, routers, SSL CAs, etc.? Trust has to happen at som

Technically nothing can be trusted e.g. can anyone trust their silicon, wires, device drivers, compilers, OS, routers, SSL CAs, etc.? Trust has to happen at some point. The difference is that it's trivial for this developer to insert a backdoor to steal Google credentials since they know exactly how and where the oauth tokens are located. It's significantly harder for e.g. a webpack developer to insert a backdoor to steal Google credentials since they would have to first determine the code it's processing is handling oauth tokens and then figure out where they are stored. The barrier to entry is the key in assessing your threat model. 3 letter agencies may not care about the cost if the target is valuable but a bored kid on the other side of the world will give up pretty quickly.

cmeacham98 5y ago
> The difference is that it's trivial for this developer to insert a backdoor to steal Google credentials since they know exactly how and where the oauth tokens are located So does all the malware: your browser's cookie store
- trinovantes 5y ago
  Not every application runs in the browser i.e. not SPA and any injected frontend js would have to bypass browser's sandboxing to steal another domain's cookies i.e. a zero day which is beyond your threat model
  - cmeacham98 5y ago
    > Not every application runs in the browser We're talking about YouTube in this thread. > any injected frontend js would have to bypass browser's sandboxing to steal another domain's cookies i.e. a zero day which is beyond your threat model Where did this random unrelated attack vector come from? We're going talking about running untrusted software on your computer, remember? That's the attack vector we're discussing. Your point was "malware in random unrelated software won't know where to look for my YouTube session key", my response was "it will".
    - trinovantes 5y ago
      > We're going talking about running untrusted software on your computer, remember? You are talking about running untrusted software on your computer. This thread is about the "youtubei.js" npm package that is acting as a wrapper around YouTube's API. My point is it's trivial for this developer to add additional code to `youtube.signIn(creds)` that I'm calling vs. any developer of one of my dependency to inject code to steal the same creds. If it's frontend code, their injected code cannot execute beyond mydomain.com. If it's backend code, their injected code would have to guess how my application works. I guess they can trivially dump my env variables but that's about it.
      - chmod775 5y ago
        > If it's frontend code Since you cannot use youtube.js in a browser (because it's not supported & because of CORS checks would fail), we can only be talking about 'backend' code here. Thus the comparison has to be with other backend dependencies and software running on your computer/servers.
      - trinovantes 5y ago
        After giving this topic a bit more thought, you are partially right. Any malicious dependency developer can simply pollute the XMLHttpRequest prototype to steal the results of oauth calls. If this is the threat model, then we can simply Object.freeze(XMLHttpRequest). But at this point, we're in a game of cat and mouse. Ultimately, it's still (somewhat) harder for you to steal credentials from injecting code into my app vs I explicitly calling your code with the credentials.

cmeacham98 5y ago

> The difference is that it's trivial for this developer to insert a backdoor to steal Google credentials since they know exactly how and where the oauth tokens are located So does all the malware: your browser's cookie store

trinovantes 5y ago
Not every application runs in the browser i.e. not SPA and any injected frontend js would have to bypass browser's sandboxing to steal another domain's cookies i.e. a zero day which is beyond your threat model
- cmeacham98 5y ago
  > Not every application runs in the browser We're talking about YouTube in this thread. > any injected frontend js would have to bypass browser's sandboxing to steal another domain's cookies i.e. a zero day which is beyond your threat model Where did this random unrelated attack vector come from? We're going talking about running untrusted software on your computer, remember? That's the attack vector we're discussing. Your point was "malware in random unrelated software won't know where to look for my YouTube session key", my response was "it will".
  - trinovantes 5y ago
    > We're going talking about running untrusted software on your computer, remember? You are talking about running untrusted software on your computer. This thread is about the "youtubei.js" npm package that is acting as a wrapper around YouTube's API. My point is it's trivial for this developer to add additional code to `youtube.signIn(creds)` that I'm calling vs. any developer of one of my dependency to inject code to steal the same creds. If it's frontend code, their injected code cannot execute beyond mydomain.com. If it's backend code, their injected code would have to guess how my application works. I guess they can trivially dump my env variables but that's about it.
    - chmod775 5y ago
      > If it's frontend code Since you cannot use youtube.js in a browser (because it's not supported & because of CORS checks would fail), we can only be talking about 'backend' code here. Thus the comparison has to be with other backend dependencies and software running on your computer/servers.
    - trinovantes 5y ago
      After giving this topic a bit more thought, you are partially right. Any malicious dependency developer can simply pollute the XMLHttpRequest prototype to steal the results of oauth calls. If this is the threat model, then we can simply Object.freeze(XMLHttpRequest). But at this point, we're in a game of cat and mouse. Ultimately, it's still (somewhat) harder for you to steal credentials from injecting code into my app vs I explicitly calling your code with the credentials.