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