HTTP Security Headers

I dislike HSTS and the remote reporting features. So, I would not want to implement them in a new web browser (if there is any report, it can be viewed by the end user (perhaps in the web developer console, with an indicator in the status line to indicate if any reports are available), who can then save it or do whatever else is wanted with it).

I also dislike "X-Content-Type-Options: nosniff"; the browser should never try to guess the MIME type, and should always use the Content-Type header unless it is overridden by the user. Of course, it is harmless for the web site operator to include such a header, since it will be ignored by clients that do not understand it. I merely say that the effect of "X-Content-Type-Options: nosniff" would be implied in any browser that I would want to write.

The other headers can be useful.

One of the features that I would want to include in a new web browser is user-defined header rewriting (both requests and responses) (which is the only way to set language preferences and Do-Not-Track, among other things); the headers described in the linked document (both old and new) can then be useful as a standardized way for the end user to configure several other options too. (Independently of this, there are many other things I would change too (e.g. changing the way deice handling works entirely), but that is beyond the scope of the current topic.)

Also, in my opinion, scripts should never be executed for <img>; if you need scripts, other commands such as <object> or <iframe> should be used instead. (Although, scripts should usually be avoided when not needed anyways.)

It is also necessary to ensure that <meta http-equiv> is implemented securely. It should never add permissions which have been denied, nor conflict with anything that has already been loaded (e.g. you can't override the MIME type in a <meta>, since it is already HTML if the <meta> is to be parsed at all).