Re: Some half-baked thoughts about cookies.

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

> On Thu, Aug 16, 2018 at 7:29 PM Mike West <mkwst@google.com> wrote:
> >> 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/`
> <https://example.com/>:
> >
> > *   The navigational request would include `https://example.com`'s
> token.
> > *   Requests to `https://example.com/` <https://example.com/> would
> include `https://example.com`'s token.
> > *   Requests to `https://sub.example.com/` <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/` <https://not-example.com/>
> would include `https://not-example.com`'s token iff it had opted-into
> `cross-site` delivery.
>
> OK, I misunderstood who was opting in.  Thanks.  I suspect that some
> of the cross-site options here might be blocked by browser policy
> (double-keying).
>

I think that's very likely. I imagine these being an upper-limit on
availability that the site is responsible for setting. User agents can
ratchet that down based on a number of heuristics and/or user-facing
permission grants, just as they do for cookies today.

> What means are you thinking of? Cookies? GET parameters?
>
> In the context you are talking about, GET and service workers
> primarily.  (If the goal is to progressively neuter cookies, then we
> can't start to rely on them more.)
>

Got it, thanks.

 -mike