Google Inc. upcoming changes in Chrome aimed at enhancing privacy. The first part of the changes concerns cookie handling and support for the SameSite attribute. Starting with Chrome 76, expected in July, there will be the 'same-site-by-default-cookies' flag, which will default to 'SameSite=Lax' if the SameSite attribute is absent in the Set-Cookie header, limiting cookie transmission for third-party embeds (but sites can still override this restriction by explicitly setting the SameSite value to None when establishing a cookie).
The attribute allows defining the situations in which cookie transmission is permissible when a request comes from a third-party site. Currently, the browser sends cookies on any request to the site for which cookies are set, even if a different site was originally opened, and the request is made indirectly through image loading or via iframe. Ad networks use this feature to track user movements between websites, while
attackers use it for organization (when opening a resource controlled by the attackers, a request is invisibly sent to another website where the current user is authenticated, and the user's browser sends session cookies for such a request). On the other hand, the ability to send cookies to third-party sites is used for embedding widgets on pages, for example, for integration with YouTube or Facebook.
With the SameSite attribute, you can control the behavior when setting cookies and allow cookies to be sent only in response to requests initiated from the site from which these cookies were originally obtained. SameSite can take three values: 'Strict', 'Lax', and 'None'. In 'Strict' mode, cookies are not sent for any type of cross-site requests, including all incoming links from external sites. In 'Lax' mode, more lenient restrictions apply, and cookie transmission is blocked only for cross-site subrequests, such as image requests or loading content via iframe. The difference between 'Strict' and 'Lax' comes down to blocking cookies when following a link.
Other upcoming changes will also include strict limitations prohibiting the processing of third-party Cookies for requests without HTTPS (Cookies with the SameSite=None attribute can only be set in Secure mode). In addition, work is planned to protect against hidden identification ('browser fingerprinting'), including methods for generating identifiers based on indirect data, such as , a list of supported MIME types, specific parameters in headers ( and ), analysis of installed , availability of certain Web APIs specific to graphics cards rendering using WebGL and Canvas, with CSS, analyzing the peculiarities of working with and .
Additionally, in Chrome protection against abuse related to difficulties in returning to the original page after navigating to another site. This refers to the practice of cluttering the visit history with a series of automatic redirects or artificially adding fake entries to the browsing history (via pushState), making it impossible for users to use the 'Back' button to return to the original page after an accidental redirect or forced transfer to a fraudulent or malicious site. To protect against such manipulations, Chrome will skip entries related to automatic redirects and manipulations with the visit history in the Back button handler, leaving only pages opened by explicit user actions.
Source: opennet.ru
