The CVE associated with it (CVE-2026-85046) is already being exploited in the wild. If we put our thinking caps on, how much do you think this vulnerability is actually worth? How much do you think an organization like Google would spend on, for example, AI tokens or compute to detect this internally before it was found and exploited in the wild?
Ethical disclosure is a complicated topic, because researchers shouldn't hold bugs for ransom or demand high payment. But at the same time, if someone submits a critical issue like this, it makes sense to pay them what the bug's actually worth. Why should a researcher be effectively penalized for responsibly telling a vendor instead of selling the bug to a "research firm" or three-letter agency?
It's one thing if you're an open source project maintainer just trying to put something out to the community. The math is a lot different if you're Google.
tptacek 3 days ago [-]
If the vulnerability is already being exploited in the wild --- as in, it's a vector people already know about and are tracking --- it's possibly not worth much at all. Vulnerability valuations depend heavily on the lifespan of the vulnerability; payments on black market are tranched (explicitly or less explicitly, as with "maintenance payments") based on whether they're patched.
Further: a vulnerability is probably not worth that much either, even if it's a hypercapable vulnerability, because the grey market buys full enablement kits, not vulnerability information. People making 6 figures on vulnerabilities are selling fully enabled full chain exploit systems, not just intelligence about a sandbox escape.
flatline 2 days ago [-]
Isn’t the implication that the vulnerability had already been found and exploited instead of reported to Google, because its value to Google was so low? Whoever found it originally had more incentive to sell it on the grey/black market. Or is the incentive structure truly different for vulnerabilities discovered to be already in the wild?
infinite_spin 2 days ago [-]
Some exploit hunters sell strictly to the grey/black market to avoid opsec issues. If you're selling on both, you're more likely to be identified by both.
toast0 2 days ago [-]
Surely google has telemetry when their sandbox is escaped? (Only mostly /s)
rileymat2 3 days ago [-]
I was under the impression that the three letter agencies and contractors bought vulnerabilities?
StrauXX 2 days ago [-]
Sometimes, yes. But usually, as a security researcher, you usually sold to brokers. The brokers made the vulnerability into a reliable exploit. That is whst they then sold to agencies. For a markup of course. The industry was in a tough spot already the past years. Now AI is shaking it up even more.
monster_truck 2 days ago [-]
They want the good shit, not this bargain bin fuckup
nullsanity 2 days ago [-]
[dead]
Gabrys1 2 days ago [-]
Knowing the vulnerability, creating an exploit might be relatively easy now that we have AI to figure the boring stuff out.
kllrnohj 2 days ago [-]
This "only" escapes the JavaScript sandbox. You still need to chain it with an escape for the process sandbox. So it's not just the boring stuff of turning a predictable crash into arbitrary execution, but also finding a second RCE vulnerability to chain this with
kccqzy 2 days ago [-]
Right and in recent memory Google actually awarded a renderer sandbox escape with $250k [0]. Now you can see actually how serious this is.
If it’s being exploited “in the wild”, it means someone has already found how to chain it, otherwise what would be the point?
bethekidyouwant 2 days ago [-]
Right but this actually hasn’t happened…
r_lee 1 days ago [-]
"Google is aware that an exploit for CVE-2026-85046 exists in the wild."
anonymars 2 days ago [-]
I'm curious now, how is it being actively exploited? Unless there is already some other exploit with which it's currently being chained?
r_lee 1 days ago [-]
there are many vulns that are sitting idle waiting to be chained like this. plus in some cases adjacent bugs can be found once you find a bug like this.
fr2029 3 days ago [-]
[flagged]
doubletwoyou 3 days ago [-]
Mate, it’s a style thing that depends on which style guide you’re following
AP recommends spaces around them, whereas Chicago doesn’t
besides if we’re critiquing incorrect following of English orthography
—Sentences should be capitalized
—The word “don’t” requires an apostrophe
—End sentences with a period
—That’s incorrect usage of an em-dash at the end there — but what does it matter anyways ;)
itsTyrion 3 days ago [-]
Books I've read would disagree. Are you the emdash police?
blfr 2 days ago [-]
Aren't we all nowadays.
fr2029 2 days ago [-]
comic books aren't books.
itsTyrion 2 days ago [-]
?
fr2029 1 days ago [-]
did I stutter, nerd?
howard941 1 days ago [-]
When did being a nerd become unfashionable again?
fr2029 19 hours ago [-]
the day you were born
altmanaltman 3 days ago [-]
[flagged]
ukuina 3 days ago [-]
> Spacing around an em dash varies. Most newspapers insert a space before and after the dash, and many popular magazines do the same, but most books and journals omit spacing, closing whatever comes before and after the em dash right up next to it.
altmanaltman 3 days ago [-]
[flagged]
idiotsecant 3 days ago [-]
Before the LLMs made the emdash the tool of the electronic oppressor I used it often enough and other people did too.
I hate that it's basically become the little hitler moustache of punctuation. There was at least one guy who was really enjoying his tiny little moustache until he couldn't anymore. That is the emdash for me.
Heythatsfunny 3 days ago [-]
> the emdash has become the little hitler moustache of punctuation
Legendary.
Miss that shit too.
Ez way to shit on Windows users who had to double up endashes like they were impoverished.
I guess in your analogy the double endash is Stalin’s mustache and the Soviet Union in general - Gaudy, excessive, starving for more
vonunov 2 days ago [-]
In the spirit of good pedantic fun, I'll point out that en dashes are no less inconvenient than em dashes for the average Windows user to insert. The hyphen-minus immediately accessible on the keyboard was (and is) used for the common typewriting kludge attested in Garner's[1] as well as the LaTeX-syntax triple-hyphen em dash (which, might I add, for lack of a better place to do so, isn't one of the ways I've seen dashes used by LLMs or disguised by their operators).
That's really informative but maybe a little overly capitalist-brained.
We shouldn't look to the black market as cost discovery for these vulnerabilities, most non-criminal researchers are not putting up an ask order and letting the black market compete with Google.
JoshTriplett 3 days ago [-]
> We shouldn't look to the black market as cost discovery for these vulnerabilities
We absolutely should. One of the points of bug bounties is to discourage people from selling to the black market.
jameshart 2 days ago [-]
The black market also prices in a risk premium for ‘this is illegal and you could go to jail for selling me this’.
Google is only paying for the vulnerability; the exploit market is also paying for your mortal soul.
sterlind 2 days ago [-]
There's plenty of legal gray-hat companies that will buy a bug. Zerodium is a good example though it no longer exists. These companies in turn sell to NSA, etc. maybe even foreign governments for all I know. There's very little regulation of the space iirc.
I had a friend that worked in the space. He lived an exciting life; I hope he's still alive..
iknowstuff 2 days ago [-]
I'm surprised that selling knowledge is illegal? Is it really? Maybe it shouldn't be
jameshart 2 days ago [-]
Ah the classic programmer mistake when encountering the legal system of thinking ‘but surely this act, in and of itself, could not be considered illegal?’ When what the law criminalizes are not mere acts but actions carried out with intent and knowledge in a context.
‘Officer, you can’t arrest me for carrying a gold bar!’
‘I can if you are carrying it out of the Federal Reserve vault without permission’
Similarly:
‘Surely selling someone the knowledge that a piece of software can be hacked isn’t illegal?’
‘It is if you know or suspect that that person’s intention is to use that knowledge to commit crimes’
This would make you a ‘coconspirator’ or possibly an ‘accessory before the fact’ in any crimes they committed.
ok123456 2 days ago [-]
Ask Stephen Huntley Watt.
nixon_why69 3 days ago [-]
That's one of the points, yes, but the black market doesn't dictate the value of the exploit to Google.
A hardline bargaining position with Google would be more like "pay me what I want, or else I'll give it to all takers on the black market for maximum damage". That would be unethical and probably illegal to boot but it's a better definition of value than "1$ greater than max bid".
xprnio 2 days ago [-]
The value to Google - sure. But the market value of the exploit itself - the black market I think is a factor in that regardless of what Google offers.
The value of something is dictated by what _the market_ offers, and just because Google throws a lowball price because _they_ don't value it doesn't necessarily mean that the value of the exploit itself is as low as they dictate.
There will always be someone who would screw Google just for the love of the game, and if they got a better price from elsewhere, I don't see why _morality_ would really play that big of a role. It all comes down to incentives, and if Google doesn't incentivize doing the good thing enough, then someone _will_ incentivize them to do the bad thing just a bit more.
WarmWash 2 days ago [-]
Your conflating capitalism with markets.
Markets are fundamental things and exist regardless of any kind of moral "should". Otherwise we wouldn't have people buying hard drugs or trafficing women.
nixon_why69 2 days ago [-]
If we abandon the moral "should", then the right move is to shake down Google along the lines I already said.
Google should, as a rational actor, pay out better for legitimate vulnerabilities that pose actual risk to them to avoid such a situation.
My beef here is that morality and ethics are only assigned to the researchers.
WarmWash 2 days ago [-]
So what does that have to do with capitalism?
0xbadcafebee 3 days ago [-]
How much money is lost by consumers/businesses for every hour the vulnerability is exploited in the wild with no patch?
tantalor 3 days ago [-]
The value of the report is dependent on the scarcity of the knowledge. If anybody can report it, the bid goes down.
onion2k 2 days ago [-]
The value of future reports should also be a component though. By paying a low amount you discourage ethical bug bounty hackers from bothering to look for more exploits. If I think I'm only getting $1000 for a Chrome issue versus $100,000 for an Acme Co issue, I'll be spending my time looking for Acme Co issues.
Bug bounties are as much a way of attracting talent to even try to exploit your system as they are about the exploits themselves. If you lowball the bounties the talent goes elsewhere.
tclancy 2 days ago [-]
How do you figure? The value of the report is, ethics aside, the same as the value of exploiting it. Doesn’t matter if I can conceive of it, it matters if I can exploit it.
cannonpalms 2 days ago [-]
Supply and demand has to be considered. The more parties aware of the vulnerability, the more attractive sellers (reporters) have to make their ask to the buyer (defender).
brookst 2 days ago [-]
Not following that. The report is the upstream resource the exploit needs. The value of iron ore is definitely not the value of the steel made with it. Or maybe I misunderstood your view?
toomuchtodo 3 days ago [-]
There is a theta decay component. The zero day is highly valuable until known; once known, its value rapidly declines to zero.
randyrand 3 days ago [-]
That’s not how things are valued. That’s moreso how the absence of something is valued.
wat10000 3 days ago [-]
Go without air for a few minutes and you’ll die, and yet they give the stuff away for free.
luipugs 2 days ago [-]
Stop giving them ideas.
noduerme 2 days ago [-]
Well, the implication (and I'm not saying this is right) is that to Google it's only worth $1k to have this brought to their attention by a white hat, versus finding out by exploitation.
Which means that they have zero concern from this incident about reputational damage to themselves or their browser. That's pretty good circumstantial evidence of a monopolistic practice, when you can safely assume that there's effectively no difference to your bottom line if your software is hacked.
thayne 2 days ago [-]
But google is also a monopsony. There isn't anyone else the researcher can ethically sell it to. They just have to take whatever bounty google decides to pay.
noduerme 2 days ago [-]
I'm just saying it's more evidence that Google should be broken up.
xnx 2 days ago [-]
How would you break up Google that would make browsers more secure?
ruszki 2 days ago [-]
Google should have been split up into shreds like 2 decades ago. Search wants to have income from ads? Good sell it to anybody who pays the most, just like every single newspaper does. Gmail wants to sell our data, or ad space? Good sell them, and not just reuse them internally. Chrome wants to monetize every single request you do? Go, sell them on the open market. And not this fake, "we're separate companies, but only on paper" way.
This should have been done a long time ago.
Firefox, and the browser market would be much more healthy. Btw, Microsoft, Apple, Facebook, now even Twitter/SpaceX and all of these should have been forced the same way. And of course not just in this field, but all of them, like oil companies. They can pivot, of course, with some grace period, but that would mean giving up something at the end.
And if we are there, we can abolish most of trade secrecy too, which exists only to keep up the status quo while hindering progress.
WarmWash 2 days ago [-]
Google is the answer to an Internet that largely blocks ads and uses backdoors to circumvent pay walls. A single massive pillar with enough surface area to carry all the dead weight.
If people want a better internet, they can start fostering one, rather than endlessly complain that someone else should be fostering it for them.
There will probably be upwards of 1000 people who read this comment that have used Google services for 15+ years, never loaded a single ad, and complain about Google ruining the internet. Please, pick-up a mirror. Nobody wants to build a competitor to serve your cheap ass
aka-rider 1 days ago [-]
Google is routinely buying and destroying competitors.
They lower prices to kill competition en-masse. They promote their own products in search and elsewhere over paid ads.
Search Engine have chicken and egg problem, you can only have a good search if enough people use it to tune the ranking and see enough search spam cases.
“Just compete with a monopoly on their own field with one hand tied behind”
WarmWash 1 days ago [-]
Every Google competitor has the problem that 40% of users won't load ads and 99% won't pay a subscription.
They don't need to do anything adversarial, the greed driven mindset of the internet (ads suck, everything should be free) staves off any real competition.
ruszki 1 days ago [-]
That 40 percent is definitely not true in the general audience. Also they will load ads, just not all of them. Surveys ask that. Especially on mobile, and apps. Also, when we measured on our car rental site, with near perfect precision (it's absolutely not difficult), then the number was around 20%. Also, according to download statistics, there are less than half a billion people who use ad blocking browsers or other solutions on Android. And that's downloads, which is obviously inflated, even obvious from browser statistics (no not 100% of Firefox users are on Android, it's almost the opposite).
It's not nothing, but it's probably around 20%.
Also as others stated. I pay for everything, if they give me the opportunity to pay them for ad free versions. I don't see ads on my Android, and I don't use a general ad blocker on it (except my browser, but I rarely visit sites which would contain ads, and basically all of them from Hacker News). I don't use free search, email, newspapers, I pay for YouTube, and I would pay for Facebook if I would use it. I don't even use Hacker News freely, because I paid for the app which I use to not see ads, and have more features. Heck, I pay even for my torrent, because I support them.
You're in the wrong neighborhood with this sentiment. But yes, the general populace is not like this.
WarmWash 23 hours ago [-]
Good for you, now get others to do it. Definitely not the wrong neighborhood though, HN is extremely pro ad-block and every paywall link has an archive.ph link in the comments.
Hell the top story right now is about a tool for backdooring twitter...
sire-vc 1 days ago [-]
I dont like ads. Would you be willing to pay for content? Obviously not, stupid.
This comment in general, not aimed at you.
genxy 1 days ago [-]
I pay for email and search.
There are hundreds of us, hundreds.
2 days ago [-]
noduerme 1 days ago [-]
I don't see how we could have more vulnerability, on a massive scale, than to have two companies which pre-install both the OS and the browser, on their own hardware in the case of Apple, for 95% of the planet.
Microsoft was sued by the USDOJ in 1998 precisely for this, that it was leveraging the pre-installation of Windows to force Internet Explorer to be the default browser for PC consumers. That that was bad for both security and for the web seems pretty obvious in retrospect, when you think about the trajectory of IE.
Apple's insistent blocking of non-webkit web engines, including V8, on its own hardware/iOS is an even more egregious and dangerous phenomenon.
Browser security and browsers themselves would be vastly improved if they weren't a monopoly of the two mobile OS makers.
brookst 2 days ago [-]
Do the smaller browser makers pay more for big bounties?
Henchman21 2 days ago [-]
What smaller browser makers???
kccqzy 2 days ago [-]
That’s exactly right, and applies to more than Google. I can’t think of a single browser vendor that would think a single vulnerability materially causes reputational damage.
CookieCrisp 3 days ago [-]
While I agree 1000 is hilariously low for this, worth is hard to quantify. Do you pay what it could theoretically cost your company? the amount the top bidding bad actor would be willing to pay?
altairprime 3 days ago [-]
The discount Google is getting on bounties versus internal spend is easy to estimate:
# assumed to be $0.5mil USD or greater
A := What quantity of salaries-and-benefits and AI-dollars does Google spend on zero-day research?
# assumed to be greater than zero
B := How many full sandbox RCEs are they *hoping* to discover per year with that budget?
# $/RCE budgeted spend
C := A ÷ B
# $/bounty
D := $1000 USD
# % discount per bounty relative to in-house spend
E := (C - D) / C
While we lack the data to be sure, it is reasonable to estimate that they're getting a discount of 90% or better versus internal spend on this bounty payment, if one assumes that they do not have many sandbox RCEs left undiscovered. It's unclear whether that assumption holds, but with only a single researcher at an assumed $0.5mil/year (all-inclusive after pay, stock, and benefits) is enough to support the plausibility of that 90% figure, before accounting at market rates for their internal use of the house AIs.
So, the most likely case is that they're greedy and miserly, and hope we don't do the math. However I recognize that there are judgment calls to be made here. Either their internal spending finds hundreds of RCEs per year, or they're significantly discounting bounty payments versus their actual worth, or they're negligent in budgeting for RCE discovery at all, or they assign zero value to the security of the Chromium platform underpinning Edge, Electron, et al. All of these are bad in different ways; one hopes a competent tech reporter actually pursues this line of questioning with them!
cogman10 3 days ago [-]
> or they're negligent in budgeting for RCE discovery at all, or they assign zero value to the security of the Chromium platform underpinning Edge, Electron, et al
I generally agree, but a 3rd explanation is they figure that too generous a bounty will flood them with reports of minor issues making major ones harder to see (and costing time and money to verify that could be spent looking for security issues).
altairprime 2 days ago [-]
Having previously worked near a bounty program, I can confirm that they are regardless flooded with people fishing for bounties, even before AI, no matter how cheap the bounty may be — people will grift anything with the most pathetic skript kiddie attempts possible to try and pad their resume with a hit, and bounties that pay $0 are more valuable than pull requests that pay $0.
teravor 3 days ago [-]
ideally, an auction and the vendor or a government can bid against malicious actors (which can also be a government). hard to set up though.
eru 3 days ago [-]
What kind of auction would you like to run?
Remember that you can sell the same vulnerability to multiple people: it's software you can copy.
Barbing 3 days ago [-]
Maybe needs a Good-Guy-Buy-It-Now w/instant delivery at a fair price. (OK that’s kind of a threat—you’re running an auction and you have the price the corp has to pay to avoid the auction ending.)
$1k is so dumb and the fact we’re discussing auctions is proof (hello, Sundar, what you doing over there?).
Guess this will change after the next e.g. nationwide hospital ransomware by a hacker who publicly laments bounty rates, if the news cycle accommodates the story long enough.
eru 2 days ago [-]
> Guess this will change after the next e.g. nationwide hospital ransomware by a hacker who publicly laments bounty rates, if the news cycle accommodates the story long enough.
Negotiating with terrorists or black mailers is a bad idea.
Barbing 1 days ago [-]
Agreed. Paying security researchers fair rates is a good idea though right? Keeps future researchers honest?
27183 3 days ago [-]
it seems unlikely google's lawyers would go for this
aeonik 3 days ago [-]
Maybe some code is so important and heavily trafficked it becomes a public works project, and various legs can bid for pieces of the project, line how all infrastructure works.
teravor 3 days ago [-]
well that's why setting it up is hard, because you would want to do it in a way that what they want doesn't matter.
quotemstr 3 days ago [-]
You let the market decide. Google could purchase the bugs on the same market blackhats do.
tptacek 3 days ago [-]
Google directly competes with the grey market for vulnerabilities. They are competitive in a bunch of different directions:
* They pay for vulnerabilities without reliable exploits (more for vulnerabilities that are demonstrably reliable).
* They don't require you to actually build a reliable exploit chain.
* They pay up front, not in tranches.
* They work with essentially all comers, unlike the grey market, where you're generally subcontracting to sell your first few.
jeffbee 3 days ago [-]
They pay in plain old money, too. On the market your counterparty will be a criminal who is trying to scam you every step of the way.
tptacek 3 days ago [-]
Not so much, the grey market is pretty well structured.
paulhebert 3 days ago [-]
Is there anywhere I could read more about this?
Sound very interesting!
nbk_2000 2 days ago [-]
The Grugq has done several interesting interviews/articles on the industry.
There's also a couple of Darknet Diaries episodes with similar interviews.
ajkjk 3 days ago [-]
we really do not want to engineer a system in which using bugs to make money is considered economically legitimate activity. It is still crime. The main reason to report bugs and get the bounties for doing so is still because it makes the world safer and healthier. The money is there to make is to incentivize the work of finding and reporting them -- not to outbid the bad actors.
necovek 2 days ago [-]
I would say that maintaining legacy systems as a software engineer is effectively "using bugs to make money" and very much an "economically legitimate activity".
If old systems had no bugs/issues, companies could do without the maintenance burden altogether (which includes even systems not being evolved/extended).
Alive-in-2025 3 days ago [-]
Companies sometimes reward their employees with important bug fixes. When I worked on a big dev team, we'd even decide what were the most important fixes and give people a special 5k bonus or something.
But they weren't security issues necessarily. I never thought about it, fixing a huge performance issue is big. A security fix that gets caught early makes no noise so you just don't know how important it would have been. We also once had a really terrible bug that lead to lots of customers getting effectively attacked.
vova_hn2 2 days ago [-]
> Companies sometimes reward their employees with important bug fixes.
Potentially creates a misaligned incentive to intentionally hide bugs in the code you write so that later you can fix it and get the bounty.
0xbadcafebee 3 days ago [-]
> using bugs to make money
Aka security research.
It's one thing to hold something for ransom ("give me $5M or I release the 0day"). It's another to sell a valuable piece of information ("give me $5M if you want the 0day"). As long as you're only offering the bug to the company who would be impacted by its release, there's nothing unethical about asking for payment.
Maybe you think that, ethically, all bugs should be reported, regardless of payment, because it prevents harm. Well a lot of things prevent harm that we don't all take it upon ourselves to do voluntarily. Should everyone do all safety-related work for free? If we don't want to do it for free, should we not do safety work at all?
If the company really wanted it safe, and they can't make it safe themselves, they can pay someone else to make it safe. If they aren't willing to do that, then nobody is obligated to do free work for them, because we don't require anyone else to do safety-critical work for free. Let's not forget, this isn't a scrappy startup struggling for a seed round, this is one of the world's largest corporations with billions of dollars in cash. If they want your labor, make them pay for it.
wafflemaker 2 days ago [-]
>Well a lot of things prevent harm that we don't all take it upon ourselves to do voluntarily. Should everyone do all safety-related work for free?
Thanks for putting it like that, it changed my opinion on the subject.
If it's normal to expect people to be compensated for other security work, it implies it should also be normal to compensate security researches.
codedokode 3 days ago [-]
"Crime" is very flexible term. One country's criminal is another country hero. Maybe the author would sell the vulnerability to an organization making exploits for government use.
"Safety" is also a relative thing, when the world is safer for one party, it is usually worse for another.
allendoerfer 3 days ago [-]
Having secure browsers, encryption etc. actually clearly benefits the world. No “but think about the children/terrorists” please.
simonra 2 days ago [-]
As our surroundings grow more secure, the justice system variant of swatting becomes a greater portion of the threats to worry about. There will be abuseable bugs and situations in our non static world, there is no way we'll ever have perfect security of anything. So a motivated actor with a grudge should be able to plant something a place you provably beyond reasonable doubt have sole control of, given enough time. How do you propose then that we secure deniability once the justice system is wielded as a weapon against the innocent, when everyone feels that there is no reasonable way defects exist and could have been used? Just look at the British post office scandal, real world justice systems have already operated under the assumption that software doesn't have bugs for decades, which speaks volumes on their inclination to believe that they both exist and are used by a unknown third party with ill intent. Thus the widespread trust in that things are secure is a threat in itself. And unlike airports we don't need the users to have an artificial sense of security for computers, networks, software, and digital services to be viable markets.
make3 2 days ago [-]
Brain dead moral relativism argument. The question is whether eg. a group trying to scam elders out of insurance money or a Columbian cartel to hack local politicians to do blackmail, or South Sudan to hack Darfur or whatever, should be allowed to compete with the companies making products for their own exploits.
99.999% of people will agree that reducing software vulnerabilities is desirable if they're able to understand the question, including the bad actors themselves a lot of the times.
The situations like bad state actors are already not bound by laws, and things like keeping activism legal are better fought for through other ways
bothers 3 days ago [-]
> The main reason to report bugs and get the bounties for doing so is still because it makes the world safer and healthier.
Yeah let's see how this plays out, paying people less than their time is worth for RCEs.
kube-system 3 days ago [-]
> we really do not want to engineer a system in which using bugs to make money is considered economically legitimate activity. It is still crime.
"Making money from bugs" is not solely a black-market activity. There are plenty of grey and even white hat activities in this market.
flutas 3 days ago [-]
Finding bugs is hardly a crime, selling them even isn't.
Now exploiting them? Yes that's a crime.
avazhi 3 days ago [-]
> using bugs to make money [is a crime]
No it’s not lol
bawolff 3 days ago [-]
Well, someone did decide to tell google about this in exchange for a thousand dollars (albeit unclear how much the money was the motivator). Doesn't that mean the market did decide in google's favour?
drdexebtjl 3 days ago [-]
Someone decided to tell Google about this in exchange for an unknown amount of money, chosen unilaterally by Google at a later date, at which point the market value of the vulnerability is $0.
There's no way money is the motivator.
bawolff 3 days ago [-]
Money is not the only coin to pay someone in.
asdfaoeu 3 days ago [-]
Blackhat markets will always be able to pay better. Selling to Google though you aren't chancing jail time.
quotemstr 3 days ago [-]
> Blackhat markets will always be able to pay better.
... than Google?
> Selling to Google though you aren't chancing jail time.
Why would you go to jail for selling a vulnerability? It's free speech.
ajkjk 3 days ago [-]
"Aiding and Abetting" crime is also a crime. Free speech has nothing to do with it.
quotemstr 3 days ago [-]
Has anyone actually been convicted of abetting a crime by selling a vulnerability, by itself, not conspiring with the buyer to commit a crime using said vulnerability? Not as far as I can see. It would be absurd to jail someone for accurately describing a bug.
ndriscoll 2 days ago [-]
It would be absurd to jail someone for accurately describing a bug on their blog or whatever.
Not so much for taking money from someone who the buyer should know has no reason to be interested in buying the information. And either you know who your counterparty is, in which case you know that they are using it nefariously, or you don't know who your counterparty is, in which case you know that they are using it nefariously. Any court and any jury should see straight through this.
Similarly if you figure out how to get the ATM down the street to give you free money, and you "accurately describe the bug" to people who pay you, and they use it to steal money from the ATM, expect to be charged for participating in, and in fact being an instrumental enabler of their crime. Because it is beyond all reasonable doubt that you could've believed they could have been interested enough to pay you for any other reason.
quotemstr 2 days ago [-]
Has anyone actually been charged and convicted for disclosing knowledge of a vulnerability in exchange for money with no further collusion to commit a crime?
ndriscoll 2 days ago [-]
Jeremy Jethro seems to be an example. His lawyer claimed he had no knowledge of what the exploit would be used for, and that it didn't even work, but he ultimately pled guilty to criminal conspiracy.
12_throw_away 2 days ago [-]
Hmm. Are you aware of any publicly identifiable security researchers that openly talk about selling their exploits on the black market?
Since it's all so legal and risk-free, you'd think selling an exploit for a million bucks would be quite the feather in their cap!
It may also be helpful to visualize being interviewed by the FBI and being asked "Did you sell this exploit? To whom? How much did you receive? For what purpose did you think it would be used?". And to remember they already know the answers to these questions, and lying to the FBI is also a crime.
quotemstr 2 days ago [-]
My question stands.
3 days ago [-]
literalAardvark 2 days ago [-]
"this vulnerability is being sold for research purposes only and must never be used outside of a tightly controlled research sandbox"
joshuamorton 2 days ago [-]
courts are very good at reasoning about things like this and figuring out its bullshit. Zerodium is probably the closest you could get to some reasonable denial about this. Selling an exploit on crime.com for "research puposes only" will get you laughed at on the way to the cell.
Loughla 3 days ago [-]
Telling someone the steps to rob a bank world probably catch you some charges, I'm assuming.
paulryanrogers 2 days ago [-]
Are true crime authors going to jail? Or even authors of heist fiction?
quotemstr 3 days ago [-]
No, it wouldn't.
readme 3 days ago [-]
They would be broke quick.
jsw97 3 days ago [-]
In the past I would have thought this would incentivize finding bugs that might never be found. However it is now clear that all bugs that can be found will be found. So this makes a ton of sense.
eru 3 days ago [-]
> In the past I would have thought this would incentivize finding bugs that might never be found.
Isn't that a good thing?
> However it is now clear that all bugs that can be found will be found. So this makes a ton of sense.
If Google can find all the bugs nowadays, presumably with AI, why still pay a bug bounty? At least by this logic, bug bounties make less sense now.
DANmode 3 days ago [-]
Because there’s still a sizable group of people who see $1,000 from Google as more than $1,000.
Even a resume item.
jsw97 3 days ago [-]
Sure they make sense — you need some incentive to drive the price to zero.
3 days ago [-]
AustinDev 2 days ago [-]
No company will ever value your privacy or security more than or equal to how much you value them. This is why you gotta keep an unencrypted bitcoin private key in your password manager. I'll know pretty quickly (within ~ 10 minutes or less) that someone has access to all of my passwords.
socalgal2 3 days ago [-]
you're taking someone's word it's being exploited. It says right at the top of the report
> allowed a remote attacker to execute arbitrary code *inside the sandbox*
A bug in V8 leads to code execution in Chrome's web page process. It does not lead to execution in general. For that you need other exploits that escape the web page process. Those are not detailed here. This CVE is not a big deal. You're responding the poster's title, not the actual CVE
roywiggins 2 days ago [-]
> I chained this bug with an n-day sandbox escape and flagged the v8CTF.
Then what it was chained to is the real issue, not this one. The entire point of having webpages run in their own process is to prevent bugs like this one from doing worse. If you're claiming this bug is the bug that matters, you're effectively claiming they shouldn't need to run pages in their own process and just trust that there are zero bugs. No major browser does that. Not Firefox, not Safari, and not Chromium.
that's why bugs in the webpage process pay out very little. Without a worse 2nd bug, they are less serious. Bugs that let you RCE outside the webpage process pay much higher.
TedDoesntTalk 2 days ago [-]
Sophisticated attacks will always leverage multiple vulnerabilities. That’s why you have to think of any vulnerability holistically, not in isolation.
parineum 2 days ago [-]
Then just call them both one exploit that allows arbitrary sandbox escape.
magicalist 2 days ago [-]
I believe that means the v8 sandbox, not a renderer sandbox, based on the v8CTF reference.
strictnein 3 days ago [-]
If this would have included a full RCE chain with Sandbox escape Google would have paid significantly more.
Having just a Sandbox RCE is neat, I've got some on my laptop currently, but it's just a piece of the puzzle.
stymaar 2 days ago [-]
That sounds like a dumb strategy because if non-evil people sit on individual pieces of the puzzle waiting to solve it in full google loses most of the advantage of having a multi-layer system…
Issue3299 3 days ago [-]
Makes you wonder how many hacks wouldn't have occurred if security researchers (and vulnerability disclosure) was actually rewarded proportional to the possible/potential damage said vulnerability may have otherwise caused.
It's insulting how poorly incentivised white hats are, just look at how much North Korea is raking in with their cyber shenanigans - current estimates put it at around $6.75 billion to date (over the past 10 years or so).
bawolff 3 days ago [-]
> But at the same time, if someone submits a critical issue like this, it makes sense to pay them what the bug's actually worth.
I'd point out that part of the reason the grey and black market pays so well is because it is that type of market. You have to pay people extra to look past their morals and a risk premium against potential reputational and legal consequences.
That said, the gap is probably not just that.
s1artibartfast 3 days ago [-]
It seems like by definition it is.
Someone could sell it on the black market, sell it to Google, or just move on with their life and not sell it.
I don't know what this is worth on the black market, maybe I'd be scammed by even trying to sell it. Maybe I don't want to be a bad person. These are all things that go into the prices
denistaran 2 days ago [-]
[dead]
paxys 3 days ago [-]
There are plenty of people out there who find vulnerabilities and sell them to the highest bidder. Anyone is welcome to do it, including the researchers and hackers reporting them responsibly. There's no need to try and make a convoluted ethical justification. "I did this bad thing because you didn't pay me enough not to" doesn't work past the 6th grade.
r_lee 3 days ago [-]
this is why again, researchers should just honestly sell these to vuln brokers instead of donating them to trillion dollar companies for nothing.
nothing will change until big tech can no longer rip off security researchers
nullbio 3 days ago [-]
They're not going to stop underpaying security researchers just because security researchers decide to sell them to vuln brokers. Advocating for this is reckless.
r_lee 2 days ago [-]
they will if it becomes common knowledge that nobody serious is participating in their bug bounty programs. besides, they have incredibly deep pockets and they can afford to pay 6 figures for bugs like these
advocating for this is much more ethical than donating money to Google. I'd rather have that money go my family than a multi trillion dollar company.
bethekidyouwant 2 days ago [-]
Who is to say they didn’t already do that?
r_lee 2 days ago [-]
you're not allowed to burn exploits like that if you've signed a deal, and who would risk that for $1k?
of course it could be a colleague or someone with access to such tools
2 days ago [-]
bethekidyouwant 2 days ago [-]
“You are not allowed to do things” - lol
r_lee 1 days ago [-]
I forgot HN doesn't believe in contracts. sorry.
from what I remember, they also don't pay it all out at once but rather over time where the payments stop if the bug gets patched.
I don't understand why you're being so cocky here? this is how many 0 click exploits are sourced
DANmode 3 days ago [-]
But my “Google paid me” on my resume!
computably 3 days ago [-]
> How much do you think an organization like Google would spend on, for example, AI tokens or compute to detect this internally before it was found and exploited in the wild?
On average, probably not that much. What's the amortized cost of all testing, static analysis, and audit / code review, per "prevented potential bug"?
rectang 2 days ago [-]
The potential damage is all to users bound by terms and conditions, who are unlikely to collect damages successfully from a vendor. Structurally, vendors don’t have to care. Therefore, vulnerabilities have little direct financial value to a vendor.
It’s natural to feel cognitive dissonance because the value to the vendor is so disproportionate to the potential harm to users, but the incentive structure is what it is.
A vulnerability which lets an attacker harm the vendor has much higher direct financial value.
arjie 3 days ago [-]
Interesting question, and how much should a user pay Google to fix the vulnerability? I suppose the smallest unit of currency less than the amount of effort they'd have to put in to mitigate it. A fully market economy of bug fixing here is an interesting idea, certainly, but if I'm being honest I actually don't want to pay Google a thousand dollars to fix security issues. In the limit, what would happen is that I end up with the competitor browser Elgoog Emorhc which fixes security issues for free, and pays very little for them, which is the status quo.
In the world where security issues are paid for entirely at market rate, it would also be very important to not use browsers by poor groups because they would be unable to pay for security reports on the market and consequently the browsers would be less secure.
Interesting idea, for sure, but I don't think it lands in a place I want to go since I neither desire stochastic payments nor desire that all browsers should be from large corporations.
esseph 3 days ago [-]
The problem is they are being flooded with both fake AND real disclosures. Imagine if they tried to pay out $250,000 or more per bug? Would the cost be worth it? Maybe, but shareholders may not be pleased... Unless they viewed it as insurance against it being more financially sound for the finder to sell the exploit on the gray or black market instead...
Barbing 3 days ago [-]
Pre-flood, they didn’t pay more did they?
> viewed it as insurance
Of course. Beyond the ethics, the social obligation, sleeping well at night by compensating hardworking people fairly.
“We can’t pay more or we’d have to hire more human reviewers” should never be a massive company’s line of thinking.
Increasing each year, interesting. Would have to really dive in to answer my own question. Thanks!
mccr8 2 days ago [-]
In fact, Google will pay you $250,000 for a full chain exploit. The CVE reported here is a renderer process vulnerability. Google used to pay more for those before the vulnpocalypse. Now, they are fixing hundreds of bugs per week that they find themselves.
They should just multiply a base rate against the severity level. Say the base rate is ranged so low-severity stuff is $500-1K base but high-severity stuff is $10K base. That would net a researcher ~$88K for this specific bug (8.8 severity).
SteveNuts 3 days ago [-]
That would create a perverse incentive to inflate the severity levels even more than they already are
rglover 2 days ago [-]
It doesn't have to. Just put a cap and say "we officially recognize 1-10" and be done with it.
vlovich123 3 days ago [-]
CVE severity is a terrible way to do this. If you follow the cybersecurity space you should know why.
rglover 2 days ago [-]
It's a simple multiplier number and you can set a cap on it (and payout amounts). Where's the fire?
vlovich123 2 days ago [-]
CVEs are handed out like candy for non issues, the severity rating system isn’t a serious evaluation of the actual severity (eg a vulnerable function may not even be compiled in), the scoring is inconsistent and subjective and frequently inflated to make the severity seem worse, and with the AI flood they have a massive backlog of handing out CVEs.
Like look at CVEs curl dealt with at one point that were just completely bogus and given huge severity ratings to start with.
But honestly if you’re the one proposing a “simple solution” maybe do some research yourself.
rglover 2 days ago [-]
> But honestly if you’re the one proposing a “simple solution” maybe do some research yourself.
It's an off the cuff idea on a nerd forum. Relax buddy.
r_lee 3 days ago [-]
it's such a drop in the bucket, it wouldn't make any difference
babuskov 2 days ago [-]
With such low payment, it makes one wonder how many exploits exist which were sold to 3rd parties and are currently used in the wild without Google even knowing about it.
3 days ago [-]
dataflow 3 days ago [-]
It sounds insultingly low, yeah. I'm trying to imagine why they would pay so little. The only two reasons I can think of are either (a) they were already aware of it and fixing it, and therefore the report didn't really change much, or (b) it requires an unusual configuration or otherwise rare opportunity to that makes it impractical to exploit most users. Really curious to see what the issue was whenever it gets made public.
solenoid0937 3 days ago [-]
(c) there are so many undiscovered vulnerabilities that it doesn't make sense for them to offer a decent payout
spacedoutman 3 days ago [-]
"because researchers shouldn't hold bugs for ransom or demand high payment"
Maybe they should now, not like anyone else cares about ethics anyway.
Alive-in-2025 3 days ago [-]
Imagine the consideration for the Trump admin, should we pay this guy a million bucks for this attack that gets us into the command system of Iran, or would that be unethical. Of course they don't consider that at this time.
zx8080 1 days ago [-]
This sends 2 clear signals:
- for developers: don't report, it's not worth it
- for users: Google does not care about security as it doesn't pay for reporting (enough).
2 days ago [-]
klm127 2 days ago [-]
I heard, on the podcast Darknet Diaries, that there are auctions for zero days in Argentina. This security researcher could probably have cleared a million dollars for a bug like that if they were unscrupulous. The bug bounty should absolutely be higher.
3 days ago [-]
paulpauper 3 days ago [-]
The CVE associated with it (CVE-2026-85046) is already being exploited in the wild. If we put our thinking caps on, how much do you think this vulnerability is actually worth? How much do you think an organization like Google would spend on, for example, AI tokens or compute to detect this internally before it was found and exploited in the wild?
in the darkweb, due to crypto, a lot. there is where the $ is, whether it's stealing crypto directly or phishing developers.
vasco 3 days ago [-]
You've been on HN for 16 years and still comment the lowest brow possible comment on security vulnerability threads that the bounty isn't big enough. How many times do we need to have a top comment crying about the same thing? If you think its too little, sell the exploits you find for more.
gosub100 2 days ago [-]
> researchers shouldn't hold bugs for ransom or demand high payment.
why? google removed don't be evil off their charter a long time ago. why shouldn't security researchers also seek to maximize profits?
fuzzfactor 3 days ago [-]
>researchers shouldn't hold bugs for ransom or demand high payment.
Hell no, the same level bugs at Google should be enthusiastically paid way more than from an undercapitalized startup, who actually needs the help more so. Should be orders of magnitude difference in relation to scale.
>it makes sense to pay them what the bug's actually worth.
Honest fair-dealing should come into play at least but there are some players who have struck it so rich they can now take enough pride to pay an additional premium just because they can, and their good human nature almost compels them ethically to do way more than the minimum.
Just apparently not at Google.
If a company has achieved financial success to a degree that they are no longer worried about complete failure for the foreseeable future, then it's only a matter of generosity vs Scrooge-like behavior.
What's missing from their overall business acumen if they can't even afford to project an image of generosity yet?
If they're not actively making a serious effort to pay the maximum they can well afford for bugs that are truly serious, there is a technical term for that. Chickenshit.
gblargg 3 days ago [-]
People are free to pool their money and offer higher bounties.
martyfunkhouser 3 days ago [-]
If you really explore the concept of worth, Google "engineers" are grossly overpaid, otherwise they would have found this themselves already.
How many PMs are making more than bug bounties to fetch coffee and bagels?
Their priorities are all out of order.
wilg 3 days ago [-]
Seems like it was worth $1000 to the researcher in question.
3 days ago [-]
3 days ago [-]
Mtinie 3 days ago [-]
> Ethical disclosure is a complicated topic, because researchers shouldn't hold bugs for ransom or demand high payment.
Why not? Capitalism requires they maximize their value. These profitable companies lay bare at the altar, so they should understand the requirements of their god.
noja 2 days ago [-]
> how much do you think this vulnerability is actually worth? How much do you think an organization like Google would spend on, for example, AI tokens or compute to detect this internally before it was found and exploited in the wild?
What? That's not how you calculate the value of something at all.
The value is not based on the prevention, it's the cost of the cure.
avazhi 3 days ago [-]
> Ethical disclosure is a complicated topic, because researchers shouldn't hold bugs for ransom or demand high payment.
I mean, why not?
TZubiri 2 days ago [-]
>Ethical disclosure is a complicated topic, because researchers shouldn't hold bugs for ransom or demand high payment
Why not?
"Hey, I found a cvss 8.8 bug in chrome that allows arbitrary code execution when loading my http url. For X USD I can send a report along, and for Y USD I can send a commit with the fix."
Sounds like a basic contract to me
What I do think is ethically dubious is:
"Hey I found this bug and I will MAKE IT PUBLIC WITHIN 90 DAYS SO LOOK AT IT"
I know it's a convention from 'security researchers', but I think the first approach is more ethical than the latter.
etcetcetcetceta 2 hours ago [-]
[dead]
nullsanity 2 days ago [-]
[dead]
publlus_enigma 3 days ago [-]
Normalising running arbitrary code delivered over the internet (in the form of JavaScript and WASM), as a necessary condition for accessing most web pages may not have been one of the best decisions we have made.
pizlonator 3 days ago [-]
I think the problem is that we've let JS engines become absurdly complex so there's no way to avoid them having really gross bugs.
That said, I think that the V8 team has done a fantastic job of securing their engine. Their heap sandbox feature is really inspiring! It's really wild that (as far as I can understand this issue) someone is able to bypass it.
(Posted from a memory safe browser - WebKit MiniBrowser compiled with Fil-C. Pretty sure this is safer than even V8 and the heap sandbox.)
ruuda 2 days ago [-]
In Chromium you can turn off V8's JIT compiler for this reason. You can even opt in again for sites you trust that need the additional performance.
preg_match 2 days ago [-]
The additional performance from the JIT is actually really small for most tasks. It should, ideally, be disabled by default. For your average JS you get <10% performance gain. Most of the cost is browser API, not JS, so the performance is underwhelming.
It’s only very heavy calculations that see a boost in performance. But, realistically, how many websites require this or currently use this today? <1%? Maybe <.1%?
This is pretty typical across JIT engines, too. PHP also sees only a slight increase in performance from the JIT. Because of the nature of PHP applications, most time is spend on the network and database. Only very CPU-heavy code sees a significant speed up.
That’s even the case for C#, which is why the dotnet runtime only conditionally JIT compiles code. Only hot path code is eligible for JIT compilation.
pjmlp 7 hours ago [-]
That is surely not the case for C#, contrary to most JVM implementations, on the CLR CIL is always jitted before execution since .NET 1.0, and this not taking into account AOT scenarios like NGEN (since .NET 1.0), and everything that came later as AOT toolchains.
The only .NET implementations that interpret CIL were the .NET Compact and Micro frameworks due to hardware limitations, nowadays mostly gone as .NET workloads, and alternative implementations like Mono.
kccqzy 2 days ago [-]
I’ve done that long ago. In fact on iOS it’s simpler: since Apple doesn’t allow third party browsers to use the JIT, using any browser other than Safari will disable the JIT.
acchow 1 days ago [-]
Chrome on iOS has always been JIT'd because it used a WKWebView.
It still uses a WKWebView today, even in the EU, despite Apple now allowing alternative browser engines in the EU as of 2 years ago.
I'm sure Chrome will eventually ship Blink+V8 in the EU. It will take some time
gsnedders 2 days ago [-]
This hasn’t been true in over a decade.
cageface 2 days ago [-]
Do you have any citations for this? Not that I doubt you but I’d like to read more about it.
In synthetic benchmarks, there was a 40-80% reduction in performance when disabling the JIT. But in a simulated test on YouTube.com, the performance delta was only 6%.
This isn’t the best source as it’s a bit old, and it wasn’t just JIT that was disabled. But the core idea is the same: calculation-heavy code can see an improvement, but most code won’t. Why this matters is how people actually use JS on the web. It’s not for cryptography and such, it’s to manipulate the DOM.
We see a similar pattern: in synthetic benchmarks, the performance gain is large. But Wordpress, by far the largest PHP deployment in the wild, only saw ~3% performance gain. It again comes down to how PHP is used. It’s mostly HTML construction and database calls, neither of which will see any performance gain from a JIT. And, PHP has extensions, where most heavy code is moved to. Things like cryptography are done in PHP extensions, in C, where the JIT doesn’t matter. I’m more familiar with PHP, so I’ve known about the history of PHP not shipping a JIT due to the lackluster performance.
a022311 2 days ago [-]
I'm glad I've already done that! I haven't seen any difference in performance like others mention though. Weird. The only override I've made is for a website which needs to run some client-side cryptography code and it would take ages without the JIT.
creshal 2 days ago [-]
> Posted from a memory safe browser - WebKit MiniBrowser compiled with Fil-C. Pretty sure this is safer than even V8 and the heap sandbox.
It's easy to be safer, as long as performance can be sacrificed for it.
vanderZwan 2 days ago [-]
We live in a world where my laptop is forced to waste tons of computational power on immensely bloated websites even with ad-block, with now even having to worry about agentic bullshit that I didn't ask for, and plenty of others apparently still think throwing computational cycles at cryptocurrency is good for anything.
Complaining about a relatively small performance price for Fil-C in that context honestly feels like that one famous newspaper photo of a smoking pregnant woman drinking a beer with a caption saying she's wbrried about the effects of the loud construction noises next door on her unborn child.
Except even that is wrong, because at least she had a point about the construction noises, while this is more of a "refusing to eat your vegetables" kind of situation.
ChocolateGod 2 days ago [-]
We also live in a world where site owners purposely put anime cat girls on their websites that serve no purpose then to waste cpu cycles.
vanderZwan 2 days ago [-]
Using personal websites read by a handful of programmer nerds that work fine if you turn off javascript to justify literally everyone else being forced to navigate bloated, broken company websites isn't particularly convincing as an argument against memory-safe C imo.
tclancy 2 days ago [-]
Perhaps you do.
pizlonator 2 days ago [-]
> easy to be safer
It took over two years and help from contributors to get to the point where WebKit could be made fully memory safe.
odyssey7 2 days ago [-]
When Chromium and V8 are written in a memory-safe language then I might believe this.
Yes, if your JavaScript engine is written in C++, it’s going to be very hard to avoid very gross bugs. We have better options now.
The ability of adversaries to find and exploit very gross bugs in C++ codebases should have already compelled the industry to move to memory safety. Now that AI has democratized the ability to scour C++ codebases for really gross and exploitable bugs, I should think that our hands are at last being forced. I’m not impressed by what I’ve seen in the industry with respect to taking memory safety seriously.
account42 9 hours ago [-]
A JIT by definition bypasses the safety mechanisms of whatever language you write it in. Think before you post.
tsoukase 1 days ago [-]
I believe programmers still write in C(++) after memory safe options, in order to continue being occupied afterwards, fixing the bugs that will arise. Without criminals, police is obsolete.
rvz 2 days ago [-]
Exactly this. This is a never ending problem with C/C++ and it's these same memory corruption CVEs appearing all the time.
I also cringe at projects that "compile C to WASM" and then believe that it is immediately "memory-safe". (It really is not.)
The only exception for C/C++ projects is Fil-C which that is memory-safe. New projects at this point should just consider using Rust instead.
heresie-dabord 2 days ago [-]
> WebKit MiniBrowser compiled with Fil-C
Sir, do you happen to have instructions for doing this? We who benefit from your philanthropy salute you.
dingdong2026 2 days ago [-]
My thought exactly.
Which is why I have NoScript in my Firefox and have gotten used to manually enabling javascript for select pages. Small price to pay.
Unfortunately the web is full of trivial websites that have no business running javascript. Recently wanted to read the famed post on Gates Notes. But for some reason Bill requires javascript to render text and images. Which reminded me Bill is not a person with good judgement on matters of IT and policy. Time saved.
razemio 2 days ago [-]
Wow... I understand your point but if you feel that strong about gates using js on his personal website, it is a bit harsh isn't it? Could have multiple reasons why it is needed. Especially for someone with such a huge follower base. Lazy loading, tracking, client based adjustments, using a framework, fun [:)]... I could go on with a 100 more points why js might be needed.
dijit 2 days ago [-]
I know that this is sarcasm, but there are people who really think this.
They get emotional (usually angry) when you tell them you disable javascript- as if every site that serves any kind of content has an automatic entitlement to run arbitrary code on your computer.
choo-t 2 days ago [-]
HTML has lazy loading.
There not a lot of reason to not have at least a fallback to serve your text-only content without JS.
razemio 2 days ago [-]
That is true, but it is very basic and depending on the browser how it is implemented. On traffic heavy sites, which I assume gates blog is, js gives you full control over what get loaded when and at the same time enables tracking how far the user read the article and which parts he most likely skipped.
I am not saying that this is good, however if you have these requirements js is a valid choice.
ndriscoll 2 days ago [-]
Basically no one has a requirement to track what someone else is looking at. In fact, if not given explicit consent by the person being tracked (like they've specifically sought you tracking it for them, e.g. marking their place), we should frankly criminalize it. Mass surveillance should result in jail time.
killerstorm 2 days ago [-]
I don't think there's any valid reason to _require_ JS on a static web site unless interactivity is the whole point.
flippingheck 3 days ago [-]
> decision we have made
This might oversell the agency that practicioners have.
Sandboxed zero-install delivery will outcompete anything with more frictionful installs.
It's probably not the right model for a pacemaker though.
Web/JS has been a double-edged sword for FOSS: sure, I can run a free OS, but if most of my "apps" happen to be JS that I can't practically control, then I have won a battle and lost a war.
JacobKfromIRC 3 days ago [-]
I wish Haketilo [1] would have caught on more. There's so many free JavaScript apps but we're mostly just missing a way to actually control which version or derivative of the JavaScript is run.
There's also the problem of most free apps not doing a good job of providing license info and a link to source code, but this could be sidestepped by a trusted repository which provides license info itself.
Running code by itself isn't that bad, it's the fact that browser developers have decided for some reason that this code needs to be as performant as possible, so, JIT.
I don't get it! The way JS is typically used, it doesn't even benefit from JIT all that much. Making ajax requests, doing stuff with strings, and moving DOM elements around doesn't need every CPU clock cycle to be used as optimally as possible. It's exceedingly rare for websites to actually be doing something that needs raw performance. And SPAs will be slow no matter what.
varenc 3 days ago [-]
I disagree about JIT performance not mattering. I enabled "Lockdown Mode" on iOS which disables the JIT for the mentioned security reasons, and it causes a very noticeable lagginess on many sites. Of course, the primary cause is the unnecessary JS monstrosities wasting CPU cycles. But practically speaking I can say that disabling the JIT results in a very subpar experience of many JS heavy pages.
Rohansi 3 days ago [-]
It will also increase power consumption because your CPU has to do more work to run the same code.
timr 3 days ago [-]
That's largely because a lot of developers have made the devil's bargain of replacing standard web stuff with badly re-implemented JS versions of same. People did it because they could, but never considered if they should.
See most of the ecosystem around React, for reference. It's idiotic that things like URL management are done in Javascript. Or form controls. I guarantee that if we stopped doing this kind of stuff, JIT wouldn't matter.
To some extent this is just saying "developers will depend upon the performance given to them", and that's true, but it's also true that as soon as things like V8 and Node appeared, JS became ubiquitous. Pandora's container, if you will.
grishka 2 days ago [-]
> See most of the ecosystem around React, for reference.
I've never used React myself, but what I've heard about it makes me question my own sanity. So are you going to tell me that instead of just updating the DOM tree directly I'm going to apply the changes to my data, then pass the entire model to the framework, which would then diff it with the previous version to get the changes back out, it would then call my functions that return components, and it would then diff the virtual DOM to find out what changed, and only then would it update the actual page? Why the fuck would anyone ever want that? What's so hard about simply changing the innerText or inserting elements or whatever?
Oh and now Google and Apple are insisting that this is the way to do UIs in native apps as well, with Compose and SwiftUI respectively.
The way the front end developer community seems to largely encourage learning top-down isn't helping either. I'll forever remember that one guy we made a small project with. He learned React but had no clue what "send a request" and "pass a parameter" means, and I had to explain him how to use XHR.
leptons 2 days ago [-]
The DOM is the slowest part of the browser. It's not Javascript, it's the DOM. React is an attempt to manage the slowness of the DOM. One seemingly small change to a page (like setting innerText) can have many ripple effects with reflow on mamy parts of a page.
With thousands of DOM elements on a page, the DOM becomes a bottleneck. This isn't the fault of front-end developers, and it's not really the fault of browser developers. HTML/CSS/JS is a very powerful system, but it's also complex and can cost a lot of compute. When you understand this, then the reasons for React and other front-end frameworks become easier to accept.
grishka 2 days ago [-]
> One seemingly small change to a page (like setting innerText) can have many ripple effects with reflow on mamy parts of a page.
I haven't looked into how browsers actually do it, but my mental model for it is that if something changes, this merely sets a flag on that element or its parent that its layout is not valid any more. Then, on next vsync, all the elements that have this flag set have their layout recalculated, potentially going up the tree as necessary. The only exception is if your script tries to get any layout-related property, e.g. offsetWidth. Then, as if as part of the getter of such a property, the layout recalculation will run immediately.
That is to say, if you need to make a lot of changes to the DOM, you should make them within one JS invocation so only one layout pass happens sometime after you're done.
timr 2 days ago [-]
OP here. The steel-man argument for React is not that it is faster at rendering. It cannot be, because it ultimately relies on the same DOM that everyone else does to do the job, and it has to set up a massive JS data structure to do what it does, which uses a lot of memory and has big GC costs. Arguments that assert that the React virtual DOM are faster than the native/shadow DOM are simply wrong [1]. Even the React team admits this [2] (though back in the day, they made a number of puffed-up claims about speed that never made sense).
The principle argument in favor of React today are developer ergonomics. People don't have to manually alter individual elements anymore -- they just describe state, and React takes care of the UI change set. On top of that, you have components, etc., that are debatably more pleasant to work with, and at the least create an ecosystem advantage for users of the framework. One can certainly see the argument for something like facebook, where there are probably dozens of different things changing independently at any given time.
But that said, one really has to question whether React makes sense anymore, given LLMs. Back when the alternative was that someone had to bespoke code every UI component, it might have been worth taking the hit of having to adopt the entire React ecosystem. But now that LLMs are writing the code, there's really no argument for developer ergonomics, and suddenly, things like "rewriting URL handling in JS" are pure liabilities.
[1] Though sadly, many front-end devs don't know this.
Well, I'm an old-school guy. I'm all for developer ergonomics, as long as they don't affect the runtime. I use PostCSS and TypeScript in my own projects precisely for this reason, because they both make things more convenient for me yet leave no trace in the finished product that the users see.
> But now that LLMs are writing the code
Hopefully that's a temporary state of affairs and everyone will eventually go back to writing code by hand. I've never even considered using an LLM to get my job done, the whole idea is as alien to me as are these types of UI frameworks. To me, the best language to describe what you want from a computer isn't English, it's a programming language.
leptons 2 days ago [-]
>But now that LLMs are writing the code, there's really no argument for developer ergonomics, and suddenly, things like "rewriting URL handling in JS" are pure liabilities.
The popular coding AIs go down all the time. Last week all of them were down at the same time. If there's a bug causing losses of thousands or millions of dollars per minute, do we really want to let the LLM write incomprehensible code?
2 days ago [-]
exe34 2 days ago [-]
You may not need react. If you want to make the smallest possible change to the dom to reduce latency, then make the smallest possible change to the dom. Choose solidjs. (Not a sponsored post).
marcosdumay 2 days ago [-]
> Why the fuck would anyone ever want that? What's so hard about simply changing the innerText or inserting elements or whatever?
It's so that you have the page reflecting your data at all times.
The browsers should have been written this way, instead of having byzantine update functions with all forms and a pair of *Text to rule them all. But creating it in Javascript is a really bad idea.
tgv 2 days ago [-]
The problem is not url management. That should happen just once or twice during the life cycle of a page. If it takes 0.1ms or 1ms doesn't have any impact on the usability.
One of my problems was that I wanted to show data in the browser. It is a convenient delivery platform, after all. However, Chrome (and Chrome in particular) has tremendous trouble displaying large pages. A 400x400 table takes a long time to render. I could solve that in JavaScript. I had to, really.
So, as practically always, the problems stem from a combination of factors, and bad programming definitely is one of them.
2 days ago [-]
vickychijwani 2 days ago [-]
That's largely because a lot of developers have made the devil's bargain of replacing standard hardware and OS primitives with badly re-implemented C versions of same. People did it because they could, but never considered if they should.
See most of the ecosystem around modern systems software, for reference. It's idiotic that things like memory layout and bit-level hardware management are done in C abstractions. I guarantee that if we stopped doing this kind of stuff, compiler optimizations wouldn't matter.
To some extent this is just saying "developers will depend upon the performance given to them", and that's true, but it's also true that as soon as things like compilers and standard libraries appeared, C became ubiquitous. Pandora's container, if you will.
timr 2 days ago [-]
> It's idiotic that things like memory layout and bit-level hardware management are done in C abstractions. I guarantee that if we stopped doing this kind of stuff, compiler optimizations wouldn't matter.
Cute, but no, not even close to a good metaphor. The C example is abstracting away fundamental complexity in a new platform. The other is completely re-writing -- in duplicate and slightly broken -- what the platform gives you for free. There's nothing about implementing form controls or URL management in JS that is more abstract. It's just different; a downstream bad decision that branches off a long tree of other bad decisions.
The equivalent level of idiocy in a C-related metaphor would be...I dunno...if you decided that you didn't like the way that header files worked, and decided to keep the C compiler, but build an external header-file management system in Fortran [1] that calls the C compiler for you. Or even closer to the JS metaphor, you shipped a special C compiler that had an embedded interpreted language that only activated at compile time, and you then used that language to allow any user to fundamentally change the syntax of C.
(It hopefully shouldn't be lost on you that this exact approach to language features has been repeatedly tried in the javascript world, including right now, with package management. But see also: typescript, coffeescript before that, Dart, etc. Javascript is a mess, and history repeats itself with regularity about every 5 years.)
[1] ...and then you re-write that about sixty times, each time being slightly incompatible with the last, and all having different fundamental incompatibilities with C headers.
cookiengineer 2 days ago [-]
you are talking about the effect, not the cause.
Sites are slow because with all that excess performance they do more tracking, instead of keeping the website as-is.
Because that's the only thing business managers can come up with in that situation. It's a misaligned goal of users vs businesses.
In my opinion the "user agent" behavior of browsers is long gone, because they're not acting on behalf of their users anymore. They're acting on behalf of businesses.
mark_l_watson 2 days ago [-]
I have used Lockdown mode also. Not that inconvenient but I didn’t mind the slight no JIT slowdown. I did find not seeing some images annoying.
cute_boi 3 days ago [-]
Agree. Chrome should just disable JIT by default and boom many website owner will start to optimize their website.
andrekandre 3 days ago [-]
jira and confluence come to mind...
macintux 3 days ago [-]
I suspect the people who agree to buy Jira & Confluence are not particularly heavy users of them. At least, that's the only explanation I can fathom for their continued sales.
DANmode 2 days ago [-]
Enterprise Software
DANmode 3 days ago [-]
Is it their app’s features that are slow, or the analytics bolted on top?
shakna 3 days ago [-]
Both. And all the dependencies of both are slow. And the dependencies of those are slow, too.
DANmode 3 days ago [-]
> SPAs will be slow no matter what.
Uh…no?
You’re presumably talking about specific terrible prebuilt frameworks - not someone building a nice vanilla SPA.
realusername 2 days ago [-]
I've never seen an SPA which scales properly and doesn't become a bloated mess, maybe that's possible but it's definitely harder to make it work than using traditional server side template rendering
DANmode 2 days ago [-]
Plenty of app usecases don’t need to “scale” - immediately or ever!
realusername 2 days ago [-]
That's a good point but you never know that from the start, "this app won't scale well" is a hard sell for a new project in my opinion
DANmode 2 days ago [-]
Especially today, single-user stuff, especially in categories of things like health,
especially when you’re writing your own stuff,
that’s when you know from the start that scaling doesn’t matter! =]
Related, and more powerful than my comments in this thread are going to be:
I don't only mean "scale" in terms of users but also scale in terms of features.
So you have to guarantee that your product will stay low users and low features forever or spend a very high effort to try to partially overcome that block when you change your mind.
And guaranteeing that it will stay low features is much harder than low users I think.
In exchange for that you get a better talent pool for recruiting but does that matter if your product has to stay low scale anyways?
DANmode 14 hours ago [-]
Or you have to distribute your code in such a fashion, and structure your business model in such a way, that “scale” doesn’t require you doing things that have nothing to do with providing the feature set (most SaaS).
realusername 11 hours ago [-]
I'm currently working on a SaaS at my company and we have a lot of issues because of the SPA, I estimate we spend around 5% at least, maybe 10% of the workforce just on SPA complexity.
It can work for some SaaS but if you stay low employee count, low users and you have a core feature used everywhere in the whole product and nothing else
DANmode 9 hours ago [-]
What’s the stack? Is it being used even sort-of in the right place / way?
Feels like a glaring omission =]
realusername 8 hours ago [-]
The stack is Rails / React SPA for the frontend.
> Is it being used even sort-of in the right place / way?
It's a SaaS where users are mostly always logged-in, kind of an app so you would think it should work from the outside.
I think these are the full requirements I would put for a good SPA experience:
- low users
- low number of features / or a single main feature reused in different ways
- low number of employees
- it's an app and not a website
- you don't have any users living in remote places / poor internet connection
- users are all using modern browsers and can be asked to switch to another one if needed
And I think in my company we only have one of this list, making it painful.
grishka 3 days ago [-]
At this point SPA pretty much implies React. But even if you optimize everything the best you could and avoid any third-party runtime dependencies, it's still going to be significantly more work to make API requests and do client-side rendering vs just rendering HTML server-side.
dvdkon 2 days ago [-]
Not always. Consider an SPA that connects via WebSockets and streams in data, adding points to a chart. The JS-less alternative would be refreshing an SVG or even the whole page once a second. The SPA is clearly more efficient here (unless someone screws it up badly).
grishka 2 days ago [-]
I wouldn't consider that an SPA at all, it's just a page with an interactive element. An SPA is something that renders everything client-side and uses a generic client API to talk to the backend. A telltale sign of an SPA is that the first thing you see when you open it is some sort of loading indicator instead of the actual page you're visiting.
DANmode 2 days ago [-]
No, the telltale sign of a SPA is that it’s an app that’s a single fucking page, lol
Please stop changing the definitions of explicit words and phrases - to anyone reading this!
preg_match 2 days ago [-]
Right but the implication of a SPA is that it’s an application which has many logical pages, but only one real page. The logical pages are constructed by dynamically updating the DOM using JavaScript. As opposed to navigating to a new, server-provided page.
For example, a search function. For a MPA, each search query would be a new page. For a SPA, each query is a new logical page, served on the same real page.
Technically yes, a SPA may have minimal client side rendering. But then it’s not doing much of anything at all - it’s just a site. When people say SPA, they typically mean an application with client side rendering.
DANmode 2 days ago [-]
> it’s just a site
sigh
…does someone else want to finish this up?
preg_match 2 days ago [-]
This reply means basically nothing to me or anyone.
To expand on what I mean, if the implication isn’t obvious: a SPA with no client side rendering is just a single HTML page. It’s a document, not an application.
So SPA naturally implies client side rendering.
The difference between a SPA and MPA isn’t the amount of pages, they both have about the same amount of logic pages. It’s about where those pages are rendered. Dynamically on the front end, or on the back end.
EDIT: okay okay to expand, my website has a contact form. With JS enabled, the form submit displays a little box that says “thank you for submitting”. With JS disabled, it navigates you to a “thank you for submitting” page.
Both are the same logic page, they have the same function. One page is just rendered client side, and one server side. Most websites or applications are hybrids. There’s very few true single page applications, and very few true multi page applications. Most SPAs have multiple real pages for different things. Most MPAs combine multiple logic pages into one real page.
DANmode 2 days ago [-]
Single HTML files / pages can be fully-featured, full-purpose-fulfilling applications.
> Most websites or applications are hybrids.
and some are emphatically not.
But…where were you going with that?
preg_match 23 hours ago [-]
The features of HTML are still greatly limited. You can’t really create applications with just one HTML page and no client-side rendering. You can play a video, sure, but that’s not an application. You can also do magic with CSS but that’s an experimental fun thing, not a thing people actually do.
As soon as you, say, use JS to update the DOM or a canvas, I consider that client-side rendering. That you can do, and that would be a SPA.
But I’m curious, what are some examples, even hypothetical, of applications consisting of one HTML page? I don’t think I’ve ever seen it.
DANmode 14 hours ago [-]
You can inline the following in one HTML page:
CSS (.css)
JavaScript (.js)
Plain Text (.txt)
HTML (.html)
SVG (.svg)
Raster Images (.png, .jpg, .jpeg, .gif, .webp, .bmp)
Audio (.mp3, .wav, .ogg)
Video (.mp4, .webm)
JSON (.json)
PDF (.pdf)
plus bring in other source resources as needed.
To answer your question:
The installer for GrapheneOS / Google Pixel phones is an “SPA” (or “webapp”).
I’ve seen bespoke fitness trackers of all kinds,
appliance control apps,
budget and pace-tracking stuff,
basically all of what computer programs used to do - before we started dynamically loading a ton of extra stuff onto the screen that nobody needed to do the task they came to do.
grishka 2 days ago [-]
By that definition, Smithereen, my fediverse server software, is also an SPA, since it does what I call "ajax navigation" on desktop, so that the notifications websocket doesn't get disconnected and reconnected every time you click a link. It's technically a single page that gets most of its content replaced at runtime when you click a link, after all, right?
DANmode 2 days ago [-]
Yes.
Could you point out where you think the gotcha is? I can taste the tone.
Just because a bunch of engineers applied implicit meaning that didn’t exist to a very literal phrase for a few years doesn’t make it correct.
Doesn’t make webapps inherently bad.
Doesn’t make SPAs bad.
DANmode 2 days ago [-]
> At this point SPA pretty much implies React
At this point, app pretty much implies React - ask an LLM for an app and see if that’s not what you get.
robalni 2 days ago [-]
That's basically the comment I was just going to write but you made me not need to.
We need simpler protocols and formats, especially those that are used over the internet.
I want everyone to really start fighting for this.
I always use a browser that doesn't run any scripts (w3m) for both this reason and others.
It hurts when I see websites that don't work without js.
A bit funny though that this page is one of them so I was not able to read it.
phoghed 2 days ago [-]
We have them, and have had them for a long time. Nobody wants to use them.
throwaway27448 2 days ago [-]
> Nobody wants to use them.
Wikipedia is basically the most popular application of all time and it doesn't rely on javascript. People just generally don't give a shit about where their money goes.
phoghed 2 days ago [-]
I don’t think the parent comment was talking about html, css, and https. Rather something like Gemini.
heresie-dabord 2 days ago [-]
> People just generally don't give a shit
The whole biosphere is over there in the corner, weeping.
Levitating 2 days ago [-]
> We need simpler protocols and formats
But we do! It doesn't get much simpler than HTML/CSS/JS. It's just abused to make apps instead of web documents.
antonvs 1 days ago [-]
There is no possible interpretation under which JS fits “simpler protocols and formats,” and no world in which JS could form part of a truly secure network client environment.
christophilus 2 days ago [-]
Hm. HTML, maybe. CSS and JS? No way. View the CSS here sometime:
That you can do complicated things with it does not make it complicated.
zahlman 2 days ago [-]
And people ask me why I complain about web pages failing to display basic content without JS.
(I keep WASM and WebGL disabled in Firefox settings, too. Yes, I had another post ITT questioning why those things are any less secure than the JavaScript, given that they're supposed to be in a sandbox. But you know, defense in depth. It's insane that we're expected to put up with these grossly unnecessary risks all the time. Just like how it's insane that frontier models are being tested in environments that are physically capable of connecting to the Internet at large.)
xorcist 2 days ago [-]
Things such as WASM and WebGL should really be click-to-play, just like media files are.
I am decidedly uninterested in those features for most web pages I visit. Should they be able to spin up my CPU fan just for that I would consider it a misfeature. Just like a movie on high volume would be.
If anyone familiar with Firefox could implement that or point in the right direction, that would be most welcome.
ptx 2 days ago [-]
Before JS and WASM we had arbitrary code delivered in the form of ActiveX components, Java applets and Flash applications, which were much worse. At least now we have multiple open source implementations of the runtime.
IshKebab 2 days ago [-]
Rubbish, it was a great decision. So many websites wouldn't have been possible otherwise - Google maps, YouTube, ChatGPT, WhatsApp, etc. etc.
Do you remember what the alternative was? Flash, Java, ActiveX. No thank you.
Sure security is difficult but vulnerabilities of this magnitude are rare. If anything the lesson is don't write highly security sensitive software in C/C++.
asveikau 3 days ago [-]
I remember noticing this shift in nerd culture. In the early 2000s, it was common for people to say on places like Slashdot that they don't trust JavaScript and run their browser with it off. In the early 2010s, I noticed HN commenters thought this was insane, tinfoil hat type thinking.
Espressosaurus 3 days ago [-]
It became insane because nothing bloody worked without Javascript some time in the early 2010s.
Like cellphones, javascript became necessary if you want to use webmail, access your bank's website, or whatever.
ThunderSizzle 3 days ago [-]
I still run with u matrix though, and most third party requests can be limited, but I no longer have enough patience when a required page doesn't work - I'll just rely on ublock origin to work.
nixosbestos 3 days ago [-]
I say this as someone does NOT disable JS in my main browser (because like, I have a job), but also knows a fair bit about why Firefox inside Tails now restarts in some cases...
It's the classic thing. Across every gdmf metric, excluding with "true empathy", no one *gives a fuck* until it affects them, or someone within (1-3) degrees of separatation. And having broad empathy is generally a good way to get yourself labeled/astrocized: both about as obvious "compriate" and obvious "adversary".
dbdr 2 days ago [-]
Is compriate a typo, a neologism? I could not find a definition.
abanana 2 days ago [-]
The end of that post came out in such a mess, it must be a typo for something - "compatriot" maybe? I like the other standout neologism in there though, I can see it in a dictionary now:
astrocized - banished to outer space.
nixosbestos 2 days ago [-]
the end of that post sure did turn out a disaster and I'm not even sure what I meant. Pretty... awful.
I do know how to spell ostracized ? I'm not sure if that's what I meant? Truly a mess.
xorcist 2 days ago [-]
... or just use Google even.
bawolff 3 days ago [-]
In fairness, in the early 2000s they were probably right. Early browser security model was a bit of a mess. The fact that this article is even talked about is a sign of how much better things are.
Rendello 3 days ago [-]
Plus add in Flash and Java applets.
bawolff 2 days ago [-]
And ActiveX!
whizzter 3 days ago [-]
I still do "random" browsing in FF with NoScript, that said, I'll acknowledge the frequency of updates of Chrome,etc and years of hardening.
It's not the Bonzi-buddy and driveby-installed IE toolbars wild west of the early 00s.
nik282000 3 days ago [-]
The browsers on the computers at work show that it is very much still the driveby tool-bar install days.
no-name-here 2 days ago [-]
> it is very much still the driveby tool-bar install days
Can you please provide a link to a page where a “toolbar drive-by install” occurs?
Sharlin 2 days ago [-]
In the early 2000s JS was used for silly novelty effects and some rudimentary DOM manipulation with `innerHTML`.
In the early 2010s you had to have JS enabled for many sites to work at all. The cost:benefit equation had became entirely different.
l00sed 3 days ago [-]
It's so ubiquitous and unavoidable at this point.. I was at a conference lecture in 2020 where someone was suggesting disabling JavaScript and I thought the same thing— how absurd. The times have really changed...
eru 3 days ago [-]
In the future we can ask that your JaveScript and Wasm comes with a proof of being benign.
The idea is to make it harder for malicious actors to produce a valid proof than it is for benign actors.
account42 7 hours ago [-]
It does that: malicious actors would not be compliant with the spec.
muvlon 2 days ago [-]
What would that even look like? What is "benign"? The browser environment already has pretty strict rules for what the JS can do. It's not allowed to read your files, see your webcam without permission, know about other tabs or windows etc.
The problem here is that the browser failed to correctly implement those rules. If the chromium team cannot do that, what makes you think they can implement any other kind of "benign code" verification with zero bugs?
eru 2 days ago [-]
To give an example that goes beyond what you already suggested:
You can prove that your code terminates (or rather responds to events in a finite time, even if the event loop itself runs forever.) Or you can even prove that your code reacts quickly, ie within some time limit. You can also prove memory limits.
> The problem here is that the browser failed to correctly implement those rules. If the chromium team cannot do that, what makes you think they can implement any other kind of "benign code" verification with zero bugs?
Defense in depth. And you can have competing implementations relatively easily for this, and another way to find and report bugs. Especially if the verifier is open source.
The verifier itself can be pretty simple: it's the prover that's complicated and needs smarts, but that's being run on the author's computer, not in the user's browser.
account42 7 hours ago [-]
In practice it would be "big tech has provided a digital signature that the author has paid the required software tax".
account42 9 hours ago [-]
Yes it's been a disaster for accessibility, compatibility, interoperability, energy efficiency and computing freedom (good luck using a Browser not approved by Buttflare).
The security implications are just the cherry on top.
tcdent 3 days ago [-]
V8 as a runtime goes far deeper than just webpages.
DangitBobby 2 days ago [-]
Controversial opinion on this website ;)
throwaway27448 2 days ago [-]
At this point it doesn't even feel good to flex evidence of a warning
But, anyone who thinks we need JS for a functional internet is fucking retarded
ruuda 2 days ago [-]
> Type confusion in V8
Fortunately I disabled js by default. Unfortunately, it breaks about 30% of the web. Including nvd.nist.gov, which shows a completely blank page without js enabled, even though with js it’s just a simple page with only static content.
terseus 2 days ago [-]
> Unfortunately, it breaks about 30% of the web.
More like 99%
I use Firefox with Noscript and I'm _totally aware_ that almost no website works without allowing it JS.
Even using Noscript it's becoming more and more exhausting every year, it's plain impossible to browse the internet without JS at all.
account42 7 hours ago [-]
This is a gross exaggeration. More than not, random websites still work without JS for basic content but a few big ones don't.
Culonavirus 2 days ago [-]
The problem is that a lot of frontend web dev is driven by the React ecosystem which requires you to have SSR figured out for "no js on the client" to even partially work, which, if you ever tried to go all the way (e.g. RR v7 w/ full SSR) in a not-a-toy project, is not easy to set up and think about by any means, because your server has to be a js one at which point your entire server-side solution consist of node or node-like js server, postgres or mysql (with pooled connections through something like mysql2 and probably drizzle), something for caching like Redis, some complex process manager like pm2... i say complex because if you want to have a high performance fault tolerant gracefully restarting automatic new code deploying system ... and all of that with caching layer(s), Redis sending cache updates without you polling etc., you have to implement and test these yourself... Everything async and thinking in long term running processes and thinking about the async loop instead of a "php-like" model. Components being a potential source of memory leaks, thinking about components having to work on client and server environments, keeping SSR performance (in the sense of component rendering complexity) up etc.
This is not something just anyone is going to rush into. Bigger teams or js/ts evangelists will eventually arrive at that point if they're running something where no-js (really a side effect of seo goals) is important, but "normal people" will spend this time and engineering effort elsewhere.
I think the industry in general is moving past React, as now, and definitely in near future, the only thing that matters is ideas, the rest is for the LLMs to figure out, and so the "frameworks" are going to completely disappear from people's minds as "programming" essentially becomes "telling the AI what to do" and the AI writes asm or even binary. That is when, no JS, may become more viable again lol.
People, including me, resist it, but in the future "programming" is not going to be about writing code (or even checking it, we're way too slow and error-prone to do that), but about coming up with ideas of how to capture real world problems in an IT system, and how to solve those problems by existing (or novel) ways, picking the right tools for the job (say a statistician picking the fitting metric to capture some property of the system that will actually project meaningful observability improvements and not be "just a bunch of noise") and making the right architectural decisions in terms of correctness, performance, scope, taking into account deadlines and budget. And being the domain model glue. Everything else, all the nitty gritty we used to call programming, all the <insert a quadrillion of CS jargon keywords>, is going to be done by AI ... it's a mag 9.5 quake tsunami and it can't be stopped now.
This might completely wipe out things like React (which are largely made for humans writing the code, not for humans consuming the output of that code) faster than anyone thought possible.
gib444 2 days ago [-]
> Unfortunately, it breaks about 30% of the web
Only 30%? In 2026? With CloudFlare and Anubis et al absolutely everywhere? Not to mention SPAs
account42 7 hours ago [-]
CloudFlare is a fair point though it depends on the threat level set by the website and how much CF doesn't like your browser fingerprint. In many cases it will just let you through without scripts.
Anubis is trivially bypassed by an extension.
ruuda 2 days ago [-]
Right, Anubis is a fair point, that has for sure been rising in recent months. Often when I get an Anubis page, I am reminded that I was doomscrolling and that I did not want to see the page that badly anyway, and I close the tab.
internetter 2 days ago [-]
> Unfortunately, it breaks about 30% of the web.
Only 30?
ruuda 2 days ago [-]
I think my subjective feeling is in that ballpark, yes. There are of course many sites that are more like web apps that require js, but those are relatively trusted, I added exceptions for them long ago. For sites that I visit for the first time, I think more than half still work to some extent. Maybe they are slightly broken, but at least I can read the page. I’d say around 20–30% of the web even gets _better_, because you don’t get ads or cookiewalls. But then there are also many sites that just remain a blank page, not even showing a message that js is required. (And as the sibling comment points out, recently Anubis is also becoming more common; maybe in recent months it’s closer to 40–50% unusable.) When I hit that, often I am reminded that I wasn’t that interested anyway, and I close the tab. So maybe it’s more than 30% that breaks, and a more accurate statement would be “of the sites where I ended up reading a page, I had to opt in to js about 30% of the time”.
baobabKoodaa 2 days ago [-]
People who disable JS are very likely to have delusions like this.
odyssey7 2 days ago [-]
How many Heartbleeds[1] must software users and our national security interests endure before the industry treats memory safety as a best practice for systems with exposure to the Internet?
The V8 vulnerability being exploited today, CVE-2026-85046, is listed in NVD under CWE-843, "Access of Resource Using Incompatible Type ('Type Confusion')."[2] On this class of vulnerabilities, MITRE explains:
> When a memory buffer is accessed using the wrong type, it could read or write memory out of the bounds of the buffer
Memory safety is specifically intended to prevent errors like these from becoming arbitrary out-of-bounds memory access and native code execution. Even type safety --- from the 1970s --- can prevent type confusion.
The CISA and the NSA have called for the adoption of memory-safe languages.[3] We exercise poor engineering judgment and poor ethics, as an industry, when we continue to expose users to classes of wholly avoidable security weaknesses in Internet-facing software.
If including JIT in a system renders its developer incapable of guaranteeing memory safety, then perhaps that developer’s approach to JIT is not yet mature enough to ethically distribute to non-technical consumers who are not positioned to evaluate that their security is being traded off by the developer on their behalf.
We’re past the era where security issues emanating from memory-unsafe code were tolerated due to being unavoidable — continuing to expose your software’s users to them in this present day and age is simply a choice.
jaen 1 days ago [-]
You're just offering non-helpful ivory tower criticism without even understanding the problem space (which is actually one of the hardest open research problems in software engineering, cs.PL + formal methods).
But if I'm wrong, dare say, how would you write a production memory-safe JIT compiler today?
odyssey7 1 days ago [-]
If I couldn't guarantee memory safety, I wouldn't. We're talking about an optional feature for JavaScript engines.
Security is where the rubber hits the road. It's whether customers' identities get stolen. It's whether leaders of undemocratic countries can monitor communications, locations, and social networks of people whom they oppress.
Calling this an "ivory tower" criticism is, ironically, a lack of acknowledgement of reality and that our actions have consequences to others.
dundarious 2 days ago [-]
Type confusion bugs exist in Rust programs too, the language does not eliminate all such issues (though it does help somewhat). I think it would be more prudent to wait until we have details before getting on the soapbox.
wavemode 2 days ago [-]
This was a type confusion bug in generated JIT code, not in C++ code.
Retr0id 2 days ago [-]
How do you write a performant memory-safe JS JIT?
richdougherty 2 days ago [-]
You probably need a programming language more powerful than Rust that can encode and check the complicated invariants needed by the JIT.
There are classes of type system—"dependently-typed"—where you can encode arbitrary predicates into the type checking. I've remember seeing examples where they could prove arbitrary facts at the assembly level, including self-modifying code. Lean is such a language, currently very popular, but there are others.
Correctness of such programs depends on some basic assumptions about the CPU/memory environment, which should work absent hardware bugs like speculative execution or side channels. Although these could probably be encoded as well, and accounted for.
Without such a general proof language, you could probably make a special language to support JIT development, although its type system would be very complicated and the language itself could be a source of bugs.
Given such languages or proofs (maybe tractable now with AI-assisted theorem proving), you can actually make insanely performant code, since you don't really need to rely on other runtime protection so much (although maybe a good idea still).
2 days ago [-]
dchest 2 days ago [-]
There's more to it than just using a memory safe language.
2 days ago [-]
no-name-here 2 days ago [-]
[dead]
no-name-here 2 days ago [-]
Is the HN title true that it affects all "all Chromium versions"?
Per OP link, it only affects Chrome versions prior to .82; .82 was released as stable 2 days ago. [1]
(HN title also does not match the original title, which is the CVE ID -- not particularly intuitive.)
Not to downplay the severity (patch your browsers!), but there have been 5-10 actively-exploited V8 type confusion vulnerabilities in the last year. I'd be curious if this one blew up because it was the only one that was posted, or if it barely crossed some line in the collective consciousness this time around.
RA2lover 2 days ago [-]
I think it's the first one where the Chrome version fixing it has no Manifest V2 support at all.
throwatdem12311 3 days ago [-]
I’m so tired. I think I’m just going to get a job as a garbage man and cancel my internet.
Sha1rholder 2 days ago [-]
Don't. Garbage Collector hurts your memory
dgellow 2 days ago [-]
GC doesn’t hurt, you just need to stop the world, do a cleanup, and you’re good to go :)
neogodless 2 days ago [-]
Sometimes you want nothing more than to make room for new memories.
throwatdem12311 2 days ago [-]
I kinda want to just forget things though.
iammrpayments 3 days ago [-]
They just released a CVE for a garbage truck vulnerability where an attacker could brick the vehicle by exploiting the telemetry system these things now have preinstalled in factory.
jdironman 3 days ago [-]
Sounds like much needed downtime for the person slinging the garbage then.
jesse_dot_id 3 days ago [-]
There's been a Chrome CVE like every week ever since it came out.
bombcar 2 days ago [-]
You've not watched the poor guy have to reboot his truck, have you?
Is graphene even affected? JIT is disabled in default configurations.
drewfax 1 days ago [-]
That's how the system or browser should be configured. Secure by default and any insecurity must be an opt-in. But Google won't do it because their websites are JS heavy monster trucks and millions of websites run their tracking scripts which require JIT enabled by default for optimal page load.
d2kx 3 days ago [-]
This issue is already fixed in Google Chrome (152.0.7977.83)
azakai 3 days ago [-]
TFA says
> Type confusion in V8 in Google Chrome prior to 152.0.7977.82 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page.
So it was fixed in 152.0.7977.82 (before .83), if I read that right.
ttsiodras 3 days ago [-]
You read that right. From the article:
"Affected products: ... Up to (excluding) 152.0.7977.82"
.82 is fixed.
chuckadams 3 days ago [-]
The release version just now updated to 152.0.7977.83 which has the fix.
fmajid 3 days ago [-]
I upgraded Vivaldi, which is reporting 152.0.7977.112
3 days ago [-]
TZubiri 3 days ago [-]
Why is this 8.8?
It's because User Interaction is Required. CVSS 10 would be the case where everyone can be exploited without interaction.
Interestingly the 8.8 is more alert-worthy than the 9.8 and 10 cvss, because there is a need to be alerted of the current security risk, whereas with a cvss 2 vuln, there is nothing to be done by users, only admins.
mikeweiss 3 days ago [-]
Isn't this exactly why there is a sandbox? What can the RCE actually do or obtain within the sandbox?
socalgal2 3 days ago [-]
Yes, it says right in the CVE
> allowed a remote attacker to execute arbitrary code *inside the sandbox*
mikeweiss 2 days ago [-]
So then what's the big deal? If you had JavaScript turned off it would allow code to run in the sandbox anyway?
3 days ago [-]
nikanj 2 days ago [-]
Doesn’t any <script> tag let you run arbitrary code inside a sandbox anyway?
lima 1 days ago [-]
Inside the JS sandbox, not the browser's outer containment sandbox.
snorbleck 3 days ago [-]
So basically, Edge, Brave and any other browser built on Chromium. Nice.
anonymars 3 days ago [-]
Monocultures are great!
strenholme 3 days ago [-]
There’s a reason I use Firefox (Gecko). Also, Ladybird—another completely different web engine—is really promising. I spent five hours building it from source, having it take about 8 gigabytes of space, and it perfectly renders my own webpages and blogs.
I have a feeling someone’s going to make an open source browser using Ladybird’s engine before Ladybird has official binaries.
tkot 2 days ago [-]
Is Firefox actually safer than Chromium-based browsers though?
The reason why I support Gecko and Ladybird’s engine is because I am opposed to monoculture, however. Even if Gecko (Firefox) is less secure than Chromium (Chrome, Edge, etc.), by not having a monoculture, a Chrome exploit will only take down the subset of people using the Chromium ecosystem, and not affect Gecko users. Alas, most people are in the Chromium ecosystem right now so that means malicious hackers only need to target one codebase.
It’s the same reason I wrote MaraDNS back in 2001—back then, there was only one open source DNS server[1,2] so I wrote another one.[3]
[1] Djbdns was around back then but wasn’t open source, which limited its adoption.
[2] MaraDNS was and is optimized for running at most a few dozen domains on a system running a bunch of other services, where one does not want the DNS server causing security problems for the server, and where the DNS server needs to be lightweight as possible.
armadyl 2 days ago [-]
No. The post applies to Android, but the situation is significantly worse on desktop platforms since Android at least has OS-level sandboxing, etc.
"CISA maintains the authoritative source of vulnerabilities that have been exploited in the wild."
crtasm 3 days ago [-]
This line, I think? >This CVE is in CISA's Known Exploited Vulnerabilities Catalog
esseph 3 days ago [-]
"Google has confirmed that an exploit exists in the wild but has not disclosed information about the threat actors, targeted organizations, or attack campaigns while the update is still rolling out."
basilikum 3 days ago [-]
For what is this exploited in the wild when it doesn't include a sandbox escape?
Is this chained with n-days?
pizlonator 3 days ago [-]
There's a risk that someone had been sitting on a sandbox escape that assumed having RCE inside the sandbox first, and so they'd been waiting for an RCE exactly like this one.
Those folks would not be disclosing their sandbox escape unless they were good guys.
(Posted with a memory safe WebKit, Fil-C FTW)
oynqr 2 days ago [-]
You should add a disclaimer that you are the CEO of Fil-C. /s
In the context of this vulnerability, I doubt memory safety would have made much of a difference.
This is a great reminder though, currently doing a full userspace replacement on my 3D printer and Fil-C might be just what I need for the irreplaceable C parts.
iTokio 12 hours ago [-]
Type confusion, leads to using an object in memory with the wrong type, that means accessing memory with a different layout, like an out of bounds buffer.
So I think memory safety does matter in that case.
pizlonator 2 days ago [-]
How would memory safety have not made a difference?
pizdocalmin 3 days ago [-]
[flagged]
sebstefan 3 days ago [-]
If it's in the CISA known exploited vulnerabilities catalog, tell me if I'm wrong but I assume people don't go around exploiting million dollar 0-days in public just to fuck around safely in a chrome sandbox.
So maybe we're going to see another CVE for the sandbox escape soon?
daveguy 3 days ago [-]
Crypto mining would be one application. But also, combined with a sandbox escape would make it particularly devastating. Usually full control of a device takes at least two exploits given the layers of security present in OS and browser environments.
lima 2 days ago [-]
It would be chained with a separate 0day sandbox escape.
odyssey7 2 days ago [-]
It’s really a shame that my engineering school requires me to use Google Chrome because their Honorlock browser extension[1] requires Google Chrome.
You would think that an engineering school would be wiser than to require their students use a specific web browser that’s tied to a specific vendor.
> You would think that an engineering school would be wiser...
Schools are a business run by administrative staff who make purchasing decisions to solve business problems. Schools love to reduce billable teaching hours through online coursework, which invites academic dishonesty from students, and paying for honorlock is a way to achieve that reduction in expenditure, rather than paying tutors to supervise exams in person.
vhiremath4 2 days ago [-]
It seems like the Chromium issue on their bugboard, which presumably would have the example HTML and vuln patch, is blocked from being viewed. Is this because making it public increases the risk of exploitation?
> Type confusion in V8 in Google Chrome prior to 152.0.7977.82 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High)
What's the difference between "executing arbitrary code inside the sandbox via a crafted HTML page" and running whatever is in the <script> tag?
guipsp 2 days ago [-]
In the script tag you only have access to JS. This allows you to escape JS and have native code execution. It is still sandboxed by os-level primitives, but it is an escalation/first step in successful exploitation.
tkot 1 days ago [-]
I see, so there are certain things that arbitrary native code could try do (let's say, try to execute a certain syscall) that native code produced by the JIT compiler wouldn't normally be able to attempt?
Is this known to be exploitable in any Electron apps, and specifically VSCode extensions?
neuroticnews25 2 days ago [-]
I would guess it's now trivial for attackers to have an llm analyse every new commit to chromium repo linking to an issue that's 403 for security reasons, but maybe I'm missing something.
notatoad 2 days ago [-]
Equally trivial for Google to do the same thing. Is it trivial to do this in a way that exceeds googles own ability to detect flaws?
neuroticnews25 2 days ago [-]
What i meant is analyze fixes for already reported and fixed vulnerabilities before the updated version is pushed to users.
hnav 2 days ago [-]
What do CVEs like this one mean for the likes of fly.io and cloudflare who use V8 for sandboxing 3p workloads? I guess they have some degree of KYC and some hardening outside the sandbox, but chaining this with a container escape running under a free tier account could pwn the host.
Eridrus 2 days ago [-]
You can just ask ChatGPT these questions these days, but it was a fun read:
fly.io depends on Firecracker microVMs, so you should be concerned if you're running untrusted code, but not concerned about other people interacting with you wrt v8.
Cloudflare depends on v8 isolates, which depend on the trustworthiness of the v8 sandbox, which is a non-trivial hurdle, but not an insurmountable one for attackers with the resources to have a v8 bug in the first place.
sans_souse 1 days ago [-]
> just ask ChatGPT these questions these days, but it was a fun read
I'd prefer they ask here. Just saying.
pizlonator 3 days ago [-]
Sounds wild.
(Posted from memory safe WebKit; i.e. WebKit compiled with filcc and all of WebKit's dependencies compiled with filcc.)
kllrnohj 2 days ago [-]
Which wouldn't have actually done anything about this bug fwiw since this wasn't a memory safety issue with any C/C++ code itself
yjftsjthsd-h 3 days ago [-]
Wait, you have that working? What's the lowest friction to run it? Like, VM or docker container or...
Then build WebKit using do_cmake_yolo_simpler.sh in projects/webkitgtk-2.44.3
It's still pretty rough, but works more than well enough to post on HN. My regression test is to post on X. That works too
yjftsjthsd-h 3 days ago [-]
Sweet, thanks. I guess running in a VM is also a bonus protective layer:)
pizlonator 3 days ago [-]
lol yeah
Pls file bugs if you encounter issues.
Also, fair warning, it's hella slow right now on JS-heavy websites (like X). It barely works.
But we can fix that with some effort, I think
achierius 3 days ago [-]
Is that just the MiniBrowser?!
I have to say I can't imagine daily driving that if so. Why WebKit over a Chromium-based (and more featureful) browser?
pizlonator 3 days ago [-]
I'll port Epiphany eventually.
WebKit's JS engine (JavaScriptCore) is super friendly to pointer capabilities. I did not have to change much to make it use the Fil-C GC instead of its own GC and to make it use a capability per JS object.
On the other hand, Chromium's JS engine (V8) does a bunch of crazy stuff with pointer encoding, so the best you could do there is probably a single arena for the whole JS heap.
Also, JavaScriptCore has a well-supported mode that involves not only zero JIT but a fully portable C++ interpreter. Not sure V8 has that.
krackers 3 days ago [-]
For it to be memory safe, do you have to disable the JIT?
pizlonator 3 days ago [-]
Yeah
amluto 3 days ago [-]
It sounds technically possible to build a JIT where a verifier checks that the JIT-generated code is correctly pizlonated before allowing it to become executable. :)
Ohentis 3 days ago [-]
I think it makes more sense to verify that the jit is correct than to verify that it's output is correct at runtime.
pizlonator 3 days ago [-]
Nah
It's damn near impossible to verify that the JIT is correct.
But it is possible to verify at runtime that the code that the JIT emitted obeys some memory safety law.
(V8's heap sandbox is an example of this; a sarcastic JIT would be an arguably stronger example of this.)
amluto 2 days ago [-]
One might argue that verifying the correctness of a JIT is basically the same problem as verifying the correctness of an entire compiler, with the added caveat that malicious inputs to the JIT are expected whereas malicious inputs to a compiler might be seen as rare.
IIRC rustc still has a couple of known soundness bugs, for example. It’s only been a few weeks since someone managed to exploit Lean, and Lean is all about formalizing things :)
Ohentis 2 days ago [-]
If you have a runtime check of some correctness, why can't you just prove that the output of your compiler always passes that check?
pizlonator 3 days ago [-]
Yes
I have a new tech called SaRCAsm, which is a memory-safe assembler. So the next step is a "Sarcastic JIT" :-)
noduerme 2 days ago [-]
Just outta curiosity because I can't find it at a cursory look - what exactly would be the type (coersion?) that would allow v8 to execute arbitrary code? Is this like something in post data to nodejs that terminates early and is able to run exec or something, like unto a sql injection?
timschumi 2 days ago [-]
The Chromium issue is not public yet, so let's go with a very simple example.
Let's say that you have a type confusion bug that (in terms of the interpreted language) allows you to use an Integer variable as an Array.
That sounds nonsensical when just considering the high-level language, but your computer is going to need something to work with when running a script. For an Integer variable it will for example store the value, and for an Array it would store a pointer to a data area (and that area then contains values).
Now, if the interpreter loses track of which type a certain variable is, then it will also not know whether to interpret the internal data as a plain value (arbitrarily chosen by the script/attacker) or a pointer to well-formed data (carefully chosen by the runtime).
As an immediate step, letting the attacker use an address of their choosing for array operations would allow them to read and write arbitrary memory that is reachable with this form of addressing.
I'm putting specific emphasis on "form of addressing" here, because the v8 authors have considered this possibility and put additional protections in place. Within the sandbox, "addresses" are limited to a size of 32 bits, and address within a dedicated 4 Gigabyte area that is specifically for interpreter data. Within that area you are not going to find a lot of critical data to affect outside operations, you'd have to find a way to escape that memory area first.
The next part is going to be a bit hazy because it's been some time since I did Chromium exploitation, and getting code execution within the sandbox from data writes is itself not an easy task.
Now, we have established that there is not a lot of terribly important data within the 4 GB area. The data managing the interpreter lives outside, and any JITed code will also live outside because it needs different access permissions. We only really get to play with Objects and their data.
Objects handling executable code are rare, but there are a few that are at least adjacent. Last time I checked, WASM was one feasible choice where you get reasonably predictable results with custom data, as it included a pointer to actual executable code that represents the WASM program.
Under the assumption that the WASM interpreter/compiler does its job correctly the full block of executable code will not be very interesting. However, any integer constant in the program will end up somewhere within the executable code, and that would give you enough controllable data to encode one or two arbitrary instructions and a relative jump to the next integer constant. To start execution at the first integer constant, we'd then just modify the Object data of the WASM program to slightly offset the entrypoint.
And that's the short form of a possible (and likely outdated) way of getting semi-arbitrary code execution within the sandbox (as we are running as a WASM program, and therefore have all the usual syscall restrictions and other security features engaged).
noduerme 1 days ago [-]
I appreciate the thorough explanation... you seem to understand the domain... but I still don't get how this would work in practice. My experience with C/C++ is somewhat limited but I imagine V8 does something like reserve a whole bunch of addresses and then manage them itself, with some internal list where script arrays/objects correspond to blocks. Or maybe it delegates some of that to C++ vectors that can scale up. But what scripted integer or array could you pass it that would access anything already freed or outside the bounds of the addresses that array was mapped to? The only thing I can think is some kind of asynchronous wipe that would allow the engine to write other data to that block, and using a race condition to access it after it was free. But that doesn't sound quite like a type confusion.
What's an actual snippet of pseudo-JS that could make the engine overrun its memory and start reading out of arbitrary addresses, even within the sandbox? Wouldn't that have been accounted for in the most basic design?
timschumi 14 hours ago [-]
> you seem to understand the domain
I'll have to note that I'm probably way worse than anyone doing this professionally or semi-professionally. This is the extent of what I learned as part of university, which was exclusively using planted vulnerabilities. The knowledge required to find and exploit such issues in a real-world scenario goes much deeper. My dayjob in security is on the entirely opposite side, since I'm doing defensive security on the system-level.
In short, it is quite likely that someone may join in and point out where my information is outdated or plain wrong. (Please do so!)
> My experience with C/C++ is somewhat limited but I imagine V8 does something like reserve a whole bunch of addresses and then manage them itself [...]
That is essentially correct, that's what the 4 Gigabyte allocation I mentioned before is. Let's call it the "v8 heap", because it is distinct from the heap that your system manages (which is the one used for `malloc` and `new`), but it will largely work in the same way.
> [...] with some internal list where script arrays/objects correspond to blocks.
v8 does have a lot of internal checks to make sure that what it is touching looks sane (at least on debug builds), but it will not have a lot of duplicated information. Having to check or update information in multiple places is both an artificial limit on performance as well as its own source of bugs (if not kept in sync correctly).
If v8 needs a JavaScript Object then it will simply ask the v8 heap for an appropriately sized memory allocation and fill in its data there, not unlike normal C or C++ objects (except that v8 usually refcounts, I believe). After this it will simply continue to work with the pointer that it already has.
> But what scripted integer or array could you pass it that would access anything already freed or outside the bounds of the addresses that array was mapped to?
You need to keep in mind that in this scenario, reading/writing outside the intended memory area is already the effect that we want to achieve, it is not the vulnerability.
We are not abusing some insufficient bounds check on an existing Array, _we make v8 believe that there is an Array_ (or at the very least something that it can use like one; in either case it's completely made up), and it happens to have its data stored at the location and length that we want.
> Wouldn't that have been accounted for in the most basic design?
Yes, and for that reason the interpreter itself is considered pretty much battle-tested. However, in search for more performance, multiple JavaScript engines have turned towards engineering Just-In-Time compilers to accelerate running code that runs so often that the compile overhead is worth it. v8 / Chromium / Google alone have a set of three JIT compilers (Sparkplug, Maglev, TurboFan) that compile interpreter bytecode to actual machine instructions depending on what is currently required and how fast the resulting code should be.
> What's an actual snippet of pseudo-JS that could make the engine overrun its memory and start reading out of arbitrary addresses, even within the sandbox?
Those are a bit hard to come by, even more so since the focus for v8 exploitation has changed to targeting the JIT compilers. This usually means that a lot of the exploit would be concerned with wrangling the compiler into place.
I'll try to give an example of what a type confusion involving the JIT compiler looks like, but this is based on work by my classmates, since I never finished that particular part of the exercise.
It is also recited purely from recollection, since I'm not near my university notes.
To get the best possible code optimization the compiler wants to work with some assumptions. If any of those don't hold anymore, the compiler should either never have optimized or at the very least it should deoptimize before anything happens and fall back to a more flexible way of running that code.
One such nugget of information is whether certain well-known properties (let's say .name) can have side effects, those are kept as lists in the source code of the compiler [1]. If the compiler is told that .name can not mutate its object (contrary to the specification and the remainder of the v8 implementation), then it may choose to elide type change checks within the optimized function (that has already been optimized for a specific type) and miss a deoptimization.
If v8 then uses the optimized function after it should have been deoptimized, we essentially get a function that uses an area of memory as if it were a different type of object.
PS: I should get back into this, even just explaining already-done things sounds fun.
Wow. If I understand, your .name example kinda blows my mind. So that would be where the JIT compiler might be pre-optimized to expect a certain length for a supposedly immutable parameter... right? Even if the spec makes everthing mutable. I didn't know that was part of the optimization, but it makes some sense.
That makes it possible for me to visualize how a use-after-free might work inside a JIT engine's sandbox. If I'm not misunderstanding, you're saying that the type confusion attack could be accessed by changing something as simple as the prototype for Object, in a way that the JIT compiler was hardcoded to ignore? Essentially that the compiler is not built to spec, and then getting the garbage collector to somehow free the extra memory, it's still possible to open a hole to read sequential blocks. But the main flaw would be that the compiler reserves X memory for quickly writing an object and then in some unoptimized phase sees that the object only took up X-y and reuses a portion of it...?
I'm a high school dropout..Am I seeing this right?
jokoon 2 days ago [-]
I prefer firefox, but doesn't firefox have a history of more similar exploits?
dgellow 2 days ago [-]
Pretty sure every browser has that history
Terr_ 3 days ago [-]
As somebody who prefers to browse with JS off whenever possible, there's something absurd about the balance everyone takes for granted between (A) your personal safety against a devastating hack by malicious code and (B) surveillance advertising.
"Sorry, but to enter this shop you need to take one of the used syringes from that pile some dude delivers every day and poke yourself with it."
TZubiri 3 days ago [-]
This seems irrelevant as the issue talks about being exploitable with a crafted HTML page, no mention of JS. If true, you would be able to be hit without js enabled.
krackers 3 days ago [-]
It mentions a type confusion in V8. Is it possible to trigger that without JS enabled?
The "all chromium versions" part of the title is also misleading, most browser CVEs do not distinguish between "untested lower bound" vs "affects all" (even though it seems like it'd be trivial to bisect).
Woodi 3 days ago [-]
struct MessageBuffer
{
int msgType;
union {
char *name;
int nameID;
};
};
That finally convinced me getting data using functions (accessors, getters, setters) is a good thing, even in C :) Just all that unnecesary if's are so annoing and killing performance...
jimmydoe 2 days ago [-]
I don't like this question, but why Google still open source Chrome as AI finding exploits so fast?
I want Chrome stay open source, but why should I believe it's possible?
gib444 3 days ago [-]
There's something funny about the site needing JavaScript to display anything
throwaway27448 2 days ago [-]
Hell yea. Let's see some real leaks.
johnnyApplePRNG 3 days ago [-]
NIST probably had this one filed and ready to announce years ago
like those news agencies have obituaries of famous old people pre-written
edoceo 3 days ago [-]
I know a regular old geezer who's written his own obituary. Publish this when I die.
I bet famous people have their people write one to distribute immediately.
Also, writing those for your family sucks, easier to do it when they are alive and can tell some key stories.
keel-control 2 days ago [-]
Google has the means and ability to rewrite Chromium ; bug for bug in Rust from C++ using Astra & Fable.
Same for the Linux kernel. Considering the Fermat's Last Theorem lean proof was 13MLoC and cost $300,000 it would cost $2M to rewrite Chromium & Linux in Rust going purely of combined LoC.
mccr8 2 days ago [-]
Writing Chromium entirely in Rust wouldn't prevent a JIT bug like this.
keel-control 2 days ago [-]
ok for this CVE exactly it wouldn't have worked
but the general pareto 80-20 rule stands regarding the rest of the memory safety vulns
weberer 2 days ago [-]
Why don't you do it and post it here then?
keel-control 2 days ago [-]
I don't have $2M
radium3d 3 days ago [-]
Doesn't everyone else immediately update everything on their computer before they start doing anything?
chrisjj 2 days ago [-]
Is that frequent enough? I mean an update might be issued after you start doing something.
Invictus0 3 days ago [-]
what planet are you living on
throawayonthe 2 days ago [-]
that feels pretty table-stakes no?
claiir 2 days ago [-]
Aren’t all the big chrome vulnerabilities type confusion?
badabingfrlgl 2 days ago [-]
Next time, sell it to me, I’ll pay $1001!
malinono 2 days ago [-]
Sandbox RCE again. Every "it's sandboxed so it's safe" pitch really means "we hope the sandbox holds." Not a security model, just a sentence.
ajross 2 days ago [-]
This is missing the point. The whole point of a "sandbox" in the sense of defense in depth is precisely because it's expected that first-line security guarantees will be broken. Like, maybe V8 has a bug and you can write Javascript that fools it into running arbitrary binary code. But that's less dangerous, because the V8 engine runs in a process sandbox and doesn't have access to the rest of the browser state.
Which is exactly what happened here, as it turns out. This isn't a breakout (or isn't alleged to be a breakout) to the broader OS, only to the sandbox environment.
soiax 2 days ago [-]
The title is bad, it is not sandbox escape, it is "RCE inside the sandbox", so only RCE when sandbox is disabled.
petra303 3 days ago [-]
Only a score of 8.8?
teravor 3 days ago [-]
RCE inside sandbox, so requires chaining with another 0day.
zahlman 3 days ago [-]
What exactly does "RCE inside sandbox" describe that goes beyond "the webpage can supply arbitrary JavaScript and the JavaScript engine executes it", but is still isolated from the system?
StilesCrisis 3 days ago [-]
Chrome runs webpages in individual sandbox processes with very low privileges, as a defense-in-depth strategy. It generally requires at least two exploits to actually affect a user--first, get RCE in a sandboxed process, then find a separate vulnerability that lets you escape the sandbox process entirely. For this bug to have actually been used in the wild, there was almost certainly a second bug as well.
jimrandomh 3 days ago [-]
It means it can execute native code inside the sandbox, as opposed to Javascript. While still sandboxed, this lets it access some parts of the attack surface that JS would not have been able to, some of which may have other exploits that allow escaping the rest of the way.
jnwatson 3 days ago [-]
It means it can execute arbitrary machine code in the sandbox.
r_lee 3 days ago [-]
I think people would like to understand what the "sandbox" is here and what isolation does it provide, is it an unprivileged process? something chromium specific? a v8/JS thing? etc.
ranger_danger 3 days ago [-]
Seems to use OS-specific kernel syscall filtering facilities.
I would assume in this case that there's full renderer control, not just a bypass of the in-process isolation.
r_lee 3 days ago [-]
great link, thanks
zahlman 3 days ago [-]
Okay, and why is that more of a security risk than executing arbitrary JavaScript in the sandbox?
arcfour 3 days ago [-]
Among other things, JavaScript in the browser has no way to even express "kill PID 1234 on the user's machine" or "list the contents of `C:\Users\Documents` and upload all of the files" or "spawn cmd.exe on the user's machine". How would you even do these things if you could run any JavaScript in the browser? You can't.
However, chrome.exe itself does because it's a native application, as is the sandboxed JavaScript interpreter inside of chrome.exe.
(This is a very oversimplified explanation but I think this is the disconnect people are having)
bawolff 3 days ago [-]
> JavaScript in the browser has no way to even express ... "list the contents of `C:\Users\Documents` and upload all of the files"
this is besides the point, but javascript has the file system api.
anyways to your broad point, i dont think this is convincing. What's the difference between not having an api vs having an api that is disabled (e.g. the syscall exists but is filtered). Either way you are not taking the action. RCE in the sandbox is an important step in the bigger exploit chain, but not because you can express things in the traditional syscalls inside the sandbox.
zahlman 2 days ago [-]
Okay, but we're still talking about running machine code inside the sandbox, where that functionality is still not available.
arcfour 2 days ago [-]
The functionality is restricted, but the capability of expressing the intent at all exists.
insanitybit 3 days ago [-]
Because Javascript theoretically can't just access files on disk. Control over the render would let you do that, if not for the process level sandbox, which constraints things like file access, system, calls, etc.
But the process is still more capable than the VM. The process can talk to other processes via IPC, for example.
That's why you don't go from "javascript -> computer is taken over", instead you go from "javascript -> renderer control -> computer is taken over".
p-e-w 3 days ago [-]
It can do some things that JS can’t do, such as invalid pointer writes. But you are correct that this doesn’t automatically imply system access.
r_lee 3 days ago [-]
because with proper code exec you can trigger other bugs to escalate beyond the sandbox, whereas with JS you'd have to find a bug to escape from JS to native
can't get a proper ios/Android RCE with just JS code exec
TacticalCoder 3 days ago [-]
> It means it can execute arbitrary machine code in the sandbox.
Well which is precisely why we have sandboxes.
To me "executing arbitrary code in the sandbox" is similar to "I don't give a flying fuck for it's what a sandbox is for".
More information is needed. As someone commented: this has to be paired with at least another exploit to make anything remotely useful.
A sandbox is a sandbox. We want to understand how "code running in a sandbox" is "actively exploited".
johnsmith1840 3 days ago [-]
Memory isolation having one tab or account open on your bank and another on this page does not mean it could leak across the sandbox and steal bank account details but anything inside of your general page content can be lost
3 days ago [-]
3 days ago [-]
TZubiri 3 days ago [-]
This doesn't affect the score though, the reason there's 1.2 points less than the max is because there is a Required User Interaction. The user needs to visit a specific html page.
Even with the sandbox protection layer, the rest of the parameters are maxed out.
iririririr 3 days ago [-]
what is online ad networks for $100, alex
jeremyjh 3 days ago [-]
I don't know why this is being downvoted. This is called malvertising and its one of the most significant vectors for exploiting a vulnerability like this. Its happened multiple times over the last two decades.
My read of Google's disclosure is that there is likely no known escape from the sandbox. I don't agree this would be reported this way just because "user action" like "using web browser" is required. Even if this individual CVE is correctly an 8.8 there would be a critical assessment of a known chain. The only reason there wouldn't be, would be if the other vulnerability is known to Google but has no patch yet.
3 days ago [-]
Animats 3 days ago [-]
Chromium, or just Chrome?
3 days ago [-]
iberator 2 days ago [-]
Good antivirus should protect you from such attacks.
Even zero day ones.
3 days ago [-]
b8 3 days ago [-]
$1k for this vuln is laughable. If the researcher wrote an exploit as the nday exploit devs did and sold it in the gray market they would of got significantly more.
eschaton 3 days ago [-]
Anyone who sells such an exploit should go to prison.
b--l 3 days ago [-]
Agreed--if you can catch them of course.
rietta 2 days ago [-]
Another type confusion vulnerability! Interesting.
vilas900420 3 days ago [-]
[flagged]
shledery 2 days ago [-]
[flagged]
nazmul_ai 2 days ago [-]
[dead]
jewsdienow 2 days ago [-]
[dead]
jewsdienow 3 days ago [-]
[dead]
flippingheck 2 days ago [-]
Does that somehow also explain why many (most?) desktop users survive with just a browser?
To be clear, I'm not saying it doesn't. I'm saying I don't understand.
jewsdienow 3 days ago [-]
[dead]
mellowbadger70 2 days ago [-]
[flagged]
jewsdienow 3 days ago [-]
[dead]
jewsdienow 3 days ago [-]
[dead]
colincowardly 3 days ago [-]
[dead]
mamzxcvbn779807 3 days ago [-]
[dead]
jewsdienow 3 days ago [-]
[flagged]
DANmode 3 days ago [-]
It’s not. Same as credible threats are also seen as nothing to do with free speech.
It just isn’t what free speech is.
It’s a separate thing.
fc417fc802 3 days ago [-]
No, it is a limit on free speech but it is one of several that various governments (and cultures as a whole) throughout the world have upheld fairly consistently. Free speech is more or less an unachievable platonic ideal that we aspire to. Success varies, as do the compromises made along the way.
Speaking more generally, don't let your ideals bias your judgment. Just because you support policy X and also view ideal Y as good that doesn't mean that X isn't detrimental to Y. It's important to be objective about these things.
DANmode 17 hours ago [-]
> Free speech is more or less an unachievable platonic ideal that we aspire to
I’m almost certain it’s shorthand for “freedom of expression”, which most reasonable people throughout history have not grouped threats of violence into.
In fact, they’ve done violence in return, historically, in response to credible threats, and some jurisdictions uphold that legal right.
So, it truly has nothing to do with my ideals.
fc417fc802 15 hours ago [-]
I'd counter that freedom of expression is either equivalent to or a superset of freedom of speech. The specifics are purely an argument of semantics and thus most likely uninteresting and not worthwhile.
Most reasonable people throughout history have not attempted to defend any sort of blanket right to make threats of violence in any and all circumstances, I obviously agree with you there. My point was that this is clearly a restriction on the freedom to express oneself. I don't know how to articulate my reasoning here any further because the meaning is about as literal as you can get. A threat of violence is most certainly an expression made by an individual after all.
It isn't always desirable or even possible to achieve a platonic ideal that we otherwise generally recognize as being good to strive for. However pretending that we aren't making carveouts leads to muddy thinking and paves the way for abuses.
roschdal 3 days ago [-]
[flagged]
turpentine 3 days ago [-]
What does your vibe-coded-in-C browser do to mitigate this kind of exploit?
roschdal 2 days ago [-]
My vibe-coded browser doesn't have a JIT JavaScript compiler.
Just one more reason to never use Chrome. Their removal of MV2 to prevent UBlock Origin from working is another.
fidotron 3 days ago [-]
Chrome product management is horrible. Chrome software engineering is some of the best ever done.
(And no, I don't use it except for testing).
noir_lord 3 days ago [-]
I don’t disagree, two or more things can be true at once.
That said I still use Firefox for other reasons.
I simply don’t trust google, I don’t trust Mozilla either but I do trust them more than Google and you do kinda have to have a browser to function in the modern world.
lima 3 days ago [-]
Which browser has a better security track record?
bawolff 3 days ago [-]
Despite what people are saying here, chrome has a really excellent track record. Nobody is perfect. Switching just because chrome got exploited one time will likely result in you switching to something worse.
If you're paranoid, disable JIT.
jacquesm 2 days ago [-]
It's not about switching because chrome got exploited one time, it's about switching not to reward unethical behavior.
bawolff 1 days ago [-]
well one someone posts on an article about an exploit in chrome saying that the exploit is a reason to switch, i think its fair to say its not about "not reward[ing] unethical behaviour"
dwattttt 3 days ago [-]
Or disable JS altogether, and enjoy many sites working much quicker. Many others fail & need to be selectively allowed, but it's been worth it.
doublerabbit 2 days ago [-]
If by quicker you mean blank content, I'll agree, it is worth it.
dwattttt 2 days ago [-]
Actually thinking back, I get _more_ content, because there's a notable number of access screens that just don't function with JS off, leaving the whole article available.
dwattttt 2 days ago [-]
Somehow I don't think you've tried, if you think all I get is blank content.
p-e-w 3 days ago [-]
Firefox with uBlock Origin. It’s astonishing how many exploits uBO stops before they ever reach your browser engine. It’s the antivirus of the 2020s.
Cider9986 3 days ago [-]
Brave would be a much better option if you want security and good adblocking.
vachina 2 days ago [-]
Brave is just a wrapper on top of Chromium. Just like the many other “browsers” you can think of recommending.
Alifatisk 3 days ago [-]
I suggest Zen browser (fork of FF), it feels closer to chrome.
Barbing 3 days ago [-]
I hear about Zen. Random q:
It can’t trick Canva into letting you use the color picker, or otherwise enable it, can it - if someone happens to know?
(What a dumb feature to be locked to the Googlesphere.)
Alifatisk 1 days ago [-]
I don’t know honestly.
aleksandrm 3 days ago [-]
What does it mean "closer to chrome"?
Alifatisk 1 days ago [-]
I should have been more specific. I meant the aesthetics. Zen mimics Arc Browser with vertical tabs and a hidden sidebar to maximize screen space.
ZiiS 3 days ago [-]
In a good way?
Alifatisk 1 days ago [-]
Yes, in my opinion. I know a couple of people who actually jumped from Chrome to Zen because of it. In their mind, Firefox is something from the past and rough around the edges. Zen gave new attraction to FF. I am all for any opportunity to disrupt the Chrome monopoly we currently have.
lima 2 days ago [-]
uBlock Origin won't help with this kind of targeted exploit, and Firefox has a much worse security track record.
p-e-w 2 days ago [-]
It absolutely does help, because it blocks hundreds of thousands of shady origins.
lima 1 days ago [-]
That blocks all sorts of abuse, but a targeted exploit would be delivered on a clean domain.
Batman8675309 2 days ago [-]
uBO stops exploits? Source?
bawolff 1 days ago [-]
malvertising is really a method of delivering exploits, but there is no reason to think its relavent to this situation.
For non technical users, scam adverts are probably the biggest threat.
So i agree ubo is an important security technology, but its probably irrelavent to the topic at hand.
p-e-w 2 days ago [-]
It blocks many shady domains, which stops many exploits before they ever reach your browser.
armadyl 3 days ago [-]
[flagged]
drnick1 3 days ago [-]
The idea here is that uBlock filters the domains that may serve the malware in the first place. It basically works the same as a DNS filter.
armadyl 2 days ago [-]
You should be using a DNS filter ideally so it never hits the device in the first place. Adding an extension only increases browser attack surface.
qlte 2 days ago [-]
Which you can also easily do with uBlock Origin Lite in Chrome/Chromium.
armadyl 2 days ago [-]
People pretend like uBoL doesn’t work at all
yjftsjthsd-h 3 days ago [-]
I'm willing to believe that stock chrome has a better record than stock Firefox, but
> and on top of it you’re recommending an extension as a security measure
... Yes? Why can a browser extension not be a security measure/improvement?
armadyl 2 days ago [-]
Because extensions especially MV2 ones only increase attack surface.
yjftsjthsd-h 2 days ago [-]
No, they don't only increase attack surface. In particular, uBo reduces attack surface a lot more than it increases it.
armadyl 2 days ago [-]
The only scenario in which one could possibly argue this is if the option is using MV3 uBlock Origin Lite in basic mode, where the browser handles the content blocking just reading rules from uBoL.
uBO MV2 and MV3 in any of the higher two modes objectively add more attack surface when the alternative is basic uBoL + DNS level filtering which is the most secure combination second to just DNS-only filtering.
And ultimately ad blocking is only badness enumeration which is a poor security measure to rely on, especially when the main application (Firefox) lacks proper security measures versus Chromium. It’s like the NVIDIA owners coming up with 3,000 different cable solutions to the burning connectors when its a problem with the card itself.
According to the Chrome release page (https://chromereleases.googleblog.com/2026/09/stable-channel...), Google paid a researcher $1000 for ethically reporting this.
The CVE associated with it (CVE-2026-85046) is already being exploited in the wild. If we put our thinking caps on, how much do you think this vulnerability is actually worth? How much do you think an organization like Google would spend on, for example, AI tokens or compute to detect this internally before it was found and exploited in the wild?
Ethical disclosure is a complicated topic, because researchers shouldn't hold bugs for ransom or demand high payment. But at the same time, if someone submits a critical issue like this, it makes sense to pay them what the bug's actually worth. Why should a researcher be effectively penalized for responsibly telling a vendor instead of selling the bug to a "research firm" or three-letter agency?
It's one thing if you're an open source project maintainer just trying to put something out to the community. The math is a lot different if you're Google.
Further: a vulnerability is probably not worth that much either, even if it's a hypercapable vulnerability, because the grey market buys full enablement kits, not vulnerability information. People making 6 figures on vulnerabilities are selling fully enabled full chain exploit systems, not just intelligence about a sandbox escape.
[0]: https://news.ycombinator.com/item?id=44861106
AP recommends spaces around them, whereas Chicago doesn’t
besides if we’re critiquing incorrect following of English orthography
—Sentences should be capitalized
—The word “don’t” requires an apostrophe
—End sentences with a period
—That’s incorrect usage of an em-dash at the end there — but what does it matter anyways ;)
I hate that it's basically become the little hitler moustache of punctuation. There was at least one guy who was really enjoying his tiny little moustache until he couldn't anymore. That is the emdash for me.
Legendary.
Miss that shit too.
Ez way to shit on Windows users who had to double up endashes like they were impoverished.
I guess in your analogy the double endash is Stalin’s mustache and the Soviet Union in general - Gaudy, excessive, starving for more
1. (. . . Modern American Usage) https://i.vgy.me/UYqs89.png
We shouldn't look to the black market as cost discovery for these vulnerabilities, most non-criminal researchers are not putting up an ask order and letting the black market compete with Google.
We absolutely should. One of the points of bug bounties is to discourage people from selling to the black market.
Google is only paying for the vulnerability; the exploit market is also paying for your mortal soul.
I had a friend that worked in the space. He lived an exciting life; I hope he's still alive..
‘Officer, you can’t arrest me for carrying a gold bar!’
‘I can if you are carrying it out of the Federal Reserve vault without permission’
Similarly:
‘Surely selling someone the knowledge that a piece of software can be hacked isn’t illegal?’
‘It is if you know or suspect that that person’s intention is to use that knowledge to commit crimes’
This would make you a ‘coconspirator’ or possibly an ‘accessory before the fact’ in any crimes they committed.
A hardline bargaining position with Google would be more like "pay me what I want, or else I'll give it to all takers on the black market for maximum damage". That would be unethical and probably illegal to boot but it's a better definition of value than "1$ greater than max bid".
The value of something is dictated by what _the market_ offers, and just because Google throws a lowball price because _they_ don't value it doesn't necessarily mean that the value of the exploit itself is as low as they dictate.
There will always be someone who would screw Google just for the love of the game, and if they got a better price from elsewhere, I don't see why _morality_ would really play that big of a role. It all comes down to incentives, and if Google doesn't incentivize doing the good thing enough, then someone _will_ incentivize them to do the bad thing just a bit more.
Markets are fundamental things and exist regardless of any kind of moral "should". Otherwise we wouldn't have people buying hard drugs or trafficing women.
Google should, as a rational actor, pay out better for legitimate vulnerabilities that pose actual risk to them to avoid such a situation.
My beef here is that morality and ethics are only assigned to the researchers.
Bug bounties are as much a way of attracting talent to even try to exploit your system as they are about the exploits themselves. If you lowball the bounties the talent goes elsewhere.
Which means that they have zero concern from this incident about reputational damage to themselves or their browser. That's pretty good circumstantial evidence of a monopolistic practice, when you can safely assume that there's effectively no difference to your bottom line if your software is hacked.
This should have been done a long time ago.
Firefox, and the browser market would be much more healthy. Btw, Microsoft, Apple, Facebook, now even Twitter/SpaceX and all of these should have been forced the same way. And of course not just in this field, but all of them, like oil companies. They can pivot, of course, with some grace period, but that would mean giving up something at the end.
And if we are there, we can abolish most of trade secrecy too, which exists only to keep up the status quo while hindering progress.
If people want a better internet, they can start fostering one, rather than endlessly complain that someone else should be fostering it for them.
There will probably be upwards of 1000 people who read this comment that have used Google services for 15+ years, never loaded a single ad, and complain about Google ruining the internet. Please, pick-up a mirror. Nobody wants to build a competitor to serve your cheap ass
Search Engine have chicken and egg problem, you can only have a good search if enough people use it to tune the ranking and see enough search spam cases.
“Just compete with a monopoly on their own field with one hand tied behind”
They don't need to do anything adversarial, the greed driven mindset of the internet (ads suck, everything should be free) staves off any real competition.
It's not nothing, but it's probably around 20%.
Also as others stated. I pay for everything, if they give me the opportunity to pay them for ad free versions. I don't see ads on my Android, and I don't use a general ad blocker on it (except my browser, but I rarely visit sites which would contain ads, and basically all of them from Hacker News). I don't use free search, email, newspapers, I pay for YouTube, and I would pay for Facebook if I would use it. I don't even use Hacker News freely, because I paid for the app which I use to not see ads, and have more features. Heck, I pay even for my torrent, because I support them.
You're in the wrong neighborhood with this sentiment. But yes, the general populace is not like this.
Hell the top story right now is about a tool for backdooring twitter...
This comment in general, not aimed at you.
There are hundreds of us, hundreds.
Microsoft was sued by the USDOJ in 1998 precisely for this, that it was leveraging the pre-installation of Windows to force Internet Explorer to be the default browser for PC consumers. That that was bad for both security and for the web seems pretty obvious in retrospect, when you think about the trajectory of IE.
Apple's insistent blocking of non-webkit web engines, including V8, on its own hardware/iOS is an even more egregious and dangerous phenomenon.
Browser security and browsers themselves would be vastly improved if they weren't a monopoly of the two mobile OS makers.
So, the most likely case is that they're greedy and miserly, and hope we don't do the math. However I recognize that there are judgment calls to be made here. Either their internal spending finds hundreds of RCEs per year, or they're significantly discounting bounty payments versus their actual worth, or they're negligent in budgeting for RCE discovery at all, or they assign zero value to the security of the Chromium platform underpinning Edge, Electron, et al. All of these are bad in different ways; one hopes a competent tech reporter actually pursues this line of questioning with them!
I generally agree, but a 3rd explanation is they figure that too generous a bounty will flood them with reports of minor issues making major ones harder to see (and costing time and money to verify that could be spent looking for security issues).
Remember that you can sell the same vulnerability to multiple people: it's software you can copy.
$1k is so dumb and the fact we’re discussing auctions is proof (hello, Sundar, what you doing over there?).
Guess this will change after the next e.g. nationwide hospital ransomware by a hacker who publicly laments bounty rates, if the news cycle accommodates the story long enough.
Negotiating with terrorists or black mailers is a bad idea.
* They pay for vulnerabilities without reliable exploits (more for vulnerabilities that are demonstrably reliable).
* They don't require you to actually build a reliable exploit chain.
* They pay up front, not in tranches.
* They work with essentially all comers, unlike the grey market, where you're generally subcontracting to sell your first few.
Sound very interesting!
There's also a couple of Darknet Diaries episodes with similar interviews.
If old systems had no bugs/issues, companies could do without the maintenance burden altogether (which includes even systems not being evolved/extended).
But they weren't security issues necessarily. I never thought about it, fixing a huge performance issue is big. A security fix that gets caught early makes no noise so you just don't know how important it would have been. We also once had a really terrible bug that lead to lots of customers getting effectively attacked.
Potentially creates a misaligned incentive to intentionally hide bugs in the code you write so that later you can fix it and get the bounty.
Aka security research.
It's one thing to hold something for ransom ("give me $5M or I release the 0day"). It's another to sell a valuable piece of information ("give me $5M if you want the 0day"). As long as you're only offering the bug to the company who would be impacted by its release, there's nothing unethical about asking for payment.
Maybe you think that, ethically, all bugs should be reported, regardless of payment, because it prevents harm. Well a lot of things prevent harm that we don't all take it upon ourselves to do voluntarily. Should everyone do all safety-related work for free? If we don't want to do it for free, should we not do safety work at all?
If the company really wanted it safe, and they can't make it safe themselves, they can pay someone else to make it safe. If they aren't willing to do that, then nobody is obligated to do free work for them, because we don't require anyone else to do safety-critical work for free. Let's not forget, this isn't a scrappy startup struggling for a seed round, this is one of the world's largest corporations with billions of dollars in cash. If they want your labor, make them pay for it.
Thanks for putting it like that, it changed my opinion on the subject.
If it's normal to expect people to be compensated for other security work, it implies it should also be normal to compensate security researches.
"Safety" is also a relative thing, when the world is safer for one party, it is usually worse for another.
99.999% of people will agree that reducing software vulnerabilities is desirable if they're able to understand the question, including the bad actors themselves a lot of the times.
The situations like bad state actors are already not bound by laws, and things like keeping activism legal are better fought for through other ways
Yeah let's see how this plays out, paying people less than their time is worth for RCEs.
"Making money from bugs" is not solely a black-market activity. There are plenty of grey and even white hat activities in this market.
Now exploiting them? Yes that's a crime.
No it’s not lol
There's no way money is the motivator.
... than Google?
> Selling to Google though you aren't chancing jail time.
Why would you go to jail for selling a vulnerability? It's free speech.
Not so much for taking money from someone who the buyer should know has no reason to be interested in buying the information. And either you know who your counterparty is, in which case you know that they are using it nefariously, or you don't know who your counterparty is, in which case you know that they are using it nefariously. Any court and any jury should see straight through this.
Similarly if you figure out how to get the ATM down the street to give you free money, and you "accurately describe the bug" to people who pay you, and they use it to steal money from the ATM, expect to be charged for participating in, and in fact being an instrumental enabler of their crime. Because it is beyond all reasonable doubt that you could've believed they could have been interested enough to pay you for any other reason.
Since it's all so legal and risk-free, you'd think selling an exploit for a million bucks would be quite the feather in their cap!
It may also be helpful to visualize being interviewed by the FBI and being asked "Did you sell this exploit? To whom? How much did you receive? For what purpose did you think it would be used?". And to remember they already know the answers to these questions, and lying to the FBI is also a crime.
Isn't that a good thing?
> However it is now clear that all bugs that can be found will be found. So this makes a ton of sense.
If Google can find all the bugs nowadays, presumably with AI, why still pay a bug bounty? At least by this logic, bug bounties make less sense now.
Even a resume item.
> allowed a remote attacker to execute arbitrary code *inside the sandbox*
A bug in V8 leads to code execution in Chrome's web page process. It does not lead to execution in general. For that you need other exploits that escape the web page process. Those are not detailed here. This CVE is not a big deal. You're responding the poster's title, not the actual CVE
https://serotav.github.io/Writeups/v8/when-sorting-leads-to-...
that's why bugs in the webpage process pay out very little. Without a worse 2nd bug, they are less serious. Bugs that let you RCE outside the webpage process pay much higher.
Having just a Sandbox RCE is neat, I've got some on my laptop currently, but it's just a piece of the puzzle.
It's insulting how poorly incentivised white hats are, just look at how much North Korea is raking in with their cyber shenanigans - current estimates put it at around $6.75 billion to date (over the past 10 years or so).
I'd point out that part of the reason the grey and black market pays so well is because it is that type of market. You have to pay people extra to look past their morals and a risk premium against potential reputational and legal consequences.
That said, the gap is probably not just that.
Someone could sell it on the black market, sell it to Google, or just move on with their life and not sell it.
I don't know what this is worth on the black market, maybe I'd be scammed by even trying to sell it. Maybe I don't want to be a bad person. These are all things that go into the prices
nothing will change until big tech can no longer rip off security researchers
advocating for this is much more ethical than donating money to Google. I'd rather have that money go my family than a multi trillion dollar company.
of course it could be a colleague or someone with access to such tools
from what I remember, they also don't pay it all out at once but rather over time where the payments stop if the bug gets patched.
I don't understand why you're being so cocky here? this is how many 0 click exploits are sourced
On average, probably not that much. What's the amortized cost of all testing, static analysis, and audit / code review, per "prevented potential bug"?
It’s natural to feel cognitive dissonance because the value to the vendor is so disproportionate to the potential harm to users, but the incentive structure is what it is.
A vulnerability which lets an attacker harm the vendor has much higher direct financial value.
In the world where security issues are paid for entirely at market rate, it would also be very important to not use browsers by poor groups because they would be unable to pay for security reports on the market and consequently the browsers would be less secure.
Interesting idea, for sure, but I don't think it lands in a place I want to go since I neither desire stochastic payments nor desire that all browsers should be from large corporations.
> viewed it as insurance
Of course. Beyond the ethics, the social obligation, sleeping well at night by compensating hardworking people fairly.
“We can’t pay more or we’d have to hire more human reviewers” should never be a massive company’s line of thinking.
Total rewards given $81,933,423
https://bughunters.google.com/about/rules/chrome-friends/chr...
Like look at CVEs curl dealt with at one point that were just completely bogus and given huge severity ratings to start with.
But honestly if you’re the one proposing a “simple solution” maybe do some research yourself.
It's an off the cuff idea on a nerd forum. Relax buddy.
- for developers: don't report, it's not worth it
- for users: Google does not care about security as it doesn't pay for reporting (enough).
in the darkweb, due to crypto, a lot. there is where the $ is, whether it's stealing crypto directly or phishing developers.
why? google removed don't be evil off their charter a long time ago. why shouldn't security researchers also seek to maximize profits?
Hell no, the same level bugs at Google should be enthusiastically paid way more than from an undercapitalized startup, who actually needs the help more so. Should be orders of magnitude difference in relation to scale.
>it makes sense to pay them what the bug's actually worth.
Honest fair-dealing should come into play at least but there are some players who have struck it so rich they can now take enough pride to pay an additional premium just because they can, and their good human nature almost compels them ethically to do way more than the minimum.
Just apparently not at Google.
If a company has achieved financial success to a degree that they are no longer worried about complete failure for the foreseeable future, then it's only a matter of generosity vs Scrooge-like behavior.
What's missing from their overall business acumen if they can't even afford to project an image of generosity yet?
If they're not actively making a serious effort to pay the maximum they can well afford for bugs that are truly serious, there is a technical term for that. Chickenshit.
How many PMs are making more than bug bounties to fetch coffee and bagels?
Their priorities are all out of order.
Why not? Capitalism requires they maximize their value. These profitable companies lay bare at the altar, so they should understand the requirements of their god.
What? That's not how you calculate the value of something at all.
The value is not based on the prevention, it's the cost of the cure.
I mean, why not?
Why not?
"Hey, I found a cvss 8.8 bug in chrome that allows arbitrary code execution when loading my http url. For X USD I can send a report along, and for Y USD I can send a commit with the fix."
Sounds like a basic contract to me
What I do think is ethically dubious is:
"Hey I found this bug and I will MAKE IT PUBLIC WITHIN 90 DAYS SO LOOK AT IT"
I know it's a convention from 'security researchers', but I think the first approach is more ethical than the latter.
That said, I think that the V8 team has done a fantastic job of securing their engine. Their heap sandbox feature is really inspiring! It's really wild that (as far as I can understand this issue) someone is able to bypass it.
(Posted from a memory safe browser - WebKit MiniBrowser compiled with Fil-C. Pretty sure this is safer than even V8 and the heap sandbox.)
It’s only very heavy calculations that see a boost in performance. But, realistically, how many websites require this or currently use this today? <1%? Maybe <.1%?
This is pretty typical across JIT engines, too. PHP also sees only a slight increase in performance from the JIT. Because of the nature of PHP applications, most time is spend on the network and database. Only very CPU-heavy code sees a significant speed up.
That’s even the case for C#, which is why the dotnet runtime only conditionally JIT compiles code. Only hot path code is eligible for JIT compilation.
The only .NET implementations that interpret CIL were the .NET Compact and Micro frameworks due to hardware limitations, nowadays mostly gone as .NET workloads, and alternative implementations like Mono.
It still uses a WKWebView today, even in the EU, despite Apple now allowing alternative browser engines in the EU as of 2 years ago.
I'm sure Chrome will eventually ship Blink+V8 in the EU. It will take some time
In synthetic benchmarks, there was a 40-80% reduction in performance when disabling the JIT. But in a simulated test on YouTube.com, the performance delta was only 6%.
This isn’t the best source as it’s a bit old, and it wasn’t just JIT that was disabled. But the core idea is the same: calculation-heavy code can see an improvement, but most code won’t. Why this matters is how people actually use JS on the web. It’s not for cryptography and such, it’s to manipulate the DOM.
Microsoft also has some benchmarks here: https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...
For PHP the RFC analyzes it: https://wiki.php.net/rfc/jit
We see a similar pattern: in synthetic benchmarks, the performance gain is large. But Wordpress, by far the largest PHP deployment in the wild, only saw ~3% performance gain. It again comes down to how PHP is used. It’s mostly HTML construction and database calls, neither of which will see any performance gain from a JIT. And, PHP has extensions, where most heavy code is moved to. Things like cryptography are done in PHP extensions, in C, where the JIT doesn’t matter. I’m more familiar with PHP, so I’ve known about the history of PHP not shipping a JIT due to the lackluster performance.
It's easy to be safer, as long as performance can be sacrificed for it.
Complaining about a relatively small performance price for Fil-C in that context honestly feels like that one famous newspaper photo of a smoking pregnant woman drinking a beer with a caption saying she's wbrried about the effects of the loud construction noises next door on her unborn child.
Except even that is wrong, because at least she had a point about the construction noises, while this is more of a "refusing to eat your vegetables" kind of situation.
It took over two years and help from contributors to get to the point where WebKit could be made fully memory safe.
Yes, if your JavaScript engine is written in C++, it’s going to be very hard to avoid very gross bugs. We have better options now.
The ability of adversaries to find and exploit very gross bugs in C++ codebases should have already compelled the industry to move to memory safety. Now that AI has democratized the ability to scour C++ codebases for really gross and exploitable bugs, I should think that our hands are at last being forced. I’m not impressed by what I’ve seen in the industry with respect to taking memory safety seriously.
I also cringe at projects that "compile C to WASM" and then believe that it is immediately "memory-safe". (It really is not.)
The only exception for C/C++ projects is Fil-C which that is memory-safe. New projects at this point should just consider using Rust instead.
Sir, do you happen to have instructions for doing this? We who benefit from your philanthropy salute you.
Which is why I have NoScript in my Firefox and have gotten used to manually enabling javascript for select pages. Small price to pay.
Unfortunately the web is full of trivial websites that have no business running javascript. Recently wanted to read the famed post on Gates Notes. But for some reason Bill requires javascript to render text and images. Which reminded me Bill is not a person with good judgement on matters of IT and policy. Time saved.
They get emotional (usually angry) when you tell them you disable javascript- as if every site that serves any kind of content has an automatic entitlement to run arbitrary code on your computer.
There not a lot of reason to not have at least a fallback to serve your text-only content without JS.
This might oversell the agency that practicioners have.
Sandboxed zero-install delivery will outcompete anything with more frictionful installs.
It's probably not the right model for a pacemaker though.
Web/JS has been a double-edged sword for FOSS: sure, I can run a free OS, but if most of my "apps" happen to be JS that I can't practically control, then I have won a battle and lost a war.
There's also the problem of most free apps not doing a good job of providing license info and a link to source code, but this could be sidestepped by a trusted repository which provides license info itself.
[1] https://haketilo.koszko.org/
I don't get it! The way JS is typically used, it doesn't even benefit from JIT all that much. Making ajax requests, doing stuff with strings, and moving DOM elements around doesn't need every CPU clock cycle to be used as optimally as possible. It's exceedingly rare for websites to actually be doing something that needs raw performance. And SPAs will be slow no matter what.
See most of the ecosystem around React, for reference. It's idiotic that things like URL management are done in Javascript. Or form controls. I guarantee that if we stopped doing this kind of stuff, JIT wouldn't matter.
To some extent this is just saying "developers will depend upon the performance given to them", and that's true, but it's also true that as soon as things like V8 and Node appeared, JS became ubiquitous. Pandora's container, if you will.
I've never used React myself, but what I've heard about it makes me question my own sanity. So are you going to tell me that instead of just updating the DOM tree directly I'm going to apply the changes to my data, then pass the entire model to the framework, which would then diff it with the previous version to get the changes back out, it would then call my functions that return components, and it would then diff the virtual DOM to find out what changed, and only then would it update the actual page? Why the fuck would anyone ever want that? What's so hard about simply changing the innerText or inserting elements or whatever?
Oh and now Google and Apple are insisting that this is the way to do UIs in native apps as well, with Compose and SwiftUI respectively.
The way the front end developer community seems to largely encourage learning top-down isn't helping either. I'll forever remember that one guy we made a small project with. He learned React but had no clue what "send a request" and "pass a parameter" means, and I had to explain him how to use XHR.
With thousands of DOM elements on a page, the DOM becomes a bottleneck. This isn't the fault of front-end developers, and it's not really the fault of browser developers. HTML/CSS/JS is a very powerful system, but it's also complex and can cost a lot of compute. When you understand this, then the reasons for React and other front-end frameworks become easier to accept.
I haven't looked into how browsers actually do it, but my mental model for it is that if something changes, this merely sets a flag on that element or its parent that its layout is not valid any more. Then, on next vsync, all the elements that have this flag set have their layout recalculated, potentially going up the tree as necessary. The only exception is if your script tries to get any layout-related property, e.g. offsetWidth. Then, as if as part of the getter of such a property, the layout recalculation will run immediately.
That is to say, if you need to make a lot of changes to the DOM, you should make them within one JS invocation so only one layout pass happens sometime after you're done.
The principle argument in favor of React today are developer ergonomics. People don't have to manually alter individual elements anymore -- they just describe state, and React takes care of the UI change set. On top of that, you have components, etc., that are debatably more pleasant to work with, and at the least create an ecosystem advantage for users of the framework. One can certainly see the argument for something like facebook, where there are probably dozens of different things changing independently at any given time.
But that said, one really has to question whether React makes sense anymore, given LLMs. Back when the alternative was that someone had to bespoke code every UI component, it might have been worth taking the hit of having to adopt the entire React ecosystem. But now that LLMs are writing the code, there's really no argument for developer ergonomics, and suddenly, things like "rewriting URL handling in JS" are pure liabilities.
[1] Though sadly, many front-end devs don't know this.
[2] https://rossenahuh.netlify.app/React/react-concept-1---virtu...
> But now that LLMs are writing the code
Hopefully that's a temporary state of affairs and everyone will eventually go back to writing code by hand. I've never even considered using an LLM to get my job done, the whole idea is as alien to me as are these types of UI frameworks. To me, the best language to describe what you want from a computer isn't English, it's a programming language.
The popular coding AIs go down all the time. Last week all of them were down at the same time. If there's a bug causing losses of thousands or millions of dollars per minute, do we really want to let the LLM write incomprehensible code?
It's so that you have the page reflecting your data at all times.
The browsers should have been written this way, instead of having byzantine update functions with all forms and a pair of *Text to rule them all. But creating it in Javascript is a really bad idea.
One of my problems was that I wanted to show data in the browser. It is a convenient delivery platform, after all. However, Chrome (and Chrome in particular) has tremendous trouble displaying large pages. A 400x400 table takes a long time to render. I could solve that in JavaScript. I had to, really.
So, as practically always, the problems stem from a combination of factors, and bad programming definitely is one of them.
See most of the ecosystem around modern systems software, for reference. It's idiotic that things like memory layout and bit-level hardware management are done in C abstractions. I guarantee that if we stopped doing this kind of stuff, compiler optimizations wouldn't matter.
To some extent this is just saying "developers will depend upon the performance given to them", and that's true, but it's also true that as soon as things like compilers and standard libraries appeared, C became ubiquitous. Pandora's container, if you will.
Cute, but no, not even close to a good metaphor. The C example is abstracting away fundamental complexity in a new platform. The other is completely re-writing -- in duplicate and slightly broken -- what the platform gives you for free. There's nothing about implementing form controls or URL management in JS that is more abstract. It's just different; a downstream bad decision that branches off a long tree of other bad decisions.
The equivalent level of idiocy in a C-related metaphor would be...I dunno...if you decided that you didn't like the way that header files worked, and decided to keep the C compiler, but build an external header-file management system in Fortran [1] that calls the C compiler for you. Or even closer to the JS metaphor, you shipped a special C compiler that had an embedded interpreted language that only activated at compile time, and you then used that language to allow any user to fundamentally change the syntax of C.
(It hopefully shouldn't be lost on you that this exact approach to language features has been repeatedly tried in the javascript world, including right now, with package management. But see also: typescript, coffeescript before that, Dart, etc. Javascript is a mess, and history repeats itself with regularity about every 5 years.)
[1] ...and then you re-write that about sixty times, each time being slightly incompatible with the last, and all having different fundamental incompatibilities with C headers.
Sites are slow because with all that excess performance they do more tracking, instead of keeping the website as-is.
Because that's the only thing business managers can come up with in that situation. It's a misaligned goal of users vs businesses.
In my opinion the "user agent" behavior of browsers is long gone, because they're not acting on behalf of their users anymore. They're acting on behalf of businesses.
Uh…no?
You’re presumably talking about specific terrible prebuilt frameworks - not someone building a nice vanilla SPA.
especially when you’re writing your own stuff,
that’s when you know from the start that scaling doesn’t matter! =]
Related, and more powerful than my comments in this thread are going to be:
https://www.robinsloan.com/notes/home-cooked-app/
So you have to guarantee that your product will stay low users and low features forever or spend a very high effort to try to partially overcome that block when you change your mind.
And guaranteeing that it will stay low features is much harder than low users I think.
In exchange for that you get a better talent pool for recruiting but does that matter if your product has to stay low scale anyways?
It can work for some SaaS but if you stay low employee count, low users and you have a core feature used everywhere in the whole product and nothing else
Feels like a glaring omission =]
> Is it being used even sort-of in the right place / way?
It's a SaaS where users are mostly always logged-in, kind of an app so you would think it should work from the outside.
I think these are the full requirements I would put for a good SPA experience:
- low users
- low number of features / or a single main feature reused in different ways
- low number of employees
- it's an app and not a website
- you don't have any users living in remote places / poor internet connection
- users are all using modern browsers and can be asked to switch to another one if needed
And I think in my company we only have one of this list, making it painful.
Please stop changing the definitions of explicit words and phrases - to anyone reading this!
For example, a search function. For a MPA, each search query would be a new page. For a SPA, each query is a new logical page, served on the same real page.
Technically yes, a SPA may have minimal client side rendering. But then it’s not doing much of anything at all - it’s just a site. When people say SPA, they typically mean an application with client side rendering.
sigh
…does someone else want to finish this up?
To expand on what I mean, if the implication isn’t obvious: a SPA with no client side rendering is just a single HTML page. It’s a document, not an application.
So SPA naturally implies client side rendering.
The difference between a SPA and MPA isn’t the amount of pages, they both have about the same amount of logic pages. It’s about where those pages are rendered. Dynamically on the front end, or on the back end.
EDIT: okay okay to expand, my website has a contact form. With JS enabled, the form submit displays a little box that says “thank you for submitting”. With JS disabled, it navigates you to a “thank you for submitting” page.
Both are the same logic page, they have the same function. One page is just rendered client side, and one server side. Most websites or applications are hybrids. There’s very few true single page applications, and very few true multi page applications. Most SPAs have multiple real pages for different things. Most MPAs combine multiple logic pages into one real page.
> Most websites or applications are hybrids.
and some are emphatically not.
But…where were you going with that?
As soon as you, say, use JS to update the DOM or a canvas, I consider that client-side rendering. That you can do, and that would be a SPA.
But I’m curious, what are some examples, even hypothetical, of applications consisting of one HTML page? I don’t think I’ve ever seen it.
CSS (.css) JavaScript (.js) Plain Text (.txt) HTML (.html) SVG (.svg) Raster Images (.png, .jpg, .jpeg, .gif, .webp, .bmp) Audio (.mp3, .wav, .ogg) Video (.mp4, .webm) JSON (.json) PDF (.pdf)
plus bring in other source resources as needed.
To answer your question:
The installer for GrapheneOS / Google Pixel phones is an “SPA” (or “webapp”).
I’ve seen bespoke fitness trackers of all kinds,
appliance control apps,
budget and pace-tracking stuff,
basically all of what computer programs used to do - before we started dynamically loading a ton of extra stuff onto the screen that nobody needed to do the task they came to do.
Could you point out where you think the gotcha is? I can taste the tone.
Just because a bunch of engineers applied implicit meaning that didn’t exist to a very literal phrase for a few years doesn’t make it correct.
Doesn’t make webapps inherently bad.
Doesn’t make SPAs bad.
At this point, app pretty much implies React - ask an LLM for an app and see if that’s not what you get.
We need simpler protocols and formats, especially those that are used over the internet. I want everyone to really start fighting for this.
I always use a browser that doesn't run any scripts (w3m) for both this reason and others. It hurts when I see websites that don't work without js. A bit funny though that this page is one of them so I was not able to read it.
Wikipedia is basically the most popular application of all time and it doesn't rely on javascript. People just generally don't give a shit about where their money goes.
The whole biosphere is over there in the corner, weeping.
But we do! It doesn't get much simpler than HTML/CSS/JS. It's just abused to make apps instead of web documents.
https://a.singlediv.com/
(I keep WASM and WebGL disabled in Firefox settings, too. Yes, I had another post ITT questioning why those things are any less secure than the JavaScript, given that they're supposed to be in a sandbox. But you know, defense in depth. It's insane that we're expected to put up with these grossly unnecessary risks all the time. Just like how it's insane that frontier models are being tested in environments that are physically capable of connecting to the Internet at large.)
I am decidedly uninterested in those features for most web pages I visit. Should they be able to spin up my CPU fan just for that I would consider it a misfeature. Just like a movie on high volume would be.
If anyone familiar with Firefox could implement that or point in the right direction, that would be most welcome.
Do you remember what the alternative was? Flash, Java, ActiveX. No thank you.
Sure security is difficult but vulnerabilities of this magnitude are rare. If anything the lesson is don't write highly security sensitive software in C/C++.
Like cellphones, javascript became necessary if you want to use webmail, access your bank's website, or whatever.
It's the classic thing. Across every gdmf metric, excluding with "true empathy", no one *gives a fuck* until it affects them, or someone within (1-3) degrees of separatation. And having broad empathy is generally a good way to get yourself labeled/astrocized: both about as obvious "compriate" and obvious "adversary".
astrocized - banished to outer space.
I do know how to spell ostracized ? I'm not sure if that's what I meant? Truly a mess.
It's not the Bonzi-buddy and driveby-installed IE toolbars wild west of the early 00s.
Can you please provide a link to a page where a “toolbar drive-by install” occurs?
In the early 2010s you had to have JS enabled for many sites to work at all. The cost:benefit equation had became entirely different.
https://datatracker.ietf.org/doc/html/rfc3514
The problem here is that the browser failed to correctly implement those rules. If the chromium team cannot do that, what makes you think they can implement any other kind of "benign code" verification with zero bugs?
You can prove that your code terminates (or rather responds to events in a finite time, even if the event loop itself runs forever.) Or you can even prove that your code reacts quickly, ie within some time limit. You can also prove memory limits.
> The problem here is that the browser failed to correctly implement those rules. If the chromium team cannot do that, what makes you think they can implement any other kind of "benign code" verification with zero bugs?
Defense in depth. And you can have competing implementations relatively easily for this, and another way to find and report bugs. Especially if the verifier is open source.
The verifier itself can be pretty simple: it's the prover that's complicated and needs smarts, but that's being run on the author's computer, not in the user's browser.
The security implications are just the cherry on top.
But, anyone who thinks we need JS for a functional internet is fucking retarded
Fortunately I disabled js by default. Unfortunately, it breaks about 30% of the web. Including nvd.nist.gov, which shows a completely blank page without js enabled, even though with js it’s just a simple page with only static content.
More like 99%
I use Firefox with Noscript and I'm _totally aware_ that almost no website works without allowing it JS.
Even using Noscript it's becoming more and more exhausting every year, it's plain impossible to browse the internet without JS at all.
This is not something just anyone is going to rush into. Bigger teams or js/ts evangelists will eventually arrive at that point if they're running something where no-js (really a side effect of seo goals) is important, but "normal people" will spend this time and engineering effort elsewhere.
I think the industry in general is moving past React, as now, and definitely in near future, the only thing that matters is ideas, the rest is for the LLMs to figure out, and so the "frameworks" are going to completely disappear from people's minds as "programming" essentially becomes "telling the AI what to do" and the AI writes asm or even binary. That is when, no JS, may become more viable again lol.
People, including me, resist it, but in the future "programming" is not going to be about writing code (or even checking it, we're way too slow and error-prone to do that), but about coming up with ideas of how to capture real world problems in an IT system, and how to solve those problems by existing (or novel) ways, picking the right tools for the job (say a statistician picking the fitting metric to capture some property of the system that will actually project meaningful observability improvements and not be "just a bunch of noise") and making the right architectural decisions in terms of correctness, performance, scope, taking into account deadlines and budget. And being the domain model glue. Everything else, all the nitty gritty we used to call programming, all the <insert a quadrillion of CS jargon keywords>, is going to be done by AI ... it's a mag 9.5 quake tsunami and it can't be stopped now.
This might completely wipe out things like React (which are largely made for humans writing the code, not for humans consuming the output of that code) faster than anyone thought possible.
Only 30%? In 2026? With CloudFlare and Anubis et al absolutely everywhere? Not to mention SPAs
Anubis is trivially bypassed by an extension.
Only 30?
The V8 vulnerability being exploited today, CVE-2026-85046, is listed in NVD under CWE-843, "Access of Resource Using Incompatible Type ('Type Confusion')."[2] On this class of vulnerabilities, MITRE explains:
> When a memory buffer is accessed using the wrong type, it could read or write memory out of the bounds of the buffer
Memory safety is specifically intended to prevent errors like these from becoming arbitrary out-of-bounds memory access and native code execution. Even type safety --- from the 1970s --- can prevent type confusion.
The CISA and the NSA have called for the adoption of memory-safe languages.[3] We exercise poor engineering judgment and poor ethics, as an industry, when we continue to expose users to classes of wholly avoidable security weaknesses in Internet-facing software.
[1] https://en.wikipedia.org/wiki/Heartbleed
[2] https://cwe.mitre.org/data/definitions/843.html
[3] https://www.nsa.gov/Press-Room/Press-Releases-Statements/Pre...
Here's the commit that fixes this issue: https://chromium.googlesource.com/v8/v8/+/e0562d87ad9c17042b...
We’re past the era where security issues emanating from memory-unsafe code were tolerated due to being unavoidable — continuing to expose your software’s users to them in this present day and age is simply a choice.
But if I'm wrong, dare say, how would you write a production memory-safe JIT compiler today?
Security is where the rubber hits the road. It's whether customers' identities get stolen. It's whether leaders of undemocratic countries can monitor communications, locations, and social networks of people whom they oppress.
Calling this an "ivory tower" criticism is, ironically, a lack of acknowledgement of reality and that our actions have consequences to others.
There are classes of type system—"dependently-typed"—where you can encode arbitrary predicates into the type checking. I've remember seeing examples where they could prove arbitrary facts at the assembly level, including self-modifying code. Lean is such a language, currently very popular, but there are others.
Correctness of such programs depends on some basic assumptions about the CPU/memory environment, which should work absent hardware bugs like speculative execution or side channels. Although these could probably be encoded as well, and accounted for.
Without such a general proof language, you could probably make a special language to support JIT development, although its type system would be very complicated and the language itself could be a source of bugs.
Given such languages or proofs (maybe tractable now with AI-assisted theorem proving), you can actually make insanely performant code, since you don't really need to rely on other runtime protection so much (although maybe a good idea still).
Per OP link, it only affects Chrome versions prior to .82; .82 was released as stable 2 days ago. [1]
(HN title also does not match the original title, which is the CVE ID -- not particularly intuitive.)
[1] https://chromereleases.googleblog.com/2026/09/stable-channel...
https://github.com/GrapheneOS/Vanadium/releases
https://github.com/brave/brave-browser/releases
Only if you use Nightly wait maybe not.
> Type confusion in V8 in Google Chrome prior to 152.0.7977.82 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page.
So it was fixed in 152.0.7977.82 (before .83), if I read that right.
"Affected products: ... Up to (excluding) 152.0.7977.82"
.82 is fixed.
It's because User Interaction is Required. CVSS 10 would be the case where everyone can be exploited without interaction.
Interestingly the 8.8 is more alert-worthy than the 9.8 and 10 cvss, because there is a need to be alerted of the current security risk, whereas with a cvss 2 vuln, there is nothing to be done by users, only admins.
> allowed a remote attacker to execute arbitrary code *inside the sandbox*
I have a feeling someone’s going to make an open source browser using Ladybird’s engine before Ladybird has official binaries.
I know this is old: https://madaidans-insecurities.github.io/firefox-chromium.ht...
but has the situation changed substantially in favor of Firefox?
https://www.wilderssecurity.com/threads/security-chromium-ve...
The reason why I support Gecko and Ladybird’s engine is because I am opposed to monoculture, however. Even if Gecko (Firefox) is less secure than Chromium (Chrome, Edge, etc.), by not having a monoculture, a Chrome exploit will only take down the subset of people using the Chromium ecosystem, and not affect Gecko users. Alas, most people are in the Chromium ecosystem right now so that means malicious hackers only need to target one codebase.
It’s the same reason I wrote MaraDNS back in 2001—back then, there was only one open source DNS server[1,2] so I wrote another one.[3]
[1] Djbdns was around back then but wasn’t open source, which limited its adoption.
[2] https://lwn.net/2001/0208/
[2] MaraDNS was and is optimized for running at most a few dozen domains on a system running a bunch of other services, where one does not want the DNS server causing security problems for the server, and where the DNS server needs to be lightweight as possible.
https://www.reddit.com/r/GrapheneOS/comments/1unhtxu/initial...
"CISA maintains the authoritative source of vulnerabilities that have been exploited in the wild."
Is this chained with n-days?
Those folks would not be disclosing their sandbox escape unless they were good guys.
(Posted with a memory safe WebKit, Fil-C FTW)
In the context of this vulnerability, I doubt memory safety would have made much of a difference.
This is a great reminder though, currently doing a full userspace replacement on my 3D printer and Fil-C might be just what I need for the irreplaceable C parts.
So I think memory safety does matter in that case.
So maybe we're going to see another CVE for the sandbox escape soon?
You would think that an engineering school would be wiser than to require their students use a specific web browser that’s tied to a specific vendor.
[1] https://app.honorlock.com/install/extension
Schools are a business run by administrative staff who make purchasing decisions to solve business problems. Schools love to reduce billable teaching hours through online coursework, which invites academic dishonesty from students, and paying for honorlock is a way to achieve that reduction in expenditure, rather than paying tutors to supervise exams in person.
https://issues.chromium.org/issues/542403045
What's the difference between "executing arbitrary code inside the sandbox via a crafted HTML page" and running whatever is in the <script> tag?
https://github.com/nordstjernen-web/northstar-browser/blob/m...
fly.io depends on Firecracker microVMs, so you should be concerned if you're running untrusted code, but not concerned about other people interacting with you wrt v8.
Cloudflare depends on v8 isolates, which depend on the trustworthiness of the v8 sandbox, which is a non-trivial hurdle, but not an insurmountable one for attackers with the resources to have a v8 bug in the first place.
I'd prefer they ask here. Just saying.
(Posted from memory safe WebKit; i.e. WebKit compiled with filcc and all of WebKit's dependencies compiled with filcc.)
https://fil-c.org/pizlix
Then build WebKit using do_cmake_yolo_simpler.sh in projects/webkitgtk-2.44.3
It's still pretty rough, but works more than well enough to post on HN. My regression test is to post on X. That works too
Pls file bugs if you encounter issues.
Also, fair warning, it's hella slow right now on JS-heavy websites (like X). It barely works.
But we can fix that with some effort, I think
WebKit's JS engine (JavaScriptCore) is super friendly to pointer capabilities. I did not have to change much to make it use the Fil-C GC instead of its own GC and to make it use a capability per JS object.
On the other hand, Chromium's JS engine (V8) does a bunch of crazy stuff with pointer encoding, so the best you could do there is probably a single arena for the whole JS heap.
Also, JavaScriptCore has a well-supported mode that involves not only zero JIT but a fully portable C++ interpreter. Not sure V8 has that.
It's damn near impossible to verify that the JIT is correct.
But it is possible to verify at runtime that the code that the JIT emitted obeys some memory safety law.
(V8's heap sandbox is an example of this; a sarcastic JIT would be an arguably stronger example of this.)
IIRC rustc still has a couple of known soundness bugs, for example. It’s only been a few weeks since someone managed to exploit Lean, and Lean is all about formalizing things :)
I have a new tech called SaRCAsm, which is a memory-safe assembler. So the next step is a "Sarcastic JIT" :-)
Let's say that you have a type confusion bug that (in terms of the interpreted language) allows you to use an Integer variable as an Array.
That sounds nonsensical when just considering the high-level language, but your computer is going to need something to work with when running a script. For an Integer variable it will for example store the value, and for an Array it would store a pointer to a data area (and that area then contains values).
Now, if the interpreter loses track of which type a certain variable is, then it will also not know whether to interpret the internal data as a plain value (arbitrarily chosen by the script/attacker) or a pointer to well-formed data (carefully chosen by the runtime).
As an immediate step, letting the attacker use an address of their choosing for array operations would allow them to read and write arbitrary memory that is reachable with this form of addressing.
I'm putting specific emphasis on "form of addressing" here, because the v8 authors have considered this possibility and put additional protections in place. Within the sandbox, "addresses" are limited to a size of 32 bits, and address within a dedicated 4 Gigabyte area that is specifically for interpreter data. Within that area you are not going to find a lot of critical data to affect outside operations, you'd have to find a way to escape that memory area first.
The next part is going to be a bit hazy because it's been some time since I did Chromium exploitation, and getting code execution within the sandbox from data writes is itself not an easy task.
Now, we have established that there is not a lot of terribly important data within the 4 GB area. The data managing the interpreter lives outside, and any JITed code will also live outside because it needs different access permissions. We only really get to play with Objects and their data.
Objects handling executable code are rare, but there are a few that are at least adjacent. Last time I checked, WASM was one feasible choice where you get reasonably predictable results with custom data, as it included a pointer to actual executable code that represents the WASM program.
Under the assumption that the WASM interpreter/compiler does its job correctly the full block of executable code will not be very interesting. However, any integer constant in the program will end up somewhere within the executable code, and that would give you enough controllable data to encode one or two arbitrary instructions and a relative jump to the next integer constant. To start execution at the first integer constant, we'd then just modify the Object data of the WASM program to slightly offset the entrypoint.
And that's the short form of a possible (and likely outdated) way of getting semi-arbitrary code execution within the sandbox (as we are running as a WASM program, and therefore have all the usual syscall restrictions and other security features engaged).
What's an actual snippet of pseudo-JS that could make the engine overrun its memory and start reading out of arbitrary addresses, even within the sandbox? Wouldn't that have been accounted for in the most basic design?
I'll have to note that I'm probably way worse than anyone doing this professionally or semi-professionally. This is the extent of what I learned as part of university, which was exclusively using planted vulnerabilities. The knowledge required to find and exploit such issues in a real-world scenario goes much deeper. My dayjob in security is on the entirely opposite side, since I'm doing defensive security on the system-level.
In short, it is quite likely that someone may join in and point out where my information is outdated or plain wrong. (Please do so!)
> My experience with C/C++ is somewhat limited but I imagine V8 does something like reserve a whole bunch of addresses and then manage them itself [...]
That is essentially correct, that's what the 4 Gigabyte allocation I mentioned before is. Let's call it the "v8 heap", because it is distinct from the heap that your system manages (which is the one used for `malloc` and `new`), but it will largely work in the same way.
> [...] with some internal list where script arrays/objects correspond to blocks.
v8 does have a lot of internal checks to make sure that what it is touching looks sane (at least on debug builds), but it will not have a lot of duplicated information. Having to check or update information in multiple places is both an artificial limit on performance as well as its own source of bugs (if not kept in sync correctly).
If v8 needs a JavaScript Object then it will simply ask the v8 heap for an appropriately sized memory allocation and fill in its data there, not unlike normal C or C++ objects (except that v8 usually refcounts, I believe). After this it will simply continue to work with the pointer that it already has.
> But what scripted integer or array could you pass it that would access anything already freed or outside the bounds of the addresses that array was mapped to?
You need to keep in mind that in this scenario, reading/writing outside the intended memory area is already the effect that we want to achieve, it is not the vulnerability.
We are not abusing some insufficient bounds check on an existing Array, _we make v8 believe that there is an Array_ (or at the very least something that it can use like one; in either case it's completely made up), and it happens to have its data stored at the location and length that we want.
> Wouldn't that have been accounted for in the most basic design?
Yes, and for that reason the interpreter itself is considered pretty much battle-tested. However, in search for more performance, multiple JavaScript engines have turned towards engineering Just-In-Time compilers to accelerate running code that runs so often that the compile overhead is worth it. v8 / Chromium / Google alone have a set of three JIT compilers (Sparkplug, Maglev, TurboFan) that compile interpreter bytecode to actual machine instructions depending on what is currently required and how fast the resulting code should be.
> What's an actual snippet of pseudo-JS that could make the engine overrun its memory and start reading out of arbitrary addresses, even within the sandbox?
Those are a bit hard to come by, even more so since the focus for v8 exploitation has changed to targeting the JIT compilers. This usually means that a lot of the exploit would be concerned with wrangling the compiler into place.
I'll try to give an example of what a type confusion involving the JIT compiler looks like, but this is based on work by my classmates, since I never finished that particular part of the exercise. It is also recited purely from recollection, since I'm not near my university notes.
To get the best possible code optimization the compiler wants to work with some assumptions. If any of those don't hold anymore, the compiler should either never have optimized or at the very least it should deoptimize before anything happens and fall back to a more flexible way of running that code.
One such nugget of information is whether certain well-known properties (let's say .name) can have side effects, those are kept as lists in the source code of the compiler [1]. If the compiler is told that .name can not mutate its object (contrary to the specification and the remainder of the v8 implementation), then it may choose to elide type change checks within the optimized function (that has already been optimized for a specific type) and miss a deoptimization.
If v8 then uses the optimized function after it should have been deoptimized, we essentially get a function that uses an area of memory as if it were a different type of object.
PS: I should get back into this, even just explaining already-done things sounds fun.
[1] https://chromium.googlesource.com/v8/v8/+/9f30cc5fc4ad6c3236...
That makes it possible for me to visualize how a use-after-free might work inside a JIT engine's sandbox. If I'm not misunderstanding, you're saying that the type confusion attack could be accessed by changing something as simple as the prototype for Object, in a way that the JIT compiler was hardcoded to ignore? Essentially that the compiler is not built to spec, and then getting the garbage collector to somehow free the extra memory, it's still possible to open a hole to read sequential blocks. But the main flaw would be that the compiler reserves X memory for quickly writing an object and then in some unoptimized phase sees that the object only took up X-y and reuses a portion of it...?
I'm a high school dropout..Am I seeing this right?
"Sorry, but to enter this shop you need to take one of the used syringes from that pile some dude delivers every day and poke yourself with it."
The "all chromium versions" part of the title is also misleading, most browser CVEs do not distinguish between "untested lower bound" vs "affects all" (even though it seems like it'd be trivial to bisect).
{
};That finally convinced me getting data using functions (accessors, getters, setters) is a good thing, even in C :) Just all that unnecesary if's are so annoing and killing performance...
I want Chrome stay open source, but why should I believe it's possible?
like those news agencies have obituaries of famous old people pre-written
I bet famous people have their people write one to distribute immediately.
Also, writing those for your family sucks, easier to do it when they are alive and can tell some key stories.
Same for the Linux kernel. Considering the Fermat's Last Theorem lean proof was 13MLoC and cost $300,000 it would cost $2M to rewrite Chromium & Linux in Rust going purely of combined LoC.
Which is exactly what happened here, as it turns out. This isn't a breakout (or isn't alleged to be a breakout) to the broader OS, only to the sandbox environment.
Windows: https://chromium.googlesource.com/chromium/src/+/HEAD/docs/d...
Linux: https://chromium.googlesource.com/chromium/src/+/0e94f26e8/d...
https://chromium.googlesource.com/v8/v8.git/+/refs/heads/mai...
However, chrome.exe itself does because it's a native application, as is the sandboxed JavaScript interpreter inside of chrome.exe.
(This is a very oversimplified explanation but I think this is the disconnect people are having)
this is besides the point, but javascript has the file system api.
anyways to your broad point, i dont think this is convincing. What's the difference between not having an api vs having an api that is disabled (e.g. the syscall exists but is filtered). Either way you are not taking the action. RCE in the sandbox is an important step in the bigger exploit chain, but not because you can express things in the traditional syscalls inside the sandbox.
But the process is still more capable than the VM. The process can talk to other processes via IPC, for example.
That's why you don't go from "javascript -> computer is taken over", instead you go from "javascript -> renderer control -> computer is taken over".
can't get a proper ios/Android RCE with just JS code exec
Well which is precisely why we have sandboxes.
To me "executing arbitrary code in the sandbox" is similar to "I don't give a flying fuck for it's what a sandbox is for".
More information is needed. As someone commented: this has to be paired with at least another exploit to make anything remotely useful.
A sandbox is a sandbox. We want to understand how "code running in a sandbox" is "actively exploited".
Even with the sandbox protection layer, the rest of the parameters are maxed out.
My read of Google's disclosure is that there is likely no known escape from the sandbox. I don't agree this would be reported this way just because "user action" like "using web browser" is required. Even if this individual CVE is correctly an 8.8 there would be a critical assessment of a known chain. The only reason there wouldn't be, would be if the other vulnerability is known to Google but has no patch yet.
To be clear, I'm not saying it doesn't. I'm saying I don't understand.
It just isn’t what free speech is.
It’s a separate thing.
Speaking more generally, don't let your ideals bias your judgment. Just because you support policy X and also view ideal Y as good that doesn't mean that X isn't detrimental to Y. It's important to be objective about these things.
I’m almost certain it’s shorthand for “freedom of expression”, which most reasonable people throughout history have not grouped threats of violence into.
In fact, they’ve done violence in return, historically, in response to credible threats, and some jurisdictions uphold that legal right.
So, it truly has nothing to do with my ideals.
Most reasonable people throughout history have not attempted to defend any sort of blanket right to make threats of violence in any and all circumstances, I obviously agree with you there. My point was that this is clearly a restriction on the freedom to express oneself. I don't know how to articulate my reasoning here any further because the meaning is about as literal as you can get. A threat of violence is most certainly an expression made by an individual after all.
It isn't always desirable or even possible to achieve a platonic ideal that we otherwise generally recognize as being good to strive for. However pretending that we aren't making carveouts leads to muddy thinking and paves the way for abuses.
https://github.com/nordstjernen-web/northstar-browser/blob/m...
(And no, I don't use it except for testing).
That said I still use Firefox for other reasons.
I simply don’t trust google, I don’t trust Mozilla either but I do trust them more than Google and you do kinda have to have a browser to function in the modern world.
If you're paranoid, disable JIT.
It can’t trick Canva into letting you use the color picker, or otherwise enable it, can it - if someone happens to know?
(What a dumb feature to be locked to the Googlesphere.)
For non technical users, scam adverts are probably the biggest threat.
So i agree ubo is an important security technology, but its probably irrelavent to the topic at hand.
> and on top of it you’re recommending an extension as a security measure
... Yes? Why can a browser extension not be a security measure/improvement?
uBO MV2 and MV3 in any of the higher two modes objectively add more attack surface when the alternative is basic uBoL + DNS level filtering which is the most secure combination second to just DNS-only filtering.
And ultimately ad blocking is only badness enumeration which is a poor security measure to rely on, especially when the main application (Firefox) lacks proper security measures versus Chromium. It’s like the NVIDIA owners coming up with 3,000 different cable solutions to the burning connectors when its a problem with the card itself.
Chromium is still far superior on the security front than any other browser.