[rfmoz]

Adding more security headers every year feels like strapping seatbelts onto a collapsing roller coaster. It would be better to stop this "sec headers stack" in favour of simpler, secure by default browser primitives with explicit opt-out. Getting an example from https://securityheaders.com the list nowadays is as follows:

- Strict-Transport-Security - Content-Security-Policy - X-Frame-Options - X-Content-Type-Options - Referrer-Policy - Permissions-Policy - Cross-Origin-Embedder-Policy - Cross-Origin-Opener-Policy - Cross-Origin-Resource-Policy

[thaumasiotes]

Yeah, redoing the defaults would probably be good.

On the other hand, I tried doing a Google search with javascript disabled today, and I learned that Google doesn't even allow this. (I also thought "maybe that's just something they try to pawn off on mobile browsers", but no, it's not allowed on desktop either.)

So the state of things for "how should web browsers work?" seems to be getting worse, not better.

[PhilipRoman]

Wow, I used to be able to search google even from terminal browsers like 'elinks'

[paffdragon]

I think it still works if you set your user agent to something like lynx. I had a custom UA set for Google search in Firefox just for this purpose and to disable AI overviews.

[rfmoz]

The reference of robots.txt offer a good way to define specific behavior for the whole domain, as example. Something like that for security could be enough for large amount of websites.

Also, a new header like “sec-policy: foo-url” may be a clean way to move away that definitions from the app+web+proxy+cdn mesh to a fixed clear point.

[_heimdall]

This is an extremely common approach across industries. Look into diesel engine emission control systems sometime if you aren't familiar. The last few decades has been bolting one new system on every dew years because the ones already added continue to cause unintended reliability problems.