@LorenzoAncora @Suiseiseki @tennoseremel @lxo Which is a good reason to be disappointed by all the C++ browsers with C libraries lacking any formal verification being used.

It is a predictable outcome and yet practices are not being adapted accordingly.

One of the most important would be to constrain unexpected computation the browser may induce (no arbitrary code execution, such as JavaScript), since hardware vulnerabilities of various sorts may defeat even entirely correct programs' security.

@LorenzoAncora @lxo @quasi @Suiseiseki @tennoseremel > It's just a *necessity* to meet the minimum quality standards.

Funny that. I actually consider my bank's site to have actively degraded every single update they made since adding JavaScript to it. The original version was also considerably faster to use.

@Suiseiseki @LorenzoAncora @tennoseremel @lxo There is also zero reason why a first-party site couldn't embed malicious data directly, such as image data malformed specifically to exploit bugs in a codec library used by some common browsers.

There is no reason, either, to assume that iframes cannot be controlled by the same first-party and used to obviate unnecessary JavaScript interactions.

> Exploitation, information exfiltration etc require JavaScript to pull off - meanwhile you cannot do any of that with just HTML.

Technically, other flaws in a browser implementation may permit it. This is the result of unsafe programming practices.