+mkwst and sleevi: can you think of any very bad things that would happen if we allowed certificate errors (without requiring the --allow-insecure-localhost) flag on loopback IPs? Apparently this would be useful to devs testing Service Workers + H/2.

I don't understand why we'd need this. We treat both `http://127.0.0.1` and `http://locahost` as secure contexts, don't we? What's the additional value to allowing any cert to assert itself for those hosts?

I guess I don't understand the purpose of "allow-insecure-localhost" in the first place. Why is it valuable for developers?

Re #3: the rationale (in email thread "ServiceWorker on localhost over TLS") is that right now, you need --allow-insecure-localhost if you want to locally test an application that uses H/2 and Service Workers. You need HTTPS to run H/2 locally, and you need a connection without cert errors to install a SW. Even if you click through an interstitial for a site that has cert errors, you still won't be allowed to install a service worker for that certificate (presumably because the Service Worker would persist beyond the lifetime of the certificate clickthrough).

Surma, have you chatted with the net stack folks about enabling H/2 on http://localhost (i.e. not requiring HTTPS for H/2 to localhost)? Is that a possibility at all?

(No, I have not spoken to the net stack folks.) As far as I know, not requiring HTTPS is not a possibility as no browser has h2c implemented (and honestly, that’s something I don‘t want us to do anyways). 

Note that allowing certificate errors on loopback IPs would still have measurable differences between doing actual network-based testing (both from a Chrome/caching perspective - as 'allowing an error' still means you're not allowed to persist to the cache - and from a network perspective, given that loopback interfaces behave measurably differently than actual network interfaces on most of our platforms)

This strikes me as something that Chrome should not be doing unilaterally, but working within the appropriate spec (Fetch?) to define if there's consistent agreement that bypassing security checks is acceptable. It would be wrong for Chrome to support this feature and then push Firefox into supporting it or having to argue (to both Chrome developers and web developers that have come to rely on the Chrome behaviour) that it's OK.

I'm not fully sure I understand the motivation. Is it fair to say that "because developers don't like running with a command-line flag on their development machine"?

> developers don't like running with a command-line flag on their development machine

Yes. Because it’s not ergonomic. On most systems, you have to close your Chrome and restart it with a flag. That gets weird when you have multiple profiles open. 
If you start a new instance of Chrome with a new user profile to separate it from your main instance, all your settings and extensions are missing etc etc. 

In general, we probably shouldn’t assume that _web_ developers are familiar/comfortable with command line flags, but that shouldn‘t keep them from developing with HTTP/2 and/or TLS.

Another idea: Is it worth considering tying allowing certificate errors on localhost to having DevTools open?

I would think the DevTools-related gate would add significantly more complexity and confusion.

I have a difficult time understanding the ergonomics position, since that can be made with just about every possible feature as an argument. Do we have a model of the developer cases we 'support' and those we 'don't support' - much like we have a defined security model that rules out physically local attacks from it?

For example, understanding why developing with https://127.0.0.1 (or IPv6) is a 'core feature' to support (with such changes to Chrome and the Fetch spec) versus developing with an actual certificate (such as freely obtained ones from LE) is useful and valuable.

My own personal take, which may be incorrect, but at least is worth understanding philosophically where I'm coming from, is that we shouldn't try to support everything possible because someone 'might' want to use it, and should instead try to help support and guide towards a path that can be well-defined and well-supported. Again, using the example of physically-local attacks - it's not because there aren't some things that we 'could' do, but their value as a security boundary, the diminishing returns from each bit, and the tradeoffs that become necessary for product excellence to support these cases, are all reasons why we stop the discussion at the source.

That's not to say this is a 'hard no', but I'm having difficulty understanding the rationale first and foremost.

Regardless of my own personal preferences, however, I think that it may be worth having this discussion (presumably, on Fetch spec) with other browsers before we telescope too much on a particular Chrome solution. If the ergonomics are right, we can prioritize the effort to sort out whatever Chrome-specific issues there are.

I can vouch for the ergonomics argument.

Regarding why we need it, developers need to see the realistic behavior of H/2 & QUIC in their development flows. No, loopback isn't perfect, but we need to be able to use devtools-based throttling to give insight into the expected behavior. Without this, we further the distance between "works on my machine" and real-world user experience. Getting this done matters as we scale out PRPL messaging and outreach.

@Comment 10: I appreciate the chime-in, but it doesn't help define the boundary of what's reasonable, and continues to use an unreasonable, subjective interpretation for that, which does not help meaningfully identify priorities or alternatives, and thus doesn't help advance the conversation productively.

That is, we could argue the 'ergonomics' of using Visual Studio vs Eclipse, and there will be good arguments on either side. People have waged metaphoric wars on vi vs emacs.

In this particular case, understanding the rationale and motivations is useful, as is the cross-browser collaboration. For example, we could argue 'ergonomics' are good for requiring 'dev.example.com' to be used (and which could resolve to 127.0.0.1), as that helps train developers on using DNS. Or we can use 'ergonomics' to argue against it.

I appreciate and empathesize with the desire to make developing as frictionless as possible, but, much like trying to say "guaranteed security", there's a whole lot of devil in those details and hard bargains. I'd like to better understand why this is seen as an unacceptably high trade-off to make - one which both simplifies the platform and acculturates useful concepts (e.g. the automatic acquisition of TLS certificates and deployment) - rather than what are unquestionably 'hacks' and 'loopholes' in the platform.

Before we get too deep into the how, I'm just asking to make sure we articulate the why and ensure other browsers agree. I hope that's not too unreasonable.

I think asking to make sure that we have other browser vendors on board with this decision is perfectly reasonable. I’m happy to lead that discussion with the other browser vendors.

As for the ergonomics bit: I’d love if it would be simple to just use real certificates from LE for this, but AFAIK, the way LE issues certificates doesn’t lend itself for local development. IIRC, LE requires you to put a signed file under a path and LE then requests that file and validates the signature to assert ownership. So you’d have to expose your local development server if you had a domain name like `dev.example.com` that resolves to localhost. 

My fear is that a _very_ large portion of developers are going to struggle (and stop) to experiment with PRPL because their local development setup has no easy way to use h2 with ServiceWorker. 

We already allow ServiceWorker for localhost development without TLS. I know it’s not quite the same, but it seems unintuitive if we would block ServiceWorker over h2://localhost.

(FWIW: Firefox does already allow SW installations to succeed after click through the security exception interstitial).

That's probably a security bug on their part, but it may be worth figuring out if there are mitigations they're doing, and if we should just standardize on that :)

If resolving this bug requires community discussion, we should get on it ASAP, since it will take a while.

That said, I'm not sure it does. It'd be better to have many/all browsers align on policy here, but I don't see that us unilaterally changing our behavior would necessarily "push" Firefox to change (#7) anymore than Firefox' SW registration bug (#13) pushes us to change.

Re comment 13-16: I'll ask Mozilla people what they think. 

I intentionally split this bug this off issue 717340 which is for service workers specifically. I thought there was rough consensus to just allow cert errors on localhost (comments 3-5 there), regardless of web platform feature being used (SW or not). It's clear now there is no such consensus so it may have been better to just keep everything on one bug.

I'm removing ServiceWorker from the component here to clear our Untriaged queue. The SW bug that is blocked on this is still open with the SW component.

Certificate errors are not allowed with https://localhost either 

According to https://sites.google.com/a/chromium.org/dev/Home/chromium-security/security-faq?pli=1#TOC-Which-origins-are-secure-

*://localhost/ and *://127.0.0.1/ are both considered secure origins

See also https://bugs.chromium.org/p/chromium/issues/detail?id=901858