Issue metadata
Sign in to add a comment
|
Block third-party also blocks cookies to subdomains
Reported by
dev.akh...@gmail.com,
Dec 16 2016
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.98 Safari/537.36 Steps to reproduce the problem: This will work on any domain, but this is the test I know. 1. Turn on "Block third party cookies and site data" in settings 2. Go to www.dropbox.com 3. It sets a CSRF cookie 't' for the dropbox.com top level domain 4. Open developer console. 5. In your console do: var x = new XmlHTTPRequest(); x.open("GET","https://dl-web.dropbox.com/askldjsald") x.send() 6. Notice that the request has no cookies even though it was set on a site I visited and a subdomain isn't usually considered third party This actually makes it hard to use the same origin policy for isolation. What is the expected behavior? Request is sent with the t cookie or any other cookie set for dropbox.com TLD What went wrong? The request has no cookies even though it was set on a site I visited and a subdomain isn't usually considered third party This actually makes it hard to use the same origin policy for isolation. Did this work before? Yes Does this work in other browsers? N/A Chrome version: 54.0.2840.98 Channel: n/a OS Version: OS X 10.11.6 Flash Version: Shockwave Flash 24.0 r0
,
Dec 19 2016
,
Dec 19 2016
x.withCredentials=true
,
Dec 19 2016
@dev.akhawe -- Followed the steps provided on Mac using Chrome Stable# 55.0.2883.95 and observed the error in Console. (Attaching a screenshot). Could you please confirm whether this is the issue you are noticing. Thanks in Advance.
,
Dec 20 2016
@l446240525 we are seeing this bug even with .withCredentials=true; it works fine normally but block third party content means our servers doesn't get any cookies. @msrchandra that error is fine; but the problem is if you see the network request, it has no cookies.
,
Dec 23 2016
,
Dec 24 2016
hello! sorry; I screwed up the repro. This bug is apparent when a third domain (in iframe) makes a request. In particular, in our case, our CDN: cfl.dropboxstatic.com hosts the HTML for PDF.JS and is trying to fetch data at dl-web.dropbox.com and no cookies are sent. Since there is no spec for third party cookie blocking, I am not sure if this is intentional. Note that the third party domain is not *setting* new cookies; rather, the bug is that the request is going without any cookies at all. Easiest way to repro is to create a Dropbox account and go to www.dropbox.com and view the Getting Started.pdf file. Now turn on third party cookie blocking and try again and see it fail
,
Dec 28 2016
,
Dec 28 2016
Sorry for the delayed response, a lot of people are out these two weeks. Chrome's third party cookie blocking logic now follows the First-Party rules spelled out by https://tools.ietf.org/html/draft-west-first-party-cookies-00 (i.e., it makes all cookies match the behavior of cookies with the First-Party attribute). This does not currently match the third party cookie blocking logic of other browsers. Marking this as a dupe of another bug filed about this. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by rsesek@chromium.org
, Dec 16 2016