Proposed new way to identify a tab using a session cookie.

[Dean Jackson]

Hi, Chromium developers and security folks!  Let me know if there's a better list for this, as this was a first-guess of where something like this might go to.

Having users open a single web application across multiple tabs is pretty common.  That's also extra work for developers; you currently need to inject a url parameter to track this (which makes for uglier URLs and worse user experience).

We already have cookies, which securely identify a browser across requests.  Given that, it'd be nice to have a similar method to identify a *tab* across requests.   Would it be reasonable to suggest a new type of cookie here, where a session cookie could be locked to a specific tab?

The response header might look like:

Set-Cookie: name=value;scope=tab

With another valid value of "scope" being "browser", which would be the default.  This would let web applications have tab-based sessions without mucking up the URL, which is what cookies were added to simplify on a per-browser level.

Thoughts?

-Dean

[Ryan Sleevi]

On May 1, 2014 12:58 PM, "'Dean Jackson' via Security-dev" <securi...@chromium.org> wrote:
>
> Hi, Chromium developers and security folks!  Let me know if there's a better list for this, as this was a first-guess of where something like this might go to.
>
>
> Having users open a single web application across multiple tabs is pretty common.  That's also extra work for developers; you currently need to inject a url parameter to track this (which makes for uglier URLs and worse user experience).

Your only downside listed is ugly URLs. That's an aesthetic choice and a subjective one. It would be better if you could actually elaborate your downsides, if we are to look at other solutions.

For example, consider a UA that doesn't show the user the URL, but instead shows the origin. It would seem your problem has now been solved - but I suspect you would disagree.

>
> We already have cookies, which securely identify a browser across requests.  Given that, it'd be nice to have a similar method to identify a *tab* across requests.   Would it be reasonable to suggest a new type of cookie here, where a session cookie could be locked to a specific tab?

No.

1) It would break plenty of applications that don't handle extra directives - for which there are many

2) tab is a UA specific concept that exists only in the abstract. Consider mobile devices. Are the distinct pages 'tabs'? Or are they 'windows'? What about other concepts of UIs?

3) How do such concepts apply to all the other non-UI HTTP clients? Command-line tools, for example.

Most importantly, one of taste, intent, and design - Web Applications 'should' be agnostic to the user's chosen means of browsing. This is a strength of the Web, and why it works so well on so many devices and in so many concepts. A well-written web application should be agnostic to these things - or it risks alienating users with valid uses and devices.

[David Benjamin]

There actually already exists tab-scoped storage: sessionStorage is like localStorage but it's scoped to a tab. (Unlike session cookies which are scoped to a "browser session", a less useful concept these days.)

[Chris Palmer]

You should never put authentication tokens in a URL anyway.

> To unsubscribe from this group and stop receiving emails from it, send an
> email to security-dev...@chromium.org.

[Dean Jackson]

On Thu, May 1, 2014 at 1:27 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

On May 1, 2014 12:58 PM, "'Dean Jackson' via Security-dev" <securi...@chromium.org> wrote:
>
> Hi, Chromium developers and security folks!  Let me know if there's a better list for this, as this was a first-guess of where something like this might go to.
>
>
> Having users open a single web application across multiple tabs is pretty common.  That's also extra work for developers; you currently need to inject a url parameter to track this (which makes for uglier URLs and worse user experience).

Your only downside listed is ugly URLs. That's an aesthetic choice and a subjective one. It would be better if you could actually elaborate your downsides, if we are to look at other solutions.

The parallel case are cookies, which by the same argument are a subjective, aesthetic choice.  We used to track user sessions by tokens in the URL, and at some point, decided that it was worth the aesthetic choice for session cookies.

For example, consider a UA that doesn't show the user the URL, but instead shows the origin. It would seem your problem has now been solved - but I suspect you would disagree.

Can you elaborate here?  

> We already have cookies, which securely identify a browser across requests.  Given that, it'd be nice to have a similar method to identify a *tab* across requests.   Would it be reasonable to suggest a new type of cookie here, where a session cookie could be locked to a specific tab?

No.

1) It would break plenty of applications that don't handle extra directives - for which there are many

It'd be possible for servers to detect those applications from the User Agent header, and send accordingly.

