Content deleted Content added
GreenC bot (talk | contribs) Move 1 url. Wayback Medic 2.5 per WP:URLREQ#symantec.com |
Citation bot (talk | contribs) Altered title. Add: authors 1-1. Removed parameters. Some additions/deletions were parameter name changes. | Use this bot. Report bugs. | Suggested by Abductive | Category:Use American English from April 2021 | #UCB_Category 566/782 |
||
Line 51:
In 2016 [[Google Chrome]] version 51 introduced<ref name="T8177">{{Cite web|url=https://www.chromestatus.com/feature/4672634709082112|title='SameSite' cookie attribute, Chrome Platform tatus|website=Chromestatus.com|access-date=2016-04-23|archive-url=https://web.archive.org/web/20160509064447/https://www.chromestatus.com/feature/4672634709082112|archive-date=2016-05-09|url-status=live}}</ref> a new kind of cookie with attribute <code>SameSite</code> with possible values of <code>Strict</code>, <code>Lax</code> or <code>None</code>.<ref name="oCqyo">{{Cite journal|url=https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00|title=Same-Site Cookies draft-ietf-httpbis-cookie-same-site-00|last1=Goodwin|last2=West|first1=M.|newspaper=Ietf Datatracker|date=20 June 2016|access-date=2016-07-28|archive-url=https://web.archive.org/web/20160816182604/https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00|archive-date=2016-08-16|url-status=live}}</ref> With attribute <code>SameSite=Strict</code>, the browsers would only send cookies to a target ___domain that is the same as the origin ___domain. This would effectively mitigate [[cross-site request forgery]] (CSRF) attacks.<ref name="wi75q">{{Cite web|title=Using the Same-Site Cookie Attribute to Prevent CSRF Attacks|url=https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/|access-date=2021-04-05|website=www.netsparker.com|date=23 August 2016 |language=en}}</ref> With <code>SameSite=Lax</code>, browsers would send cookies with requests to a target ___domain even it is different from the origin ___domain, but only for ''safe'' requests such as GET (POST is unsafe) and not third-party cookies (inside iframe). Attribute <code>SameSite=None</code> would allow third-party (cross-site) cookies, however, most browsers require [[#Secure cookie|secure attribute]] on SameSite=None cookies.<ref name="vQf6D">{{Cite web|title=Require "Secure" for "SameSite=None". by miketaylr · Pull Request #1323 · httpwg/http-extensions|url=https://github.com/httpwg/http-extensions/pull/1323|access-date=2021-04-05|website=GitHub|language=en}}</ref>
The Same-site cookie is incorporated into a new RFC draft for "Cookies: HTTP State Management Mechanism"<ref>{{Cite report |url=https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/07/ |title=Cookies: HTTP State Management Mechanism |
Chrome, Firefox, and Edge started to support Same-site cookies.<ref name="sJzIz">{{Cite web|url=https://www.lambdatest.com/SameSite-cookie-attribute|title = Browser Compatibility Testing of 'SameSite' cookie attribute}}</ref> The key of rollout is the treatment of existing cookies without the SameSite attribute defined, Chrome has been treating those existing cookies as if SameSite=None, this would let all website/applications run as before. Google intended to change that default to <code>SameSite=Lax</code> in Chrome 80 planned to be released in February 2020,<ref name="QPJhf">{{Cite web|title=SameSite Cookie Changes in February 2020: What You Need to Know|url=https://blog.chromium.org/2020/02/samesite-cookie-changes-in-february.html|access-date=2021-04-05|website=Chromium Blog|language=en}}</ref> but due to potential for breakage of those applications/websites that rely on third-party/cross-site cookies and [[COVID-19]] circumstances, Google postponed this change to Chrome 84.<ref name="Ne4hV">{{Cite web|title=Temporarily rolling back SameSite Cookie Changes|url=https://blog.chromium.org/2020/04/temporarily-rolling-back-samesite.html|access-date=2021-04-05|website=Chromium Blog|language=en}}</ref><ref>{{Cite web |last=Schuh |first=Justin |date=2020-05-28 |title=Resuming SameSite Cookie Changes in July |url=https://blog.chromium.org/2020/05/resuming-samesite-cookie-changes-in-july.html |access-date=2024-02-18 |website=Chromium Blog |language=en}}</ref>
Line 210:
{{as of|2014}}, some websites were setting cookies readable for over 100 third-party domains.<ref name="BYMXD">{{cite web |url=http://webcookies.org/third-party-cookies/ |title=Third party domains |publisher=WebCookies.org |access-date=2014-12-07 |archive-url=https://web.archive.org/web/20141209234746/http://webcookies.org/third-party-cookies/ |archive-date=2014-12-09 |url-status=live}}</ref> On average, a single website was setting 10 cookies, with a maximum number of cookies (first- and third-party) reaching over 800.<ref name="cOnAw">{{cite web |url=http://webcookies.org/number-of-cookies/ |title=Number of cookies |publisher=WebCookies.org |access-date=2014-12-07 |archive-url=https://web.archive.org/web/20141209235956/http://webcookies.org/number-of-cookies/ |archive-date=2014-12-09 |url-status=live}}</ref>
The older standards for cookies, RFC 2109<ref name="RFC2109"/> and RFC 2965, recommend that browsers should protect user privacy and not allow sharing of cookies between servers by default. However, the newer standard, RFC 6265, explicitly allows user agents to implement whichever third-party cookie policy they wish. Most modern web browsers contain [[privacy settings]] that can [[ad blocker|block]] third-party cookies. Since 2020, [[Apple Safari]],<ref name="zw6bb">{{Cite web|last=Statt|first=Nick|date=2020-03-24|title=Apple updates Safari's anti-tracking tech with full third-party cookie blocking|url=https://www.theverge.com/2020/3/24/21192830/apple-safari-intelligent-tracking-privacy-full-third-party-cookie-blocking|access-date=2020-07-24|website=The Verge|language=en}}</ref> [[Firefox]],<ref name="GSofz">{{Cite web|date=2019-06-04|title=Firefox starts blocking third-party cookies by default|url=https://venturebeat.com/2019/06/04/firefox-enhanced-tracking-protection-blocks-third-party-cookies-by-default/|access-date=2020-07-24|website=VentureBeat|language=en-US}}</ref> and [[Brave (web browser)|Brave]]<ref name="sUPt1">{{Cite web|last=Brave|date=2020-02-06|title=OK Google, don't delay real browser privacy until 2022|url=https://brave.com/ok-google/|access-date=2020-07-24|website=Brave Browser|language=en-US}}</ref> block all third-party cookies by default. Safari allows embedded sites to use Storage Access API to request permission to set first-party cookies. In May 2020, [[Google Chrome]] 83 introduced new features to block third-party cookies by default in its Incognito mode for private browsing, making blocking optional during normal browsing. The same update also added an option to block first-party cookies.<ref name="xiHRq">{{cite web |last1=Protalinski |first1=Emil |title=Chrome 83 arrives with redesigned security settings, third-party cookies blocked in Incognito |url=https://venturebeat.com/2020/05/19/google-chrome-83/ |website=VentureBeat |access-date=25 June 2020 |date=19 May 2020}}</ref> As of April 2024, Chrome postponed third-party cookie blocking by default to 2025.<ref>{{Cite web |last=Amadeo |first=Ron |date=2024-04-24 |title=Google
==Privacy==
| |||