I really wish Mozilla would focus relentlessly on a privacy-first, performant browser across major platforms. Nothing else. I don’t want extensions (attack vector), vpns, fancy bookmarking services that are deprecated later on etc. I want to browse the web safely and privately and preserve battery life - nothing more.
I wouldn't want a browser without extensions. Ad blocking in particular.
To me, ad blocking belongs in extensions. The job of a web browser is to show web pages as intended according to the standards. It includes all the ads, tracking, etc... the page has put in. If you want to block stuff or deviate from the standards in any way, that's what extensions are for.
And extension like ad blocking are an arms race, websites will deploy countermeasures to make them less effective and to which extensions can respond. Again I dont want the core browser to participate in an arms race. Keeping it free of vulnerabilities is already hard enough not to fight against standard behavior.
Extensions are the primary threat to your security today. Nothing else comes close. Organizations are not basically competent if they are not restricting or blocking extensions, and you should not have more than one to three very trusted extensions in your browser. I'd argue the case for eliminating them in favor of in house code is significant.
As a reminder: Extensions execute with post-decryption access to the websites you view, and they update to new code silently and without asking for permission. HTTPS might as well not bother existing if you have extensions you do not have incredible trust in.
I would argue that building in extension-like features inside the browser is worse. In both cases, that's extra code, with security implications, but in case of extensions, you can choose not to have it.
Now, that's a question of whether you trust those who write the browser more than those who write the extension.
And by the way, the argument you have is the same that justifies the much hated "manifestV3", which makes extensions less powerful for security reasons. But it also limits the blocking capabilities of browsers to a simple, less effective blacklist. That Firefox still supports the old "insecure" way is a big selling point over Chrome.
We obviously know Chrome team is not doing things for security reasons, they are doing things for ad revenue reasons. But it's also true that blocking ads requires an insane amount of trust: The uBlock Origin author can choose to read your bank account numbers and passwords. (Although he is high profile enough this would be caught quite quickly.)
Arguably the problem is that Manifest V3 proposed removing an ad blocking capability without replacement, whereas I would argue just as popup blocking was a couple decades ago, it belongs as a first class browser feature, not outsourcing extremely sensitive capabilities to random outside parties. Browsers should not be operated by (or funded by.........) ad networks, and should built high quality, secure tools to filter unwanted content from their users.
This is incredibly untrue. Many extensions can see and modify everything you see on any other site. Installing a browser extension is best described as installing a rootkit in your browser.
If I couldn't use the ublock origin extension with Firefox, I'd leave for another browser. I consider it essential for privacy reasons as well as for adblocking, and I can't imagine it hurts battery life compared to all the ads and other crap it blocks.
Firefox's VPN service also has its privacy-related uses (yes, I'm aware of the limitations), but I think it mostly serves as a possible source of non-google revenue for Mozilla.
Extensions were why Firefox was so popular among those considered 'abnormal.' Chrome just copied the idea. VPNs, Pocket, and sync services are all great features; it's their implementation and execution that is so poor.
All Mozilla (and Firefox) needs is to be run by developers, not the fucking MBAs.
> focus relentlessly on a privacy-first, performant browser across major platforms. Nothing else. [...] to browse the web safely and privately and preserve battery life - nothing more.
"Nothing more," you say.
The chief focus should be Privacy... Privacy and Performance... Our two chief focuses should be Privacy and Performance... and Cross-Platform Executables with Functional Parity... Our three chief focuses should be Privacy, Performance, Cross-Platform Executables with Functional Parity, and Safety on the Web... Our four chief focuses should be Privacy, Performance, Cross-Platform Executables with Functional Parity, Safety on the Web, and ruthless Efficiency in Preserving Battery Life... Our five... no... Amongst our chief focuses... Amongst our non-trivial chief focuses that users think are easy... are such elements as Privacy, Safety on the Web, Cross-Platform Executables with Functional Parity... I'll come in again.
How do you expect Mozilla to make enough money from just Firefox to survive if Google ever decides to stop paying them for being the default search engine?
Seeing as google keeps paying them more and more even as they shift away from improving the browser, you have to reevaluate what they are really being paid for.
Charge me. I’ll pay. I’m not going to donate to the org right now as I don’t use Firefox as it uses (noticeably) too much battery on my MacBook compared to safari and chrome.
Notably, also, it's not currently possible to donate to Firefox; you can only give Mozilla money to use on unrelated projects. As a Firefox user, the inability to pay for the thing I actually want is grating.
I've not seen anyone discuss yet what kind of impact these AI features are likely to have on battery life. If they are running small on-device models, this will have a measurable impact on battery life with regular usage.
I've worked on projects in the airline and health industry which are highly regulated too. The regulations can be incredibly difficult to process and implement, and make sure you adhere to everything correctly. I've been involved in multiple scenarios where people have made false assertions about compliance or lack of. I'd still place a bet that the SOA models make _far_ less mistakes than humans.
They might make fewer mistakes, but they aren't evenly distributed. They don't use logic when making mistakes, it is gaps in the training data and now large of a span they have to bridge in the latent space. Just as they aren't smart like humans, they aren't stupid like humans. Don't mistake rate for quality.
Yeah, this starts to overlap with some autonomous vehicle stuff, where I like to say that the rate of errors is not the shape or distribution of errors.
We have long historical experience and innate tools for detecting and mitigating errors made by humans. If we can't apply those to automation, then even fewer total mistakes may end up being a worse outcome.
>I'd still place a bet that the SOA models make _far_ less mistakes than humans.
Genuine question: your top coder seems to be producing the most error-free code from your perspective, has the deepest knowledge of the architecture and codebase, and is faster on the trigger than the others.
But your top coder has proven and verifiable dementia, where they will confidently assume the existence of apis and code that do not exist, mix up the purpose of others and forget other things, and you can't predict when and how they will introduce errors into the system or the severity of such errors.
Are you really comfortable letting this person with dementia generate most of your codebase in the airline and health industry?
I also hope you have an iron-clad agreement that prevents the model provider from doing silent updates because all your evidence of correctness you collected thus far goes out the window in that case.
Another genuine question:
You have witnessed a human coder and the AI you're using make the same important mistake. Assuming you do not have the time and resources to retrain, fine tume, and test your frontier model:
Who would you trust not to make the same mistake multiple times in the future after you have warned them that their job depends on it, the AI or the human?
Your top coder has guard rails in place to prevent him autonomously going free - right? This is how you should approach agentic development with LLMs. Like it or not, we are the final bastion, the gatekeepers. The hallucination thing I think is mostly overblown and from speaking to colleagues it seems to vary wildly depending on which model and harness you are using - always go for SOA. In the last 3 months I can count on one hand where it's done something wrong and that's primarily as I'm operating it with guard rails and giving it context.
>Your top coder has guard rails in place to prevent him autonomously going free - right?
The parent is implying they would prefer an AI when working in the airline and health industry because it makes less errors. Read the comment again.
They have not said, "Hey, I work in the airline and health industry and I'd love to use AI for a couple of the bullshit IT UIs we have as long as we can put guardrails on the AI to stay in its lane."
I asked a yes or no question. The guardrails you can put to mitigate errors are the same guardrails pre-AI for the humans (tests, regressions, reviews). If you were wary of employing a top lead engineer with verifiable dementia prior to AI for a mission critical system, logic implies you should think twice giving that much responsibility to an AI as well.
> The hallucination thing I think is mostly overblown
Can you predict when and how the SOTA model will hallucinate? Yes or no. Can you predict the severity impact of that error beforehand? Yes or no.
>from speaking to colleagues it seems to vary wildly depending on which model and harness you are using
You have partially answered my question it would seem.
> Can you predict when and how the SOTA model will hallucinate? Yes or no. Can you predict the severity impact of that error beforehand? Yes or no.
No, but the same can be said for your colleagues. You might call what the LLM does hallucinations, I'd call them mistakes. I think we have totally forgotten that humans make them all the time and are confidently wrong too.
Your original question, doesn't really get to the bottom of the point I'm trying to make, and I don't really feel it fairly represents the issue we are talking about here. They are not the same things.
This is such a tired, meaningless argument. I've never seen a human in 10 years of professional software engineering at a large company ever so confidently, consistently create and send out seemingly well-reasoned code that's as wrong as what SOTA models using CC or Codex do. If a human did this, they would be fired or perpetually remain a junior who no one wants to work with.
Also, if a human does this, you can replace them and get a human who will not do it. The default for an LLM is to generate plausible-looking text that may or may not be completely incoherent. That is not the default for a human. Again, if you find that your colleague consistently fabricates APIs, you can hire someone who isn't crazy instead, but you cannot do the same with LLMs.
If a human was hallucinating and polluting a codebase with errors, they would be fired and possibly treated for dementia. Even worse, an LLM is trained to produce plausible-looking results, so it's harder to detect the mistakes.
>No, but the same can be said for your colleagues.
That's absolutely false. My collegues don't routinely and confidently invent apis that are not there, or spectacularly and repeatedly misunderstand the purpose of certain functions or exhibit extreme forgetfullness. Especially when I've warned them. Hallucinations and confabulations in otherwise healthy individuals are mental disorders. When I ask them why they made an certain kind of error, I can expect to get a reasonable answer. No one has uttered the phrase "Bob hallucinated again while writing those tests" when the Bob in question is a human.
Well, your experience doesn't align with mine. I have been using, and in part of an organisation that is extensively using, Claude with Opus for everything for about 3 months now and I am not experiencing the problems you describe. We'll have to agree to disagree here.
That is fine. "Your experience may vary" is the crux of my argument amusingly. You can't have just realized that people are having different experiences using AI, or even that the same person has different experiences when they change domains or technical contexts. There's been lots of comments littered on this forum to that effect.
Calling hallucinations simply mistakes does not seem to me to be a healthy way to reason about LLMs. I can ask a collegue how well they can program in Ada and adjust my expectations on productivity and bug rates. I can't ask an LLM how well they can code in Ada (just a throwaway example), or even how much of Ada was in its training data. I have to actually spend money and spend time code reviewing before I can even formulate any expectations at all.
Not only have I never ran across a hallucination in the past ~6 months or so; the latest Opus models have gotten to the point where they can emit inline assembly that is _superior_ to what gcc or clang can generate from optimized cpp. Had it rewrite a hot simd loop that took it from ~10 flops/cyc to ~14 by shaving off broadcasts. I _could not_ get any compiler to do this, no matter which flags I tried to use. So I literally have no idea what these people are talking about when they claim that SOA models hallucinate constantly.
Last week, Opus gave me a decrement instead of an increment, on one particular line. Where I already had the decrement, but it was changing the width of the datatype everywhere.
And it took "convincing" that it had made a mistake.
For some reason, tons of people seem to be in camps at both extremes. It's either "AI sucks don't trust it!" or "AI is so much better than humans!"
But the most reasonable take, which I'm happy to see reflected in so many comments in this thread, is… use both.
Do an AI pass, and have humans verify, and vice versa. Let the humans drive the AI. Then the unique shortcomings of each party can be covered by the other's strengths.
AI review is never going to beat a fully resourced human review.
It might beat an underresourced human review, on time, efficiency, cost metrics. But on the metric of accuracy, throwing unlimited humans at a problem will still beat throwing unlimited AI at it
That's an irrelevant comparison because cost is always a constraint, so there are not going to be unlimited AI or humans. The question is how to optimally combine them for a given cost.
> Do an AI pass, and have humans verify, and vice versa. Let the humans drive the AI.
You can do that, sure. But doing so negates any improvements in speed the LLM brought. And at that point, you may as well just do it yourself to begin with.
When Google showed up on the scene I found I no longer needed to memorize basic syntax and other such things. If I couldn't remember on the fly, i'd just do a quick google search and move on. This freed space in my mind to instead focus on bigger & better things.
I use GenAI tools when coding a lot, but I do not vibe code. I go through everything it generated, and we iterate. And yes, it doesn't save me a lot of time. But what it does do is free up mental capacity in a similar manner. But instead of syntax, it's more complicated patterns. Maybe I don't remember how to stitch something together, but i know it can be done. Instead of spending the time to look it up and then code it, I just tell it to do it for me.
> Maybe I don't remember how to stitch something together, but i know it can be done.
That's how I use the current AI, too. I never ask them to do something without specifying how it should be done. I ask questions first, use /plan to let the model ask me questions, then I let it execute the plan while reviewing the results. More and more often, I get something close enough to what I would have written. In the opposite case, I at least know exactly how to rewrite the result, if needed.
I observe the same effect as you: while it does sometimes speed up the implementation a bit, it's not very noticeable; however, it frees me from having to recall all the obscure little details up front. Instead, I can describe them, have the model implement them, and then recognize them (and refresh my memory) when reviewing. The effect is that it's easier to start a task because I don't need to prepare as much to execute it. It's especially notable on things that I haven't touched for some time. I know, more or less, how my Elixir projects are set up, but after ~2 years of not working on them, getting back into them had been a hassle - with AI, it's no longer that. I think the biggest difference comes from the AI lowering the cost of context switching for me - I used to have huge problems with that, and AI certainly helped a lot.
Yeah, humans reviewing the AI review can only detect the false positives, where the LLM claims something is non-compliant and flags it for review/correction by a human or another agent. Human review can’t find the false negatives (true deficiencies not flagged) unless you do a full audit yourself to find whatever deficiencies the AI missed.
This is commonly known as "LLM-as-a-judge" and anecdotally multiple people I know who write code using OpenRouter or using multiple models say it's surprisingly effective. It's strange that there don't appear to be any major papers on it since ~early 2025, which at this point is basically ancient history.
It's not just about it taking the technical competence away from our job, it's taken away the joy [1] which I wrote about.
I feel like many of my peers are beating around the bush on this topic and in denial. Even if you accept it can do a large portion of the technical part of our work, we are just supervisors at this point making sure it doesn't do any stupid shit. What is the point? Where is the fun in this? Where is the challenge? At least I have enjoyed building my career over the last 20+ years and building software, but find little joy in the work I'm doing now.
I think we're going to see a massive exodus of folks leaving the profession and a huge mental health crisis, long before the folks working in other sectors realise what's hit them.
I don't see the problem here. It's a great product and if they want to make money then I don't mind. If it's too expensive, and they hike the price to something ridiculous then I'll vote with my wallet.
I’m fine with paying a bit more. I honestly don’t think I even use any of the premium features. I started paying because their founder answered some question I sent years ago and I figured that kinds of support deserved my support. I could still be on the free tier if cost were a concern.
With that said, I do find the direction here concerning. Quietly rewriting values, removing promise of free tier, hiking prices with almost no notice. I’m concerned that this feels sudden and sneaky. Sneaky behavior erodes trust.
Management and leadership values, character, and integrity matter because it's unwise to assume there is some homogenous allegiance to customers behind the propaganda of putting the customer first. PE will and must squeeze for their margins as is their wont. They have learned it's unwise to draw attention to this.
I'm in the same boat, became a premium member to support Bitwarden and use the built-in authenticator. The subscription price is now a negative proposition, alongside the silent rollout and the other red flags raised in the post. I'll probably move to self-hosted, since I have spare compute on my VPS.
I am fine with the price increase, for me its how sneaky they're being about everything. If they sent a few emails about the recent changes I wouldn't care, but it feels like they do not want customers to know which is the last thing I want from a password manager.
Indeed. As I'm sure the new PE-focused CEO knows, the sale of a company includes not just the typical balance sheet items but also intangible assets such as goodwill. Being sneaky about is an attempt to minimize the loss of such intangibles ahead of a sale.
The problem is the rug-pull. You can't go and proudly state "free forever", and then silently back down on that commitment. That is a textbook example for the enshittification cycle... lure users in with grand promises, sell out once you got enough of a following.
(Well, technically, you can, but then don't complain about getting called out)
You must be getting a different version of that page than me. The free tier is there but there’s no “always free” verbiage. There is “start free” verbiage.
Edit: “always free” was hidden under a collapsed section
LOL.. you are correct. Funny thing though... the 'Always Free' text is linked to a "/start-free/" action\page. One could argue that they are hedging their bets.
Some other commenter says there are Archive.org cached versions with "Start free" instead of "Always free", so they must have backpedaled on this. Maybe they realized they turned the knob a bit too much towards "hot", increasing the temperature of the proverbial water too noticeably.
I’m not willing to check all the pages on archive.org but for sure a month ago they had a big “Basic Free” tile in the plan comparison. Now it’s just Premium and Family. They are definitely downplaying the ability to use it for free.
Seems like they want to downplay the mentally that you would never benefit from an upsell to the paid plans, even if the free plan itself stays always free
Let them cook. Anything that they can do to get rid of the absolute hell that is dependencies in the JS ecosystem is worthwhile. I really don't care what they add as long as it's maintained
Usually on the discover weekly playlists. It started with hip hop jazz remakes about a year ago, presumably as I like hip hop, have engaged with genuine hip hop jazz covers before and these were going viral at the time.
I hate to think what else might have surfaced on these generated playlists (which for me are the #1 selling point and reason I have stayed with Spotify), that I haven't noticed yet is AI.
I'm always wondering how long it will take for popular sentiment to finally shift. So many years of things like Blinky the fish in the Simpsons really did a number on our shared consciousness.
I think the series of actual nuclear disasters from the 1950s to 2000s - plus the fear of a hot nuclear war in the ‘70s - had more impact on the collective consciousness than The Simpsons.
reply