Firefox 120.0 released
Posted Nov 21, 2023 20:57 UTC (Tue)
by cozzyd (guest, #110972)
[Link] (19 responses)
Posted Nov 21, 2023 21:12 UTC (Tue)
by fraetor (subscriber, #161147)
[Link] (18 responses)
Posted Nov 22, 2023 8:48 UTC (Wed)
by epa (subscriber, #39769)
[Link] (17 responses)
My forlorn hope is that one day, we can do without Javascript-laden banners and popups altogether, and have the browser itself ask the user whether to accept a cookie, as some old-fashioned browsers such as Lynx still do.
Posted Nov 22, 2023 13:32 UTC (Wed)
by iainn (guest, #64312)
[Link] (16 responses)
Yeah, I think this is different from "I don't care about cookies". Personally, I care about cookies: I don't want to be tracked by them. However, nor do I want to be bothered by them, to be cajoled into "consenting" to tracking, by cookie banners full of antipatterns, every time I visit a website.
Until this Firefox feature is rolled out worldwide, there are extensions like Consent-o-matic and Ghostery, which automatically reject all non-essential cookies.
> have the browser itself ask the user whether to accept a cookie, as some old-fashioned browsers such as Lynx still do.
The problem is functionality cookies are actually useful (provided "functionality" isn't misused to mean tracking, which sometimes happens). Accepting or denying individual cookies is way too fine a granularity.
Of course, browsers have a Do Not Track header, but almost all websites ignore it.
Posted Nov 22, 2023 13:51 UTC (Wed)
by pabs (subscriber, #43278)
[Link] (6 responses)
Posted Nov 22, 2023 16:21 UTC (Wed)
by rschroev (subscriber, #4164)
[Link]
Posted Nov 26, 2023 6:56 UTC (Sun)
by rbtree (guest, #129790)
[Link]
I was really prejudiced against it after reading lots of comments mostly made by those who know nothing about it, but now I am not sure if Firefox really is as privacy-preserving and user-caring as it could be.
Posted Dec 2, 2023 1:07 UTC (Sat)
by jschrod (subscriber, #1646)
[Link] (2 responses)
FWIW: I know that such Web application architectures are not necessary. Nevertheless most essential Web sites use them. If you are able to discard them, you're living in an other reality than I do.
Posted Dec 2, 2023 3:45 UTC (Sat)
by pabs (subscriber, #43278)
[Link] (1 responses)
I also wish we didn't have per-site login protocols. Browsers should just have a UI indicator for "site wants you to login", which you click to toggle the login state.
Posted Dec 2, 2023 4:00 UTC (Sat)
by jschrod (subscriber, #1646)
[Link]
Further more, my Usenix account, my ACM account (for access to Digital Library), my ORA account (for whatever Safari is called right now), needs session cookies. Shall I re-authenticate to read the next page of a book that I'm reading in Safari?
I don't even want to consider the large amounts of accounts at Web sites where I buy stuff -- all of them use session cookies. And buying something usually needs more than 5 minutes.
Hey, my Apache Confluence Wiki account uses a session cookie to track my login. And I don't want to be logged out within 5 minutes while I'm writing something there.
As I wrote: I seem to live in a different reality than yours.
Posted Dec 2, 2023 2:43 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link]
Posted Nov 22, 2023 14:13 UTC (Wed)
by epa (subscriber, #39769)
[Link] (8 responses)
Posted Nov 22, 2023 15:14 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link] (5 responses)
Posted Nov 22, 2023 16:43 UTC (Wed)
by excors (subscriber, #95769)
[Link] (3 responses)
But users can't log out, because HTTP authentication doesn't have that concept. And it's hard to rate-limit login attempts, because HTTP doesn't have the concept of logging in either - every request is authenticated independently.
I think you can't have a page that's accessible both anonymously and logged-in, because there's no guarantee the browser will preemptively send the Authorization header on every subsequent request - it might wait for the server to return a 401 (in which case anonymous users would be shown the login dialog box every time).
If you use Basic authentication, the password is sent in the HTTP headers on every request, which increases the risk of e.g. an attacker finding some buggy old PHP script on your domain that will leak the user's password from the headers (which is worse than leaking a temporary session key). If you use Digest authentication you're stuck with MD5 (because that's all Chrome supports), which is broken; plus the server has to store the password as cleartext or minimally hashed (you can't use PBKDF2 etc), which is very bad when the password database gets leaked.
Also, passwords are bad in general - anything that cares about security should be using OTPs, passkeys, etc.
HTTP authentication does not seem like a good solution in any situation. Much better to use a proper login page and a persistent session cookies. (If you really don't like cookies you could design and implement some new mechanism for browsers to store session identifiers and send them in every HTTP request, except that would simply be a cookie by another name, so I see no reason to do that instead of continuing to use cookies.)
Posted Nov 23, 2023 3:41 UTC (Thu)
by alavaliant (subscriber, #104924)
[Link] (2 responses)
From my understanding of the tech. It seems like the browser could list in a menu/dialog somewhere, every domain that a HTTP auth login is active for. And if you select that entry from the menu the browser would clear/forget it's record of the http auth details for that domain. Which would effectively log you out of that site since the next time you load a page at that site no auth details would be available to be sent and you'd be back to being asked for login details again.
so while websites themselves can't offer a way to logout of http auth, the browser would be able to do it if such a feature was added?
Posted Nov 23, 2023 9:09 UTC (Thu)
by excors (subscriber, #95769)
[Link] (1 responses)
I suspect the basic problem is that browsers don't prioritise improving HTTP authentication because sites don't use it, while sites don't use it because browsers provide a poor UI, and because there is already an adequate alternative (forms and cookies). Browser developers prefer to work on improving features that are already widely used, because that'll provide an immediate benefit to their users, or on developing new features aimed at an unaddressed need. E.g. they've put a lot of effort into WebAuthn and passkeys, which are more secure and more convenient than passwords and have a good chance of becoming widely adopted and would be impossible without browser support; but there's no similar incentive to work on HTTP authentication and it will likely remain abandoned.
Posted Nov 23, 2023 10:35 UTC (Thu)
by farnz (subscriber, #17727)
[Link]
Personally, I think the biggest improvement that could be made to HTTP authentication in the browser context is teaching browsers how to treat it as a special form of session cookie. This needs a special form type that tells the browser that it's going to set an authentication cookie, and would then allow the browser to add its own chrome around the process to warn the user that they're logging in.
With the advent of passkeys, where the actual authentication exchange is done by the browser, and the browser's UI handles asking the user for permission, we're going in the right direction; the next step is a browser that can do passkey authentication itself, rather than requiring the site to do it via JavaScript.
Posted Nov 22, 2023 21:19 UTC (Wed)
by docontra (guest, #153758)
[Link]
Posted Nov 23, 2023 14:30 UTC (Thu)
by simon.d (guest, #168021)
[Link]
Posted Nov 23, 2023 16:02 UTC (Thu)
by anselm (subscriber, #2796)
[Link]
A session cookie from the server you're actively logged into isn't a huge problem. It solves the problem of HTTP itself being a stateless protocol with no memory from one request to the next, which HTTP authentication (being part of the stateless protocol) isn't really set up to tackle.
What's annoying is “third-party” cookies from other (advertising) servers which let those servers track you across the various sites you visit.
Posted Nov 21, 2023 21:03 UTC (Tue)
by fraetor (subscriber, #161147)
[Link]
Posted Nov 21, 2023 21:19 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (5 responses)
Posted Nov 22, 2023 2:26 UTC (Wed)
by rsidd (subscriber, #2582)
[Link] (3 responses)
Posted Nov 22, 2023 7:27 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
I'm using https://github.com/black7375/Firefox-UI-Fix to restore sanity to the UI, and it got broken by the update, requiring reinstallation (of the fix).
Dear Firefox, PLEASE, just return the regular tab UI. Like in all other browsers.
Also, it looks like passkeys still don't work :(
Posted Nov 22, 2023 9:18 UTC (Wed)
by rsidd (subscriber, #2582)
[Link] (1 responses)
Oh, the issue is the lack of vertical lines between tabs? The icon is not enough indication of a separator between tabs?
Seriously, I never even noticed that there are no vertical lines. Current tab is highlighted and other tabs are pretty obvious.
Posted Nov 22, 2023 21:24 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Nov 22, 2023 10:53 UTC (Wed)
by turistu (guest, #164830)
[Link]
You can generate such a stylesheet e.g. here (there may be other similar sites, but this is one that came up in a google search and which I have just tested with 120.0 and nightly).
Posted Nov 22, 2023 8:40 UTC (Wed)
by turistu (guest, #164830)
[Link]
Even if their fix is unreliable and incomplete (and doesn't have any regression tests), and they tried to downplay and mischaracterize the bug itself, it's still something to celebrate that it took them only two months to fix it, considering that the average bug fixing time at mozilla is around 35 years.
Posted Nov 22, 2023 9:37 UTC (Wed)
by lamikr (guest, #2289)
[Link] (1 responses)
Another service which refuses to work for me on Linux is the NBA gamepass that is implemented on top of the microsoft azure, it complaints both with the firefox and chrome from the missing DRM support. NFL gamepass developers seems to be more capable and have better implemented services as NFL gamepass works just fine on Linux browsers.
Posted Nov 22, 2023 15:34 UTC (Wed)
by rnestler (subscriber, #160299)
[Link]
Have you tried just overriding the user agent to the value that chrome sends?
Posted Nov 22, 2023 10:19 UTC (Wed)
by aragilar (subscriber, #122569)
[Link]
Firefox 120.0 released
Firefox 120.0 released
Firefox 120.0 released
Firefox 120.0 released
Firefox 120.0 released
Firefox 120.0 released
Firefox 120.0 released
Firefox 120.0 released
Firefox 120.0 released
Firefox 120.0 released
Firefox 120.0 released
Firefox 120.0 released
Firefox 120.0 released
Firefox 120.0 released
Firefox 120.0 released
Firefox 120.0 released
Firefox 120.0 released
Firefox 120.0 released
Firefox 120.0 released
Firefox 120.0 released
Even LWN sins in this regard. The login is done using cookies.
Firefox 120.0 released
Firefox 120.0 released
Firefox 120.0 released
Firefox 120.0 released
Firefox 120.0 released
Firefox 120.0 released
You can fix those floating tabs by setting Firefox 120.0 released
toolkit.legacyUserProfileCustomizations.stylesheets to true in about:config and then tweaking the appearance via a chrome/userChrome.css stylesheet inside the profile directory.
This version also doesn't let any random page from a background tab pastejack you anymore, see CVE-2023-6208.
background pastejack fix
Firefox 120.0 released
I first tried with 115 version and got message that the browser is too old and is not supported.
Then I downloaded the 120.0 version but received the same message. With chrome, the amazon music works just fine.
Firefox 120.0 released
> I first tried with 115 version and got message that the browser is too old and is not supported.
> Then I downloaded the 120.0 version but received the same message. With chrome, the amazon music works just fine.
Firefox 120.0 released