W3C home > Mailing lists > Public > public-xg-webid@w3.org > February 2011

RE: nasty nasty bug in chrome

From: Peter Williams <home_pw@msn.com>
Date: Wed, 9 Feb 2011 05:58:09 -0800
Message-ID: <SNT143-w65A825B976409754A880E892ED0@phx.gbl>
To: <nathan@webr3.org>
CC: "public-xg-webid@w3.org" <public-xg-webid@w3.org>

is it a bug
I dont know what an incognito window is.
But the general rule is that a browser can be itself replicated, and it can inherit the ssl state of its replicator.
You have to remember (and IETF NEVER got this) is that https target hypermedia, and the brower concept. Pre tabs and pre-popups), one expected to be looking at page X, and want to see page Y in parallel. The UI notion of Linking didnt allow for this. One could "duplicate" a browser frame however, and then link from there -  producing a view of X and Y.
If X was an https hypermedia document supproting by n SSL sessions, and m SSL connections, so too must replicant of X (since on X' only, the user may refresh before linking on)
This all generalizes to the browser behaviours in Mozilla (and its strict emulators, such as IE) on client certs. This "theory of UI and state" controls when a cert dialog is shewn, when and when behind the scenes on  the nth SSL session handshake on 1 TCP connection the client signing key for (RSA) client authn is automatically shewn to have been used, without prompting user for pin or bio. Similar arguments hold for shared cookie stores when one opens an "icognito" IE instance - a play where famously IE security model different from Mozilla - as anyone who builds server-side session managers in windows knows.
If you observe the behaviour of other invokers of https with client authn (e.g. the infocard "trusted desktop" of the Windows window manager) its behaviour is not mozilla-compatible. its not trying to be a browser with its link concept, after all; its trying to be an authentication protocol SEF. And, it has to support a browser, classical windows apps doing (web services) client/server, and ajax callbacks and ajax sockets. Its still a consumer and user of the webid protocol, I believe, even though its not a browser.
This webid protocol has rapidly gone from rescueing client certs from obscurity and 15 year old waits for national smartcards... to something modern.
 > From: henry.story@bblfish.net
> Date: Wed, 9 Feb 2011 11:38:35 +0100
> CC: public-xg-webid@w3.org
> To: nathan@webr3.org
> Subject: Re: nasty nasty bug in chrome
> On 9 Feb 2011, at 02:21, Nathan wrote:
> > 
> > It appears, that if you webid auth in chrome, them open a new incognito window, then go to the same website again, it'll automatically send your cert and auth you w/o asking..
> Did you report that bug? It's worth doing it. They are very responsive. 
> Just send us the bug ID here, and we can all vote on it :-)
> Henry
> > 
> > 
> Social Web Architect
> http://bblfish.net/
Received on Wednesday, 9 February 2011 13:59:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:41 UTC