Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
In the process of making a website GDPR compliant i need to identify and categorize cookies used on that website. Now i came across the issue to differentiate between first and third party cookies.
I was not able to find the information how to do that. So my question is: how can i find out if a cookie is a third-party-cookie with help of the developer tools of chrome and relative to the current website open.
Thanks a lot!
OK user3507003.
I am going to try to answer your question, even though I am not an expert on cookies. I am very interested in the topic however, so as I say, I am going to try to answer your question.
I am going to include background information on the subject as I try to answer your question, as the intent, purpose, and history of website cookies is short and sometimes confusingly often changing. You might like to skip to the TL;DR section near the end, for some reason I felt like pressing computer keyboard buttons for more than an hour and fifteen minutes this morning. I also just like thinking about the idea of "party cookies".
Being sure to define what is meant by "cookie": A 'cookie' is a small piece of data that is sent by a website server as part of the HTTP/S protocol as part of a response for a browser request for a webpage, then is stored locally by the browser, then is sent along with subsequent browser requests for website pages. What can make that confusing is when you ask your browser to ask a webserver for a web page, the request for the webpage can sometimes involve more than one HTTP request and to different servers for different parts of the webpage. Depending on cookie data property values different cookies could sometimes be sent with those different HTTP requests for webpage parts.
That explanation does not explain the difference between first party and third party cookies. It covers both indiscriminately. My US market-leading internet search engine (Google) results ((which should be largely unbiased by account histories except somewhat anonymized cookie data)) for "are there other types of cookies than party cookies" confirms that some websites talk about 'session', 'persistent', and 'third-party' cookies. That distinction is likely not directly relevant to your question, but it might be useful to know.
To be clear, what I think you are asking, and what I am trying to answer, is how you can tell the difference between third party cookies and first party cookies in the context of the developer tool storage inspector, as you have shown in a screenshot of that.
In your screenshot, on the left is an expandable view of the types of data storage that your browser (Chrome) supports, including "Local Storage" and "Cookies", among other types of storage. You have expanded the 'Cookies' section and selected the first item in the 'Cookies' list, and the inspector is showing a list of more than eighteen different cookies, starting with an 'ads_prefs' cookie.
The list on the right, starting with the 'ads_prefs' cookie is a list of cookies that were set by the selected website server in the list on the left. This is where my experience with cookies is less than sure, but I think you are confused that there are now two website domains involved with each cookie in the data you are seeing as in your screenshot.
The list of website domains on the left shows website domain servers that have set cookies as part of the most recent webpage request of your browser. All of the website domain servers that are not the domain of your original webpage request are third party servers with respect to your requested webpage. Those requests to third party servers are often pixel image trackers, advertising brokers, that sort of thing.
The cookies set by any website servers that are not the website domain server for your initial request (the first domain in the Cookie section view list on the left) are, I believe, considered "third party cookies".
The list of cookies on the right has a "Domain" column. What this should mean is that the Chrome browser is conformant to an HTTP/S cookie specification that allows webpage responses to set cookies for your browser that are intended for other webserver domains, and not the server that set the cookie. That "Domain" cookie property name does complicate the vocabulary around first party and third party servers and cookies, but once you understand the context as centered around a browser's webpage request, consistent disambiguation would be excessive.
TL;DR
The cookies set by the first-listed first party server as intended for other webpage domain servers are considered 'first party cookies' (with central respect to your first browser request for a webpage), even though they can involve another website domain as an intended recipient. All of the other cookies set by other servers (that were not the domain webserver for your initial browser webpage request) are 'third party cookies'.
Disclaimer: I could be wrong about some or all of that.
Related
I am very confused as to how Safari ITP 2.3 works in certain respects, and why sites can’t easily circumvent it. I don’t understand under what circumstances limits are applied, what the exact limits are, to what they are applied, and for how long.
To clarify my question I broke it down into several cases. I will be referring to Apple’s official blog post about ITP 2.3 [1] which you can quote from, but feel free to link to any other authoritative or factually correct sources in your answer.
For third-party sites loaded in iframes:
Why can’t they just use localStorage to store the values of cookies, and send this data back and forth not as actual browser cookie headers 🍪, but as data in the body of the request or a header like Set-AuxCookie? Similarly, they can parse the response to updaye localStorage. What limits does ITP actually place on localStorage in third party iframes?
If the localStorage is frequently purged (see question 1), why can’t they simply use postMessage to tell a script on the enclosing website to store some information (perhaps encrypted) and then spit it back whenever it loads an iframe?
For sites that use link decoration
I still don’t understand what the limits on localStorage are in third party sites in iframes, which did NOT get classified as link decorator sites. But let’s say they are link decorator sites. According to [1] Apple only start limiting stuff further if there is a querystring or fragment. But can’t a website rather trivially store this information in the URL path before the querystring, ie /in/here without ?in=here … certainly large companies like Google can trivially choose to do that?
In the case a site has been labeled as a tracking site, does that mean all its non-cookie data is limited to 7 days? What about cookies set by the server, aren’t they exempted? So then simply make a request to your server to set the cookie instead of using Javascript. After all, the operator of the site is very likely to also have access to its HTTP server and app code.
For all sites
Why can’t a service like Google Analytics or Facebook’s widgets simply convince a site to additional add a CNAME to their DNS and get Google’s and Facebook’s servers under a subdomain like gmail.mysite.com or analytics.mysite.com ? And then boom, they can read and set cookies again, in some cases even on the top-level domain for website owners who don’t know better. Doesn’t this completely defeat the goals of Apple’s ITP, since Google and Facebook have now become a “second party” in some sense?
Here on StackOverflow, when we log out on iOS Safari the StackOverflow network is able to log out of multiple sites at once … how is that even accomplished if no one can track users across websites? I have heard it said that “second party cookies” still can be stored but what exactly makes a second party cookie different from a third party?
My question is broken down into 6 cases but the overall theme is, in each case: how does Apple’s latest ITP work in that case, and how does it actually block all cases of potentially malicious tracking (to the point where a well-funded company can’t just do the workarounds above) while at the same time allowing legitimate use cases?
[1] https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/
I am not sure if the below answers are correct, please comment if they are not:
It seems applications can use localStorage with no problem, up to 7 days. But it won’t be persisted across multiple enclosing domains. I would even recommend using sessionStorage, since the goal is just to have nothing more than a seamless session. You can then roll your own cookie mechanism using a different set of headers, the only thing you can’t implement is http-only cookies.
They can, but ITP won’t let the JavaScript on the enclosing page store cookies (at least, not if your third party domain was flagged as a tracker by Safari).
Yeah, the description of “link decoration” technically doesn’t mention this workaround, but probably Apple has or will update its classifier to handle this workaround.
Yes, if a first-party webpage will send a request to the server and it sets a cookie in the response headers, then these aren’t blocked by ITP, even if it has an iframe to a tracking site. They say that’s not their goal.
Yes, in fact your first-party site can just let your site redirect to google.com and back quickly (like with oAuth) and thereby inform Google of whatever you wanted, without cookies. Google’s JavaScript can do this as well, if you allow it. Then the JavaScript can just load your google-hosted subdomain in an iframe and set a cookie that persists for years, tracking the user. However, ITP 2.3 seems to have also added mitigation to this, so you might use A records instead? https://cookiesaver.io/archives/analytics-guides/cname-cloaking-mitigation-eliminates-safari-itp-workarounds/
Probably the StackExchange network uses a version of #5
I'm posting a question here but may be even advice is already good.
To be complied with the GDPR, we are now requested by legal department to clarify the data processing for the cookies we use. For each cookie, we need to clarify:
What data it process
Does that data processing involve a server (like sent to the server) or just proceeded locally
Combine with other information to decide if the cookie is processing personal data or not.
Among the cookies we are having on our website, there are 3rd party cookies set by auth0 custom domain, they are:
Now it's really hard for us to fulfill the request because from what we know and from the document we found on auth0 website, the information we're looking for is not available.
Please help to give advice on how should we find the information we're requested.
You'll find some information here: https://auth0.com/docs/manage-users/cookies/authentication-api-cookies. Also I'd advice you to contact Auth0 directly as they are your "processor" and obliged (under the GDPR article 28) to provide you with the information you need. Unless you can read javascript, you need to ask Auth0 for the purpose(s) of each cookie.
The answer for your 2nd question depends on your implementation. If those are 3rd party cookies (set by Auth0), then they always involve a 3rd party server. This means that personal data (IP addresses) are always processed when those cookies are used.
You will get the answer for your 3rd question once you get information on the purposes of each cookie (why they are being set).
Also your legal team would probably want to know the location of those servers (where end users fetch those cookies). As IP-addresses and other traffic data are being processed, it might involve transfers to 3rd countries (and this is where the GDPR gets really complicated).
I would like to track what websites my site's visitors go to after they leave.
Would it be possible to place a cookie on their browser when they visit my site, and then later if they go to Facebook.com or stackoverflow.com, my cookie will retreive the browser's URL data and send it back to my server.
I could then look at this data and know that my visitors had gone to Facebook.com and stackoverflow.com after they left my site.
Is this possible using cookies?
Thanks for the help.
No. Cookies are not executed or anything. They are just dumb bits of data.
You would need to be able to execute code on the page they are visiting afterwards.
What I presume you are trying to ask, is that you want to track your outbound links.
This is mainly done with Javascript: You need to intercept click events from outbound anchor links, and send an event notification as described here, or using the hitCallbackmethod prior to completing the redirection to the external website. For Google Analytics see documentation. Or you could do via a custom JS implementation sending the info back to your server instead.
Alternatively your could replace all outbound links on the server side in your html source, and have all links pointed to your server first, and redirected to the external sites. But using redirects for this purpose is not really a good recommendation, unless you are an ad networks or a search engine company requiring such method.
Lastly, there is an alternative method using the HTML5 'ping' attribute. But the feature has been either removed and/or not yet fully implemented across all browsers as of this writing.
But you can't track where your visitors go beyond the 1st level outbound links of your site.
I work for an e-commerce site. Part of what we do is to offer customized items to some clients. Recently some non-technical management promised that we could incorporate our check-out process into one such client's website. The only way we've figured out how to do this is by using an iframe (I know, I don't like it either). The issue is that most customers of this site are unable to check out because we use cookies to determine which custom items to display. Browsers are recognizing our cookies as third party and almost everybody has third party cookies turned off, as they should. I'm going to be shocked if the answer is yes, but is there any workaround for this? ie can the site hosting our iframe somehow supply the necessary cookie?
Try an invisible, interstitial page.
Essentially the hosting site would issue a redirect to a site within your domain, which is then free to set cookies (because at this point is is actually the first party). Then your site immediately redirects back to the hosting site. At this point your newly-created cookies will be invisible to the hosting site but visible to your iFramed page henceforth.
Unfortunately the hosting site will have to do this every time a cookie is to be updated but the double-redirect can happen so quickly they'll hardly notice. Hopefully your system only needs the cookies to be set once.
Instead of using a cookie, pass the information in the each url request as name/value pairs.
It is a bit of a pain to add the name/value to every url...I know...oh well...it will work.
I'm going to be shocked if the answer is yes, but is there any workaround for this? ie can the site hosting our iframe somehow supply the necessary cookie?
Your iframed page itself, which is the third party in this scenario, could send a P3P Cookie Policy header – some browsers then accept third-party cookies by default, whereas others (mainly Safari) will not be convinced to do so at all if not by the user manipulating the default settings themselves.
What you could also do, is pass the session id not (only) by cookie, but as a GET or POST parameter as well – f.e. under PHP this can be done quite easily by configuring the session options. You should consider if that’s worth the slightly increased risk of session stealing.
The interstitial page solution should work but it might be a lot of trouble for your hosting site, so here's another solution that will allow you to work cookieless.
Write an HttpModule that responds to the BeginRequest event, reads the querystring, and inserts corresponding cookie headers into the Context.HttpRequest object (Note: you can't use AddCookie, you have to use AddHeader, because cookies added by a module directly are disposed of before they hit your application proper). That way the hosting site can simply issue a request (within the iFrame) that contains the necessary value in the querystring, the module will convert it into a cookie (that only exists in memory, not on the wire), and your application will be deceived into thinking that there's a cookie there. No code changes required, you just need to add the module in web.config.
This only works if you are using IIS 7.0+ in integrated pipeline mode. If you're on an earlier version of IIS or if you have to run in classic mode, you'll need an ISAPI filter instead.
Ryan , John
For the Chrome v80 update with SameSite flags, want to set the samesite=none;secure for the site hosting our iframe and somehow supply the necessary samesite=none;secure cookie. We have apache 2.2 and tomcat 6 setup, so would appreciate a solution and advice on how to make it work. Currently with flag enabled the iFrame is not punching out successfully.
Thanks
We have several websites on different domains and I'd like to be able to track users' movements on these sites.
Obviously cookies are not feasable, because they don't cross domain borders.
I could look at a combination of IP address and User Agent, but there are some cases where that does not work.
I don't want to use flash or other plugins.
Any ideas? Or am I doomed to rely on the IP/User_Agent combination?
You can designate one domain or subdomain to tracking and have it serve a 1x1 pixel image which you include in all pages you would like to track. Serve a cookie with the image, look at the tracking domain's server logs, voilà.
This solution requires no JavaScript, and works even if the user disables third-party cookies.
First, let's make sure the user agent is sending cookies:
If getCookie("c") == null then setCookie("c", "anyValue")
Then let the request finish (aka wait for next request)
Let's call our tracker cookie uaid.
If GET http://child.com/any-page and getCookie("c") is not null and getCookie("uaid") is null...
Redirect to http://parent.com/give-me-a-uaid?returnTo=http://child.com/any-page
On http://parent.com/give-me-a-uaid, check for cookie uaid
If not exists, create it and add it to response. If it exists, get its value.
Redirect to http://child.com/any-page?uaid=valueOfParentsUAIDCookie
Child.com sets cookie uaid with valueOfParentsUAIDCookie
Redirect to http://child.com/any-page
And of course, you are validating input, and white-listing your redirect URLs :)
Flows:
This question is closely related to the Question Accessing Domain Cookies within an iFrame on Internet Explorer.
For Internet Explorer I need to take P3P Policies into account and set an additional P3P HTTP-Header to allow images to set cookies across domain borders. Then I can use simon's suggestion.
You can follow the same concept used in Google Analytics. Injecting javascript in the pages you want to track.
You do not give any context to your situation -just the basic problem. So it is difficult to give an answer that clearly fits. However, here are some techniques/mechanisms for passing information from one page to another, regardless of what domain is involved.
include hyperlink to a 1x1 pixel transparent gif image (sometimes called a "beacon")
rely on referrer information in HTTP request headers to identify page hyperlink is on
include extra parameters in hyperlinks to other site - assuming you run both sites
buy services of a company like Akamai to do user tracking for you
possibly use cross domain cookie mechanism in the future if standard is ever approved
Which techniques really come down to whether you can place software on all of the sites (servers) that the user will visit where you have interest - or you cannot place your software on all of them.