Define the behavior for third-party cookie blocking.

[mikewest]

We believe that Clear-Site-Data ought to take effect even when the user has chosen to block third-party cookies from a given site. That's apparently not what Chrome is doing.

[ericlaw1979]

Context: https://bugs.chromium.org/p/chromium/issues/detail?id=540525#c14

affirmed this stance when shipping the Clear-Site-Data header; bulk deletion of cookies for an origin is not allowed when cookies are blocked

[msramek]

In the Fetch integration section, we describe that Clear-Site-Data does not take effect if fetch does not have the credential flag set, i.e. if fetch is instructed not to affect cookies.

I would see third-party blocking as user's indication that no third party fetch should have the credential flag set. In fact, that's how it's implemented in Chromium. Clear-Site-Data only sees that the network stack marked the request as net::LOAD_DO_NOT_SAVE_COOKIES, but doesn't know why - it could be a plain fetch, or it could be user settings.

So I would argue that this is not missing from the spec, we actually spec'd the opposite! :-)

@mikewest , I remember that we were going back and forward on this issue a lot before we shipped. What's the rationale for the change?

There are arguments in crbug.com/540525 for not respecting cookie deletion, although granted, that's more relevant for Set-Cookie; with Clear-Site-Data, you'd only get one bit per registrable domain.

[dveditz]

How do we think sites will use Clear-site-data? Will their primary content set the header in response to a log-out, or will they fetch https://accounts.mysite.com/clear-all to do it? If it's the former then continuing to ignore this when 3rd party cookies are blocked is probably fine, but if it's the latter (assuming the user is on https://www.mysite.com/) we're blocking a useful case. Of course if they redirect through an oauth-like service to login, they could redirect through it the same way to log out and then Clear-site-data wouldn't be 3rd party.

More problematic for framed 3rd party content, but if cookies are meaningful in that context and 3rd party cookies are blocked then it's not going to be functional framed content. If logging out via Clear-site-data is broken it's just one more broken thing and not worth worrying about.

with Clear-Site-Data you'd only get one bit per registrable domain.

3 or 4 bits currently (cache, cookies, storage, executionContexts--not sure the last one is useful), though that's not much worse. But in the same way you could construct a bit field deleting individual cookies with Set-Cookie if we allowed it when blocked, you could do the same thing with a series of separate domains and Clear-Site-Data. Both would be a PITA to actually try to use in practice.

Although I was in favor of this issue when we discussed it in TPAC I think I'm coming around to leaving things as they stand unless we start seeing things break in practice as people start to use this feature.

[ericlaw1979]

The privacy/security concern here is that a user may have configured their browser to block third-party cookies, then use a "logout" feature on a site that's part of a federated set of services (e.g. Windows Live, Google, etc).

A site's developers may fail to recognize that Clear-Site-Data is unreliable in the face of privacy-sensitive enduser configurations and thus may not design their logout mechanisms to redirect the top-level context through the various logout pages for each site that is a part of the "federation." In such cases, the user will be told that they've successfully logged out while their browser still bears and presents cookies to such services if they are revisited in a top-level browsing context.