Re: Some half-baked thoughts about cookies.

On Thu, Aug 16, 2018 at 11:18 AM Martin Thomson <martin.thomson@gmail.com>
wrote:

> On Thu, Aug 16, 2018 at 5:11 PM Mike West <mkwst@google.com> wrote:
> >> Cookies are - from the perspective of a user - superior in almost
> >> every way.
> >
> > Superior in what sense?
>
> Well.  Everything we hate is a feature someone else relies on.
>

Got it. :)


> >> The CSRF benefits here seem fairly hard to get excited
> >> about enough to use this new, more limited thing.  I can maybe see
> >> sites doing this for high value state, if it comes to that, but that's
> >> being optimistic.
> >>
> >> I don't understand how the cross-origin use of these is intended to
> >> work (what requests do the options apply to?).
> >
> >
> > The options are meant to apply to the token itself; the `delivery` token
> in particular is similar to the `SameSite` attribute if you squint a bit.
> That is, when the server says "This token should be delivered cross-site.",
> then it will be delivered along with any request that would deliver cookies
> that weren't set with a `SameSite` attribute. If the server says "This
> token should be delivered same-origin.", then it would be delivered along
> with any request that would deliver a cookie set with a theoretical
> `SameOrigin` attribute.
>
> So, if I'm visiting a page on example.com, the default behaviour would
> be to have the token delivered in requests to example.com.
> Subresources loaded on the same page would - by default - have no
> associated token?  Or the token associated with that origin?  And if
> the site said "cross-site" in a response, then the token would be
> attached to all subresource requests?


In a browser context, when a user navigates to `https://example.com/`:

*   The navigational request would include `https://example.com`'s token.
*   Requests to `https://example.com/` would include `https://example.com`'s
token.
*   Requests to `https://sub.example.com/` would include `
https://sub.example.com`'s token, unless it had opted-into `same-origin`
delivery (in which case it would be excluded).
*   Requests to `https://not-example.com/` would include `
https://not-example.com`'s token iff it had opted-into `cross-site`
delivery.

Doesn't that mean that you can't pass it to a.example without also passing
> it to b.example?
>

Correct. This proposal ~matches the granularity we created with `SameSite`,
with the addition that it can be tightened beyond a "site" to an "origin".
Do you think more granularity would be helpful?


> Given that sites have finer-grained means of passing information to
> subresource loads, why even provide this capability at all?
>

What means are you thinking of? Cookies? GET parameters?

-mike