It's said that sameSite attribute protects the user from information leakage.
But I'm still not entirely clear. For example:
It's hardly that any cookies can be stolen. I mean, any cookie has its own domain and path attributes. So, it looks like only cookies from advertising site that are located on the user's device can be loaded during this HTTP request.
So, my question is: what's the use of collecting information about its own site on the another site? I mean, this site can also collect statistics about itself "at home".
It's a bit of a misunderstanding, the purpose of samesite cookies is not protection against information leakage to advertisers.
The security issue that the samesite attribute mitigates is csrf, cross-site request forgery.
Without going into too much detail here, the root cause of the problem is that a request (any request) from a browser will include cookies for the target domain by default, regardless of the page the user is looking at. So let's say you are logged into your banking website and to transfer money, a post request is needed to /transfer with the appropriate parameters. Those parameters are not a secret, all users will send the same kind of request, but in their own sessions. Now if you visit attacker.com for whatever reason, what keeps an attacker from creating a form (in a most naive example) that when you submit on attacker.com will post to your bank's /transfer the right parameters, so the attacker will receive your money? And your session token from your banking session cookie will be sent, so the request will be valid (because the cookie is for the banking website, and the request is going to the banking website - it doesn't matter that the user was on attacker.com)!
(You could argue that it's the same origin policy that prevents this, but it does not, not in this simplified example, and also not really if ajax is involved.)
There are multiple strategies to mitigate this from synchronizer tokens through double submit and so on. All decent websites have mitigations in place against csrf. And another strategy that emerged in the past years is the samesite attribute.
If a cookie (typically your session cookie for an application) is marked as samesite, it will not be sent with requests if the visible origin in the browser doesn't have the same site as the request's target url. That means the attacker site on attacker.com will not be able to post to your bank. (In fact it can post, but a samesite session cookie will not be included, so the request will be invalid).
This by default only works for non-get requests (samesite=lax), but can be made to work for get requests too (samesite=strict), for a little more security, at the cost of a lot worse ux.
Note that while I talked about session cookies as the most prevalent example, this applies to any cookie that you in your application don't want to receive when the request is cross-site.