> This is... annoying. This sounds like Chromium team throwing up their hands, "We can't keep attackers out, so don't be giving out any data attackers can use."

> This is... annoying. This sounds like Chromium team throwing up their hands, "We can't keep attackers out, so don't be giving out any data attackers can use." It's actually the correct approach to realize that side-channels on shared processors are inevitable, and it's much easier to reason through the model of "anything your process can access, a malicious script running in that process can access too," instead of "well, maybe we'll patch HighResTimer to give a reduced precision, and change SharedArrayBuffer a little, to prevent the one known Spectre-like attack we've seen, and keep spaghetti-and-meatballing patches when more attacks surface." > A legitimate user, using a browser app to try to link to a resource, can't access the resource because of CORS, then blames the app for being broken. Yes, if your web app can't load a resource for legitimate user, it is broken. > An attacker, finding they can't access a resource because of CORS, writes a script to spoof the HTTP headers and gets access regardless. CORS rules are enforced by the browser, not the server, so that isn't a possible attack. > Maybe I'm wrong. Someone explain it to me. I miss the weird web, CORS broke the weird web You'll have to be more specific. What's broken? > but I've yet to see any explanation for how it actually prevents malicious behavior. Things like CORS and Frame-options prevent a malicious site from embedding your bank's login page beneath an innocent-looking button and clickjacking your session cookie to transfer money, for example. There's a lot more information about these measures readily available on MDN etc.