[prev in list] [next in list] [prev in thread] [next in thread] 

List:       webkit-dev
Subject:    Re: [webkit-dev] Same-Site cookies by default
From:       Maciej Stachowiak <mjs () apple ! com>
Date:       2020-03-07 22:41:35
Message-ID: 4C34EEBF-D966-468F-9EEB-61F35437446C () apple ! com
[Download RAW message or body]



> On Mar 6, 2020, at 6:58 PM, Patrick Griffis <pgriffis@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@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


[prev in list] [next in list] [prev in thread] [next in thread]