[webkit-dev] Same-Site cookies by default

[Maciej Stachowiak]

> On Mar 6, 2020, at 6:58 PM, Patrick Griffis <pgriffis at igalia.com> wrote:
> 
> On 2020-03-06 6:51 pm, John Wilander wrote:
>> Hi Patrick!
>> 
>> Thanks for bringing this up. I’ll share my view of where we are.
>> 
>> First of all, cookies mostly live in the http layer so the various
>> WebKit ports would have to work this out independently to some extent.
>> Maybe libcurl and libsoup have readily available APIs for this?
> 
> libsoup added samesite support this cycle implemented as the spec
> describes so I was wondering if we should add a toggle for this new
> behavior.
> 
>> Second, we have communicated tentative support for SameSite=lax by
>> default, but in terms of its privacy protections, WebKit is far ahead
>> with its Intelligent Tracking Prevention (ITP, or Resource Load
>> Statistics in open source). Servers that expect to get default
>> third-party cookie access merely through a SameSite=none; Secure
>> configuration will find that such an option does not exist under ITP.
>> Instead, third-parties who need cookie access can make use of the
>> Storage Access API which gives users control and transparency.
> 
> There are still ports without ITP; I understand the solution there is to
> implement ITP though :)

In current trunk, if your port has ITP fully supported, "SameSite=Lax by default” would be a no-op. If you don’t have ITP, then it is a good fallback. If your port has a history of using ITP, or the older Safari/WebKit third-party cookie policy, then you will probably face lower compatibility risk than Chrome. If not, then watch out for compat issues.

I would urge ports to enable ITP if at all possible, and if you need help from Apple folks, we’re happy to advise or otherwise help.


A thought I had while writing this: how should SameSite=Lax interact with Storage Access API? Can sites get access to Lax cookies using SAA, or do they need to be SameSite=None *and* you have to use SAA to get them? (I should probably file this as a spec issue against SAA).


> 
>> Finally, as far as I know, Chrome is still the only browser to try out
>> SameSite=lax plus forced TLS for SameSite=none and they seem to be at
>> 10% rollout at this moment. We’d like to hear some lessons learned
>> from them since it may be a tough rollout, at least for a browser that
>> has historically allowed all cookies in third-party contexts by
>> default. Safari is among a few browsers that has not allowed that. I
>> do not know what default cookie policies the other WebKit browsers
>> have.
>> 
>>   Regards, John
>> 
>>> On Mar 6, 2020, at 1:07 PM, Patrick Griffis <pgriffis at igalia.com> wrote:
>>> 
>>> Chromium has had the idea to treat all cookies as SameSite=Lax by
>>> default as well as blocking SameSite=None over HTTP for a while now,
>>> hidden behind a flag, and seem to be rolling this out soon.
>>> 
>>> The topic is discussed in detail here:
>>> https://web.dev/samesite-cookies-explained/#changes-to-the-default-behavior-without-samesite
>>> 
>>> I just wondered if other developers had any thoughts on this move and
>>> if/when WebKit should follow. The downside is of course compatibility
>>> but the upside is improved privacy.
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev