I hear that some web analytics solutions or consultants recommand the use of "friendly third party cookies".
How do they differ from "regular" 3rd party cookies?
What are there pro & cons compared to usual 3rd and 1st party cookies?
The difference is only in the name of the domain the cookie comes from. The domain name of a 'friendly' 3rd-party cookie may be similar to the 1st-party domain - making it appear 'friendly', as opposed to a potentially 'non-friendly' unknown/unrelated 3rd-party domain.
To a browser, the cookie is still considered '3rd-party' (i.e. not from the current host domain). To a user, they may be more willing to accept the cookie (if they are given a choice), or maybe less likely to delete it later, if the domain name appears familiar.
A 3rd-party cookie (if the browser/user accepts it) can maintain the identity of a single visitor across multiple domains. This is why they are considered a privacy concern. If you use 1st-party cookies on multiple domains, the visitor would receive a unique visitor ID cookie from each site on arrival (unless you use something like Google Analytics cross-domain tracking on all inter-site links to stitch the ID's together.)
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 am working in Kentico 11. I have multiple sites in the same Kentico instance each hosted on subdomains of a primary domain (news.example.com, www.example.com). I want to share the currentcontact cookie between those subdomains. Currently each of the subdomains show that cookie originating from that specific sub.
How can I set it up so that the currentcontact cookie and its value is available across the subs?
one approach is what Vasu had suggested where you can leverage the fact, that subdomain cookies can be shared to some extent, though browsers by default do try to separate even these to certain extent.
Another would be to create a so-called super-cookie which goes above domains (https://security.stackexchange.com/questions/122372/how-to-detect-inspect-and-delete-a-super-cookie-of-a-specific-website )
Than you can create your own implementation of ICurrentContactProvider or IContactPersistentStorage interfaces where GetPersistentContact or respectively GetExistingContact methods would look at other cookies or supercookie as well to track contact across domains.
I have a website where I don't ask to user any data, I don't create cookies and I have only AWStats available in the cPanel (preinstalled by the hosting mantainer).
Do I still need to show any legal information (i.e. GDPR, privacy policy, cookie policy) or can I omit all things?
Thanks
You don't need to make any mention of GDPR - that's just one of the applicable laws.
If you don't set any persistent third-party cookies and do not use any third party scripts that set third party cookies (like Google Analytics or Facebook buttons), you don't need a cookie pop-up.
Strictly speaking, your web logs may contain personal data in the form of IP addresses and user agent strings. That data can be reasonably kept for a short period, say 10-30 days, for the purposes of combating abuse, but after that you should either truncate logs or strip out data that can be associated with any individual - and this should be mentioned in your privacy policy too. AWStats typically generates aggregate info from raw logs, and that's fine, so long as it does not end up containing data that allows you to identify individuals (for example, don't store GeoIP data at resolution finer than a city).
You should still have a privacy policy - a policy is just that, it's not something visitors need to agree to, it just tells them how you handle their data. If you don't collect data, don't set cookies, don't share with any third parties, then that's what it needs to say. You don't need a separate cookie policy, especially if you're not using them beyond what's "strictly necessary".
Make sure you have set all applicable HTTP security headers, and (if you're not already) you should be using HTTPS, even for a static site.
Run your site through Webbkoll and Cookiebot to check how the outside world sees it.
I understand the concept of third-party cookies, but don't understand by what mechanism they are placed (if you're visiting Domain A in our browser, why is it that not all cookies placed have to come from Domain A?). Furthermore, I don't understand how they have access to, say, search parameters? (I'm referring to the common occurance of, say, searching for "buy a watch" on Website A and then visiting a Website B later and seeing advertisements for watches).
Any help would be appreciated!
Third-party cookies are placed by 3rd-party content. That is to say an image, iframe or other resource coming from a domain other than the page you're on (like an ad from an ad server).
Third-party cookies cannot access information from the main site directly but no technical means prevents the first and third parties from sharing that data with each other behind the scenes (ie, through corporate deals). Then again, for all you know company A owns company B or vice-versa.
Therefore in the example you provided company A would trade or sell your search queries to company B and they'd use some sort of identification process to match the results (like the time and IP of the request).
I understand the concept of third-party cookies, but don't understand by what mechanism they are placed (if you're visiting Domain A in our browser, why is it that not all cookies placed have to come from Domain A?).
A site sets the cookie by sending a cookie header along with the page content. They look like this:
Set-Cookie: NAME=VALUE; expires=DATE; path=/; domain=.stackoverflow.com; secure
As you can see, the cookie header includes a parameter that allows the site to set the domain to anything it wishes, even domains that differ from the web server's actual domain. When they differ, it's called a third party cookie. It's up to the browser to decide whether to accept them.
Furthermore, I don't understand how they have access to, say, search parameters? (I'm referring to the common occurance of, say, searching for "buy a watch" on Website A and then visiting a Website B later and seeing advertisements for watches)
Typically the cookie will set an identifier that represent you as a unique viewer on the web site, then start a database on the back end that tracks where you've been. Different parties share access to this database (via B2B web services on a paid basis). They can use your cookie to get your ID, look you up in the database, and see where you've been and what kind of products you've viewed.
I would like to set a specific cookie domain for my cookies, because this might solve some issues our site seems to have with IE8. Django seems to have a setting called SESSION_COOKIE_DOMAIN which can be set to obtain this. The problem however is that our site contains multiple subsites which have alternative domain names. So my question is, how can I manage this? I would like to have a standard cookie domain per domain, because I fear browsers like IE8 will reject cookies which aren't from the same domain (quicker).
I will do research myself, but I wondered if anyone perhaps has experience.
Update:
What I actually want to do is to make django store cookies for domain1 when I visit domain1.com etcetera for the other domains. I think it should be as easy as to use the current client domain when storing cookies. I doubt however that django offers such functionality without modification... Maybe I could build a middleware class that changes the global setting to the current domain..
Update:
This question and answer helped me out:
Changing Django settings variable dynamically based on request for multiple site
Thanks for help :)
Cookies can't be stored or retrieved for other domain names. In other words, if I am at yahoo.com I can't get the cookie for google.com. However, foo.yahoo.com and bar.yahoo.com can both retrieve cookies saved at .yahoo.com.
If you are running a website with multiple subsites, if they all share the same basic domain (i.e. site1.domain.com, site2.domain.com, etc) you should use that domain for SESSION_COOKIE_DOMAIN. But if they have different domains, it's basically impossible for them to share cookies without using some other method of getting the cookies. You can, for example, include images or scripts that point to a central site, and that site can store and retrieve the cookies, which are made available to the rest of the page via JavaScript.
If you must keep these alternate domain names, you can always set your web server to redirect immediately from these alternate domain names to the shared standard domain. This is easy to do with mod_rewrite.