Alternatively, there could be a second header, specifying that the next-header setting a cookie is to be set with a tab-level scope; legacy UA would ignore the unknown header, and treat it as a normal cookie. 

2) tab is a UA specific concept that exists only in the abstract. Consider mobile devices. Are the distinct pages 'tabs'? Or are they 'windows'? What about other concepts of UIs?

s/tab/one viewport/.  If a user can use the application in two separate, completely parallel windows/browsers/tabs/viewports/etc, that would count as a 'tab' for what I'm suggesting.

3) How do such concepts apply to all the other non-UI HTTP clients? Command-line tools, for example.

How do session cookies applie to non-UI HTTP clients?  I'd assume the same way would work here.

 

Most importantly, one of taste, intent, and design - Web Applications 'should' be agnostic to the user's chosen means of browsing. This is a strength of the Web, and why it works so well on so many devices and in so many concepts. A well-written web application should be agnostic to these things - or it risks alienating users with valid uses and devices.

My plan here would be to propose this as an IETF standard, if it moves forward.  Doing this for one browser doesn't help anyone, but doing it for all standards-compliant browsers would work well.  

--

Dean Jackson | Technical Program Manager

[Dean Jackson]

sessionStorage is only accessed by Javascript, that I know.  To get the same functionality there, you need to have additional javascript load and run on every page, and then modify every request sent back to the same host.  

Cookies *almost* solve this exact problem without needing to serve extra code.

[Dean Jackson]

Or, tying the two responses together;

sessionStorage seems to show that this is wanted/needed by developers.

It also requires that you pass id tokens in the URL, which isn't so great for various reasons.

Is there another good solution that could solve this that could be standardized to improve this?

[Michal Zalewski]

So... what's the specific use case for tab-scoped cookies? As in, what
user experience do you imagine?

I'm curious about two situations:

1) I wonder what the semantics should be for actions such as
right-click and 'open in a new window' / 'open in a new tab'. Should
that new tab inherit the cookie? Or should the link be followed but
state lost?

2) In a similar vein, if I have a tab where I have a tab-scoped
cookie, but navigate away to another website, and then some other
context navigates the tab back to the starting site - should the state
come back from the dead? Why / why not?:-)

/mz

[Dean Jackson]

1) I thought on that, but don't have a good answer, yet..  It'd be nice to be able to tie a new tab back to what created it, but I'm not sure the cleanest way of doing that.  What would make sense here?

2) This should likely work like a session cookie; it's only accessible by the site that set it, but does not disappear until the browser/tab is closed.  That's especially useful for back-button clicks, and consistent (but probably less useful) for normal/forward navigation.

[Dean Jackson]

Okay, a few more bits.

The primary case for this is that ids in the URL are a bad plan; they're copied when someone cut/pastes a link, which causes need for watching IP address server-side, which still has issues with mobile traffic, which may switch IP mid-session.

Using client-side storage to emulate this also isn't great; you then need to modify each outgoing link on the page with javascript, which still puts this into the URL, rotating back to the previous issue.

There's one open question; what happens when a user right clicks and opens in a new tab.  

It might be interesting to add another HTTP request header; send the same thing that would have been sent in a Cookie: header, but give it a separate name, possibly TabCookie or InitialCookie.  Would that be a reasonable thing to do here?

-D

[Michal Zalewski]

> The primary case for this is that ids in the URL are a bad plan

Yup, but cookies are comparably bad in some uses because their weird
scoping rules create a hard-to-understand attack surface (for example,
HTTP pages can generally inject cookies that HTTPS pages later rely
on). True origin-bound storage, automatically propagated to new tabs,
is considerably safer in that regard.

But between the requirement to have links that do not leak secrets
when accidentally copied-and-pasted, having these secrets preserved
when doing 'open in a new window', and not having the state preserved
when a page is bookmarked or so, I'm a bit curious about what you're
aiming to build and if it can be done without tab-bound cookies. If
it's Google-specific, feel free to drop me a mail directly :-)

/mz

[Devdatta Akhawe]

