Re: [webkit-dev] Same-Site cookies by default
> On Mar 6, 2020, at 6:58 PM, Patrick Griffis 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 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
Re: [webkit-dev] Same-Site cookies by default
> On Mar 6, 2020, at 6:59 PM, Patrick Griffis 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 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
Re: [webkit-dev] Same-Site cookies by default
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 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
Re: [webkit-dev] Same-Site cookies by default
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? 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. 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 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
Re: [webkit-dev] Same-Site cookies by default
Current WebKit trunk blocks all third party cookies (with ITP enabled), which is a more extreme version of the same thing. We’re currently testing the compatibility fallout. Treating cookies as SameSite=Lax by default is moot when third-party cookies are blocked, as the SameSite=None behavior would not be permitted at all. Chromium has been just about to roll out their change for a while now, but my understanding is that it’s still only applied to a low percentage of users. Regards, Maciej > On Mar 6, 2020, at 1:07 PM, Patrick Griffis 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] Same-Site cookies by default
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
