Subject: fyi: Tab-level cookies for the browser

From: =JeffH <[email-masked]>
Date: Wed, 29 Jul 2009 04:31:19 -0700

[ fwd'g in case http-state@ is an effectively dead list ]

Subject: [http-state] Tab-level cookies for the browser
From: Micah Lemonik <[email-masked]>
Date: Tue, 28 Jul 2009 16:41:26 -0400 (13:41 PDT)
To: [email-masked]
Cc: Ronald Ho <[email-masked]>, "Chandra, Rishi" <[email-masked]>,
	Jonathan Sergent <[email-masked]>

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.

---

From: Daniel Stenberg <[email-masked]>
Date: Wed, 29 Jul 2009 13:46:12 +0200 (CEST)

> tab and would propagate to child tabs.

[...]

> browsers and/or alternative solutions.

I fail to see a way how the server can give any particular useful hints about 
the cookie like "This is suitable for a tab" or "This is for a whole browser". 
After all, I would figure a browser could decided to do more or less *ALL* 
cookies separate in their own tabs.

The problems for a browser inlcude how to know what cookies to save and which 
that would be used globally etc. I would assume that it would make separate 
cookie jars and let the user match jars with tabs or something. And possibly 
make one of the tab's jars become the global jar...

I don't think this is a HTTP(-bis) issue. Even if the http-state list is 
mostly dead...

-- 

  / daniel.haxx.se

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Wed, 29 Jul 2009 20:04:50 +0200

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.

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: Bil Corry <[email-masked]>
Date: Wed, 29 Jul 2009 15:06:30 -0500

Yngve N. Pettersen wrote on 7/29/2009 1:04 PM: 
> 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.

It may be I'm not correctly understanding the proposal or your objection, but I'm not following the problem you presented.  Regardless if you close an existing tab, opening a new tab will start the tab with an empty tab-cookie jar and the site would require you log in again.  This may annoy those who like to close the tab, open a new one and be automatically logged in, but I imagine that's up to the server to consider when deciding to implement it.

- Bil

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Wed, 29 Jul 2009 23:14:05 +0200

On Wed, 29 Jul 2009 22:06:30 +0200, Bil Corry <[email-masked]> wrote:

> It may be I'm not correctly understanding the proposal or your  
> objection, but I'm not following the problem you presented.  Regardless  
> if you close an existing tab, opening a new tab will start the tab with  
> an empty tab-cookie jar and the site would require you log in again.   
> This may annoy those who like to close the tab, open a new one and be  
> automatically logged in, but I imagine that's up to the server to  
> consider when deciding to implement it.

Bil: The whole point about being logged into multiple webmail accounts at  
the same time in the same browser instance, is to be able to use them  
seamlessly in parallel, in multiple tabs. And you also want to be able to  
get back to all those accounts with aminimum amount of fuss.

The proposal is to use tabspecific session cookies to control which  
account is displayed in each tab.

My objection above (aside from the complexity issues) is that with that  
type of operation then my way of working, which is to close the tab when I  
am finished with it, as well as somebody accidentally closing a tab, mean  
I will most likely have to log in again in order to use the account again  
(I can think of ways that that can be avoided, but then you are already  
halfway to my URI path proposal). OTOH the whole point about being logged  
into multiple accounts is to avoid logging in again when you wan to change  
context to another account.

IMO there are probably several ways to allow a user to be logged into  
multiple accounts at the same time, without resorting to tabspecific  
cookies. One way is to store all information about the accessed accounts  
in the serverside state and use the URL path to determine which account is  
being used. There may be other methods as well. The benefit of these  
methods is that it will work in older clients as well.

-- 
Sincerely,
Yngve N. Pettersen

---

From: David Morris <[email-masked]>
Date: Wed, 29 Jul 2009 14:44:49 -0700 (PDT)

> The proposal is to use tabspecific session cookies to control which account 
> is displayed in each tab.

This is a wider issue than tabs ... a tab is just a special case of new 
browser window... IF any support is provided, it should be based on a new
notion of scope along with well thought out rules for when scope is shared 
between windows and when not. The HTTP WGs have classically avoided User 
Agent behavior issues so perhaps this should be solved elsewhere (if at 
all)?

May also be that cookie domains could sort this out already? My 
recollection of the original proposal was to deal with multiple 
application logins? If I recall and interpret correctly that would not be 
multiple logins to the same application. Not a@gmail and b@gmail but 
rather a@gmail and (a|b)@earth using the google app set. cookie2 domains 
should be able to solve that problem.

Dave Morris

---

From: Bil Corry <[email-masked]>
Date: Wed, 29 Jul 2009 16:49:06 -0500

Yngve N. Pettersen wrote on 7/29/2009 4:14 PM: 
> type of operation then my way of working, which is to close the tab when
> I am finished with it, as well as somebody accidentally closing a tab,
> mean I will most likely have to log in again in order to use the account
> again (I can think of ways that that can be avoided, but then you are
> already halfway to my URI path proposal). OTOH the whole point about
> being logged into multiple accounts is to avoid logging in again when
> you wan to change context to another account.

True, if you close the tab, you remove the tab-cookie and effectively end your session.  However, if the site chose to, it could use a normal cookie to associate your browser instance to your various tab instances, and offer you the choice of picking a non-expired tab instance when returning -- that would be up to the server to implement.

- Bil