> On Mar 6, 2020, at 6:58 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. > >> 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 <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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
