Chrome 63 changing http to https - google-chrome

Question

Does using Chrome v.63 force use of https?
I am running Apache 2.4.27 on a Windows 10 desktop as a sandbox where I can experiment and do some tutorials. I have a virtual host setup called www.tutorial.dev with an alias of tutorial.dev. In the Windows 10 hosts file I have set up www.tutorial.dev and tutorial.dev to point to localhost.
As of yesterday the url http://tutorial.dev/Bootstrap4FromScratch/ was working normally. In this case providing a directory listing as a jump off point into various examples and exercises. Today, when I type in the url Chrome changes it to https and I get a connection refused message.
I understand the connection refused message. There are no certificates setup.
The only change I can find is that Chrome changed from v.62.x to v.63.x. What in Chrome 63 could be forcing http to https?
I don't have this problem with MS Edge. I tested another similar configuration on a different machine that was in the process of downloading Chrome 63.x. It already had 62.x installed. It worked until the 63.x upgrade was complete then the same problem occurred.
Additional information: If I use http://localhost to bring up the index.html or version.php in the htdocs directory the switch from http to https does not happen. The virtual host www.tutorial.dev resides in another directory outside of htdocs.
If this has been asked and answered please point me to the question/answer thread.
Thanks in advance,
Barry

Answer 1

Google owns the .dev TLD and with Chrome 63 they are forcing HTTPS on all requests to anything.dev
I went through my local dev setup and replaced all references to .dev with .local, works fine now.
Your other option is to use Firefox for local development. .dev now triggers https in FF (since before FF61) with a workaround
Edit (asside):
I have switched to using .localhost for dev as browsers allow navigator.geolocation.getCurrentPosition() (blocked if site is not HTTPS).

Answer 2

Google Chrome 63 update, out December 2017, places .dev domains in the preloaded HSTS list with a rule enforcing HTTPS, no workarounds.
{ "name": "dev", "include_subdomains": true, "mode": "force-https" }
The "only" way is to switch .dev with something else, like .localhost
IETF states a few reserved TLDs for development:
TLDs for Testing, & Documentation Examples
There is a need for top level domain (TLD) names that can be used
for creating names which, without fear of conflicts with current or
future actual TLD names in the global DNS, can be used for private
testing of existing DNS related code, examples in documentation, DNS
related experimentation, invalid DNS names, or other similar uses.
For example, without guidance, a site might set up some local
additional unused top level domains for testing of its local DNS code
and configuration. Later, these TLDs might come into actual use on
the global Internet. As a result, local attempts to reference the
real data in these zones could be thwarted by the local test
versions. Or test or example code might be written that accesses a
TLD that is in use with the thought that the test code would only be
run in a restricted testbed net or the example never actually run.
Later, the test code could escape from the testbed or the example be
actually coded and run on the Internet. Depending on the nature of
the test or example, it might be best for it to be referencing a TLD
permanently reserved for such purposes.
To safely satisfy these needs, four domain names are reserved as
listed and described below.
.test
.example
.invalid
.localhost
".test" is recommended for use in testing of current or new DNS
related code.
".example" is recommended for use in documentation or as examples.
".invalid" is intended for use in online construction of domain
names that are sure to be invalid and which it is obvious at a
glance are invalid.
The ".localhost" TLD has traditionally been statically defined in
host DNS implementations as having an A record pointing to the
loop back IP address and is reserved for such use. Any other use
would conflict with widely deployed code which assumes this use.
PS: .foo is also in the preloaded HSTS list

Answer 3

Thanks everyone for the advice. I ended up going with .tst for now. I have a feeling I'l be switching over (forced?) to .localhost at some point. But for now .tst is less typing.