> The OP seems unaware that Claude had a lead in this space
I remember using GitHub Copilot (OpenAI "Codex" mk1) in Aug 2021 (ChatGPT would launch a year later 2 weeks after Meta's botched Galactica release). Cursor & others took it and ran a mighty good race.
Okay so regardless of the model, platforms provide attestation from end to end that nothing is being logged from either input or output, including at the firmware and OS level to the extent that the customers have proof of the data never being saved. AFAIK, both GPUs and TPUs support this.
Friends and family who are largely non-technical have referred to ChatGPT as Chat for at least a year.
I admit I was struck when I first heard someone use that shorthand in conversation at a party. It was the moment I knew that for better or worse LLMs use had permeated deep into regular life.
How? OpenAI and Antrophic are basically the Big 2 racing away at light speed; the others who can't get near them are perhaps shaky & vulnerable. And sure, there's a garden full of those.
Because the market almost certainly can’t support two foundation model labs given the increasingly little difference across models and the massive sums of cash required to keep it all going. There is no big 2, just a race to survive and be the big 1.
It probably can't support any because there's no moat and smaller, open source models are catching up. This is like investing $1T into mainframe computers in 1980.
There's at least two markets here. Consumer ad driven and worker augmentation markets. Likely a 3rd as a backend infrastructure provider to a bunch of value add companies.
I think Google has caught up enough to certainly be a player in the consumer ad driven market.
I also don't think only one foundation model adds up. Now that the trail is blazed a dozen companies can likely make a good enough model. The question is if there's a moat to make it winner take all
Google needs to catch up on what? Devs mindshare? The latest Opus 4.8 carefully selected benchmarks made sure to pick Gemini 3.1 Pro and not Gemini 3.5 Flash: 3.5 Flash is beating Opus 4.8 on several of the benchmarks Anthropic posted but simply was ignored.
I don't think SOTA-wise Google has a lot of catch up to do.
Gemini 3.5 Flash is not good at coding in practice. Gemini 3.1 Pro too, in particular is known to be bad at tool calls. Many companies would love to have alternatives to Claude Code (as it's a significant risk to depend on one vendor), so far most of the buzz is about moving to Codex but much fewer talk about moving to Gemini. All these benchmarks are not very informative, the Chinese labs do better on these benchmarks than in practice, for example.
Yeah it's very murky, but if they're arguably profitable under some definition of profitable, then it's ridiculous to claim there's "no path to profitability"
Especially if you assume that 6 months ago they weren't very close to this version of profitable
In terms of personal assistant AI the monopolists have a massive advantage because they control the platforms and can box out competitors from deeply integrating with the OS.
Data. Google has access to unphasmable amount of real human-created data with zero expectations of privacy (wink wink Apple): videos, photos, search, navigation, mobile app usage including competition platforms, emails, etc.
Both Anthropic and OpenAI only has access to whatever they can buy or steal.
And it's becoming increasingly hard to get fresh uncontaminated data for training. No amount of money can buy that.
> Both Anthropic and OpenAI only has access to whatever they can buy or steal.
A trillion can buy you quite a lot! Like offer some company a ton of money for data, and if they say no simply buy said company. Bonus points if it's someone like Atlassian who's stock price is getting hammered largely because of you.
By other indians. And indian military use malayalam to communicate, so that enemies cannot intercept. There was a report that chinese started learning south indian languages. Most movies use neutral phonetics (written language) where as spoken language is tough to understand and have many regional vriations.
Other users have provided the link, but my heart sinks a little every time I see this brought up, especially when the commenter is singled out by name. People forget that this is a real person. He also happens to be a great HN contributor, and has been for many years.
I realize it's internet fun to point neon arrows at people seeming outrageously wrong in the past, but the truth is that people aren't reading that comment accurately and there's a huge dose of hindsight fallacy here.
When BrandonM wrote "I have a few qualms with this app", he didn't mean the software. He meant their YC application. (Note the title of Drew's post: "My YC App"). He wasn't being a petty nitpicker—he was earnestly trying to help, and you can see in how sweetly he replied to Drew there that he genuinely wanted them to succeed. We should be so lucky for all responses to "crazy new ideas" to be that decent. This community would be healthier, and actually the current thread is a standout example of how far from true it is.
The criticisms he was raising turned out to be a non-issue in hindsight, but were on point in 2007, when the idea of file synchronization was widely derided as a solution-in-search-of-a-problem which only technical users would ever care about, users who (as the comment pointed out) could already roll their own solutions. The idea had recently been publicly mocked in a famous blog post*, so it was on people's minds as the prime example of an idea only technical users would ever care about—and even YC funded Dropbox because they believed in Drew, not the idea.
* described at https://news.ycombinator.com/item?id=23229275
Relatedly, people tend to forget that people who are fully aware that a real person has written a foolish and/or shortsighted comment will direct criticism at said comment. I understand that there exist people who -to oversimplify- have as their creed "Thou shall not directly say anything negative about anyone ever."... but that's a minority of people. That "soft pedal" stuff doesn't work for a notable subset of people, and -for some- generates _way_ more anxiety and stress than a frank and earnest discussion about just how stupid the stupid thing you just did is. [0]
I get that some folks are Care Bears (affectionate, non-derogatory), but not only is that not the only way to be, folks who are like that freak out a not-insignificant subset of the population.
> When BrandonM wrote "I have a few qualms with this app", he didn't mean the software.
Perhaps. But it looks to me like an eighth or so of the top-level commenters on the OP are talking as if the thing under discussion is application software. Maybe folks consistently abbreviated "YCombinator Funding Application" as "App" and "application software" as "application" at the time, but -if so- that's not made clear to me by reading the commentary.
[0] I'd also object to any characterization that BrandonM's commentary is nitpicking in any regard. Unless you know someone pretty well, you have no idea what their background is, how careful they are, or how diligently they keep their appointments with the rubber duck. Anyone who has been in this business for five, ten+ years has seen people put a lot of work into something, but fail to understand or uncover one or more basic truths that invalidate all the work they've done. Basic sanity checks are useful.
As researchers around the world race to build quantum computers that could break current encryption ... NIST is ... developing algorithms to protect our data and systems.
NIST has already released three post-quantum cryptography standards that can be implemented now ...
These Federal Information Processing Standards (FIPS) ... are mandatory for federal systems and adopted by organizations around the world ...
> Finally, for those of you who do security research: when you find a security or privacy issue, please consider notifying the maintainer/vendor before publishing your findings
How to report a bug or vulnerability
... we (currently) have no bug bounty program ... send an email to support@mullvadvpn.net
I dislike it here because I like Mullvad, but yes, I think it’s fair to go straight to public disclosure.
Someone with likely substantial qualifications put in time to find this. The company is in it for profit (at least partially). What’s fair for the company is fair for the individual. The company can either offer to pay for bugs under the terms they want, hire more security folks to find the bugs themselves, or just accept that researches get to do whatever they want with their findings.
I’d tell Mullvad, but there are companies I don’t respect enough to feel compelled to give them a heads up. Perhaps the author feels that way about Mullvad, it’s entirely within their right to use this to publicly shame Mullvad.
Those who do bug bounties full-time ignore programs with no rewards. Those who want to gain experience or pad their resume can submit reports to programs with no rewards because they are not as competitive as those with rewards.
I tried watching that but X either broke their video controls or disabled them so I can’t skip ahead and the first couple minutes are _slow_.
The whole bug bounty thing is a mess, admittedly, but lacking a bug bounty program entirely feels like immediately losing the moral high ground on “you should have told us first”. There’s a lively debate about what bugs are worth, but it’s objectively not $0 for many classes because a botnet developer will buy them for some amount.
Personally, a big part of my view is formed by the educated assumption that security practices will never improve unless poor security becomes a liability. That’s unlikely to happen with “responsible disclosure” because it gets swept under a rug. Immediate public disclosure changes that risk calculus a lot. I think wed see a lot more downward pressure from vendors to their suppliers if $RandomSaaS had to worry about losing their pants because Oracle had a vuln published.
No software is free from bugs. Category of software that undergo extensive verification like aerospace are priced far higher to accommodate the additional QA. If such extensive verification are added to average consumer or even business software, the massive costs will pass down to average users making it too expensive. Security practices need to improve but I don't think 0-day droppers are the answer. Not every threat actor is at the same skill-level. Immediate public disclosure provides them the opportunity to hit endpoints that they would not have hit coz of low skills.
Software is the only field where people will routinely argue producers can’t be expected to make a product that won’t harm its users and I don’t buy it.
The way your argument reads to me is “software as a category has such little utility that profit margins can only be derived from corner cutting”.
The reality of the landscape is that most companies don’t get hacked as the result of an incredible and novel Spectre-esque attack, it’s something bland and entirely preventable.
SAP got a CVE because they just flat out didn’t implement auth on an endpoint in an app architecture that will execute files just for being in a certain directory, and also didn’t prevent writing files to executable paths (or maybe that’s how the feature works, not a SAP person). For every 0 day with a novel root, there are like a thousand that are some kind of humdrum “didn’t enforce auth/SQL sanitation/XSS/other well known exploit with comprehensive solutions”.
I do think there are good reasons to withhold some classes of exploit. If a hacker writes a 14 page proof on how to beat some encryption we had no idea was vulnerable, that’s one thing. Getting owned for making an insecure architecture and then not even putting auth over it is a whole other issue.
Now that I've thought more about it, I agree with you. Most companies fall prey to well known exploits that are not that expensive to mitigate.
I think it's mostly ship product faster > secure product first that leads to such insecure architecture. Ideally, security should be incorporated early in the software development life cycle but most start-ups rarely hire a security guy in the initial phases. https://www.reddit.com/r/indianstartups/comments/1r6zwbg/why... They expect the software devs to have that knowledge. But security hardening is a skill that takes time to develop so most devs just focus on feature development.
Will immediate public disclosures change the mindset of top leadership regarding security? For some, yes but most will not change because breaches have become too common. They reason if top tech firms like Microsoft or GitHub can suffer breaches and come out on the other side unscathed, they too can survive a major security incident.
This ought not be considered anything close to common courtesy. This is work. Mullvad is engaged in the business of making money. They should show how serious they are with your money.
Since when do you have professionals giving you examinations out of common courtesy? Out of courtesy can I get a free cancer screening?
If I doctor performed a cancer screening on me, for free and without me asking, then yes — as a matter of courtesy I would still expect that doctor to tell me if he found cancer, rather than reading about it on his blog later.
>Since when do you have professionals giving you examinations out of common courtesy?
Maybe when they decide on their own volition, without any external pressure, to go and poke around your system?
"Hey, I'm a mechanic, I was looking at your car parked out there and noticed something incredibly dangerous that needs immediate fixing. I'll tell you what it is for $1,000."
Even better, the mechanic writes a blog post about the dangers of non-functioning brakes, but doesn't tell the car owner, because they didn't have a sign advertising their "car issue bounty program".
Seems to be a systemic issue with computer guys feeling entitled to financial compensation for strange reasons. See also, people licensing their software as "open source" and then being mad when people make money off it.
Even better, the mechanic writes a blog post about how the locks on that guy's car don't work, and how anyone could just steal it, but doesn't tell the guy because, after all, the guy wasn't paying him to.
Both of y'all confusing individual with corporate.
The mechanic writes a blog post about how the locks on [a car model] don't work, and how anyone could just steal [cars], but doesn't tell the [car company] because, after all, the [company] wasn't paying him to.
Especially, when the car company spends on 'certifications' (security audits, in this case) and specifically markets it as a differentiator. That said, uncoordinated public disclosures in cybersecurity are bad form, given the well-established existing norms & culture; but at least, let's get analogies right.
Obviously there are a hundred variables that differ between the analogy and the actual situation. You changed one that felt important to you (individual/corporation) but there are still 99 that differ. That's what makes it an analogy instead of just being a retelling of the actual situation.
But yes, if you found a general fault in the locks of a certain car model and publicized it without first informing the company and giving them a fair chance to inform the affected customers, people would probably be annoyed with you. Individuals even, not just companies.
"You chose that car that advertises good locks. Guess what, the locks are actually bad and now I'm gonna publish exactly how, to teach the manufacturer a lesson about paying me money".
When their 'common decency' is directly benefiting a money making corporation with shareholders and directors then yes they should definitely get some money out of it.
If you create a 3rd party app to some closed source insecure back end, thats on you for trusting them or not doing your due diligence.
Time and time again private companies have rug pulled things like api access for 3rd party apps (such as twitter/X). Building 3rd party clients for private systems should already be approached with heavy scepticism and always be prepared for the worst.
Most of HN readers/writers are American, of course they won't do anything unless they personally profit off it, the entire culture is built around this mindset. Meanwhile, Mullvad is Swedish, and we tend to assume we all want to help build a better world together. Mix the two, and you get this conversation :)
So what, suddenly Swedes can't live outside of Sweden? Kind of interesting to make complaints about generalizations and in the same comment falling for the same trap yourself.
You identified as Swedish, and then shifted the goal post to the country where you (apparently) currently reside.
What's your point again? Something about all Americans whether they live in the US or not? Are you trying to be incoherent? Daft? Representative of all Swedes by origin?
> Most of HN readers/writers are American, of course they won't do anything unless they personally profit off it, the entire culture is built around this mindset
American culture is highly varied. For some this is true, for others this is wrong and highly insulting.
It's OK for the country to have a pervasive culture yet not every resident or citizen of the country to be a part of that culture, or even actively work against it. If you're not one of them matching that description, it shouldn't be insulting, as it's not about you in the first place.
Maybe not everything is aimed towards you, especially if you don't feel like the description actually matches you :)
That is a lot of words for "my negative steroetypes about you and your country are fine, actually. Don't take it personally, bro. Maybe you're one of the few good ones!"
Every time someone makes a cultural comment here, the reply is always "America is a big country". America can be a big country and still have common cultural elements. It's not inaccurate to say that citizens of a large country mostly share some common characteristics. Those characteristics are what makes them one country.
Discovering a bug that could put people's lives and/or freedom at risk if they don't do something about it makes it okay to go public immediately. That said, by all means notify the maintainer/vendor as well.
It should always be assumed that someone else (if not several someone elses) have already discovered the same flaw and are currently taking advantage of it while users remain totally unaware of their actual risk. By going public immediately, you give as many of those users as possible a chance to protect themselves.
Waiting to disclose something harmful when the users in danger could otherwise take steps to make themselves safe would be like not warning people entering a building not to go in because of a gas leak until after you've contacted the building owner and the fire department has shown up.
> Expecting people to hold off on disclosure of something harmful
That's not what they said though. They said "please consider notifying the maintainer/vendor before publishing your findings, even if you intend to publish right away" (emphasis mine)
I do think hitting "send" on the email to the responsible party immediately before publishing (or at least notifying them as quickly as you can afterwards) is a smart thing to do. I mean, why wouldn't you? My concern was more about the "Not having a bug bounty or dedicated email address does not make it OK to go public immediately" comment. It can sometimes be difficult to track down the right person to notify and so when the risks to people are high enough whichever one you can accomplish the soonest is probably where I'd start.
Depending on the severity of the issue. Emailing support with a draft of the blog post and waiting even a couple of hours for a response so they can fix it first would have been more responsible than dropping the blog post to the whole wide world and catching Mullvad with their pants down.
Why wait for a couple of hours for a response while people who could protect themselves are getting harmed? It's especially true when you don't know if the maintainer/vendor will get back to you at all, or if they even check their mailboxes regularly.
The priority should be on protecting users, and not helping the company responsible for the vulnerability save face, or give them extra time to spin up their PR team, or get a head start on a patch.
When the risk to users is low, or when there's really nothing users can do to protect themselves anyway I'd agree with you. In a case like this where the risk to users can be extremely high, and the moment they are made aware of the problem there are steps the user can take to eliminate that risk, the safety of those users should outweigh inconvenience to the people responsible for the vulnerability
The problem is how do you notify users? What are the chances that a Mullvad user is going to happen across this blog post? Of the entire world of Mullvad users, somewhere between 0 and 100% of their users is going to read it and be in a place to do anything about it. If I were to make up a number though, I'd guess it's somewhere between 1 and 10% of Mullvad users. On the other hand, by telling Mullvad first, so Mullvad can fix their system first, closer to 100% of Mullvad users get the fix before attackers figure out the issue.
Mullvad fucked up. They should been as inconvenienced as thru possibly could be too fix the problem promptly! The issue is irresponsible disclosure hurts more users than it helps.
> What are the chances that a Mullvad user is going to happen across this blog post?
It's not as if the odds of new would-be exploiters seeing it are any better. It helps that the people who are at the most risk tend to have their ear to the ground already because they know what's at stake.
When the risks are this high you have to assume that it's already being actively exploited. That means that already there are more attackers who know about the vulnerability than there are users who know about the mitigation.
All you can do at that point is let as many users as possible know how to protect themselves while Mullvad figures out how to fix the issue on their end, writes and puts out the update, and the remaining users get around to updating their systems. You can't save everyone, but hopefully you at least gave some people the chance to save themselves.
> Discovering a bug that could put people's lives and/or freedom at risk if they don't do something about it makes it okay to go public immediately
The flipside of course is ... does your disclosure increase the risk?
> aiting to disclose something harmful when the users in danger could otherwise take steps to make themselves safe would be like not warning people entering a building not to go in because of a gas leak until after you've contacted the building owner and the fire department has shown up
I don't think it's like this at all. The risk of a gas leak is not increased by telling people about it and can't be prevented after its occurred. To stretch your analogy, I'd say its more like you've found the gas leak and instead of turning off the gas supply are instead running around outside the building shouting about how there's a gas leak.
> The flipside of course is ... does your disclosure increase the risk?
When you've got that much on the line you have to assume that the risk is already present for all users. It's true that there's always a chance that some users won't find your disclosure in time and additional would-be attackers who weren't aware of it already will start taking advantage of the flaw, but the alternative is that no users are safe.
> The risk of a gas leak is not increased by telling people about it and can't be prevented after its occurred.
It's true that warning people not to enter wouldn't make the gas more dangerous, but it limits the death count of the impending explosion. It keeps at least some people from entering the building and walking into a death trap.
There's no way to shut off the gas supply when you can't control what's already running on user's devices and more users are downloading and installing the buggy code all the time. It's really not a perfect analogy. The point is that immediate action will save some people, while waiting around means that nobody has a chance of being saved.
I don't feel like its hard to come up with examples where (I would say) its ethically wrong to disclose immediately. If you spotted a company's mistake that might endanger their user's lives or safety, would you put those users at risk simply because there was no obvious financial reward?
If so, I guess we just have different opinions on the ethics involved here.
You seem to have a very bright line between the acceptable behavior for “no money involved” and “money involved”.
For me, it’s more subtle than that.
Everybody (“almost all software”) has exploitable bugs. Are you a fool for not finding the ones in yours? Maybe. Sometimes.
There is a huge difference between Project Zero finding a trivial vulnerability almost identical to one reported months earlier (close to negligence) and Mullvad having the CEO personally posting a response here in a very calm tone.
> Are you a fool for not finding the ones in yours?
If I have a company which sells a paid product, and my paid engineers do not find bugs then I absolutely do not expect the public to willfully and freely make my product better for me. This is why I would have a bug bounty program as an incentive for the public to help me makle my product better and more secure, like any other company serious about finding security bugs.
If I didnt have a bug bounty program and found out that some black hats were selling backdoors to my system online, I would consider that fully my fault for not incentivizing those hackers against doing so.
I'm not sure what you mean by "Oof". We don't have a dedicated security team because security and privacy are integral to all aspects of our service. It doesn't make sense to centralise it.
As for our support team they are responsive and experienced. Several of them have worked with us for many years and do offensive security research in their free time.
Unlike many organisations we don't see customer support as a cost center, just like we don't see security as a cost center. Our support team represent our customers, and as a consequence contribute a lot to how we prioritise our roadmap.
Clearly the person who wrote "Oof" has never emailed Mullvad support.
Whenever I have emailed Mullvad support I have received a prompt reply from a human being who clearly actually cares about taking ownership of the question and seeing it through to resolution.
I have also witnessed first-hand the support person taking the question to an internal team member where it requires additional input. So there are clear paths for escalation if circumstances require it.
Finally the support mail allows for PGP encryption of communications too.
(I am not a Mullvad shill. Not a Mullvad employee. Just a satisfied customer)
Human psychology is weird and some things are just cultural. If you have the ops team make the security@ email alias just forward to support, you could avoid having to go into all that.
"Just email support@" feels like you don't care. That you do, and that your support team is awesome, doesn't change the fact that there are other companies out there who's aren't. Security people are human with human egos, and they want to feel special, so giving them a special way to reach you, even if it's the same thing behind the scene, makes a world of difference.
"We don't have a dedicated security team because security and privacy are integral to all aspects of our service".
Do you have people whose role is explicitly security? Who are the security SMEs in your organization if not? I personally find the "Security is so important to us that we don't have a team dedicated to it" argument weak, and often results in misaligned incentives - if individuals have to alternate hats from "deliver results" to "properly vet security", the business push to deliver tends to win out. I'd be very curious to hear how you ensure your team doesn't fall into that trap.
> Blocking UID 1000 connections, and blocking QUIC, has not caused any problems for me
By design, the app sandbox isn't applied as strictly on "privileged apps" (like UID 1000). There's nothing NetGuard or any userspace app can do to shore that up. System/privileged apps can bypass most OS-enforced isolation mechanisms at will: https://github.com/celzero/rethink-app/issues/224
This is besides the fact that NetGuard doesn't (yet) support "Block connections without VPN" mode.
I remember using GitHub Copilot (OpenAI "Codex" mk1) in Aug 2021 (ChatGPT would launch a year later 2 weeks after Meta's botched Galactica release). Cursor & others took it and ran a mighty good race.
reply