4 ms·

It's coming: http://www.w3.org/TR/WebCryptoAPI/ http://www.w3.org/TR/WebCryptoAPI/

politician 14y ago
Awesome! I hope it isn't marred by an attempt to close the default-open nature of web applications (they're looking for feedback on "potential missing functionalities to deploy secure web applications." Echoes of HDCP. Ugh.)
- daeken 14y ago
  Nothing in the WebCryptoAPI has anything to do with locking down applications, but attempting to make them more secure (that is, making it more difficult to compromise their integrity). That said, it doesn't accomplish this; see my sister comment to yours.
daeken 14y ago
tptacek (original author of the OP here) and I responded to the draft here: http://news.ycombinator.com/item?id=4549504 http://news.ycombinator.com/item?id=4549504 The tl;dr is: the trust model is broken, and low-level primitives exposed in the way that they are is begging for pain. Not a lot has changed since then, sadly.
- thirsteh 14y ago
  Yeah, I am not very optimistic about the primitives being used correctly, or any kind of safety in face of e.g. XSS. At least you can read from /dev/urandom...
- politician 14y ago
  Did either of you send any feedback or file any bugs at that time? A keyczar approach would be much loved by front-end devs and management. EDIT: There are some promising comments in their archives, "A high-level API is also perceived to be the only kind of API that is usable by the majority of web developers. I agree we should not put this off to long." [1] http://lists.w3.org/Archives/Public/public-webcrypto/2012Sep/0214.html http://lists.w3.org/Archives/Public/public-webcrypto/2012Sep...
  - thirsteh 14y ago
    or NaCl
- javajosh 14y ago
  Doesn't the Chrome plugin model sort of highlight the way forward? Chrome plugins have their own JavaScript environment, sharing only the DOM with client pages. A client wanting to do crypto could, for example, communicate this by mutating a piece of the DOM (for example, setting the text of a meta cleartext node) and then waiting for a DOM mutation in answer (a meta cyphertext node that, from the page's perspective, magically pops into existence). Anyway, that's how I'd do it. But yes, doing crypto within a page seems to be asking for trouble.
  - ville 14y ago
    But couldn't this magical meta node as easily be created by malicious code running on the client page?
    - javajosh 14y ago
      I suppose so. But if that's your level of paranoia you probably shouldn't be doing native crypto either, as any process on your machine could be finagling the memory regions of your "secure" program in the same way. In fact, the only secure way to do crypto, I suppose, is pen and paper.

Awesome! I hope it isn't marred by an attempt to close the default-open nature of web applications (they're looking for feedback on "potential missing functionalities to deploy secure web applications." Echoes of HDCP. Ugh.)

daeken 14y ago
Nothing in the WebCryptoAPI has anything to do with locking down applications, but attempting to make them more secure (that is, making it more difficult to compromise their integrity). That said, it doesn't accomplish this; see my sister comment to yours.

daeken 14y ago

tptacek (original author of the OP here) and I responded to the draft here: http://news.ycombinator.com/item?id=4549504 http://news.ycombinator.com/item?id=4549504 The tl;dr is: the trust model is broken, and low-level primitives exposed in the way that they are is begging for pain. Not a lot has changed since then, sadly.

thirsteh 14y ago
Yeah, I am not very optimistic about the primitives being used correctly, or any kind of safety in face of e.g. XSS. At least you can read from /dev/urandom...
politician 14y ago
Did either of you send any feedback or file any bugs at that time? A keyczar approach would be much loved by front-end devs and management. EDIT: There are some promising comments in their archives, "A high-level API is also perceived to be the only kind of API that is usable by the majority of web developers. I agree we should not put this off to long." [1] http://lists.w3.org/Archives/Public/public-webcrypto/2012Sep/0214.html http://lists.w3.org/Archives/Public/public-webcrypto/2012Sep...
- thirsteh 14y ago
  or NaCl
javajosh 14y ago
Doesn't the Chrome plugin model sort of highlight the way forward? Chrome plugins have their own JavaScript environment, sharing only the DOM with client pages. A client wanting to do crypto could, for example, communicate this by mutating a piece of the DOM (for example, setting the text of a meta cleartext node) and then waiting for a DOM mutation in answer (a meta cyphertext node that, from the page's perspective, magically pops into existence). Anyway, that's how I'd do it. But yes, doing crypto within a page seems to be asking for trouble.
- ville 14y ago
  But couldn't this magical meta node as easily be created by malicious code running on the client page?
  - javajosh 14y ago
    I suppose so. But if that's your level of paranoia you probably shouldn't be doing native crypto either, as any process on your machine could be finagling the memory regions of your "secure" program in the same way. In fact, the only secure way to do crypto, I suppose, is pen and paper.