- From: Tom Ritter <tom@ritter.vg>
- Date: Sat, 2 Feb 2013 09:51:38 -0500
- To: Ryan Sleevi <sleevi@google.com>
- Cc: public-webcrypto-comments@w3.org
Well, that's a pretty convincing rebuttal. It doesn't address use case #7 which is "I really really want it" though ;) Really, it just doesn't really make sense to me why this information wouldn't be exposed to javascript (for the main page and all subresources), along with things like page loading time, render mode, to short circuit all these page performance hacks we have - the answer is obvious: ask the browser for the performance times and the ssl information. It should have been there 5 years ago, and when things started focusing on SSL all sorts of Browser Plugins and tricks could have been deployed. But today, arguing "You should implement this" with an implicit ["instead of HPKP", "instead of TLS 1.2", "instead of something else valuable"], it makes less sense. And you're right - for most of my use cases, HPKP does work, and for the major lapse you identify neither my proposal nor HPKP work. And while I can nitpick and rebutt individual statements, or say something like "add it as a subproperty of every object that could load an external resource" - they're not things that ultimately resolve the disconnect between the multi-origin issue and the primary use case (detecting maliciousness), or provide value that HPKP doesn't. I still have this nagging sense of "This surely could be used for other reasons though", and I'm going to keep thinking about it ;) Maybe it'll be my first patch submission to a browser. -tom
Received on Saturday, 2 February 2013 14:52:25 UTC