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