Strict doesn't break links, it breaks sites that set "expected" cookies to strict. Those expected cookies won't be available in some situations that might have been expected, such as navigating to the site directly.
So if news.ycombinator.com cookies were set to strict, they will not be sent when I open the site, or indeed at all unless I was navigating from within the site (thus stopping cross origin attacks, but also stopping them being sent on first page load). If these cookies were used to identify a logged in user, the user will not be logged in as the cookie would not be sent. The link still works, but the behaviour is perhaps unexpected.
One solution is to have a trusted, strict cookie, and it is required for any actions that originate from the origin site - upvoting, new posts, comments, etc. You then have a second, untrusted, non-strict cookie that is used to identify a user. As long as this cookie is not used for any trusted operations, you have restricted the potential attack surface a lot.
None of this breaks links, it only breaks user experience expectations if utilised naively (like hacker news using strict cookies for their persistent login tokens).
Well, from a user perspective it breaks links meaning that they work in an unexpected way. For sure it is a much-needed improvement, but it is not a fix it all feature.
The feature itself doesn't break links in that way at all.
If, and only if,
(1) a website uses strict cookies on a cookie
(2) the website assumes that cookie (1) is always available for 'valid requests'
(3) the website assumes that 'valid requests' (2) include top-level navigation events (such as typing the website's url into the browser bar)
then any behaviour that relies on the existence of that cookie will break in some situations.
That is, only a naive use of this feature will cause breakage. Worthwhile knowing about for developers, but in an ideal world would never cause issues for users.
In an ideal world there would be a solution without this shortfall, but it seems like an almost necessary feature due to how some cross origin requests are made (by spawning a new window etc).
Correct, strict cookies will be sent with a request that originates from the same origin as the cookie.
It doesn't really break the idempotency of GET, as the idempotency assumes the cookies sent with the request are the same. That is, the expectation remains that if you send the same GET request with the same headers (including the same cookies) you should get the same response back.
Note that this is a client-side feature. The browser is choosing to not send cookies based on this policy. If you're crafting a request yourself it is up to you to include the correct cookies, just as it always has been.
All this is doing is providing a way for websites to ask browsers "never send this cookie unless the user is already on my site" (strict) and "never send this cookie unless the user is already on my site, or is performing a top-level request with a safe method" (lax).
The protocol still expects idempotent behaviour, but the user may be surprised that the browser didn't include their auth token with a top-level request, if the site had requested it be a strict cookie. If that happens it's a shortfall of the site, not of this addition to the protocol.
So if news.ycombinator.com cookies were set to strict, they will not be sent when I open the site, or indeed at all unless I was navigating from within the site (thus stopping cross origin attacks, but also stopping them being sent on first page load). If these cookies were used to identify a logged in user, the user will not be logged in as the cookie would not be sent. The link still works, but the behaviour is perhaps unexpected.
One solution is to have a trusted, strict cookie, and it is required for any actions that originate from the origin site - upvoting, new posts, comments, etc. You then have a second, untrusted, non-strict cookie that is used to identify a user. As long as this cookie is not used for any trusted operations, you have restricted the potential attack surface a lot.
None of this breaks links, it only breaks user experience expectations if utilised naively (like hacker news using strict cookies for their persistent login tokens).