Re: Exposing TLS & Certificate Information in Javascript

Perhaps one thing that browser vendors can do is make new window or navigator properties like this to be immuntable by the content JS - wouldn't that help with evil scripts spoofing them?

David 

----- Original Message -----
From: "Tom Ritter" <tom@ritter.vg>
To: "Ryan Sleevi" <sleevi@google.com>
Cc: public-webcrypto-comments@w3.org
Sent: Saturday, February 2, 2013 8:51:38 AM
Subject: Re: Exposing TLS & Certificate Information in Javascript

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 15:40:13 UTC