It's good that folks working on browsers are working on making this easier, but I don't think you can really rely on this for GET requests.
It's often easier to smuggle a same-origin request than to steal a CSRF token, so you're widening the set of things you're vulnerable to by hoping that this can protect state mutating GETs.
The bugs mentioned in the GitHub issue are some of the sorts of issues that will hit you, but also common things like open redirects turn into a real problem.
Not that state mutating GETs are a common pattern, but it is encoded as a test case in the blog post's web framework.
Hi, blog post author here. With regard to state-changing GET requests, I do not recommend their use and I agree that they create some problems for CSRF protection, but you are correct that I did include tests that verify that they can be enabled in my Microdot web framework.
Please correct me if I have missed anything, but I have designed this feature in my framework so that the default action when evaluating CSRF-related headers is to block. I then check all the conditions that warrant access. The idea is that for any unexpected conditions I'm not currently considering the request is going to be blocked, which ensures security isn't put at risk.
I expect there are some situations in which state-changing GET requests are not going to be allowed, where they should be. I don't think the reverse situation is possible, though, which is what I intended with my security first design. I can always revisit the logic and add more conditions around state-changing GET requests if I have to, but as you say, these are uncommon, so maybe this is fine as it is.
I was involved in the effort to add/upgrade Fetch Metadata in the OWASP cheat sheet. We had discussed GET requests, so if you find the guidance lacking about it, please let us know how.
Likewise, if you could elaborate on the open redirects issue, that would be great.