5 ms·

Aren't those trust boundary issues also present in every other piece of downloadable software, such as Tor for example? When you download a signed plugin, what'

Aren't those trust boundary issues also present in every other piece of downloadable software, such as Tor for example? When you download a signed plugin, what's the difference from downloading Tor?

daeken 13y ago
In theory, yes. There's nothing inherently more secure about Tor than an app running in the browser. However, XSS attacks are everywhere, it's trivial for servers to shoot code down to the client to evaluate, etc. In practice, an app doing crypto on your desktop is fundamentally very different from a web app doing it, even if that's signed and isolated.
- magikarp 13y ago
  Okay. But XSS is class of bugs that has nothing to do with code delivery, and that is quite possible to mitigate. So overall, the problem of code delivery is still addressed to a notable (if not complete) extent with the use of downloadable signed browser apps.
  - 0x0 13y ago
    Huh? Maybe I misunderstand what you're going on about, but if you can XSS in javascript, you can certainly change the meaning of even signed code - just hijack Object.prototype.constructor or similar.
    - magikarp 13y ago
      That may very well be the case, but isn't this a solvable problem? Just like apps made in C need to be protected against buffer overflows, apps made in JS need to be protected against XSS. Both are reasonable threats that can be mitigated.
      - wglb 13y ago
        Consider the fact that XSS is some other part of the application that the reviewed crypto plugin JS is part of has an XSS in it. Yes, but just because it can be mitigated doesn't mean that it is mitigated.
        magikarp 13y ago
        > Yes, but just because it can be mitigated doesn't mean that it is mitigated. Sure, but I just want to point to the fact that this is a solvable problem. A lot of people talk as if it is some sort of insurmountable obstacle, whereas I think responsible programmers can solve it and move on.
        daeken 13y ago
        You're arguing for a theoretical world, we're arguing from a practical one. I've spent enough time down in the trenches finding attacks in extremely well-reviewed code, that adding a massive new attack surface is not a thrilling proposition.
        magikarp 13y ago
        Well, I guess you're just slightly more pessimistic and I'm slightly more optimistic. I respect your viewpoint, though. :-)
        tptacek 13y ago
        The smiley face in that comment is doing a lot of work.
        DoubleMalt 13y ago
        I'm a really optimistic type, really. Optimistic to the annoyance of some people. But in the case of security and cryptology there does not exist a choice between optimism and pessimism, but a choice between sharp eyed paranoia and wilful ignorance. A defence is always only as strong as the weakest link, and an attacker usually has all the time in the world to find and exploit it. Optimism has no place here.

Aren't those trust boundary issues also present in every other piece of downloadable software, such as Tor for example? When you download a signed plugin, what's the difference from downloading Tor?

daeken 13y ago

In theory, yes. There's nothing inherently more secure about Tor than an app running in the browser. However, XSS attacks are everywhere, it's trivial for servers to shoot code down to the client to evaluate, etc. In practice, an app doing crypto on your desktop is fundamentally very different from a web app doing it, even if that's signed and isolated.

magikarp 13y ago
Okay. But XSS is class of bugs that has nothing to do with code delivery, and that is quite possible to mitigate. So overall, the problem of code delivery is still addressed to a notable (if not complete) extent with the use of downloadable signed browser apps.
- 0x0 13y ago
  Huh? Maybe I misunderstand what you're going on about, but if you can XSS in javascript, you can certainly change the meaning of even signed code - just hijack Object.prototype.constructor or similar.
  - magikarp 13y ago
    That may very well be the case, but isn't this a solvable problem? Just like apps made in C need to be protected against buffer overflows, apps made in JS need to be protected against XSS. Both are reasonable threats that can be mitigated.
    - wglb 13y ago
      Consider the fact that XSS is some other part of the application that the reviewed crypto plugin JS is part of has an XSS in it. Yes, but just because it can be mitigated doesn't mean that it is mitigated.
      - magikarp 13y ago
        > Yes, but just because it can be mitigated doesn't mean that it is mitigated. Sure, but I just want to point to the fact that this is a solvable problem. A lot of people talk as if it is some sort of insurmountable obstacle, whereas I think responsible programmers can solve it and move on.
        daeken 13y ago
        You're arguing for a theoretical world, we're arguing from a practical one. I've spent enough time down in the trenches finding attacks in extremely well-reviewed code, that adding a massive new attack surface is not a thrilling proposition.
        magikarp 13y ago
        Well, I guess you're just slightly more pessimistic and I'm slightly more optimistic. I respect your viewpoint, though. :-)
        tptacek 13y ago
        The smiley face in that comment is doing a lot of work.
        DoubleMalt 13y ago
        I'm a really optimistic type, really. Optimistic to the annoyance of some people. But in the case of security and cryptology there does not exist a choice between optimism and pessimism, but a choice between sharp eyed paranoia and wilful ignorance. A defence is always only as strong as the weakest link, and an attacker usually has all the time in the world to find and exploit it. Optimism has no place here.