Someone once suggested to me "secrets in URL" followed by a URL change
via history.pushState in a script tag at the very top of the page.
This also prevents secret leakage through referer. There is still an
attack window but this works today and should typically work since the
attack here does take time: "convince the human to click on the URL
bar and press ctrl-c"

Does that help? It has the huge advantage of working today and being
cross-browser. That said, a new primitive could be useful but I am not
sure tab-scoped cookies are the right design point.


--dev

On 2 May 2014 14:56, 'Michal Zalewski' via Security-dev

[Dean Jackson]

What happens when someone cut and pastes the URL, or shares it?  How does it get appended to new links on the page?  And what happens if someone right clicks a link, copies it, and shares the copy? 

Or if they bookmark the link while the page wasn't quite loaded yet?  (Or come back to the bookmarked page?)

That last one actually breaks the cookie scheme as well; if I'm browsing Facebook, then click a bookmark that was also to Facebook, that's definitely a (so far) uncovered case.

[Devdatta Akhawe]

sure. I was mainly responding to some of the discussion on the thread
about "do not leak secrets when accidentally copy/pasted" Like Michal,
I am actually waiting to hear more about what you want to build and
maybe we can think of another solution that doesn't require a new
spec. For example, I wonder if the ServiceWorkers can help here.


cheers
Dev

[Ryan Sleevi]

On Thu, May 1, 2014 at 2:08 PM, Dean Jackson <de...@google.com> wrote:

On Thu, May 1, 2014 at 1:27 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

On May 1, 2014 12:58 PM, "'Dean Jackson' via Security-dev" <securi...@chromium.org> wrote:
>
> Hi, Chromium developers and security folks!  Let me know if there's a better list for this, as this was a first-guess of where something like this might go to.
>
>
> Having users open a single web application across multiple tabs is pretty common.  That's also extra work for developers; you currently need to inject a url parameter to track this (which makes for uglier URLs and worse user experience).

Your only downside listed is ugly URLs. That's an aesthetic choice and a subjective one. It would be better if you could actually elaborate your downsides, if we are to look at other solutions.

The parallel case are cookies, which by the same argument are a subjective, aesthetic choice.  We used to track user sessions by tokens in the URL, and at some point, decided that it was worth the aesthetic choice for session cookies.

For example, consider a UA that doesn't show the user the URL, but instead shows the origin. It would seem your problem has now been solved - but I suspect you would disagree.

Can you elaborate here?  

> We already have cookies, which securely identify a browser across requests.  Given that, it'd be nice to have a similar method to identify a *tab* across requests.   Would it be reasonable to suggest a new type of cookie here, where a session cookie could be locked to a specific tab?

No.

1) It would break plenty of applications that don't handle extra directives - for which there are many

It'd be possible for servers to detect those applications from the User Agent header, and send accordingly.

Alternatively, there could be a second header, specifying that the next-header setting a cookie is to be set with a tab-level scope; legacy UA would ignore the unknown header, and treat it as a normal cookie. 

2) tab is a UA specific concept that exists only in the abstract. Consider mobile devices. Are the distinct pages 'tabs'? Or are they 'windows'? What about other concepts of UIs?

s/tab/one viewport/.  If a user can use the application in two separate, completely parallel windows/browsers/tabs/viewports/etc, that would count as a 'tab' for what I'm suggesting.

And I'm suggesting such a design decision is frequently hostile to users, and actively hostile to what makes the "Web" great.

For users, this disables such fundamental tasks as "Open in new tab", since that constitutes a new viewport (or in HTML terms, a new top level browsing context - since that's what governs the lifetime of sessionStorage). There are plenty of reasons that users may choose to do so - ranging from mundane to reasons such as it may make the data more accessible to them to be able to compare things in two distinct tabs (eg: consider tabular sets of data before/after).

For the web, this has a truly deleterious effect to the concept of linkability. If I'm viewing a page, I run the risk of no longer being able to copy the URL and have it 'just work'. When I'm navigating, I'm forced to constantly be aware of which session I was in, since the moment I try to do anything 'usable' (again, open a new tab, copy/paste a URL), then I run the risk of no longer having access to that page.

That you can (via sessionStorage) is by no means evidence that you should. That's why it's really essential to understand the use case here, and see if there isn't some other means possible, that is far less harmful to users' experiences on the web.