Mozilla Restricts All New Firefox Features To HTTPS Only (bleepingcomputer.com)
An anonymous reader shares a report: In a groundbreaking statement earlier this week, Mozilla announced that all web-based features that will ship with Firefox in the future must be served on over a secure HTTPS connection (a "secure context"). "Effective immediately, all new features that are web-exposed are to be restricted to secure contexts," said Anne van Kesteren, a Mozilla engineer and author of several open web standards. This means that if Firefox will add support for a new standard/feature starting tomorrow, if that standard/feature carries out communications between the browser and an external server, those communications must be carried out via HTTPS or the standard/feature will not work in Firefox. The decision does not affect already existing standards/features, but Mozilla hopes all Firefox features "will be considered on a case-by-case basis," and will slowly move to secure contexts (HTTPS) exclusively in the future.
...and this might be the one thing that gets me off the Firefox bandwagon as it is an incredibly backwards move. TONS of stuff does NOT need https and does not need the overhead HTTPS incurs both in processing time and certificate management. Also, do I really need HTTPS for stuff on my trusted LAN? No? So now I have to jump through hoops to enable developer mode? Just... what are they thinking? What is the recommended fork of Firefox these days? Pale Moon?
STOP POSTING WITH YOUR IPHONE
As opposed to what, exactly? Chrome, which almost certainly has as much Google spyware baked into it as a Huiwei-made smartphone? Miscreant-o-soft 'Edge', and it's associated 'telemetry' (read as: spyware)? Any of the fringe browsers, which are likely to be garbage and full of malware, too? Firefox is just as likely to be the cleanest in that regard.
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...
Come on Mozilla Foundation! Those heavy-handed tactics could work when your market share was about 50%, but not anymore...
JM2C, YMMV
*** Suerte a todos y Feliz dia!
Then we can talk.
Rolling out DNSSEC without first addressing DNS amplification is dangerous and irresponsible.
Last month bitcoin was the new fad. These silicon valley types must have been drinking too much Raw Water(TM) picked up some brain parasites.
Very little needs to be encrypted or authenticated. Not everything that needs to be encrypted when going through the open internet needs to be encrypted or authenticated when happening on a closed LAN. Encryption isn't for free. SSL certificate management isn't for free. When stepping away from the half of web browser use that happens on the open internet and into the other half that happens on closed networks, it is wasted effort for no benefit.
Not all content requires people's information to be transmitted over the wire.
"Not to mention all the idiots who use words like boxen."
Anonymous Coward on Monday August 04, @06:49PM
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.
We need to know so we can all switch to it.
Lynx's security is second to none.
He's getting rather old, but he's a good mouse.
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.
Am I really going to do a manual process on every cable modem, WAP, router, printer, switch, AP, IoT device, etc, every 3 months?
The "local network devices" problem is a real problem, and its never given proper attention in these HTTPS proclamations.
I "solved" it for myself by setting up a local CA to make certs for my stuff. Unfortunately, getting the cert for that CA into all my browsers is annoying, and can introduce its own share of issues.
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.
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?
Yes. It was originally Norwegian, but was sold to "Golden Brick Capital Private Equity Fund I Limited Partnership" for $600M at the end of 2016.
He's getting rather old, but he's a good mouse.
Mozilla developers like Anne know more about browser development than you do.
In Gecko, restricting new DOM APIs to secure contexts is simply a matter of adding an attribute to the WebIDL:
https://github.com/mozilla/gec...
Probably something similar will be added to the CSS property list.
There is also a single method you can call on the internal interface of a 'window' object to determine if you're in a secure context.
https://dxr.mozilla.org/mozill...
Selective disabling of new features is already standard practice. New features are almost always guarded by hidden preferences so they can be safely disabled just before release if a showstopper bug turns up, or so that they can be incrementally worked on over multiple releases without being shipped in a half-done state.
There's very little extra work required here.