Re: nasty nasty bug in chrome

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