Chrome To Force Domains Ending With Dev and Foo To HTTPS Via Preloaded HSTS (ttias.be) 220
Developer Mattias Geniar writes (condensed and edited for clarity): One of the next versions of Chrome is going to force all domains ending with .dev and .foo to be redirected to HTTPs via a preloaded HTTP Strict Transport Security (HSTS) header. This very interesting commit just landed in Chromium:
Preload HSTS for the .dev gTLD:
This adds the following line to Chromium's preload lists:
{ "name": "dev", "include_subdomains": true, "mode": "force-https" },
{ "name": "foo", "include_subdomains": true, "mode": "force-https" },
It forces any domain on the .dev gTLD to be HTTPs.
What should we [developers] do? With .dev being an official gTLD, we're most likely better of changing our preferred local development suffix from .dev to something else. There's an excellent proposal to add the .localhost domain as a new standard, which would be more appropriate here. It would mean we no longer have site.dev, but site.localhost. And everything at *.localhost would automatically translate to 127.0.0.1, without /etc/hosts or dnsmasq workarounds.
Preload HSTS for the .dev gTLD:
This adds the following line to Chromium's preload lists:
{ "name": "dev", "include_subdomains": true, "mode": "force-https" },
{ "name": "foo", "include_subdomains": true, "mode": "force-https" },
It forces any domain on the .dev gTLD to be HTTPs.
What should we [developers] do? With .dev being an official gTLD, we're most likely better of changing our preferred local development suffix from .dev to something else. There's an excellent proposal to add the .localhost domain as a new standard, which would be more appropriate here. It would mean we no longer have site.dev, but site.localhost. And everything at *.localhost would automatically translate to 127.0.0.1, without /etc/hosts or dnsmasq workarounds.
Maybe...? (Score:5, Insightful)
Re:Maybe...? (Score:5, Interesting)
All the strive to force users to go https has gone over the top. It's better to be nice about it.
Many sites don't need https since there's not much to protect in the communication when people just look at memes and pictures of cats.
Keep the https available for cases where users want to get the extra security. Assuming that users are stupid makes the users stupid.
Re: (Score:3)
Many sites don't need https since there's not much to protect in the communication when people just look at memes and pictures of cats.
You're making the common error of believing that the purpose of TLS is to protect the secrecy of the content stream, but that's only one half of it, and in most cases the less important half. The other goal is to ensure the integrity of the content stream, not because your cat pictures are important but because browsers are too big and too complex to secure effectively. TLS ensures that no one can inject anything malicious (or even anything annoying) into your stream of cat pictures. Of course, the site you
Re:Maybe...? (Score:4, Informative)
http://beefproject.com/ [beefproject.com]
It's so easy you can do it with a phone using an app like dSploit.
Http used to be ok, today every scriptkiddie has access to tools that will pwn any browser with a mitm attack.
Also, any http security header you might add from your site is useless without https.
Re: (Score:2)
"Grandma, don't forget to set up a VPN before you use the WiFi at the coffee shop. Otherwise you deserve to get malware on your machine."
"What's WiFi?"
Re: (Score:2)
If my 86 year old grandmother who had terminal stage 4 cancer could remember it, yours should be able to, too. It works if you use a mouse in a pantry analogy for example Something that a lot of nursing homes have found out that if you relate something to someone who's older, that fits the stuff they grew up with their brain seems to "get it" even if they don't understand it.
Re: (Score:2)
Re:Maybe...? (Score:4, Interesting)
I think you missed a key point - Google bought the .dev TLD and their intended usage is only their own projects. So what they're doing here is asserting that all their dev domains will be encrypted.
The issue here is iCANN shouldn't have been dumb enough to grant a TLD that has been widely used internally, but unfortunately they have a financial incentive to hawk as many TLDs as possible.
Re: (Score:2)
Most houses don't get robbed much so there's no point in buying locks, correct?
Assuming that users are stupid makes the users stupid.
It only appears that way if you don't pay attention. Its not because it makes a previously not-stupid user magically become stupid, but because widening the audience to allow for stupider users brings down the average. If you want to appeal to a larger market, its the way to go. If you want to stick to communities that shun non-technical people out of hand well.. there's plenty of those around the internet also.
Or to put in te
Re: (Score:2)
Many sites don't need https since there's not much to protect in the communication when people just look at memes and pictures of cats.
What someone finds offensive about someone else's browsing habits is not for the content producer to decide.
Re:Maybe...? (Score:4)
That's pretty narrow-sighted. http protects users from malicious intent by man-in-the-middle attacks such as injection by their ISP. HTTPS should be everywhere and the faster we get there the better
Encryption requires PERMISSION and thus serves as yet another point of leverage for those wishing to assert censorship over content and entities they don't like.
HTTPS as a destination is laughable... there are hundreds of entities .. some straight up state run by hostile governments with ability to generate keys seen as legitimate globally by the worlds population of web browsers. Better than nothing but hardly what I would deem to be anything approaching trustworthy or secure.
Ends don't justify means. A desire to reduce MITM opportunities does not justify forcing people to use https if they don't want to.
Re: (Score:2)
Encryption requires PERMISSION
How so? Outside of North Korea, I mean.
The requirement to own and renew a domain (Score:4, Informative)
Web browsers require HTTPS server operators to obtain a fully-qualified domain name and a certificate from a certificate authority trusted by the browser publisher. Though Let's Encrypt makes certificates available without charge to domain owners, the domain itself still requires a recurring payment to a third party. The requirement to own a domain and keep it renewed imposes an extra $15 per year (source: Gandi.net) tax on running a server inside a home LAN.
Re: (Score:3)
Web browsers require HTTPS server operators to obtain a fully-qualified domain name and a certificate from a certificate authority trusted by the browser publisher. Though Let's Encrypt makes certificates available without charge to domain owners, the domain itself still requires a recurring payment to a third party. The requirement to own a domain and keep it renewed imposes an extra $15 per year (source: Gandi.net) tax on running a server inside a home LAN.
In a home LAN you can just use a self-signed certificate and add the cert to your browsers' trust stores. Or just use plain HTTP, since you don't have any concern about malware injection. If you want a domain name you can use for free locally, you can use the .invalid or .localhost TLDs, though that's orthogonal to the question of TLS.
But your issue is really unrelated to whatever WaffleMonster was talking about, because the discussion was about a context in which ISPs, et al, could do injection attacks,
Re:The requirement to own and renew a domain (Score:4, Informative)
In a home LAN you can just use a self-signed certificate and add the cert to your browsers' trust stores.
Yes, this.
You can even, for complex home environments, run your own CA, install your own CA's cert and then use it to sign individual certs all day long without further hassle.
The only reason you'd ever have to have a cert signed by a third party CA is if you want strangers to use your services and don't want to require them to install a special cert to do so.
Re: (Score:2)
The only reason you'd ever have to have a cert signed by a third party CA is if you want strangers to use your services
By "strangers" did you intend to include non-technical friends and family visiting your home?
Re: (Score:2)
They aren't strangers, and helping them install a cert is a trivial exercise. Or, if they use a less tightass browser, telling them that the security warning is OK and they should allow a permanent exception is even easier.
If they're unwilling or unable to do either of those things, then they don't have to access my servers. I also run an open WiFi hotspot just for this purpose, which gets them throttled, limited internet access that is more than sufficient for casual use.
Re: (Score:3)
The only reason you'd ever have to have a cert signed by a third party CA is if you want strangers to use your services and don't want to require them to install a special cert to do so.
Or you wish to install programs win10 disallows https://stackoverflow.com/ques... [stackoverflow.com]
Re: (Score:3)
Anti-FUD: Test signing mode will allow you to run code signed with a private cert, even a self-signed one made with MakeCert.exe. It puts a test mode watermark in the corner of the screen, but that's okay for Dev use.
https://docs.microsoft.com/en-... [microsoft.com]
Answering the obvious "WTF" question, driver signing has been a "should" since before XP. It's now a must because it's a malware/APT vector.
Re: (Score:3)
Some specialized peripherals manufactured by hobbyists for hobbyists, such as tools to read and write cartridge storage media for retro 8- and 16-bit computers, are made in volumes is so low that the cost per year of obtaining and renewing an EV code signing certificate as well as the documents that the EV code signing CA requires would make up a substantial portion of the selling price. Is there a practical way to make low-volume peripherals compatible with 64-bit Windows? Would it be advisable for the man
Re: The requirement to own and renew a domain (Score:2)
I run my development server on a Raspberry Pi, you insensitive clod!
Re: Maybe...? (Score:3)
Re: (Score:2)
So what should a developer who doesn't already own a counterpart to mydomain.net do for his internal test servers, such as someone whose web presence is through a github.io subdomain? Or why is it fair to impose a $15/year recurring fee on every household with a home LAN?
Re: (Score:2)
Make your own cert then. Nothing is stopping you from self-signing a cert and then telling your browsers to trust it -- for free.
Re: (Score:2)
Nothing is stopping you from self-signing a cert and then telling your browsers to trust it
Not even a change to how Android handles certificates [googleblog.com]?
Re: (Score:2)
Must suck to be an android user.
Re: (Score:2)
What in Nougat is stopping you from using a cert signed by your own CA? I'm not seeing that in the page you linked to. On the contrary, I see specific instructions on how to allow exactly that.
Re: (Score:2)
In addition to the user allowing that, the app developer also has to allow that.
Re: Maybe...? (Score:2)
Now that's what I call ignorance.
Man-in-the-middle attacks require an attacker to be in the middle. Only third parties with access to the network links (or routing tables), not "any" third party.
And IPsec is still a thing.
Re: (Score:2)
Maybe use browser other than Chrome??
Firefox follows the same path (forcing https). If fact it tends to follow Chrome's every move... ...).
AFAIK Safari does it too.
I'm not sure about IE/Edge and all the small players (Opera,
Re: (Score:2)
FYI, the HSTS preload list is used by all major browsers (Chrome, Firefox, IE, Edge, Safari, Opera, etc.). This is a good thing, of course; online security shouldn't be enforced conditionally depending on which browser you're using.
The linked article got it wrong. This isn't about Chrome adding TLDs to the HSTS list, it's about the TLDs' owner (which also happens to be Google) adding them to the global HSTS list.
Re: (Score:2)
If you're on multiple platforms, why do you necessarily need to be using the same browser everywhere? Unless you're willing to let Google track you (e.g. by logging in and using their "cloud" bookmarks), there's no particular advantage to it. Web browsers are pretty simple, so it's not exactly hard to adjust to how each one does things.
I use Safari on the Mac, keeping Chrome around specifically for when some site I need to access requires Flash. If I have to venture over to Windows, I generally use Firefox.
Re: (Score:2)
I do similar to what you do....different browsers for different OSes...
I primarily use Safari on OS X and IOS.
I pretty much use Firefox on Linux and Windows...except some work applications that seem to only want to work with IE. so I use that only for a select few
To promote domain sales (Score:2)
1) Buy a domain name for a few dollars
And then do what after it has expired?
Re:Maybe...? (Score:4, Informative)
Re: (Score:2)
Thanks!
Re: (Score:2)
Thanks, AC!
Re: (Score:2)
I find your summary to be correct, but I don't personally agree with your conclusion. Moonchild's early post made it sound like it was malware and he was confused, and later he clarified that he was leading a crusade against other crusaders he disagreed with, but was careful to point out that the workaround was setting a value in about:config that disallows actual malware but allows stuff like this (of which ad nauseam is the only entry). It's a bad position for him to take, and he's wrong to do so, but i
Chrome-for-iOS is Chrome in name only (Score:3)
Chrome doesn't run on iOS either. Instead of Chrome, Google publishes Chrome-for-iOS. The difference between Chrome and Chrome-for-iOS is that while Chrome uses the Blink engine, Chrome-for-iOS uses the same Apple WebKit engine as Safari, as required by the App Store Review Guidelines. This means that if Apple declines to support a particular web API in Safari, it'll be unsupported in Chrome-for-iOS as well.
Re: (Score:2)
Switch to .test (Score:5, Insightful)
.test is an IETF standard for this purpose. .dev never was. Google own .dev, and they own Chrome, so they are perfectly welcome to do this. We could argue as to whether a browser that enforces per-domain protocols is truly adhering to browser standards (and the larger ramifications if every browser coder started doing the same), but accept that you have zero right to use .dev as your personal fiefdom and move on to something that will remain easier for you to maintain.
Re: (Score:2, Insightful)
dev != test != prod
Re:Switch to .test (Score:4, Insightful)
Re: (Score:2)
FFS. Do you seriously deploy to the .prod TLD, which is also owned by google? You should write a book called "DNS Worst Practices". This stuff is spelled out quite clearly in RFCs.
Use dev.test, test.test, etc for your 2LDs. So myservice.dev.test, etc.
Better yet, just allocate domains for internal use on top of the one you certainly already own (e.g. dev.mydumbbusiness.com) so you can have myhost.dev.mydumbbusiness.com, etc. Or register a tld specifically for internal domains. In any case, you just manage th
Re: (Score:2)
> devel != dev
Until Google buys "devel" and changes that too...
Please see RFC6761 (Score:5, Informative)
Re: (Score:2)
NOPE (Score:5, Informative)
Modded +5, Informative, but both of its statements are inaccurate. .localhost is reserved for 127.0.0.1 and no other thing. .invalid is reserved for NO use, it should never resolve.
https://tools.ietf.org/html/rf... [ietf.org]
Localhost:
Name resolution APIs and libraries SHOULD recognize localhost names as special and SHOULD always return the IP loopback address for address queries and negative responses for all other query types. Name resolution APIs SHOULD NOT send queries for localhost names to their configured caching DNS server(s).
Invalid:
Name resolution APIs and libraries SHOULD recognize "invalid" names as special and SHOULD always return immediate negative responses. Name resolution APIs SHOULD NOT send queries for "invalid" names to their configured caching DNS server(s).
Neither of these are meant for use on a local internet. .localhost is meant to resolve to loopback, and .invalid is meant to never resolve but instead give NXDOMAIN.
Maybe there are domains reserved for private usage, but it ain't these two.
Re: (Score:3)
Until .invalid gets auctioned to a bidder
They cannot be; RFC6761 is a compulsory standard to the DNS and specifies these names as permanently reserved.
Re: (Score:2)
No.
.localhost TLD? (Score:4, Informative)
Cmon, we aren't talking some crazy complicated configuration here. DNSMasq: add "address=/localhost/127.0.0.1" to your config file. Boom. Done.
Re: (Score:3)
Re: (Score:2)
I just don't understand the hatred for devs... (Score:3, Interesting)
that Google has. They already broke the "-ignore-certificate-errors" flag which was driven by their hate. I often have to change my clock for testing, and Google made the decision that I should not be allowed to use the web. We use Let's Encrypt certs that area also pretty hatefully limited to 90 days so they waste so much of our time having to maintain them, so you can't move your clock that far forward or backward before Google decides you shouldn't be able to work.
Re: (Score:2, Interesting)
They also decided to break --disable-web-security which they had previously supported for years. They even broke it in Content Shell which is used only for headless testing, which makes no sense unless they just don't want us to use Chrome for development.
Re: (Score:2)
> also pretty hatefully limited to 90 days so they waste so much of our time having to maintain them
It's a one line cron entry, if that takes too much time, maybe you should hire somebody to do your job.
Re: (Score:2)
CNAMEs are your friend if your using DNS authentication for lets encrypt.
What scares me is that millions of people fully trust what the default scripts are doing to their computers. Every 90 days certs and the scripts get updated which means someone in the chain of trust has the ability to completely p0wn a machine. How many black-hats are going through those scripts hunting for a way to exploit any bugs? The certbot-auto does enough scary things and it only needs to be run once.
Re: (Score:2)
you realize you can just have a cron job auto renew your certs right...
How so? Let's Encrypt rejects hostnames in reserved domains, such as .local, .internal, and .test. It works only with actual registered domains. This means you'd need to make another cron job renew the domain, and another cron job pay the credit card bill for the domain renewal, etc. I must be missing something; what is it?
What should you do? (Score:5, Insightful)
How about: Don't use a gTLD for your local DNS?
Also, why are you doing web development without HTTPS unless you're planning on never using it? It's not like certificates cost anything. There's also nothing stopping you loading your own CA cert and signing your own certificates too.
Browsers behave differently based on the protocol. Building against one set of rules and deploying against another is just asking for problems.
HTTPS + Zeroconf (Score:2)
Also, why are you doing web development without HTTPS
I am developing software that runs on a PC on a home LAN, and I've never seen anyone get HTTPS working with multicast DNS and DNS-SD.
Re: (Score:2)
You know your comment is moot if you quote the entire sentence, right?
why are you doing web development without HTTPS unless you're planning on never using it?
If you're using multicast dns, why are you using .dev instead of .local, as is part of the mDNS RFC?
https://tools.ietf.org/html/rf... [ietf.org]
If you're not using the Google sponsored .dev gTLD, this doesn't impact you at all. .dev domain. Just like you need to abide by certain rules if you want to use .aero or lawyer, etc. Perhaps a condition of using .dev is to only host HTTPS web servers? I haven'
They bought the rights to control who's allowed a
Re: (Score:2)
.... your other option is to install your own CA on the LAN PC's so you can issue your own trusted certificates for .local domains.
Then you've got no problem with HTTPS using mDNS
Public CA's don't issue certificates for local domains for good reason.
Re: (Score:2)
>> How about: Don't use a gTLD for your local DNS?
Lest someone take that advice the wrong way, let's be very clear.
You DO NOT want to use fake/bogus TLDs in the internal network of an enterprise. It creates serious pain points, not the least of which is that you can't get public SSL certificates against your internal names. That means you have to push your private CA cert into a bunch of applications and it's a huge PITA.
Examples: On Windows you can distribute your Enterprise CA cert via Group Polic
Re: (Score:2)
big companies love having their own CA though, it lets them decrypt and snoop on HTTPS traffic and resign it without browser security warnings
Re: (Score:2)
Sounds good to me (Score:2)
I've been using ".local" for years. I'd have no problem with ".localhost".
Re: (Score:2)
Re: (Score:2)
Yeah, I know -- but old habits die hard, and I don't use anything zeroconf. This has been on my "to fix" list for a while now, though.
What you should do... (Score:2)
Start creating sites that don't break as soon as you start using TLS 1.2.
Hopefully the other browser makers will follow (Score:2)
Re: (Score:2)
Seriously are people really using .dev URLs to point to local resources where there could be a name collision with a real TLD? So you have a bunch of links to [].dev that people have stored. And then they switch networks where .dev resolves correctly and they start erroneously sending data to third parties. And we don't all see why that is an awful problem?
Myself and others saw why it was a bad idea many years ago. Unfortunately all ICANN saw was dollar signs when they opened the floodgates at expense of the network.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Why are you *not* using https? (Score:2)
We're at the point now where using https is so easy, that there's very little reason to not use it. The biggest stumbling blocks had always been obtaining the certificate and vhost/IP limitations on certificates. But those are now taken care of with Lets Encrypt and recent changes to how certificates are handled.
Given the current technical and political climate, HTTPS should be the default for *everything*, barring very special circumstances.
Re: (Score:2)
These are dev environments we're talking about. They are often only accessible on local networks, sometimes even only on a localhost. Deploying https in a dev environment isn't really necessary for most development.
People are getting upset because you wouldn't be able to obtain a cert signed by any reputable authority for a domain you didn't actually own. After this change, you have to deploy https on those gTLDs which would mean going through self signed cert shenanigans. As others have mentioned, peop
Re: (Score:2)
It may not be necessary, but just because they're development system that doesn't mean security should be ignored.
For one thing, you may run into problems in production if it applied security that you didn't check for in dev.
For another thing, if your development efforts touch sensitive client data, then it *still* needs to be protected even if it's internal only. It's bad enough if your company is breached by an attack. It's even worse if your client data is threatened in the process.
Proper security need
HTTPS everywhere is all well and good... (Score:5, Interesting)
But it's a real pain for anything that you ship with a web interface, and expect to work unmodified for a long period of time.
Sure, that's a niche use-case, I get that, but not everything that's accessed by a web browser is something easily updated, and why should it be? If I build some device that's intended to be put on my local network, and give it a web interface, - like, say, a home router - will I be required to implement HTTPS on the device, and have it ship with a cert? A cert that expires after a relatively short period of time?
I happen to have an old computer lying around the house, and it can't run anything more modern than Chrome from about eight years ago. This browser is able to access anything on the web, other than newer HTTPS sites, because it doesn't understand their certificate. By building these mechanisms of trust, and then constantly changing them (for instance, change from Common Name to Subject Alternate Name - and whatever it is that old Chrome hates about modern certs), we are locking ourselves out of notions of backwards compatibility, and increasing the rate at which we have to throw away our devices, because we can't afford to release OS updates for old hardware, and can't afford to release browser updates for old OSs.
I get that we're talking about security here, and trust, but I personally see a high cost. Plain HTTP is great. HTTPS is a moving target, and seems like it will remain so.
Re: (Score:2)
I get that we're talking about security here, and trust, but I personally see a high cost. Plain HTTP is great. HTTPS is a moving target, and seems like it will remain so.
Web security is a moving target, and will remain so, and that applies to plain HTTP as much as to HTTPS. Your computer with eight year-old chrome is a security breach waiting to happen. You could browse some site with malware that compromises your browser, compromises the machine, then attacks everything else in your home network that is accessible from that machine.
Using unpatched (and unpatchable!) software is just a bad idea. If HTTPS changes forces you to keep things closer to current, that's a featur
Re: (Score:2)
I know, and I totally understand all that. But on the other hand, my handy home router isn't likely to be patched anytime soon, and the web interface on the product I happen to be working on is likely to be used for ten years or more, without necessarily being updated. The system may not be internet connected, but it will need to be configured by a laptop, running a browser.
If Google take this HTTPS-only approach all the way, as some people suggest that they will, what shall I do? I can't put a 10-year cert
Re: (Score:2)
HTTPS everywhere has the side effect of locking us all into an upgrade cycle that I thought slashdotters in general, were against.
Not security-focused slashdotters.
Re: (Score:2)
Get something like stunnel and wrap/unwrap the security in-stream. Problem solved. Or install an older version of the browser and then you don't even have the problem in the first place.
The world needs to be secure by default -- not just the web but email and cars and IoT pacemakers and basically everything else. Devices are too connected and hackers willing to abuse those devices too prevalent for us to continue leaving things insecure in order to avoid the odd edge case here and there.
In your case, sur
Re: (Score:2)
Re: (Score:2)
Related to this is ethernet connected "devices" and specialized embedded hardware which may not even have spare processing power for https, and have no need to it since they never are remotely reachable. A perfect example might be arduino web servers on a local lan. Pure http is a nice simple protocol that is easy to implement even on very low end devices, https is not. There are different ways to solve this, but banishing http to .localhost/127.0.0.1 is NOT one of them. I think even a new http header en
Once a week (Score:2)
It seems like once a week I'm given a new reason to be happy that I don't use Chrome.
That gives me an idea (Score:3)
This gives me an idea. gTLD wide HSTS should be done for some other gTLD as well. I'm thinking like *.bank and the like. It just forces any user of that gTLD to be at least somewhat security conscience and adds some good public reputation to those select gTLD. A private company that owns a gTLD could use this to increase the value of their gTLD because it will have a reputation of being more secure.
Re: (Score:2)
Re: (Score:2)
.localhost is for 127.0.0.1 only. What would you use to test, say, the client side of a web application on an Android phone, iPhone, Android tablet, or iPad?
Re: (Score:2)
Based on recommendations that claimed .local can conflict with various UDP multicast LAN protocols, I recently changed my home DNS to be a subdomain of a domain I pay $10 a month for. I was skeptical doing this initially, but now that it's implemented, I like it better. With search domains set up, you don't even have to care that you now have a longish domain name for internal hosts.
Alternatively, .test is meant for local use even if it doesn't seem like the best name for the job.
Re: (Score:2)
The better solution would be for you to buy yourself a cheap domain, even if you only ever use it internally. Make it your default domain, and you'll never have to explicitly enter it anywhere. The computer automatically appends it where needed. This is something you can most likely set up on your DHCP server.
What exactly is the risk? This is how DNS should work. Not every network is globally accessible, and neither
Re:Yeah (Score:4, Insightful)
You should be using .test domains - that's recommended practice by W3C https://tools.ietf.org/id/draf... [ietf.org].
The .dev domains, on the other hand, are valid gTLD and are owned by Google. It's not surprising that Google wants to force HTTPS on a gTLD that they own.
What cert for .test? (Score:2)
Then how does one obtain a certificate for a domain in .test and use it on all devices on a home LAN? I thought Android 7 "Nougat" and later didn't trust user-installed root certificates [googleblog.com] unless a particular app opts into trusting user-installed root certificates through the network security config file in the application's package. Chrome for Android appears to opt in [github.com], but Firefox for Android is untested. Using cleartext HTTP is not an option because more sensitive APIs are unavailable outside secure contex [pineight.com]
Re: (Score:2)
I thought Android 7 "Nougat" and later didn't trust user-installed root certificates [googleblog.com] unless a particular app opts into trusting user-installed root certificates through the network security config file in the application's package.
You are completely correct. So your two options are:
Re: (Score:2)
You don't, you use self-signed certificates and put the CA into /etc/ssl/certs
Android apps distrust user-installed certs (Score:2)
As of Android 7 "Nougat", Android apps distrust Android's counterpart to /etc/ssl/certs by default [googleblog.com]. In addition, I haven't tested all major models of media player appliance that stream from a web server running on one's home NAS, but I imagine some have no user-editable counterpart to /etc/ssl/certs.
Re: (Score:2)
So what should a hobbyist who needs modern browser features do? Or especially a non-technical PC owner who has installed web server software on his home PC and set it up for internal access only, so that visiting friends and family can view videos stored on the home PC that the PC owner has chosen to share?
Re: (Score:2)
Re: (Score:2)
The .dev tld is widely used for development and should never have been assigned to Google.
Talk to ICANN. It's them who destroyed the well-working system of TLDs for a quick buck.
If Chrome causes problems .... ditch it.
For 99% of usage, yeah, that's a good idea -- no one wants spyware (ok, other than 99% users, but I don't care about normies). But broken sites which work only on Chrome are too frequent to not have it installed.
Re: (Score:2)