Re: fyi: Tab-level cookies for the browser

Hi,

I am opposed to this.

Having this kind of functionality introduces more complexity when managing  
and selecting cookies to send, and I doubt the benefits outweigh the  
problems.

I have previously implemented "similar" functionality for Opera's widgets  
to isolate them from the user's normal surfing and other widgets working  
against the same host, but that was implementeded in combination with a  
separate cache for each widget, meaning that they are essentially  
exisiting in different url namespaces or applications instances, which is  
not remotely comparable to a situation where you want to share some  
cookies, but not all, with eligible resources within a single url  
namespace. The difference between the widget and the tab separation of  
cookies is that for widgets the cookie collection is identified directly  
by the namespace it is part of, that kind is not the case for a tab; a  
properly implemented HTTP stack knows nothing about which tab(s) or  
document frame(s) it is associated with (if any).

For that matter, this introduces the question of what to do if a document  
in another (unrelated) tab asks for the same unexpired resource as another  
document loaded with one of these tab-cookies. Should that resource even  
be available to the other tab? That would cause lots of extra network  
traffic. Should it be revalidated with the cookie set for the  
now-requesting tab? That would both require more complicated clientside  
decisions, and more complicated serverside scripts which have to be tab  
aware, and have to spend significant time evaluating if the cookies sent  
by the client matches with the resource it is validating.

Such functionality will probably mean some developers wants to prevent  
multitab browsing of their site, and as a reaction to that development,  
tab-bursting methods.

It is bad enough (IMO) that some web developers (including one major  
Canadian bank, at least some years back) think document.cookie in  
Ecmasscript DOM means that the cookies assigned to that are only available  
to scripts in that document context (they aren't, at least in Opera);  
adding tabs  to the system are just going to create more failure modes  
(e.g. "I opened a new tab and was no longer logged into MySocialSite.com,  
but this other tab is still logged in?").

And most of the above is before one have even considered the internal  
design complications such a system will entail.

Regarding the multiple logged-in-account problem, my non-webdeveloper  
suggestion would be to forget cookies, except a "single" session cookie  
which identifies the credentials, and use www.example.com/account1/  
www.example.com/account2/ prefixed URLs to identify the accounts (and  
account1 and account2 might just be random session values in order to  
prevent information leaks).

As an example of why tab cookies would be a problem, my method of surfing  
is to close the tabs when my task in them is completed, though I know  
others work differently. I may have quite a few tabs open at a time, but I  
close them when I no longer need them, and use bookmarks when I want to go  
back to the site. Using tab-specific cookies would not work for a user  
that work like I do. If I was logged into multiple webmail accounts at a  
time, I'd like to arrive at a frontpage and select the account(s) when I  
again opened up the webmail service.

On Wed, 29 Jul 2009 13:31:19 +0200, =JeffH <Jeff.Hodges@kingsmountain.com>
wrote:

> [ fwd'g in case http-state@ is an effectively dead list ]
>
>
> Subject: [http-state] Tab-level cookies for the browser
> From: Micah Lemonik <micah@google.com>
> Date: Tue, 28 Jul 2009 16:41:26 -0400 (13:41 PDT)
> To: http-state@ietf.org
> Cc: Ronald Ho <ronaldho@google.com>, "Chandra, Rishi"  
> <rchandra@google.com>,
> 	Jonathan Sergent <sergent@google.com>
>
>
> Greetings,
>
> We would like to propose the browser add tab-level cookies that will
> override the global process-level cookie in a given tab. That is if a tab
> override cookie is set on a particular tab, that cookie will be used in
> place of the global cookie. Tab level cookies would last the lifetime of  
> a
> tab and would propagate to child tabs.
> The use case we're trying to accommodate is to be logged into different
> google accounts in different tabs. sessionStorage gets us part of the way
> there in terms of enabling a per-tab resource that propagates to child  
> tabs,
> but sessionStorage doesn't automatically send data to the server on any
> request the way cookies do. Essentially we're looking for a solution  
> that 1.
> works with cookies for compatibility with existing infrastructure and 2.
> isn't limited to XMLHttpRequest usage where we have the ability to set
> custom headers.
>
> I would love to hear feedback from this list on how this might work in
> browsers and/or alternative solutions.
>
> Thank you,
>
> Micah Lemonik
> Staff Software Engineer
> Google Inc.



-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

Received on Wednesday, 29 July 2009 18:05:31 UTC