Tab Based Cookies

Hey all. First post on here. I also don’t know if this is appropriate for this place or not, but according to Welcome to WICG Discourse I should just post it and hope for the best!

As we turned to tab / window based browsing a while ago, I’m somewhat surprised to see a lack of the ability to set a tab based cookie.

I think it might make sense to have some standard in place for sending tab based cookies. This would allow a more seamless user experience for users when properly implemented. This could be kind of implemented by developers with url based trackers, but that method is not really an ideal solution in all situations and doesn’t work if a user manipulates URL’s, leaves the site or gets redirected.

Open to thoughts on this and directions on where this should go if it’s worth anyone’s time.

Hey Thomas!

Cookies are normally under the scope of the HTTPWG, but I think it’s appropriate to discuss new ideas related to cookies here. I trust @mnot to correct me if he feels that’s not the case.

Regarding new ideas, it’s often best to start by describing the problem that they’re destined to solve. In the current case, can you describe what problem you are trying to solve with current cookie implementations and are unable to? A detailed account of how current solutions fail to address your needs (as well as those of your users) would go a long way to convince people this is an issue worth tackling.

Cheers, Yoav

Some discussions about this previously: https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/DVQwoA0vpm4 https://bytes.com/topic/javascript/answers/878108-creating-browser-tab-specific-cookie

My thoughts on this are below. Although they are just initial thoughts:

1. Browser wide cookies should remain the default (always).
2. Tab based cookies would work just like current cookies, except they scope to the tab.
3. Child windows should not persist it’s parent cookie; at least by default. I think this could possibly be an option that is set when opening a new window via a link or javascript.

Use Cases:

1. Simple form tracking. There is a long-running problem we have on the web where form data has to be typed again and again because implementing a solution for repopulating that data is not exactly easy for developers. When a form is refreshed or arrived via a back button, form data is lost because it doesn’t make sense to persist that form data in a browser wide session; i.e. it would completely mess up someone doing two forms in multiple tabs. A tab based cookie could track form data for that specific tab. Allowing persistent form input data regardless of how many refreshes or forward / back navigations are used. It would also allow form data to persist after navigating away from a site to do something like third party sign-in.

2. Web Applications. A web application that wants to be flexible and capable of separating sessions per window must do so for the most part by persisting a GET parameter. Aside from being ugly in the browser, it adds additional overhead and a possibility of errors when certain parts of the application don’t persist that parameter. A common application issue is related to viewing multiple reports concurrently. Usually some form of report token is generated in order to separate report parameters. A tab based cookie would greatly simplify this.

Use Case 3: Consider a support application where a technician is diagnosing multiple users on an existing web application. In order to implement an “impersonation” feature, the user can really only do it one at a time or make the application persist a GET parameter. If a tab based cookie were available, the user could do an impersonation per tab, enabling them to impersonate / persist multiple users at a time.

CC: @mikewest

WFM. Be aware that the Cookie spec is currently being revised, and the bar for adding new features is pretty high (there was a previous phase where we solicited proposals, but that’s over now). It’s not impossible, mind you.

WRT tab-based cookies: One of the biggest challenges is going to be making it usable even when some browsers do implement it, and some that don’t. If it’s built on the current Cookie mechanism, that means that existing browsers will treat it as a “normal” cookie and share it between tabs. If it’s a new non-Cookie mechanism, existing browsers won’t do anything with it, and sites will likely have to figure out a fallback mechanism.

So, a discussion of how sites will deploy them with this in mind would be helpful. See also the approach to reflecting the attributes of a cookie described by Cookie Prefixes, which might be a helpful technique in this sort of thing.

Finally – at first blush, I’m a bit wary of defining a protocol mechanism for tab-based cookies; the current behaviour of cookies is not only embedded firmly in the Web stack, but also in users’ perceptions of how the Web works, and if behaviours start (seemingly) magically changing, the resulting user confusion could be detrimental to the Web platform itself.

Also, from a privacy perspective, we’d need to evaluate whether this exposes finer-grained information to trackers, etc.

I’m pondering this a little bit, and thinking maybe a cookie is overkill here. In all of the scenarios, the tab based cookie is really about one thing and that’s distinguishing tabs.

Perhaps an additional header attribute or html attribute that requests browsers include a unique tab identifier. Then the browser would send an additional header like ‘view-identifier: XX123’.

In the privacy perspective, this would definitely reveal a little bit more fine grained information in that we can now learn how the user is using each tab. A greedy developer could try limiting tabs per website somehow as well. I’m not sure how much more data can be derived from that, though. I’ll have to ponder that for a bit.

Wouldn’t storage in IndexedDB cover your use cases?

How exactly does it cover the use cases? I haven’t played with IndexedDB much, but my understanding is that it is a front-end database. If a page load occurs, the backend still can’t separate which tab is what. Unless IndexedDB can distinguish between tabs, and even then, a front-end tool doesn’t help the backend separation in between page loads and comes back to fundamentally the GET parameter.

This is not quite what you’re asking for but maybe there’s some overlap. In Firefox we’re implementing user-selected “Containers” that isolate tabs from each other. This fails your “keep site-wide cookies” part of the request because the containers act like separate users. Sometimes useful–you could log into a site as two separate users at the same time if they’re in different containers.

Building on that idea, in the Web Application Security WG there’s been at least one conversation about letting a site self-select into something like the “containers” we’re building for Firefox. For example, your bank could say “Isolate me!” through whatever mechanism we invent and then no malicious site outside that isolation container could access or try to take advantage of any data (like cookies) of the site in the container.

If it’s site-wide isolation (useful for a bank) and especially if it’s persistent in the future that might not match what you want at all. If the isolation is per-document and persists in that window/tab maybe it could be made to work for you.

https://lists.w3.org/Archives/Public/public-webappsec/2016Sep/0052.html

The proposal link in that mail suggests there may have been conversation about it here, too https://wicg.github.io/isolation/explainer.html

-Dan Veditz

While Isolate-Me sounds like a great thing to look forward to, it sounds like overkill for these use cases. The explainer link suggests that it should be used appropriately to avoid excessive processing for the browser. Separating forms as in use case 1 would mean a separate isolation for each tab.

However, we should take care not to make Isolate-Me too attractive, for fear that all sites will turn it on whether or not they need it.

It sounds great for a couple of other scenarios and especially for use case 3.

I don’t know if anyone viewed my other comment, but I’m thinking instead of using cookies for this, the browser could include a header field containing a unique view identifier.

So, consider this play by play:

• User opens browser Tab 1 and navigates to lots-of-forms.com.
• Browser sends header field view-identifier: randomid1
• User clicks a link to fill out a form in a new window. Tab 2
• Browser sends header field view-identifier: randomid2
• lots-of-forms.com tracks each view-identifier in its session and distinguishes form data per view-identifier.
• Tab 1 loads a form with a frame. Browser sends with the main page request view-identifier: randomid1 and with the frame request view-identifier: randomid3

This would have the same potential privacy issue that @mnot mentioned as it allows a website to observe more about a users habits than a simple web request.