In theory, 1000 subscribers and 4000 view hours per year means 240 view minutes per subscriber per year. That can be satisfied if all your subscribers, say, view one 5-minute video a week.
If you don't want to expose your server to the Internet, you can use Let's Encrypt with an ACME client that supports the DNS challenge instead of the HTTP challenge.
I thought all browsing on iPod touch, iPhone, and iPad was done through Safari (or through a third-party web browser that wraps Safari's engine). Are these only desktop numbers?
The web browser caches resources delivered through HTTPS the same way as resources delivered through cleartext HTTP. The only thing you lose is being able to cache on an intermediate proxy, but that is relevant if you're splitting one dial-up connection among multiple clients.
Then there is the issue of small timers who want to serve a web page from home, using an old computer and dynamic hostname.
File a support ticket with your dynamic DNS provider to request addition to the Public Suffix List. If a dynamic DNS provider is on the Public Suffix List, Let's Encrypt issues 20 certificates per customer per week instead of 20 per provider per week. The other benefit of being on the PSL is that sites on the same dynamic DNS provider can't see each others' cookies.
Let's Encrypt has short-lived certificates, which are kinda useless and annoying when you have a device that is *not* a general-purpose computer capable of running their scripts.
What is the web server itself running on if not "a general-purpose computer"? If a special-purpose computer locked down to run only particular web server software, this particular web server software can include an ACME client. Certbot is not the only ACME client that can retrieve a certificate from Let's Encrypt or another ACME CA.
Am I really going to do a manual process on every cable modem, WAP, router, printer, switch, AP, IoT device, etc, every 3 months?
No. The manufacturer of "every cable modem, WAP, router, printer, switch, AP, IoT device, etc" will include an ACME client (or some other means of renewing a certificate) in the software package that runs the web server in said device.
The real problem is configuring which domain a device uses, as Let's Encrypt issues only 20 certificates per domain per week under a particular registrable domain based on Mozilla's Public Suffix List. And I'm told it takes months for a dynamic DNS host or other subdomain provider to get onto that list. But if you manufacture hardware devices or publish commercial software, as opposed to gratis software that a user can install on a generic computer, you can do what Plex did: become a reseller for some trusted CA to issue certificates for subdomains of your domain.
The path and query string themselves are enough to infer "people's information". With cleartext HTTP, a passive attacker can infer which medical condition you looked up on Wikipedia or WebMD. With HTTPS, an attacker can see the server's hostname in the Server Name Indication of the ClientHello message, such as en.wikipedia.org or www.webmd.com, but everything else is encrypted.
In addition, even when "people's information" is not "transmitted over the wire", the viewer's ISP can still inject advertisement scripts into a cleartext HTTP connection.
An "enterprise" can afford either A. use of a fully qualified domain name or B. device management to insert the enterprise's own internal root CA as trusted on enterprise-owned devices. I'm more concerned about home users.
It's of course very weird that browsers treat unvalidated https as *worse* than http, in terms of scaring the user.
Cleartext HTTP gives the user a true sense of insecurity, as the scheme portion of the URL doesn't say https. Self-signed HTTPS gives the user a false sense of security, as it increases the chance for MITM to intercept the connection, unless the user has already verified the certificate fingerprint out of band. (It shares this false sense of security with SSH servers that don't publish server key fingerprints elsewhere.) I guess Mozilla considers the sense important to users' privacy and safety.
If the Standard call for a feature to work on Both HTTP and HTTPS, and you implement only HTTPS, then is not an standards compliant implementation...
Nor does an implementation comply if the browser implements it over cleartext HTTP but the standard specifies that it shall not work over cleartext HTTP. A growing number of web standards specify such, citing things like the W3C Candidate Recommendation "Secure Contexts".
Those heavy-handed tactics could work when your market share was about 50%, but not anymore...
That'd be a good comeback if plurality browser Chrome weren't also doing it.
So, if you have a huge compute infrastructure like Google does, SSL isn't much of a problem.
Modern server CPUs contain AES instructions that make TLS bulk encryption efficient. If the computation cost of TLS were a practical problem, you'd be seeing the problem on your client whenever you browse Slashdot, SoylentNews, YouTube, or any other HTTPS site. Any website that's more than a collection of static documents has data storage, application logic, and presentation layers on the server side, and these probably use significantly more CPU time than TLS does.
I run several websites, and not a single one of them needs HTTPS for anything.
How do you assure visitors of the several websites you run that the markup, stylesheets, images, fonts, and possibly scripts on your site have not been modified in transit by an intercepting proxy between your server and the viewer's machine? Comcast, for example, has been shown to inject advertisement scripts into HTML documents delivered through cleartext HTTP.
OMG, a MITM might substitute fake data! How awful!
The only issues was Lan IP addresses and maybe an exception should be made for private IP addresses.
You propose to exempt RFC 1918 private internets from requirements related to "Secure Contexts". If Firefox were to go this route, what logic would it contain to distinguish your home network from a probably less secure coffee shop network?
Yes there is. You need a domain, for instance, and it has to be a fully qualified domain name (FQDN), not something like.local from mDNS or.internal from a private DNS server. For example, what would the FQDN of the configuration page of the router, printer, or NAS on your LAN be? Mozilla acknowledged the difficulty of securing such nameless devices on the LAN in "Deprecating Non-Secure HTTP Frequently Asked Questions":
Q. What about my home router? Or my printer?
The challenge here is not that these machines can't do HTTPS, it's that they're not provisioned with a certificate. A lot of times, this is because the device doesn't have a globally unique name, so it can't be issued a certificate in the same way that a web site can. There is a legitimate need for better technology in this space, and we're talking to some device vendors about how to improve the situation.
It should also be noted, though, that the gradual nature of our plan means that we have some time to work on this. As noted above, everything that works today will continue to work for a while, so we have some time to solve this problem.
But since May 2015, when Mozilla published this FAQ, I haven't seen it endorse a solution.
The indieweb people seem to think every householder ought to buy (and continue to renew) a personal domain from a commercial domain registrar. I guess the owner of such a personal domain could allot subdomains of that domain for devices on his own home network and use the DNS challenge of Let's Encrypt to obtain certificates for these devices. Is this practical for most people?
So you'd rather get a slower device that will completely die unexpectedly (done people would assign blame to other factors like app boat) instead of one that dies under heavy load but can be restarted (as the battery isn't that far gone yet, since it's effects aren't being hidden)
Yes. The former (automatic power save once battery weakens) allows me to dial emergency services or hail a ride until such time as I can schedule a battery replacement. The latter does not.
Tell me why, again, I should ever have a smartphone?
Because netbooks made for* GNU/Linux are no longer sold in major U.S. electronics showroom chains. What's less bad between a smartphone (or Android tablet) and a Windows 10 tablet or laptop?
* "Made for" means shipping with or otherwise warranted to run.
So what? You'd give up banking sites and travel sites with a bone fide revenue model because they're well crafted with javascript?
I myself am not an anti-script hardliner, but I have tried to understand their position that ad-supported sites have poisoned the well. Some members of Slashdot and SoylentNews (at least claim to) choose a bank or a travel provider based on how well the company's website works with script turned off or with only identifiably free scripts turned on. Some of them claim to be willing to fall back to doing business with these companies by mail, over the telephone, or in person, as it was before JavaScript existed.
The featured article doesn't mention nitrogen oxides. But not all research projects can target all noxious pollutants. This one happened to target particulates, ending up with a successful particulate filter with solar thermal powered circulation.
Some people wanted both small and cheap. These people are probably best served with a cheap Android tablet and a folding Bluetooth keyboard. If you want Windows, that's a problem.
Slashdot Mirror
How many "new Firefox features" is a site on a server with such limited resources going to use?
In theory, 1000 subscribers and 4000 view hours per year means 240 view minutes per subscriber per year. That can be satisfied if all your subscribers, say, view one 5-minute video a week.
If you don't want to expose your server to the Internet, you can use Let's Encrypt with an ACME client that supports the DNS challenge instead of the HTTP challenge.
Via Google Search for comcast injecting javascript , I found this, this, this, and this.
If the functionality of your system depends on yet another third party, then it isn't free.
DNS registries and registrars are third parties. What makes a CA any different from DNS in this respect?
The W3C get to define the standards
Is this one?
Safari 3.42%
I thought all browsing on iPod touch, iPhone, and iPad was done through Safari (or through a third-party web browser that wraps Safari's engine). Are these only desktop numbers?
The web browser caches resources delivered through HTTPS the same way as resources delivered through cleartext HTTP. The only thing you lose is being able to cache on an intermediate proxy, but that is relevant if you're splitting one dial-up connection among multiple clients.
Then there is the issue of small timers who want to serve a web page from home, using an old computer and dynamic hostname.
File a support ticket with your dynamic DNS provider to request addition to the Public Suffix List. If a dynamic DNS provider is on the Public Suffix List, Let's Encrypt issues 20 certificates per customer per week instead of 20 per provider per week. The other benefit of being on the PSL is that sites on the same dynamic DNS provider can't see each others' cookies.
Let's Encrypt has short-lived certificates, which are kinda useless and annoying when you have a device that is *not* a general-purpose computer capable of running their scripts.
What is the web server itself running on if not "a general-purpose computer"? If a special-purpose computer locked down to run only particular web server software, this particular web server software can include an ACME client. Certbot is not the only ACME client that can retrieve a certificate from Let's Encrypt or another ACME CA.
Am I really going to do a manual process on every cable modem, WAP, router, printer, switch, AP, IoT device, etc, every 3 months?
No. The manufacturer of "every cable modem, WAP, router, printer, switch, AP, IoT device, etc" will include an ACME client (or some other means of renewing a certificate) in the software package that runs the web server in said device.
The real problem is configuring which domain a device uses, as Let's Encrypt issues only 20 certificates per domain per week under a particular registrable domain based on Mozilla's Public Suffix List. And I'm told it takes months for a dynamic DNS host or other subdomain provider to get onto that list. But if you manufacture hardware devices or publish commercial software, as opposed to gratis software that a user can install on a generic computer, you can do what Plex did: become a reseller for some trusted CA to issue certificates for subdomains of your domain.
The path and query string themselves are enough to infer "people's information". With cleartext HTTP, a passive attacker can infer which medical condition you looked up on Wikipedia or WebMD. With HTTPS, an attacker can see the server's hostname in the Server Name Indication of the ClientHello message, such as en.wikipedia.org or www.webmd.com, but everything else is encrypted.
In addition, even when "people's information" is not "transmitted over the wire", the viewer's ISP can still inject advertisement scripts into a cleartext HTTP connection.
An "enterprise" can afford either A. use of a fully qualified domain name or B. device management to insert the enterprise's own internal root CA as trusted on enterprise-owned devices. I'm more concerned about home users.
It's of course very weird that browsers treat unvalidated https as *worse* than http, in terms of scaring the user.
Cleartext HTTP gives the user a true sense of insecurity, as the scheme portion of the URL doesn't say https. Self-signed HTTPS gives the user a false sense of security, as it increases the chance for MITM to intercept the connection, unless the user has already verified the certificate fingerprint out of band. (It shares this false sense of security with SSH servers that don't publish server key fingerprints elsewhere.) I guess Mozilla considers the sense important to users' privacy and safety.
Can't be Chrome since it is less secure than Firefox, even pre-Quantum.
Since when did Firefox start using OS-level process sandboxing the way Chromium and Google Chrome do?
If the Standard call for a feature to work on Both HTTP and HTTPS, and you implement only HTTPS, then is not an standards compliant implementation...
Nor does an implementation comply if the browser implements it over cleartext HTTP but the standard specifies that it shall not work over cleartext HTTP. A growing number of web standards specify such, citing things like the W3C Candidate Recommendation "Secure Contexts".
Those heavy-handed tactics could work when your market share was about 50%, but not anymore...
That'd be a good comeback if plurality browser Chrome weren't also doing it.
So, if you have a huge compute infrastructure like Google does, SSL isn't much of a problem.
Modern server CPUs contain AES instructions that make TLS bulk encryption efficient. If the computation cost of TLS were a practical problem, you'd be seeing the problem on your client whenever you browse Slashdot, SoylentNews, YouTube, or any other HTTPS site. Any website that's more than a collection of static documents has data storage, application logic, and presentation layers on the server side, and these probably use significantly more CPU time than TLS does.
I run several websites, and not a single one of them needs HTTPS for anything.
How do you assure visitors of the several websites you run that the markup, stylesheets, images, fonts, and possibly scripts on your site have not been modified in transit by an intercepting proxy between your server and the viewer's machine? Comcast, for example, has been shown to inject advertisement scripts into HTML documents delivered through cleartext HTTP.
OMG, a MITM might substitute fake data! How awful!
Thus you answer your own question. It is awful.
The only issues was Lan IP addresses and maybe an exception should be made for private IP addresses.
You propose to exempt RFC 1918 private internets from requirements related to "Secure Contexts". If Firefox were to go this route, what logic would it contain to distinguish your home network from a probably less secure coffee shop network?
Theres no cost any more to getting an TLS cert
Yes there is. You need a domain, for instance, and it has to be a fully qualified domain name (FQDN), not something like .local from mDNS or .internal from a private DNS server. For example, what would the FQDN of the configuration page of the router, printer, or NAS on your LAN be? Mozilla acknowledged the difficulty of securing such nameless devices on the LAN in "Deprecating Non-Secure HTTP Frequently Asked Questions":
But since May 2015, when Mozilla published this FAQ, I haven't seen it endorse a solution.
The indieweb people seem to think every householder ought to buy (and continue to renew) a personal domain from a commercial domain registrar. I guess the owner of such a personal domain could allot subdomains of that domain for devices on his own home network and use the DNS challenge of Let's Encrypt to obtain certificates for these devices. Is this practical for most people?
Yep, I also used to think that having a smartphone was pointless.
Then I got one, installed a console, text editor and compiler and now I can code while on the crapper.
What's the advantage of buying a smartphone and using that on the crapper over buying a laptop made for GNU/Linux and using that on the crapper?
So you'd rather get a slower device that will completely die unexpectedly (done people would assign blame to other factors like app boat) instead of one that dies under heavy load but can be restarted (as the battery isn't that far gone yet, since it's effects aren't being hidden)
Yes. The former (automatic power save once battery weakens) allows me to dial emergency services or hail a ride until such time as I can schedule a battery replacement. The latter does not.
Tell me why, again, I should ever have a smartphone?
Because netbooks made for* GNU/Linux are no longer sold in major U.S. electronics showroom chains. What's less bad between a smartphone (or Android tablet) and a Windows 10 tablet or laptop?
* "Made for" means shipping with or otherwise warranted to run.
So what? You'd give up banking sites and travel sites with a bone fide revenue model because they're well crafted with javascript?
I myself am not an anti-script hardliner, but I have tried to understand their position that ad-supported sites have poisoned the well. Some members of Slashdot and SoylentNews (at least claim to) choose a bank or a travel provider based on how well the company's website works with script turned off or with only identifiably free scripts turned on. Some of them claim to be willing to fall back to doing business with these companies by mail, over the telephone, or in person, as it was before JavaScript existed.
The featured article doesn't mention nitrogen oxides. But not all research projects can target all noxious pollutants. This one happened to target particulates, ending up with a successful particulate filter with solar thermal powered circulation.
Some people wanted both small and cheap. These people are probably best served with a cheap Android tablet and a folding Bluetooth keyboard. If you want Windows, that's a problem.
I don't want Windows, but I do want FCEUX (debugging version) and FamiTracker. Those are free software under the GNU GPL, and I currently run them in Wine, but Wine isn't so practical on ARM. Winelib on Android was "a work-in progress" as of 2014, and the project's page hasn't been updated.
Void the warranty according to a court of law, or according to the manufacturer?
The latter, because of the cost of getting even a small-claims court involved.
Why is the firmware relevant to getting the hardware repaired?
The manufacturer could use non-stock firmware as an excuse not to provide warranty service on non-firmware components of the device.