CODEWITHSUNDEEP
samesite
John Little
John Little

Reputation: 12403

will facebook pixels see our cookies?

The specific case we are trying to figure out is what is shared with facebook (and other "first party and "third party" scripts). FB is a pixel image using GET, currently with the url www.facebook.com. Are our cookies set on the sites main domain (.mysite.com) or subdomain (www.mysite.com) shared with facebook?

If we now change facebook to use a first party url, e.g. facebook.mysite.com, are our cookies set on the domain www.mysite.com and .mysite.com shared, with or without samesite set (most of our cookies dont have this set) now shared with FB?

What would really help if if someone could supply is a super simple table of examples (as per below)

Assume using GET to pull in an external resource (e.g. image, xhr request or js library), and consider the three cases where SameSite has value None, Lax, and Strict.

origin cookie domain link cookie shared?
www.mysite.com .mysite.com pixel.facebook.com ?
www.mysite.com www.mysite.com pixel.facebook.com ?
www.mysite.com www.mysite.com pixel.mysite.com ?
www.mysite.com .mysite.com pixel.mysite.com ?

Upvotes: 1

Views: 329

Answers (1)

jub0bs
jub0bs

Reputation: 66344

Note that the scheme and (possibly implicit) port, not just the host, are components of a Web origin. Only taking the host into consideration is misleading. Therefore, I've taken the liberty to add a https scheme to all your examples (which has the added benefit of sidestepping a discussion about the Secure attribute).

Under the assumption that example.com be an eTLD+1, the answer doesn't depend on the value of the cookie's SameSite attribute in any of your four cases.

origin cookie domain link cookie shared?
https://www.example.com .example.com https://pixel.facebook.com ❌
https://www.example.com www.example.com https://pixel.facebook.com ❌
https://www.example.com www.example.com https://pixel.example.com ❌
https://www.example.com .example.com https://pixel.example.com ✅

In the first three cases, browsers will not attach such a cookie to such requests. Why? Because, in all three cases, the request host does not domain-match the cookie's domain attribute; see RFC6265bis, section 5.6, step 10 of the storage-model algorithm. In particular, cookies associated to example.com in someone's browser are never sent to or accessible by facebook.com or any subdomain thereof. However, if example.com loads facebook.com in an iframe, Facebook can use that to create cookies associated to facebook.com, which will then be attached to requests to Facebook.

In the fourth case, under the assumption that example.com be an eTLD+1, browsers will unconditionally attach such a cookie to such a request. Why? Because, in that case,

  • the request host does domain-match the cookie's domain attribute, and
  • the request is same-site, and the SameSite cookie attribute only has an effect on cross-site requests; more about this subtlety in one of my blog posts.

Here is a case where the value of the SameSite attribute would matter, because the request in question is cross-site:

origin cookie domain link SameSite cookie shared?
https://facebook.com www.example.com https://www.example.com None ✅
https://facebook.com www.example.com https://www.example.com Lax ?
https://facebook.com www.example.com https://www.example.com Strict ❌

In the SameSite=None case, browsers would unconditionally attach the cookie.

In the SameSite=Lax case, browsers would only attach the cookie if the request is a top-level navigation. See Lax allowing unsafe, though.

In the SameSite=Strict case, browsers would not attach the cookie, period.

Upvotes: 1

Related Questions