Live data from Hacker News

Firefox 84.0

mozilla.org

141–150 of 328 posts

Re: Firefox 84.0

#141
post #126
post #9

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.

[deleted]

Re: Firefox 84.0

#142

Earlier 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...

IIRC fennec (from fdroid) is going to allow all add ons too.

Re: Firefox 84.0

#143
post #71

Earlier 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.

Your best options are:

* Use Firefox; * Consider Pocket Premium; * Subscribe to Mozilla VPN.

Re: Firefox 84.0

#144
post #107

Earlier 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…

> 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.

Re: Firefox 84.0

#145
post #30

On 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.

Have you tried the "To Google Translate" Firefox add-on? It's not as seamless as Chrome's built-in translation but it works for me.

https://addons.mozilla.org/firefox/addon/to-google-translate...

Re: Firefox 84.0

#146

Huge 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…

Firefox ARM64 gang woohoo! Been running FF on my pinebook pro for over a year now. Certainly not as speedy as apple silicon, though.

Re: Firefox 84.0

#147

Earlier 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.

Me too. Waiting for the current branch to properly support extensions, or for an Android Chrome fork to support the extensions I use.

Re: Firefox 84.0

#148

Earlier 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...

Neat! I had no idea. Thanks for sharing!

Re: Firefox 84.0

#149
post #107

Earlier 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.

CORS solves much of this - servers have to opt in to allowing these requests, just like any other cross-origin requests. Badwebsite.com in general cannot send a POST to bank.com/send-money from inside your browser, and similarly it cannot POST to localhost:631.

There's caveats and of course servers can be configured insecurely, but this isn't a general risk by default.

Re: Firefox 84.0

#150
post #107

Earlier 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…

Yes, it's possible localhost servers can have security issues, but:

* 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.

Post reply on HN