Re: Harmonizing draft-west-cookie-prefixes-05 with the web origin concept

[Mike West <[e-mail]>]

On Wed, Dec 23, 2015 at 6:48 AM, Willy Tarreau <[e-mail]> wrote:

> Based on Mike's and your proposal, I'm wondering if a solution would not
> be to use special name cookies in addition to the regular ones to pass
> back *all* attributes and even to help define new attributes. We could
> have something like this :
>
>   Set-Cookie: __SID=12345; secure; path=/; domain=example.com;
>
>   Cookie: __SID=12345; __attr_secure__SID=1; __attr_path__SID=/;
> __attr_domain__SID=example.com; __attr_origin__SID=https://example.com
>
> etc... The idea being that "__attr_<attribute_name>" being prefixed in
> front of the cookie name in requests so that the client can pass the
> attributes it learned. This way, a cookie learned from the wrong
> location (eg: injected from HTTP, JS or anything) could be detected
> and replaced by the server. And it still provides unicity on the cookie
> names and value in the request.
>

Elliott (CC'd) proposed something similar in
https://groups.google.com/a/chromium.org/d/msg/blink-dev/IU5t6eLuS2Y/H6HJ-j6TBwAJ,
with a special cookie being sent along with the request that contained all
the attributes (and presumably scopes) of the rest of the cookies. We
didn't spend a whole lot of time with that proposal, as our intuition was
that such a scheme would require some amount of work for each developer to
parse and enforce on their own, while prefixes were a pragmatic solution
that the user agent could enforce for everyone. It might well be worth
picking up (in addition to prefixes?) if there's interest in this group.

-mike