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

Re: nasty nasty bug in chrome

From: Henry Story <henry.story@bblfish.net>
Date: Wed, 9 Feb 2011 15:53:29 +0100
Cc: <ltorokjr@gmail.com>, <nathan@webr3.org>, "public-xg-webid@w3.org" <public-xg-webid@w3.org>
Message-Id: <EC50FC49-B6BD-4889-BC67-28621C286A4C@bblfish.net>
To: Peter Williams <home_pw@msn.com>

On 9 Feb 2011, at 15:17, Peter Williams wrote:

> ok. incognito is a post-mozilla concept - start private browsing.

This is very much related to Issue-14  "WebID and Browsers". In particular
at the end of Chromium bug report 29784, I suggest future browser enhancements that would allow the user to see what identity he is using in communicating with a web agent - one of those is anonymous mode.

>  
> Well, now we have 2 decent use cases that are not just variants of the old SAML push/pull use cases from OASIS.

( I would not call these use cases. Rather these are questions on implementations of what can be a use case: anonymous browsing.)

>  
> 1 How does webid protocol (and its citation of certs etc, ssl sessionids) work in private browser mode

Presumably, since this is in reality an anonymous mode, the new window should not reuse any cookies or SSL sessions in this mode. If SSL connections are made and client certs are requested then user interface designer choices need to be made: show that the site requested the client side cert, but ignore it, or give a selection box that looks different from any other one, and especially would let the user know that by choosing a certificate he will leave the "private" mode. And there again this would require some study.

>  
> 2. How does webid protocol (and its...) work in the migration of normal browing to private browing mode

up to the designers. Presumably you could have one window open in private mode and one in non private 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?

these are new ideas browser designers are coming up with.

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

You mean something like drag and drop of resources onto the desktop, or from the desktop to the browser. Or since any application can be a browser of data, dragging resources across applications?

That is a good question. In theory there is no problem, but in practice, it is quite possible to place identity information in a URL, even if this cannot be very strong. So an anonymous web site can  - even when cookies don't work - create such URLs and use those to track visitor activity across the site. This is not fool proof, as the user could paste the URL and mail it to someone, but I suppose even that can be interesting.

So now you drag such a URL onto your authenticated app and drop it there. That app makes the request, and the server can now draw some relation between the initial browsing experience and the identity.

One solution to that is to warn the user in drag and drop mode of this danger, and future operating systems could even point out to the user that by doing this he has potentially left anonymous mode - depending on what the reciving app does with the URL.

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

Social Web Architect
http://bblfish.net/
Received on Wednesday, 9 February 2011 14:54:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:22 UTC