Not really. My computer generally only runs the code I tell it to. The browser is an exception, in which case I have delegated authority to the browser to decide what code to run, in return for the browser’s promise that it will only run safe code.
I’d make the argument: “apt-get” explicit lists dependencies and
defaults to asking whether you want to proceed. “HTTP GET” pulls in
whatever, and most users have no idea what’s being pulled it; it’s more
difficult to figure out what a given script or resource is supposed to do.
Sure. Nobody is (hopefully) saying you can’t do crypto in node.js, for example. Or have a static html file that encrypts a textarea and prints the result to be copy and pasted elsewhere. (We’re also clearly not saying that the browser shouldn’t be doing TLS.)
It’s unfortunate that the problem has been reduced to a sound bite. Nevertheless, it’s even more disingenuous to take the sound bite and construct a strawman out of it. (not blaming you, it’s hard to tell who to blame when this happens.)
It’s all about trust. I can run apt-get install pgp, which implies a certain level of trust in both apt and pgp. However, consider the use case for js browser crypto. I’m going to upload a file to mega, but I don’t trust mega not to look at my file so I want to encrypt it. That level of distrust implies I cannot trust the crypto code from mega either.
Trust is not entirely binary. For example, I might trust mega not to lose my file entirely, but allow for the possibility they will peek at it. Or I might trust them with my lolcat archive. But once I’ve decided not to trust them with the integrity and privacy of my file, I cannot trust them to provide any of the pieces that are necessary for integrity and privacy.
If PGP offered a cloud backup service, I’d be suspicious of that as well, but the browser’s code delivery model opens up several new avenues of attack.
Yeah, kinda like computers.
Not really. My computer generally only runs the code I tell it to. The browser is an exception, in which case I have delegated authority to the browser to decide what code to run, in return for the browser’s promise that it will only run safe code.
Oh, I don’t know. I could make the argument that: “apt-get” and “HTTP GET” both have some risks as ways to get code.
I’d make the argument: “apt-get” explicit lists dependencies and defaults to asking whether you want to proceed. “HTTP GET” pulls in whatever, and most users have no idea what’s being pulled it; it’s more difficult to figure out what a given script or resource is supposed to do.
Fair point, but JavaScript can be delivered in the “pkg_add” manner as well. And all the code is readable once you have downloaded it.
There is even bower for js package management.
More and more apps are able to run offline, crypto stuff included.
Sure. Nobody is (hopefully) saying you can’t do crypto in node.js, for example. Or have a static html file that encrypts a textarea and prints the result to be copy and pasted elsewhere. (We’re also clearly not saying that the browser shouldn’t be doing TLS.)
It’s unfortunate that the problem has been reduced to a sound bite. Nevertheless, it’s even more disingenuous to take the sound bite and construct a strawman out of it. (not blaming you, it’s hard to tell who to blame when this happens.)
It’s all about trust. I can run apt-get install pgp, which implies a certain level of trust in both apt and pgp. However, consider the use case for js browser crypto. I’m going to upload a file to mega, but I don’t trust mega not to look at my file so I want to encrypt it. That level of distrust implies I cannot trust the crypto code from mega either.
Trust is not entirely binary. For example, I might trust mega not to lose my file entirely, but allow for the possibility they will peek at it. Or I might trust them with my lolcat archive. But once I’ve decided not to trust them with the integrity and privacy of my file, I cannot trust them to provide any of the pieces that are necessary for integrity and privacy.
If PGP offered a cloud backup service, I’d be suspicious of that as well, but the browser’s code delivery model opens up several new avenues of attack.