Re: [webkit-dev] DOMCrypt
A couple updates to this thread: 1) DOMCrypt seems to be moving along the W3C path. There isn't a working group set up yet, but there seems to be sufficient interest that a W3C activity appears to be spinning up around this effort. 2) Ian Fette met with a number of banks in South Korean and Taiwan, and they're interested in using this API to replace their current reliance on ActiveX-based security plug-ins. I'm sure that many of you are more familiar with the Korean Bank problem than I am, but the main issue is that folks in Korea have trouble adopting non-IE browsers because their banks use ActiveX plug-ins to interact with certificates in order to help secure some of their banking interactions. One way we'd like to improve the web platform is to provide the web platform is to provide support for these use cases. The exact requirements from the Korean Banks are somewhat involved, and I'm not entirely sure we've understood them fully yet, so we'd like to start experimenting with something that seems generally useful and see whether how well it addresses their needs. I've added a brief description of one starting point for this discussion to the Mozilla wiki on DOMCrypt: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest#Possible_Additions (Note: I haven't discussed this use case with David Dahl yet, so it is entirely possible this will be cut from DOMCrypt.) One thing that would be helpful in making progress here would be to start experimenting with this API in WebKit. I suspect we'll need to iterate a number of times on the API in order to make sure we end up with something that works for these Korean banks. Having running code that they can play with would be very useful, especially in light of the language barrier. I'd like to re-iterate that we have no intention of enabling this feature by default until the specification and standards process is more mature. Experimenting with this API should have very little impact on other consumers of WebKit. Thanks, Adam On Wed, Jul 27, 2011 at 10:06 AM, Sam Weinig wei...@apple.com wrote: I think we should let the spec mature a bit before diving in. -Sam On Jul 26, 2011, at 10:53 PM, Adam Barth wrote: Hi webkit-dev, As some of you are probably aware, Mozilla is experimenting with exposing some basic cryptographic primitives to web applications: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest I wanted to get a sense from the WebKit community about how interested we are in implementing this feature. My sense is that this API is fairly early in it's lifecycle, so one perspective is that we should wait for Mozilla to experiment for a bit longer and revisit this question once the design is further along (e.g., submitted to the W3C standards process). Another perspective is that there are some simple parts of the API that we should implement now, and we can grow into the more involved parts of the API as they mature. For example, the CryptoHash interface can be implemented independently of the rest of the API and provides value by itself. Thoughts? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOMCrypt
For example, the CryptoHash interface can be implemented independently of the rest of the API and provides value by itself. Moving forward on that part first sounds reasonable. I've been asked about that specifically by some app developers that really aren't interested in the other parts of the larger proposal. On Wed, Jul 27, 2011 at 10:06 AM, Sam Weinig wei...@apple.com wrote: I think we should let the spec mature a bit before diving in. -Sam On Jul 26, 2011, at 10:53 PM, Adam Barth wrote: Hi webkit-dev, As some of you are probably aware, Mozilla is experimenting with exposing some basic cryptographic primitives to web applications: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest I wanted to get a sense from the WebKit community about how interested we are in implementing this feature. My sense is that this API is fairly early in it's lifecycle, so one perspective is that we should wait for Mozilla to experiment for a bit longer and revisit this question once the design is further along (e.g., submitted to the W3C standards process). Another perspective is that there are some simple parts of the API that we should implement now, and we can grow into the more involved parts of the API as they mature. For example, the CryptoHash interface can be implemented independently of the rest of the API and provides value by itself. Thoughts? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOMCrypt
On Fri, Aug 5, 2011 at 12:09 PM, Michael Nordman micha...@google.com wrote: For example, the CryptoHash interface can be implemented independently of the rest of the API and provides value by itself. Moving forward on that part first sounds reasonable. I've been asked about that specifically by some app developers that really aren't interested in the other parts of the larger proposal. Are they specifically interested in hashing blobs? David and I have been discussing what sort of types these functions should handle. Adam On Wed, Jul 27, 2011 at 10:06 AM, Sam Weinig wei...@apple.com wrote: I think we should let the spec mature a bit before diving in. -Sam On Jul 26, 2011, at 10:53 PM, Adam Barth wrote: Hi webkit-dev, As some of you are probably aware, Mozilla is experimenting with exposing some basic cryptographic primitives to web applications: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest I wanted to get a sense from the WebKit community about how interested we are in implementing this feature. My sense is that this API is fairly early in it's lifecycle, so one perspective is that we should wait for Mozilla to experiment for a bit longer and revisit this question once the design is further along (e.g., submitted to the W3C standards process). Another perspective is that there are some simple parts of the API that we should implement now, and we can grow into the more involved parts of the API as they mature. For example, the CryptoHash interface can be implemented independently of the rest of the API and provides value by itself. Thoughts? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOMCrypt
Yes, hashing blobs. Here's the last line of the relevant meeting notes... In the end, we all agreed that the main thing with the highest utility would be a native hashing implementation that could accept strings, bytes, or BLOBs. On Fri, Aug 5, 2011 at 12:32 PM, Adam Barth aba...@webkit.org wrote: On Fri, Aug 5, 2011 at 12:09 PM, Michael Nordman micha...@google.com wrote: For example, the CryptoHash interface can be implemented independently of the rest of the API and provides value by itself. Moving forward on that part first sounds reasonable. I've been asked about that specifically by some app developers that really aren't interested in the other parts of the larger proposal. Are they specifically interested in hashing blobs? David and I have been discussing what sort of types these functions should handle. Adam On Wed, Jul 27, 2011 at 10:06 AM, Sam Weinig wei...@apple.com wrote: I think we should let the spec mature a bit before diving in. -Sam On Jul 26, 2011, at 10:53 PM, Adam Barth wrote: Hi webkit-dev, As some of you are probably aware, Mozilla is experimenting with exposing some basic cryptographic primitives to web applications: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest I wanted to get a sense from the WebKit community about how interested we are in implementing this feature. My sense is that this API is fairly early in it's lifecycle, so one perspective is that we should wait for Mozilla to experiment for a bit longer and revisit this question once the design is further along (e.g., submitted to the W3C standards process). Another perspective is that there are some simple parts of the API that we should implement now, and we can grow into the more involved parts of the API as they mature. For example, the CryptoHash interface can be implemented independently of the rest of the API and provides value by itself. Thoughts? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOMCrypt
Bytes and (likely) blobs are types we're planning to do in DOMCrypt. Hashing strings is slightly more delicate because you need to pick an encoding. Do you have a sense, if we did bytes and blobs, would that be enough, or are strings really important also? Thanks, Adam On Fri, Aug 5, 2011 at 12:43 PM, Michael Nordman micha...@google.com wrote: Yes, hashing blobs. Here's the last line of the relevant meeting notes... In the end, we all agreed that the main thing with the highest utility would be a native hashing implementation that could accept strings, bytes, or BLOBs. On Fri, Aug 5, 2011 at 12:32 PM, Adam Barth aba...@webkit.org wrote: On Fri, Aug 5, 2011 at 12:09 PM, Michael Nordman micha...@google.com wrote: For example, the CryptoHash interface can be implemented independently of the rest of the API and provides value by itself. Moving forward on that part first sounds reasonable. I've been asked about that specifically by some app developers that really aren't interested in the other parts of the larger proposal. Are they specifically interested in hashing blobs? David and I have been discussing what sort of types these functions should handle. Adam On Wed, Jul 27, 2011 at 10:06 AM, Sam Weinig wei...@apple.com wrote: I think we should let the spec mature a bit before diving in. -Sam On Jul 26, 2011, at 10:53 PM, Adam Barth wrote: Hi webkit-dev, As some of you are probably aware, Mozilla is experimenting with exposing some basic cryptographic primitives to web applications: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest I wanted to get a sense from the WebKit community about how interested we are in implementing this feature. My sense is that this API is fairly early in it's lifecycle, so one perspective is that we should wait for Mozilla to experiment for a bit longer and revisit this question once the design is further along (e.g., submitted to the W3C standards process). Another perspective is that there are some simple parts of the API that we should implement now, and we can grow into the more involved parts of the API as they mature. For example, the CryptoHash interface can be implemented independently of the rest of the API and provides value by itself. Thoughts? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOMCrypt
I think bytes and blobs would be sufficient. +f...@google.com On Fri, Aug 5, 2011 at 12:58 PM, Adam Barth aba...@webkit.org wrote: Bytes and (likely) blobs are types we're planning to do in DOMCrypt. Hashing strings is slightly more delicate because you need to pick an encoding. Do you have a sense, if we did bytes and blobs, would that be enough, or are strings really important also? Thanks, Adam On Fri, Aug 5, 2011 at 12:43 PM, Michael Nordman micha...@google.com wrote: Yes, hashing blobs. Here's the last line of the relevant meeting notes... In the end, we all agreed that the main thing with the highest utility would be a native hashing implementation that could accept strings, bytes, or BLOBs. On Fri, Aug 5, 2011 at 12:32 PM, Adam Barth aba...@webkit.org wrote: On Fri, Aug 5, 2011 at 12:09 PM, Michael Nordman micha...@google.com wrote: For example, the CryptoHash interface can be implemented independently of the rest of the API and provides value by itself. Moving forward on that part first sounds reasonable. I've been asked about that specifically by some app developers that really aren't interested in the other parts of the larger proposal. Are they specifically interested in hashing blobs? David and I have been discussing what sort of types these functions should handle. Adam On Wed, Jul 27, 2011 at 10:06 AM, Sam Weinig wei...@apple.com wrote: I think we should let the spec mature a bit before diving in. -Sam On Jul 26, 2011, at 10:53 PM, Adam Barth wrote: Hi webkit-dev, As some of you are probably aware, Mozilla is experimenting with exposing some basic cryptographic primitives to web applications: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest I wanted to get a sense from the WebKit community about how interested we are in implementing this feature. My sense is that this API is fairly early in it's lifecycle, so one perspective is that we should wait for Mozilla to experiment for a bit longer and revisit this question once the design is further along (e.g., submitted to the W3C standards process). Another perspective is that there are some simple parts of the API that we should implement now, and we can grow into the more involved parts of the API as they mature. For example, the CryptoHash interface can be implemented independently of the rest of the API and provides value by itself. Thoughts? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOMCrypt
Hey Adam, I thought it might make sense to let the user specify a private key file (e.g. an RSA-key) that is in the browsers KeyChain. Would that make sense to have it implemented in the DOMCryptAPI? Otherwise I can't see many use cases, because I think encryption on a high OSI layer just doesn't make sense for me. If someone is able to sniff SSL/TLS encrypted packages due to nulling he will also be able to collect enough generated data to see how the hashing on the Browser-side works and which one will be the next hash generated - thanks to cuda and ati stream. But that's just my personal opinion on that. Greets from Germany, Chris __ Christoph Martens JavaScript Engineer, Zynga Germany Freetime Cyanogen developer, kernel.org core dev and Metasploit hacker Zynga Game Germany GmbH An der Welle 4 60322 Frankfurt, Germany cmart...@zynga.com On 7/27/11 7:53 AM, Adam Barth aba...@webkit.org wrote: Hi webkit-dev, As some of you are probably aware, Mozilla is experimenting with exposing some basic cryptographic primitives to web applications: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest I wanted to get a sense from the WebKit community about how interested we are in implementing this feature. My sense is that this API is fairly early in it's lifecycle, so one perspective is that we should wait for Mozilla to experiment for a bit longer and revisit this question once the design is further along (e.g., submitted to the W3C standards process). Another perspective is that there are some simple parts of the API that we should implement now, and we can grow into the more involved parts of the API as they mature. For example, the CryptoHash interface can be implemented independently of the rest of the API and provides value by itself. Thoughts? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOMCrypt
My sense is that the Mozilla folks want to start with the simple building blocks first and then work up to more complicated things like interacting with OS key stores and smart card readers. DOMCrypt is also useful for protecting data at rest, which isn't something you can do with TLS. For example, imagine that a web site wants to store a bunch of sensitive data on the client. The site can encrypt the data using DOMCrypt and then keep the KeyID off-device (e.g., in the cloud or in escrow). Later, the site can reunite the KeyID with the encrypted data on the client in order to decrypt. As a more concrete example of the above, consider a service like LastPass that wants to store your passwords (encrypted) on the client and never wants to touch your plaintext passwords on the server. These use cases all involve the public key encryption/decryption functionality. The hashing and MACing operations are somewhat lower level building blocks, but they seem like an easier place to start. Adam On Wed, Jul 27, 2011 at 12:59 AM, Christoph Martens cmart...@zynga.com wrote: Hey Adam, I thought it might make sense to let the user specify a private key file (e.g. an RSA-key) that is in the browsers KeyChain. Would that make sense to have it implemented in the DOMCryptAPI? Otherwise I can't see many use cases, because I think encryption on a high OSI layer just doesn't make sense for me. If someone is able to sniff SSL/TLS encrypted packages due to nulling he will also be able to collect enough generated data to see how the hashing on the Browser-side works and which one will be the next hash generated - thanks to cuda and ati stream. But that's just my personal opinion on that. Greets from Germany, Chris __ Christoph Martens JavaScript Engineer, Zynga Germany Freetime Cyanogen developer, kernel.org core dev and Metasploit hacker Zynga Game Germany GmbH An der Welle 4 60322 Frankfurt, Germany cmart...@zynga.com On 7/27/11 7:53 AM, Adam Barth aba...@webkit.org wrote: Hi webkit-dev, As some of you are probably aware, Mozilla is experimenting with exposing some basic cryptographic primitives to web applications: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest I wanted to get a sense from the WebKit community about how interested we are in implementing this feature. My sense is that this API is fairly early in it's lifecycle, so one perspective is that we should wait for Mozilla to experiment for a bit longer and revisit this question once the design is further along (e.g., submitted to the W3C standards process). Another perspective is that there are some simple parts of the API that we should implement now, and we can grow into the more involved parts of the API as they mature. For example, the CryptoHash interface can be implemented independently of the rest of the API and provides value by itself. Thoughts? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOMCrypt
Well, I think that makes sense... But not for me. I have the opinion that cloud-hosted keys aren't keys anymore - right? I mean, man-in-the-middle attacks are the 100% use case when it comes to encryption due to buggy DNS-protocol that can't be updated. I also think that this is kinda interesting when it comes to signing uploads or files from inside a WebApp. It makes sense to build a JavaScript API for hashing the values - so that you can transfer data via unencrypted connection - which isn't smart, but it should gain a low level of security depending on the algorithm. But I wouldn't trust the hoster if there are plaintext passwords stored on their servers. That's kinda php4 =/ Do you know which algorithms are planned to be implemented? Are there twofish, blowfish or similar going to be included as well? __ Christoph Martens JavaScript Engineer, Zynga Germany Freetime Cyanogen developer, kernel.org core dev and Metasploit hacker Zynga Game Germany GmbH An der Welle 4 60322 Frankfurt, Germany cmart...@zynga.com On 7/27/11 10:11 AM, Adam Barth aba...@webkit.org wrote: My sense is that the Mozilla folks want to start with the simple building blocks first and then work up to more complicated things like interacting with OS key stores and smart card readers. DOMCrypt is also useful for protecting data at rest, which isn't something you can do with TLS. For example, imagine that a web site wants to store a bunch of sensitive data on the client. The site can encrypt the data using DOMCrypt and then keep the KeyID off-device (e.g., in the cloud or in escrow). Later, the site can reunite the KeyID with the encrypted data on the client in order to decrypt. As a more concrete example of the above, consider a service like LastPass that wants to store your passwords (encrypted) on the client and never wants to touch your plaintext passwords on the server. These use cases all involve the public key encryption/decryption functionality. The hashing and MACing operations are somewhat lower level building blocks, but they seem like an easier place to start. Adam On Wed, Jul 27, 2011 at 12:59 AM, Christoph Martens cmart...@zynga.com wrote: Hey Adam, I thought it might make sense to let the user specify a private key file (e.g. an RSA-key) that is in the browsers KeyChain. Would that make sense to have it implemented in the DOMCryptAPI? Otherwise I can't see many use cases, because I think encryption on a high OSI layer just doesn't make sense for me. If someone is able to sniff SSL/TLS encrypted packages due to nulling he will also be able to collect enough generated data to see how the hashing on the Browser-side works and which one will be the next hash generated - thanks to cuda and ati stream. But that's just my personal opinion on that. Greets from Germany, Chris __ Christoph Martens JavaScript Engineer, Zynga Germany Freetime Cyanogen developer, kernel.org core dev and Metasploit hacker Zynga Game Germany GmbH An der Welle 4 60322 Frankfurt, Germany cmart...@zynga.com On 7/27/11 7:53 AM, Adam Barth aba...@webkit.org wrote: Hi webkit-dev, As some of you are probably aware, Mozilla is experimenting with exposing some basic cryptographic primitives to web applications: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest I wanted to get a sense from the WebKit community about how interested we are in implementing this feature. My sense is that this API is fairly early in it's lifecycle, so one perspective is that we should wait for Mozilla to experiment for a bit longer and revisit this question once the design is further along (e.g., submitted to the W3C standards process). Another perspective is that there are some simple parts of the API that we should implement now, and we can grow into the more involved parts of the API as they mature. For example, the CryptoHash interface can be implemented independently of the rest of the API and provides value by itself. Thoughts? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOMCrypt
These sorts of questions are probably better discussed on the whatwg mailing list (where there is currently a thread about DOMCrypt) because they're general questions about the use cases and features set of the API and not about WebKit's implementation (or non-implementation) of the API. Thanks for you interest. Adam On Wed, Jul 27, 2011 at 2:29 AM, Christoph Martens cmart...@zynga.com wrote: Well, I think that makes sense... But not for me. I have the opinion that cloud-hosted keys aren't keys anymore - right? I mean, man-in-the-middle attacks are the 100% use case when it comes to encryption due to buggy DNS-protocol that can't be updated. I also think that this is kinda interesting when it comes to signing uploads or files from inside a WebApp. It makes sense to build a JavaScript API for hashing the values - so that you can transfer data via unencrypted connection - which isn't smart, but it should gain a low level of security depending on the algorithm. But I wouldn't trust the hoster if there are plaintext passwords stored on their servers. That's kinda php4 =/ Do you know which algorithms are planned to be implemented? Are there twofish, blowfish or similar going to be included as well? __ Christoph Martens JavaScript Engineer, Zynga Germany Freetime Cyanogen developer, kernel.org core dev and Metasploit hacker Zynga Game Germany GmbH An der Welle 4 60322 Frankfurt, Germany cmart...@zynga.com On 7/27/11 10:11 AM, Adam Barth aba...@webkit.org wrote: My sense is that the Mozilla folks want to start with the simple building blocks first and then work up to more complicated things like interacting with OS key stores and smart card readers. DOMCrypt is also useful for protecting data at rest, which isn't something you can do with TLS. For example, imagine that a web site wants to store a bunch of sensitive data on the client. The site can encrypt the data using DOMCrypt and then keep the KeyID off-device (e.g., in the cloud or in escrow). Later, the site can reunite the KeyID with the encrypted data on the client in order to decrypt. As a more concrete example of the above, consider a service like LastPass that wants to store your passwords (encrypted) on the client and never wants to touch your plaintext passwords on the server. These use cases all involve the public key encryption/decryption functionality. The hashing and MACing operations are somewhat lower level building blocks, but they seem like an easier place to start. Adam On Wed, Jul 27, 2011 at 12:59 AM, Christoph Martens cmart...@zynga.com wrote: Hey Adam, I thought it might make sense to let the user specify a private key file (e.g. an RSA-key) that is in the browsers KeyChain. Would that make sense to have it implemented in the DOMCryptAPI? Otherwise I can't see many use cases, because I think encryption on a high OSI layer just doesn't make sense for me. If someone is able to sniff SSL/TLS encrypted packages due to nulling he will also be able to collect enough generated data to see how the hashing on the Browser-side works and which one will be the next hash generated - thanks to cuda and ati stream. But that's just my personal opinion on that. Greets from Germany, Chris __ Christoph Martens JavaScript Engineer, Zynga Germany Freetime Cyanogen developer, kernel.org core dev and Metasploit hacker Zynga Game Germany GmbH An der Welle 4 60322 Frankfurt, Germany cmart...@zynga.com On 7/27/11 7:53 AM, Adam Barth aba...@webkit.org wrote: Hi webkit-dev, As some of you are probably aware, Mozilla is experimenting with exposing some basic cryptographic primitives to web applications: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest I wanted to get a sense from the WebKit community about how interested we are in implementing this feature. My sense is that this API is fairly early in it's lifecycle, so one perspective is that we should wait for Mozilla to experiment for a bit longer and revisit this question once the design is further along (e.g., submitted to the W3C standards process). Another perspective is that there are some simple parts of the API that we should implement now, and we can grow into the more involved parts of the API as they mature. For example, the CryptoHash interface can be implemented independently of the rest of the API and provides value by itself. Thoughts? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOMCrypt
I think we should let the spec mature a bit before diving in. -Sam On Jul 26, 2011, at 10:53 PM, Adam Barth wrote: Hi webkit-dev, As some of you are probably aware, Mozilla is experimenting with exposing some basic cryptographic primitives to web applications: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest I wanted to get a sense from the WebKit community about how interested we are in implementing this feature. My sense is that this API is fairly early in it's lifecycle, so one perspective is that we should wait for Mozilla to experiment for a bit longer and revisit this question once the design is further along (e.g., submitted to the W3C standards process). Another perspective is that there are some simple parts of the API that we should implement now, and we can grow into the more involved parts of the API as they mature. For example, the CryptoHash interface can be implemented independently of the rest of the API and provides value by itself. Thoughts? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] DOMCrypt
Hi webkit-dev, As some of you are probably aware, Mozilla is experimenting with exposing some basic cryptographic primitives to web applications: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest I wanted to get a sense from the WebKit community about how interested we are in implementing this feature. My sense is that this API is fairly early in it's lifecycle, so one perspective is that we should wait for Mozilla to experiment for a bit longer and revisit this question once the design is further along (e.g., submitted to the W3C standards process). Another perspective is that there are some simple parts of the API that we should implement now, and we can grow into the more involved parts of the API as they mature. For example, the CryptoHash interface can be implemented independently of the rest of the API and provides value by itself. Thoughts? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
