So the issue with all of this CORS complexity is that legacy (and perhaps today's?) servers don't check for the Origin header, thus being vulnerable to XSRF attacks, i.e. browser vectors only? I guess it's too late now, but I can't help but think that the XSRF-issue should have been fixed by vulnerable server software instead of effectively turned off by browser vendors and re-enabled with major header and preflight bloat. Especially now that cross-origin is so common due to the microservice trend.

I did some work recently on a large "modern" website and man the amount of seemingly unnecessary origin related metadata is insane, mostly due to XHR chatter.

Even with permission?

I used this for Unifi Cloudy setup but other than that I am unsure of any other significant uses.

As far as I understand it everything should still work with permission. You just need to request permission first:

> the preflight requests will request permission from target websites to send HTTP requests with the header Access-Control-Request-Private-Network: true. If permission is granted, the response will carry the header Access-Control-Allow-Private-Network: true. "This ensures that the target server understands the CORS protocol and significantly reduces the risk of CSRF attacks," said Rigoudy and Kitamura.

It seems more like it's requiring cors

Right. I’ve been looking into this and they’re adding CORS like headers to enable you to continue to do it when necessary.

I thought I also saw something about a white list you could create (I’m assuming in settings), but I’m not so sure about that part.

I also found the setup thing from synology doing this http://find.synology.com/

QZ Tray (which enables access to local printers from web pages) would also probably be affected, I'd guess.