And for developers: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Rel... The biggest change from my perspective is "Firefox now ensures that localhost URLs — such as http://localhost/ and http://dev.localhost/ — refer to the local host's loopback interface (e.g. http://127.0.0.1 ). As a result, resources loaded from localhost are now assumed to have been delivered securely (see Secure contexts), and also w…
So, does that mean things like WebCrypto (which requires https to be available) will work in development environment now? Or did they already work out of box? I never tried because I assumed they won't work.
Firefox 84.0
141–150 of 328 posts
Re: Firefox 84.0
#142Earlier quoted context omitted.
They've completely redesigned it about a year ago, making it much faster, but losing add-on compatibility. So pretty much the same thing that happened to desktops on v57, except a bit worse: only 17 add-ons are currently available in nightly. Still more than what's available on Chrome and Safari on mobile, so it always remained my browser of choice on a phone.
You can install any add-on from addons.mozilla.org in Firefox Nightly for Android: https://blog.mozilla.org/addons/2020/09/29/expanded-extensio...
Re: Firefox 84.0
#143Earlier quoted context omitted.
When you donate to Mozilla the money doesn’t go to the betterment of the Firefox browser.
Correct. I wish a fund were created for Firefox, like the one for Thunderbird. I'd love to give towards Firefox but have no desire to fund Mozilla mismanagement.
* Use Firefox; * Consider Pocket Premium; * Subscribe to Mozilla VPN.
Re: Firefox 84.0
#144Earlier quoted context omitted.
>This is great for local development. Not just. There is a niche for mixed web/native apps whereby the page is loaded from the web, but interacts (at least in part) with a locally hosted web-server.
I think it's a problem from a security point of view to allow websites to do this. Often the server that runs on localhost is poorly secured and may even expose "Access-Control-Allow-Origin: *" headers. And even if it doesn't, the browser still has to run a request to find out whether such a header is present, so some attacker controlled data does end up in these services. This in turn can be used for attacks. Maybe…
A typical Linux installation can run much more web servers on localhost. I run transmission-daemon, syncthing, cups, sometimes pagico (which is a desktop app which runs a php/web server backend on loopback).
I guess that Firefox folks have thought of this otherwise, it'd be patched pretty quickly.
Re: Firefox 84.0
#145On my new work laptop, I installed Firefox first and haven't touched Google Chrome. I've been happy with this and it was finally what made me move off Chrome.
The only reason I use Chrome these days is for built in translation. Apart from that it's always FF.
https://addons.mozilla.org/firefox/addon/to-google-translate...
Re: Firefox 84.0
#146Huge update for users on new Apple Silicon Macs: > Native support for macOS devices built with Apple Silicon CPUs brings dramatic performance improvements over the non-native build that was shipped in Firefox 83: Firefox launches over 2.5 times faster and web apps are now twice as responsive You will need to do a browser reboot after updating to get the ARM64 version instead of the Rosetta version[1] [1] https://supp…
Re: Firefox 84.0
#147Earlier quoted context omitted.
What's the drama on Android? It's been working great for me for years now.
Same but I've disabled its updates since like a year.
Re: Firefox 84.0
#148Earlier quoted context omitted.
They've completely redesigned it about a year ago, making it much faster, but losing add-on compatibility. So pretty much the same thing that happened to desktops on v57, except a bit worse: only 17 add-ons are currently available in nightly. Still more than what's available on Chrome and Safari on mobile, so it always remained my browser of choice on a phone.
You can install any add-on from addons.mozilla.org in Firefox Nightly for Android: https://blog.mozilla.org/addons/2020/09/29/expanded-extensio...
Re: Firefox 84.0
#149Earlier quoted context omitted.
I think it's a problem from a security point of view to allow websites to do this. Often the server that runs on localhost is poorly secured and may even expose "Access-Control-Allow-Origin: *" headers. And even if it doesn't, the browser still has to run a request to find out whether such a header is present, so some attacker controlled data does end up in these services. This in turn can be used for attacks. Maybe…
> For example did you know that cups runs a web server at http://localhost:631 A typical Linux installation can run much more web servers on localhost. I run transmission-daemon, syncthing, cups, sometimes pagico (which is a desktop app which runs a php/web server backend on loopback). I guess that Firefox folks have thought of this otherwise, it'd be patched pretty quickly.
There's caveats and of course servers can be configured insecurely, but this isn't a general risk by default.
Re: Firefox 84.0
#150Earlier quoted context omitted.
>This is great for local development. Not just. There is a niche for mixed web/native apps whereby the page is loaded from the web, but interacts (at least in part) with a locally hosted web-server.
I think it's a problem from a security point of view to allow websites to do this. Often the server that runs on localhost is poorly secured and may even expose "Access-Control-Allow-Origin: *" headers. And even if it doesn't, the browser still has to run a request to find out whether such a header is present, so some attacker controlled data does end up in these services. This in turn can be used for attacks. Maybe…
* This only affects servers that do indeed serve the "anybody can talk to me" CORS headers. For anything else, standard cross-origin restrictions apply. A simple localhost server that has ignored this issue and isn't aware of CORS at all is generally not vulnerable.
* This change doesn't actually increase this risk, it decreases it! Localhost requests from pages were already allowed, CORS notwithstanding, it was just not possible from HTTPS sites as it was mixed content.
* This is a pretty common pattern for lots of popular software that has a desktop component - e.g. Spotify, Zoom - so there's a clear use case for it.
* There's ongoing work to restrict this further, see https://web.dev/cors-rfc1918-feedback/, proposed by the Chrome team. In short, HTTPS will be required, and a new `Access-Control-Request-Private-Network: true` header will be sent (and an `Access-Control-Allow-Private-Network: true` response required) to force servers to opt in to any requests that cross from public origins to private ones.