CSS Paint API: New possibilities in Chrome 65

Of course you can keep track of Certificates. Honestly, if more people did that the better.

However, my problem is the browsers are forcing choices on people that are not part of the standard. They are acting as if they know best. They are also making it harder for advance users to alter these decisions. Try to enable plain text HTTP 2.0 in Firefox? No option exists in about:config.

Further, I don't see an option to disable Firefox's Secure contexts for new features. Might exist, but may need to look more.

The certificate transparency initiative is going to make MITM really hard.

There are a few extra performance tricks we can do behind the scenes here.

- Chrome's implementation won't actually perform a raster at this stage, instead we'll raster later on a background thread. toDataUrl, etc will raster.

- We'll only invoke the paint method for things which we actually need to paint. E.g. if you have a long list, we won't invoke the method for things that are outside the paint window (things off-screen).

- We'll have the ability to add a bunch of caching later on. From memory the servo folks in their experimental implementation actually speculatively generated a bunch of images ahead of time.

- We are actively investigating moving this to a background thread. So even if your main thread is janked, an animation which triggers a paint worklet, will still run at 60fps.

edit - formatting.

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.

If you're just testing on localhost, there should be no need for a cert. As the article says, localhost is treated the same as https here. In the future, I expect all features that require a secure context will start treating localhost as secure, if they don't already.