Subject: [http-state] identifying "windows" and cookie scope

From: "Mike Wilson" <[email-masked]>
Date: Mon, 17 May 2010 18:03:57 +0200

Below I describe a couple of related issues and solutions. Feel
free to split into separate threads if desired.

Identifying browser windows
---------------------------
A long-time challenge for web application developers is to make
consistent handling of session state when multiple open windows 
or tabs are used. The session state is typically referenced
through a cookie shared by all the tabs which then causes side 
effects if the user tries to perform different operations in 
the different tabs. There are numerous sources that discuss this
problem, here's one random link:
http://www.mail-archive.com/[email-masked]/msg50204.html

And here's a post on whatwg suggesting to mitigate this problem
by adding a new HTTP header containing a generated unique window 
identifier:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-February/024979.htm
l

Whatever solution may be most appropriate, this is a problem
that would benefit a lot from being addressed by browsers.

Scope of cookie store
---------------------
In previous cookie specs there haven't been much mention about
the cookie store. It is good to see in the new drafts that this
is now somewhat more defined, in that one user agent is supposed
to have exactly one cookie store (do I read this correctly?).

To enhance this definition even further it would be nice with a
better specification of "user agent". For the web browser 
scenario possible interpretations could range from having one
shared cookie store for all browser implementations on the 
system, down to having one cookie store per tab.

FWIW, Internet Explorer (all the way up to version 8) is 
perceived as having one cookie store shared between processes 
for persistent cookies, while having one cookie store per process
for non-persistent cookies. It would thus fail the "one cookie 
store" definition whichever way user agent is defined.

I'm not sure where is the best place to define (or explicitly not 
define) this, but I wanted to bring it to your attention and hope 
this is a good place to discuss it.

Using scoped cookie to identify browser window
----------------------------------------------
IE's non-persistent-cookie-store-per-process feature can be used
to mimic the "state per window" (not tab) discussed initially in
this mail.

To instead allow a standard solution for this, not adding new 
headers, we could instead extend cookies to allow an explicit 
Scope attribute:

  Set-Cookie: ... Scope=browsing_context; ...

that would cause the user agent to only send this cookie for the
specified scope (here: browsing context  = window or tab) that 
received it.

The Scope parameter could be a general mechanism specified by the
cookie spec, possibly with allowed values specified in other
specs more applicable to each host environment.

Would any of this be interesting to look at within the current, or 
a future, http-state charter?

Best regards
Mike Wilson

---

From: Joshua Davies <[email-masked]>
Date: Mon, 17 May 2010 11:18:13 -0500

This would be a huge help for e-commerce sites... although the "open link in new tab/window" would almost always fail in this case, since the cookies associated with the original browsing context wouldn't be sent.  Alternatively, what about an "instance" parameter:

   Set-Cookie: ... Instance=2; ...

?  The user agent could just keep track of how many browsing contexts it had established to a specific domain (which seems like a pretty light burden on the user agent), and associate an "Instance" number with each one.  If a web application was "tab-specific", it could keep track of Instance numbers, but a more stateless application could just ignore this parameter and there'd be no backwards-compatibility issue.

I'd really like to see this standardized and will immediately offer a Firefox patch implementing such a feature if and when it is - not being able to keep track of multiple tabs/windows is a big problem for us.

On 05/17/2010 11:03 AM, Mike Wilson wrote:
> _______________________________________________
> http-state mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-state
>    

<http://twiki.dev.sabre.com/twiki/bin/view/Travelocity/TVLYArchitecture>

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 17 May 2010 19:38:55 +0200 (CEST)

On Mon, 17 May 2010, Mike Wilson wrote:

> In previous cookie specs there haven't been much mention about the cookie 
> store. It is good to see in the new drafts that this is now somewhat more 
> defined, in that one user agent is supposed to have exactly one cookie store 
> (do I read this correctly?).

I certainly do not read it like that. A user agent is said to store the 
cookies in "a" cookie store, but there's nothing that forces that cookie store 
to be the same cookie store as when the user agent gets other resources 
(although of course it should use the same if it wants to remain in the same 
http state). Certainly different users on the same machine for example will 
use different cookie stores?

-- 

  / daniel.haxx.se

---

From: Bil Corry <[email-masked]>
Date: Mon, 17 May 2010 11:02:15 -0700

Joshua Davies wrote on 5/17/2010 9:18 AM: 
> This would be a huge help for e-commerce sites... although the "open
> link in new tab/window" would almost always fail in this case, since the
> cookies associated with the original browsing context wouldn't be sent. 
> Alternatively, what about an "instance" parameter:
> 
> ?  The user agent could just keep track of how many browsing contexts it
> had established to a specific domain (which seems like a pretty light
> burden on the user agent), and associate an "Instance" number with each
> one.  If a web application was "tab-specific", it could keep track of
> Instance numbers, but a more stateless application could just ignore
> this parameter and there'd be no backwards-compatibility issue.

I'm not crazy about sequential instance numbers, but it would be useful if the server could assign an instance ID to the UA, which the UA then returns in a header with each request.  Opening a new window/tab/etc would cause the UA to send an empty instance header for that instance until the server assigns one to it.

Then for your instance cookies, you'd just need a flag, InstanceOnly, that instructs the UA to only send the cookie with that instance.  I haven't given it much thought, but such a system might help mitigate CSRF.

