Why do I need to know all of this stuff, why isn’t the web safe by default?
The answer to questions like this is often that there was no need for such safety features when the underlying technology was introduced (more examples here) and adding it later required consensus from many people and organizations who wouldn't accept something that broke their already-running systems. It's easy to criticize something when you don't understand the needs and constraints that led to it.
(The good news is that gradual changes, over the course of years, can further improve things without being too disruptive to survive.)
He's not wrong in principle, though: Building safe web sites is far more complicated than it should be, and relies far too much on a site to behave in the user's best interests. Especially when client-side scripts are used.
It's easy to criticize something when you don't understand the needs and constraints that led to it.
And that assumption is exactly what led us to the current situation.
It doesn't matter, why the present is garbage, it's garbage and we should address that. Statements like this are the engineering equivalent of "it is what it is shrug emoji".
Take a step back and look at the pile of overengineered yet underthought, inefficient, insecure and complicated crap that we call the modern web. And it's not only the browser, but also the backend stack.
Think about how many indirections and half-baked abstraction layers are between your code and what actually gets executed.
Statements like this are the engineering equivalent of “it is what it is shrug emoji”.
No, what I wrote is nothing like that. Please re-read until you understand it better.
Of course it is like that. You're saying that the complaint is wrong because the author doesn't know the history, and now you accuse me of not understanding you, because I pointed this out.
If you have to accuse everyone of "not understanding", maybe you're the one who doesn't understand.
You’re saying that the complaint is wrong because the author doesn’t know the history
That's not at all what he said. He literally even said "He’s not wrong in principle."
If you don't understand the history of why something is the way it is you can't fix it. You can suggest your new "perfectly secured web site" but if Amazon, Microsoft, Google, Firefox, Apple, etc. don't agree on your new protocol then there's going to be exactly 1 person using it.
If you don’t understand the history of why something is the way it is you can’t fix it.
See also: Chesterton’s Fence.
It doesn’t matter, why the present is garbage, it’s garbage and we should address that. Statements like this are the engineering equivalent of “it is what it is shrug emoji”.
I don't think your opinion is grounded on reality. The "it is what it is" actually reflects the facts that there is no way to fix the issue in backwards-compatible ways, and it's unrealistic to believe that vulnerable frameworks/websites/webservices can be updated in a moment's notice, or even at all. This fact is mentioned in the article. Those which can be updated already moved onto a proper authentication scheme. Those who didn't have to continue to work after users upgrade their browser.
A lot of the web used to run on flash. Then apple comes around and says "flash is terrible and insecure". Within a number of years everything moved away from flash, so it's definitely possible to force the web in new directions.
Unless I'm missing something, the post is plain wrong in some parts. You can't POST to a Cross-Site API because the browser will send a CORS preflight first before sending the real request. The only way around that are iirc form submits, for that you need csrf protection.
Also the CORS proxy statement is wrong if I don't misunderstand their point. They don't break security because they are obviously not the cookie domain. They're the proxy domain so the browser will never send cookies to it.
Anyways, don't trust the post or me. Just read https://owasp.org/ for web security advice.
The answer to questions like this is often that there was no need for such safety features when the underlying technology was introduced (more examples here) and adding it later required consensus from many people and organizations who wouldn't accept something that broke their already-running systems. It's easy to criticize something when you don't understand the needs and constraints that led to it.
(The good news is that gradual changes, over the course of years, can further improve things without being too disruptive to survive.)
He's not wrong in principle, though: Building safe web sites is far more complicated than it should be, and relies far too much on a site to behave in the user's best interests. Especially when client-side scripts are used.
And that assumption is exactly what led us to the current situation.
It doesn't matter, why the present is garbage, it's garbage and we should address that. Statements like this are the engineering equivalent of "it is what it is shrug emoji".
Take a step back and look at the pile of overengineered yet underthought, inefficient, insecure and complicated crap that we call the modern web. And it's not only the browser, but also the backend stack.
Think about how many indirections and half-baked abstraction layers are between your code and what actually gets executed.
No, what I wrote is nothing like that. Please re-read until you understand it better.
Of course it is like that. You're saying that the complaint is wrong because the author doesn't know the history, and now you accuse me of not understanding you, because I pointed this out.
If you have to accuse everyone of "not understanding", maybe you're the one who doesn't understand.
That's not at all what he said. He literally even said "He’s not wrong in principle."
If you don't understand the history of why something is the way it is you can't fix it. You can suggest your new "perfectly secured web site" but if Amazon, Microsoft, Google, Firefox, Apple, etc. don't agree on your new protocol then there's going to be exactly 1 person using it.
See also: Chesterton’s Fence.
I don't think your opinion is grounded on reality. The "it is what it is" actually reflects the facts that there is no way to fix the issue in backwards-compatible ways, and it's unrealistic to believe that vulnerable frameworks/websites/webservices can be updated in a moment's notice, or even at all. This fact is mentioned in the article. Those which can be updated already moved onto a proper authentication scheme. Those who didn't have to continue to work after users upgrade their browser.
A lot of the web used to run on flash. Then apple comes around and says "flash is terrible and insecure". Within a number of years everything moved away from flash, so it's definitely possible to force the web in new directions.
Unless I'm missing something, the post is plain wrong in some parts. You can't POST to a Cross-Site API because the browser will send a CORS preflight first before sending the real request. The only way around that are iirc form submits, for that you need csrf protection.
Also the CORS proxy statement is wrong if I don't misunderstand their point. They don't break security because they are obviously not the cookie domain. They're the proxy domain so the browser will never send cookies to it.
Anyways, don't trust the post or me. Just read https://owasp.org/ for web security advice.
As a userscript author, it is some bullshit.