https://www.cookiestatus.com/learn/Recent content in Learn on Cookie StatusHugoen-ushttps://www.cookiestatus.com/learn/basics/Mon, 01 Jan 0001 00:00:00 +0000https://www.cookiestatus.com/learn/basics/<p>Tracking protection is about <strong>storage</strong> and <strong>context</strong>: which site stores something in the browser, and on which sites it can read it back. This page covers the building blocks used throughout Cookie Status.</p> <h2 id="cookies">Cookies</h2> <p>A <strong>cookie</strong> is a small piece of data, such as <code>uid=8f3a</code>, that the browser stores for a domain and sends back with later requests to it. The web is stateless, so cookies are how a site remembers a signed-in user, a shopping cart or a returning visitor.</p>https://www.cookiestatus.com/learn/partitioning/Mon, 01 Jan 0001 00:00:00 +0000https://www.cookiestatus.com/learn/partitioning/<p><strong>Partitioning</strong> keeps the cookies and other storage of an embedded third party separate for each top-level site, the site in the address bar. A third party embedded on <code>news.example</code> gets one storage area, and the same third party on <code>shop.example</code> gets another. It can still remember things <em>within</em> a site, such as a signed-in chat widget, but it can&rsquo;t use storage to recognize the same browser <em>across</em> sites.</p> <p>It sits between the two older options:</p>https://www.cookiestatus.com/learn/how-protection-works/Mon, 01 Jan 0001 00:00:00 +0000https://www.cookiestatus.com/learn/how-protection-works/<p>Tracking protection, and similar measures, seeks to protect the <strong>user</strong> from covert data collection and exploitation by scripts and applications created for such purposes.</p> <p>Tracking protection, tracking prevention, anti-tracking, cookie blocking, content blocking, etc. are designed to:</p> <ul> <li><strong>Identify and classify</strong> domains that utilize and distribute tracking mechanisms obstructive to (browsers&rsquo; interpretation of) web user privacy.</li> <li>Restrict <strong>storage access</strong> in <strong>third-party context</strong> for such scripts so that the trackers cannot build cross-site profiles of web users.</li> <li>In some cases, restrict storage access in <strong>first-party context</strong> where it&rsquo;s likely that it could be exploited for <strong>cross-site tracking</strong> purposes.</li> </ul> <p>Once a domain is classified, a browser can <strong>block</strong> requests to it outright, or let them through but <strong>restrict its storage</strong>. Most browsers block only the categories they consider clearly harmful. See <a href="https://www.cookiestatus.com/features/tracker-blocking/">Blocking of known trackers</a> for what each browser does.</p>https://www.cookiestatus.com/learn/tracking-techniques/Mon, 01 Jan 0001 00:00:00 +0000https://www.cookiestatus.com/learn/tracking-techniques/<p>Every technique on this page also has legitimate uses, which is why browsers can&rsquo;t simply switch them off. When a browser closes one route, trackers tend to move to the next, so the protections in the <a href="https://www.cookiestatus.com/">comparison table</a> have grown roughly in the order of this page.</p> <h2 id="third-party-cookies">Third-party cookies</h2> <p>The oldest technique: a tracker embedded on many sites sets a cookie with an identifier, and gets it back on every site that loads it. See <a href="https://www.cookiestatus.com/learn/basics/#cross-site-tracking">Cross-site tracking</a> for how it works.</p>https://www.cookiestatus.com/learn/impact/Mon, 01 Jan 0001 00:00:00 +0000https://www.cookiestatus.com/learn/impact/<p>The methods used for cross-site tracking are often the same ones used for everyday features, so tracking protections affect much more than ad tech. This page sums up the practical effects for different roles. The <a href="https://www.cookiestatus.com/">comparison table</a> has the details for each browser.</p> <h2 id="web-development">Web development</h2> <h3 id="embedded-content-and-third-party-cookies">Embedded content and third-party cookies</h3> <p>If your site embeds content from another site, or your service is embedded on other sites (sign-in, comments, chat, payments, video), assume that <strong>third-party cookies won&rsquo;t work</strong> in at least Safari, Firefox and Brave:</p>https://www.cookiestatus.com/learn/testing/Mon, 01 Jan 0001 00:00:00 +0000https://www.cookiestatus.com/learn/testing/<p>The <a href="https://www.cookiestatus.com/">comparison table</a> describes each browser&rsquo;s defaults, but the quickest way to know how your own site behaves is to test it. Use a normal window with default settings: private windows and changed settings behave differently.</p> <h2 id="before-you-start">Before you start</h2> <ul> <li>Use a <strong>fresh profile</strong> in each browser, or clear the data of the sites you test, so earlier visits don&rsquo;t affect the result.</li> <li>Test on <strong>real HTTPS sites</strong>. The examples below use the public test sites <code>example.com</code>, <code>example.org</code> and <code>example.net</code>, and <code>httpbin.org</code>, which echoes requests back.</li> <li>Open the developer tools (<strong>Console</strong> and <strong>Application</strong> / <strong>Storage</strong>). In Safari, turn on <em>Show features for web developers</em> in the Advanced settings first.</li> </ul> <h2 id="is-a-third-party-cookie-sent">Is a third-party cookie sent?</h2> <ol> <li> <p>Open <code>https://httpbin.org/response-headers?Set-Cookie=cs3p%3D1%3B%20Path%3D%2F%3B%20SameSite%3DNone%3B%20Secure</code> to set a cookie on <code>httpbin.org</code>.</p>