This instance system would have additional benefits too, allowing an easy way for Yngve's Cache Context[1] to work, and an easy way for my LOGOUT rel extension proposal to work[2].  I could also see it tying into CSP[3], allowing the server to restrict the domains/IPs that the instance can communicate with (e.g. the instance is locked down to a single domain, the user types www.somesite.tld in the address bar, the UA then warns the user that they are leaving the instance for www.mybank.tld, the user then is directed to www.somesite.tld under a blank instance ID, their cache is emptied via Cache Context and the site www.mybank.tld receives the logout ping).

In any event, this will have to be something we work on after we recharter; our current charter prohibits new functionality being added.

- Bil

[1] http://tools.ietf.org/html/draft-pettersen-cache-context
[2] http://wiki.whatwg.org/wiki/RelExtensions (scroll down to 'logout')
[3] http://people.mozilla.org/~bsterne/content-security-policy/

---

From: Adam Barth <[email-masked]>
Date: Mon, 17 May 2010 11:05:59 -0700

On Mon, May 17, 2010 at 10:38 AM, Daniel Stenberg <[email-masked]> wrote:
> cookies in "a" cookie store, but there's nothing that forces that cookie
> store to be the same cookie store as when the user agent gets other
> resources (although of course it should use the same if it wants to remain
> in the same http state). Certainly different users on the same machine for
> example will use different cookie stores?

Yes, that's the intent.  We an add some text to make this clearer if you like.

Adam

---

From: Adam Barth <[email-masked]>
Date: Mon, 17 May 2010 11:00:53 -0700

[reordered...]

> a future, http-state charter?

It's probably better to address issues that require new syntax or
semantics in phase two of our work.  In the current phase, we're
working on specifying current behavior accurately.

> Identifying browser windows

There are some new features in HTML5 (e.g., sessionStorage) that might
help address this issue.  It's unclear whether it makes sense to tie
this sort of mechanism into the cookie store.

As an example, to use cookies securely in web browsers, you also need
some sort of mechanism to defend against CSRF.  There are a number of
defenses for CSRF, and some of them can also be used to identify
browser windows (e.g., you can encode that information into the secret
tokens).

> Scope of cookie store

The spec is intentionally vague on this point.  Existing user agents
have a variety of behaviors here.  For example, many browsers have a
"privacy mode" that uses a separate cookie store from the rest of the
tabs.

I'm not sure there's a reason the spec should restrict innovation in
this space.  It doesn't have much bearing on the semantics of the
Cookie and Set-Cookie headers.

> Using scoped cookie to identify browser window

This sounds like an interesting idea.  In a future version of the
cookie protocol, we should consider a cookie scope akin to the scope
used by sessionStorage in HTML5.  Ideally, we'd find a way of defining
a scope that helps mitigate CSRF vulnerabilities at the same time.

Adam

---

From: "Mike Wilson" <[email-masked]>
Date: Mon, 17 May 2010 23:25:37 +0200

Adam Barth wrote:
> On Mon, May 17, 2010 at 9:03 AM, Mike Wilson wrote:

That's fine.

> this sort of mechanism into the cookie store.

Yes, but sessionStorage needs script and by bringing this up here I'm 
trying to address server-centric apps. I brought these topics up at
the WHATWG list a year ago [1], and was directed here, though at the
time I couldn't find an active charter.

> browser windows (e.g., you can encode that information into the secret

I'm guessing these solutions are POST only? I think it is
important to find good state support for GET requests as well.

> Cookie and Set-Cookie headers.

Either way I think it would be nice with a written statement as
how the cookie store relates to the user agent, ie "explicitly not 
defined". But maybe this belongs in HTML5 along with other browser
behaviour.

> a scope that helps mitigate CSRF vulnerabilities at the same time.

Great, let's return to this when the WG finds it suitable. I should
also mention that it may be interesting to provide additional scope
levels in addition to user_agent and browsing_context.

Best regards
Mike Wilson

[1]
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-June/020423.html

---

From: "Mike Wilson" <[email-masked]>
Date: Mon, 17 May 2010 23:39:35 +0200

Bil Corry wrote:
> I'm not crazy about sequential instance numbers, but it would 
> be useful if the server could assign an instance ID to the 
> UA, which the UA then returns in a header with each request.  
> Opening a new window/tab/etc would cause the UA to send an 
> empty instance header for that instance until the server 
> assigns one to it.
> 
> Then for your instance cookies, you'd just need a flag, 
> InstanceOnly, that instructs the UA to only send the cookie 
> with that instance.  I haven't given it much thought, but 
> such a system might help mitigate CSRF.
> 
> This instance system would have additional benefits too, 
> allowing an easy way for Yngve's Cache Context[1] to work, 
> and an easy way for my LOGOUT rel extension proposal to 
> work[2].  I could also see it tying into CSP[3], allowing the 
> server to restrict the domains/IPs that the instance can 
> communicate with (e.g. the instance is locked down to a 
> single domain, the user types www.somesite.tld in the address 
> bar, the UA then warns the user that they are leaving the 
> instance for www.mybank.tld, the user then is directed to 
> www.somesite.tld under a blank instance ID, their cache is 
> emptied via Cache Context and the site www.mybank.tld 
> receives the logout ping).
> 
> In any event, this will have to be something we work on after 
> we recharter; our current charter prohibits new functionality 
> being added.

Yes, "new tab" is one of the challenges to get this working
smoothly. Yet another alternative is to send along the parent
tab's scoped cookies with names "parent-prefixed" in some 
unique way on the main request for the new tab.

Best regards
Mike Wilson