Recientemente Google developers announced their intention in the next two years to completely suspend Chrome's support for third-party cookies established when accessing sites other than the domain of the current page as these cookies are used to track user movements between sites in the code of advertising networks, social media widgets and web analytics systems.
This is a movement that also goes hand in hand, with the call that the Chromium developers made in their forums, since they have intend to remove the User-Agent header as well as restricting access to the navigator.userAgent property in JavaScript.
All this is due to the Privacy Sandbox initiative with the aim of reaching a compromise between the need to preserve user confidentiality and the desire for ad networks and sites to track visitor preferences.
By the end of this year, in test mode originally, additional APIs are expected to be included in the browser to measure conversion and personalization of advertising without the use of third-party cookies.
To determine the category of interests of users without making an individual identification and without reference to the history of visits to specific sites, Ad networks are invited to use the Floc APIAs well as evaluating user activity after switching to advertising, API conversion measurement and separating users without using identifiers between sites with the Token API Trust.
We are actively working across the ecosystem to give browsers, publishers, developers, and advertisers the opportunity to experiment with these new mechanisms, test whether they work well in various situations, and develop support implementations, including ad targeting and measurement, denial of Service Prevention (DoS), antispam / fraud and federated authentication.
The development of specifications related to the display of targeted advertising without violating confidentiality is carried out by a separate working group created by the W3C organization.
Currently, in the context of protection against the transmission of cookies during CSRF attacks, the SameSite attribute is used specified in the Set-Cookie header, which, as of Chrome 76, is set to "SameSite = Lax" by default, restricting the sending of cookies from third-party sites, but sites can remove the restriction by explicitly setting SameSite = None when setting the cookie.
The SameSite attribute can take two values of 'strict' or 'lax'.
- In "strict" mode, cookies are not sent for any type of cross-site request.
- While in 'lax' mode, lighter restrictions apply and the transmission of cookies is blocked only for secondary requests between sites, such as requesting an image or downloading content via an iframe.
In the next version of Chrome 80 (which is scheduled for February 4) a restriction will apply More strict that prohibits the processing of third-party cookies for non-HTTPS requests (with SameSite = None attribute, cookies can only be set in safe mode).
In addition, work continues on the implementation of tools to identify and protect against the use of covert identification and tracking bypass methods ("browser fingerprints").
In Firefox from version 69, by default cookies are ignored by all third-party tracking systems.
Google considers this blocking to be justified, but it requires preliminary preparation of the web ecosystem and the provision of alternative APIs to solve tasks for which third-party cookies were previously used, without violating confidentiality and without undermining the monetization models of sites funded through the display of advertisements.
In response to blocking cookies without providing an alternative, ad networks did not stop tracking, but only switched to using more sophisticated methods based on hidden user identification (fingerprint) or creating separate subdomains for the tracker on the domain of the site on which the ad is displayed.
Source: https://blog.chromium.org