| I am sorry that you are sick of the HTTPS everywhere movement. But forcing your sites to use HTTPS will also prevent your users from unwittingly participating in DDOS attacks on other sites (e.g. https://en.wikipedia.org/wiki/Great_Cannon). Consider it herd immunity. Also, to respond to some of your other anti-HTTPS comments: regarding overhead: people are also working hard to minimize the amount of overhead inherent to TLS. For instance, TLS 1.3 will establish an encrypted connection in a single roundtrip, and is capable of resuming encrypted connections in zero roundtrips with application opt-in (see https://blog.cloudflare.com/tls-1-3-overview-and-q-and-a/). The encryption itself has fairly ubiquitous support in hardware, making most of them ridiculously fast. regarding CAs: with HTTP you are implicitly relying on the honesty of people in the network path. With HTTPS you are implicitly relying on the honesty of the intersection of a) people in the network path, b) people who control a CA. This is strictly fewer people than with HTTP. People are also working hard to solidify our faith in the set (b), by requiring Certificate Transparency for all new certificates, thereby ensuring that misbehaving CAs can be detected, and drastically raising the cost of mounting a CA-based attack. You say "What if I for what ever reason don't want to use HTTPs", I you'll have to layout some of those reasons explicitly. You'll probably find that people are working on all of them. In general, the default expectation on the web should be encrypted and authenticated (i.e. only both endpoints can read/write the data). Once we live in that future, asking for the ability to allow plaintext network traffic will seem a lot like asking modern programming languages to explicitly allow buffer overflows. The language designer would be justified in saying "No", and ignoring you. The considerate language designer might ask "why would you want that", and try to address your real need. But they would still never actually give you what you ask for. This may be "taking away choice" in the same sense that mandating airbags is "taking away choice", but people shrug and accept it because the baseline has moved. |
I suppose you could that creating a secure web context is kinda of way of doing that. Separating documents from more interactive content. However, freaking HTML is a horrible way to structure such a system.
Also the CA is single point of failure. A MITM only affects the users along that routing path. CA failure can affect the entire web...
I agree default is fine, but the user should be able to change those defaults. I could always compile a version for Firefox or Chromium that does. However, that's kinda ridiculous that I don't see any thing for instance in about:config Firefox.
--Speaking of programing languages-- Honestly, I don't see any language succeeding that only allows code with run time checks running. It's why rust has the unsafe keyword. To override those checks. The reason there are lots of hardware devices where the data from said device will vary in size, and there is no way the compiler will know how all these devices work. The unsafe keyword allows Rust to be a system programming language. Heck even C requires you to revert to ASM at times for working with hardware. The generated code may not meet some strict requirements set by the hardware or you need to setup the environment so C code can run.
Honestly, the biggest problem I see with programming languages is that too many of them try to be general purpose. Domain specific languages are great. If the language is designed well for the problem space it can lead to well written concise and understandable code. If your problem domain is working with hardware you need raw pointers, memory access and accurate timing. If you problem domain is altering images you probably want easy to use vector operations, handling of regions ect...