Re: Some half-baked thoughts about cookies.

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.

>> 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?  Doesn't that mean that you
can't pass it to a.example without also passing it to b.example?

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

Received on Thursday, 16 August 2018 09:18:39 UTC