3 ms·

This is great stuff for plugins, but really bad stuff for scripts. Remember, if you can't trust the server with your secrets, you can't trust the server to sen

by wtbob 12y ago

This is great stuff for plugins, but really bad stuff for scripts. Remember, if you can't trust the server with your secrets, you can't trust the server to send you a script which can decypher your secrets.

thomasfoster96 12y ago
Is this comment meant for browser-based crypto in general, or just this API?
- wtbob 12y ago
  Browser-based crypto in general. It makes a great deal of sense to provide encryption APIs for plugins, and there's a case to be made for providing some APIs to site scripts, but in general browser crypto is just scarily insecure.
  - thomasfoster96 12y ago
    I might be wrong here, but the two major problems with browser crypto were the fact that you had to send the crypto libraries to the browser in the first place, and that then you didn't really have access to a proper random number generator. Those two issues pretty much disappear with the use of a built in api from the browser. I guess now you've just got to trust the browser, but the browser is never going to be as secure as doing things on your own server.
jessaustin 12y ago
Can one stipulate that one does trust a particular server (maybe it has a valid TLS cert?) and still derive some value from this API? E.g., it seems perfectly valid to me to do some work on the client in order to reduce data volumes or server loads?
- wtbob 12y ago
  Well, I'd never trust the server (and TLS certs are only a step or two above pure snake oil security), but if the server is willing to trust me, then I don't in principle mind decrypting data on its behalf.
  - jessaustin 12y ago
    Never trusting the server seems equivalent to never using an online service. This isn't helpful.
taf2 12y ago
Crypto Apis can be useful for things other than encrypting data - for example creating uniqueness or testing for uniqueness - I'm sure a range of other clever possibilities exist.
- wtbob 12y ago
  Excellent point. A well-chosen set of some primitives makes sense for site scripts, but the general case of encryption/decryption almost certainly doesn't in most cases.

by wtbob 12y ago

thomasfoster96 12y ago

Is this comment meant for browser-based crypto in general, or just this API?

wtbob 12y ago
Browser-based crypto in general. It makes a great deal of sense to provide encryption APIs for plugins, and there's a case to be made for providing some APIs to site scripts, but in general browser crypto is just scarily insecure.
- thomasfoster96 12y ago
  I might be wrong here, but the two major problems with browser crypto were the fact that you had to send the crypto libraries to the browser in the first place, and that then you didn't really have access to a proper random number generator. Those two issues pretty much disappear with the use of a built in api from the browser. I guess now you've just got to trust the browser, but the browser is never going to be as secure as doing things on your own server.

jessaustin 12y ago

Can one stipulate that one does trust a particular server (maybe it has a valid TLS cert?) and still derive some value from this API? E.g., it seems perfectly valid to me to do some work on the client in order to reduce data volumes or server loads?

wtbob 12y ago
Well, I'd never trust the server (and TLS certs are only a step or two above pure snake oil security), but if the server is willing to trust me, then I don't in principle mind decrypting data on its behalf.
- jessaustin 12y ago
  Never trusting the server seems equivalent to never using an online service. This isn't helpful.

taf2 12y ago

Crypto Apis can be useful for things other than encrypting data - for example creating uniqueness or testing for uniqueness - I'm sure a range of other clever possibilities exist.

wtbob 12y ago
Excellent point. A well-chosen set of some primitives makes sense for site scripts, but the general case of encryption/decryption almost certainly doesn't in most cases.