- From: Richard Barnes <rlb@ipv.sx>
- Date: Thu, 27 Mar 2014 13:42:10 -0400
- To: Mark Watson <watsonm@netflix.com>
- Cc: Ryan Sleevi <sleevi@google.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
- Message-ID: <CAL02cgTEZAeMtriVRzi7ThE+pgzCpMV8+N1vWeP+L6rR5DyYZA@mail.gmail.com>
On Thu, Mar 27, 2014 at 12:08 PM, Mark Watson <watsonm@netflix.com> wrote: > > > Sent from my iPhone > > On Mar 27, 2014, at 3:20 PM, Richard Barnes <rlb@ipv.sx> wrote: > > > > > On Thu, Mar 27, 2014 at 11:10 AM, Mark Watson <watsonm@netflix.com> wrote: > >> >> >> Sent from my iPhone >> >> On Mar 27, 2014, at 1:50 PM, Ryan Sleevi <sleevi@google.com> wrote: >> >> >> On Mar 27, 2014 3:07 AM, "Mark Watson" <watsonm@netflix.com> wrote: >> > >> > >> > >> > Sent from my iPhone >> > >> > On Mar 27, 2014, at 1:19 AM, Ryan Sleevi <sleevi@google.com> wrote: >> > >> >> >> >> >> >> >> >> On Fri, Mar 21, 2014 at 7:23 PM, Richard Barnes <rlb@ipv.sx> wrote: >> >>> >> >>> On Fri, Mar 21, 2014 at 4:04 PM, Ryan Sleevi <sleevi@google.com> >> wrote: >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> On Fri, Mar 21, 2014 at 12:59 PM, Mark Watson <watsonm@netflix.com> >> wrote: >> >>>>> >> >>>>> >> >>>>> >> >>>>> Sent from my iPhone >> >>>>> >> >>>>> On Mar 21, 2014, at 12:41 PM, Richard Barnes <rlb@ipv.sx> wrote: >> >>>>> >> >>>>>> On Fri, Mar 21, 2014 at 1:17 PM, Mark Watson <watsonm@netflix.com> >> wrote: >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> On Fri, Mar 21, 2014 at 7:50 AM, Richard Barnes <rlb@ipv.sx> >> wrote: >> >>>>>>>> >> >>>>>>>> On Tue, Mar 11, 2014 at 9:08 PM, Mark Watson < >> watsonm@netflix.com> wrote: >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> On Tue, Mar 11, 2014 at 6:00 PM, Ryan Sleevi <sleevi@google.com> >> wrote: >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> On Mar 11, 2014 5:44 PM, "Mark Watson" <watsonm@netflix.com> >> wrote: >> >>>>>>>>>> > >> >>>>>>>>>> > Hi Ryan, >> >>>>>>>>>> > >> >>>>>>>>>> > This looks good with the following comments: >> >>>>>>>>>> > >> >>>>>>>>>> > (1) Why not add this capability, whilst keeping the existing >> JWK import / export ? For example add a new format "jwk-obj". This would >> keep things simple for the other use-case where the JWK is just being >> written to / read from a wire protocol. Supporting both is hardly arduous >> since UAs must support the serialization / de-serialization for wrap / >> unwrap anyway. >> >>>>>>>>>> > >> >>>>>>>>>> >> >>>>>>>>>> We should prioritize the common case. Dealing with >> ArrayBuffers for JSON or JS Objects is not the common case for any other >> Web API. >> >>>>>>>>> >> >>>>>>>>> We might disagree about which is the common case. Since we >> already have the actual JWKs (and several browsers have implemented these >> and they are being used) it seems sensible to add functionality here. There >> is no additional work to add rather than replace, so there is no need to >> prioritize. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> It seems abundantly silly to have two options here, when there's >> a trivial conversion between them. >> >>>>>>>> >> >>>>>>>> Object -> json.stringify() -> TextEncoder -> ABV >> >>>>>>>> ABV -> TextDecoder -> json.parse() -> Object >> >>>>>>>> >> >>>>>>>> Whichever one we choose here, a small JS shim can emulate the >> other. So we should really just choose one. >> >>>>>>> >> >>>>>>> >> >>>>>>> This is fine if you have TextEncoder. It doesn't appear on >> caniuse.com. Does anyone have information about browser support of this ? >> >>>>>> >> >>>>>> >> >>>>>> Even if you don't have TextEncoder, it's a small polyfill. See, >> e.g.: >> >>>>>> http://www.onicos.com/staff/iz/amuse/javascript/expert/utf.txt >> >>>>>> http://polycrypt.net/common/util.js >> >>>>>> >> >>>>>> Object -> json.stringify() -> utf16to8() -> >> somethingLike_str2abv() --> ABV >> >>>>>> ABV -> something_like_abv2str() -> utf8to16() -> json.parse() --> >> Object >> >>>>> >> >>>>> >> >>>>> How efficient is the polyfill for large messages ? >> >>>>> >> >>>>> ...Mark >> >>>>> >> >>>> >> >>>> Define 'large messages'. 512 bytes? 40K? 80K? 2MB? >> >>>> >> >>> >> >>> Out of curiosity, I made a little speed test and made some >> measurements (on my admittedly high-end laptop). >> >>> Test: http://www.ipv.sx/transcode-test/ >> >>> Results: http://goo.gl/jAowJh >> >>> >> >>> TL;DR: All browsers tested could process 16KB in <=6ms and 256KB in >> <50ms. 20MB took a couple of seconds. >> >>> >> >>> But none of this matters, since we're talking about key packages, >> which are never going to be more than ~10KB. So performance is not an >> issue. >> >>> >> >>> --Richard >> >>> >> >> >> >> Note, recently this issue was brought to the attention of the W3C TAG >> and there has been some discussion about this at >> http://lists.w3.org/Archives/Public/www-tag/2014Mar/0026.html >> >> >> >> There is still a lot of confusion about the use cases for the >> ArrayBuffer case, so hopefully Mark can provide the use case / sample code >> to demonstrate the pattern. >> >> >> >> Otherwise, it does seem like there is a general sentiment towards >> using 'proper' JavaScript objects, especially in light of the general uses >> of JWK. >> >> >> >> I'd like to make some degree of progress on this so we can close it >> out. >> > >> > >> > As I mentioned before, if support for TextEncoding is widespread or >> expected to be soon, then (as Richard says) there is no advantage in >> supporting both options, since conversion is trivial and efficient. >> > >> > In that case, I do not have an opinion on which option we should >> support (because conversion is trivial and efficient). >> > >> > So, what is the status of TextEncoding ? >> > >> > ...Mark >> >> Mark, >> >> Conversion is still trivial and efficient - for _your_ use case, without >> Encoding support. >> >> Put simply: Can you agree to live with this without that support, or will >> you raise a formal objection? If so, the WG *needs* to know why and how to >> resolve this. >> >> Holding this spec 'hostage' for Encoding support is not a viable path. >> >> This is certainly not an issue worthy of a formal objection and I've no >> intention of holding the spec hostage. >> >> I would like to know about the status of TextEncoding. Is it something >> that all browsers are considering implementing or is it something about >> which there is controversy? It's not listed on caniuse, which usually >> covers most mainstream stuff. >> >> I don't think it's necessary to have TextEncoding supported by browsers >> in the same timeframe as WebCrypto to go with the object approach, but I >> would feel more comfortable with the object approach if it was known that >> TextEncoding was at least 'coming soon to a browser near you.' >> > > I'm confused as to why TextEncoding is still an issue here. I though I > had posted some links to polyfills up-thread, and provided some data on > their efficiency. Re-encoding strings from UTF-16 to UTF-8 is really not > hard. > > > I think if you read my mail carefully it says it is not an issue, but I > would still like to know when / if TextEncoding is likely to be supported > by browsers. > Ok, got it. FWIW, TextEncoder has been in Firefox for some time. --Richard > > ...Mark > > > --Richard > > > > >> >> ...Mark >> > >
Received on Thursday, 27 March 2014 17:42:38 UTC