andyjh

Licensing issues aside, it would cost _additional_ money to actually serve all that content to a global audience (shipping bytes over the internet isn't free).

It would also be useful if you can tell us which IP you're connecting to when you see the error (eg from dev tools).

One might reasonably assume the "bad guys" they're trying to catch would go elsewhere though, if they have any sense. So then you're just left with innocent people to spy on.

Chrome isn't forcing anyone, it's just making it clear to users that a non-https site is insecure, which it is. What's the problem with providing information so that users can make an informed choice about whether to use the site?

Why can't you just sign up via tor?

Not true: Currently the "info" indicator appears on first interaction (which _could_ be after they've auto-completed everything, but may not be). This is changing though: In Chrome 68 the info indicator will be there on all HTTP pages, without form interaction required. So this change just changes it from "info" to red warning.

No, as of chrome 68, http will be marked as not secure without waiting for any user interaction at all. The change for http pages outlined in this post is to upgrade that from the grey info message to a red warning.

Actually the target position is that https _won't_ be marked as "secure", but rather than http will be marked as "not secure". Can't really argue with that.

It's not really any business of the ISPs which services their customers want to use. If demand for bandwidth increases such that the price isn't viable anymore, charge customers more if necessary. You don't find restaurants charging potato suppliers because diners like to eat lots of fries.

I'm personally glad Mozilla take such an interest in ensuring CAs are trustworthy. After all, they are the linchpin for security and authenticity of just about everything on the web.

I think this post shows that Mozilla are trying to be as transparent as possible about what they expect, and thay they're proactively working with Digicert to make it as likely as possible that the new CA will be trusted. A certain amount of open-endedness is inevitable though, otherwise it'd be possible to find loopholes with enough motivation (and the survival of a business is fairly good motivation).

You can use client certificates in h2, you just can't do TLS renegotiation. So you have to request a client cert in the initial handshake; you can't ask later (eg for a specific URL).