RE: nasty nasty bug in chrome

ok. incognito is a post-mozilla concept - start private browsing.
 
Well, now we have 2 decent use cases that are not just variants of the old SAML push/pull use cases from OASIS.
 
1 How does webid protocol (and its citation of certs etc, ssl sessionids) work in private browser mode
 
2. How does webid protocol (and its...) work in the migration of normal browing to private browing mode
 
Dont suppose there are any design documents describing the security enforcers defined for private browsing are there?
 
Are there any standards or specs? Or is it all hidden away in vendor land, or cross-vendor forums?
 
 
 
Arguably we have a third use case (depending on W3C rules):
 
3. how does webid protocol work in the transference of control between (trusted) desktops hosting browser and non-browser https instances, each engaged in a (compartmented?) run of the webid protocol?
 

Date: Wed, 9 Feb 2011 15:08:49 +0100
Subject: Re: nasty nasty bug in chrome
From: ltorokjr@gmail.com
To: home_pw@msn.com
CC: nathan@webr3.org; public-xg-webid@w3.org

Hi,


2011/2/9 Peter Williams <home_pw@msn.com>


is it a bug

it is
 

  I dont know what an incognito window is.

Nathan is probably refering to the "mode" that is also available in Firefox as "Start private browsing".

This means all cookies and any kind of previous browsing history that might help identify you at the server is reset/unavailable. It should mimic/replicate the situation of landing on a website for the first time. Any kind of action taken during this private browsing session is purged after you terminate the session (i.e close the window)
 

 
But the general rule is that a browser can be itself replicated, and it can inherit the ssl state of its replicator.

I believe it is exactly the thing that "private/incognito browsing" should not allow.  
 
I am not sure how the rest relates to this, but I found it very insightful though.

Thanks!

Las



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/
> 
>