> On Mar 6, 2020, at 6:59 PM, Patrick Griffis <pgrif...@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.

Do you mean implemented as per SameSite=lax by default and enforced TLS for 
SameSite=none? If so, you are indeed ready to just turn it on.

SameSite support in general does not suffice for this change though, since it 
involves two upgrades of cookies, not just adhering to what incoming cookie 
headers say.

Then there’s document.cookie. I don’t know how non-Cocoa platforms stitch up 
their cookie policy to that JavaScript API.

>> 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 :)

It’s there if you want it. You just need to implement the port-specific parts 
and enable the tests.

   Regards, John

>> 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 <pgrif...@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@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to