> As is currently normal for internally found Chrome bugs, no CVE was assigned.
Why I don't care about or trust anything from Google TAG, PZ, or any other "security blog" that Google publishes.
They have no problems copping CVEs on competitors like Mozilla, Microsoft, or Apple.... but squirrel away zero days on their own products for the better part of a year or more and then quietly publish blog posts without actually filing for a CVE.
> They have no problems copping CVEs on competitors like Mozilla, Microsoft, or Apple.... but squirrel away zero days on their own products for the better part of a year or more and then quietly publish blog posts without actually filing for a CVE.
This comes up from time to time, but I'm not sure it's actually supported by the evidence, and maybe it's just random anecdotes from people that are consumed and then become opinion. Project Zero reports on Google vulnerabilities often, and in fact just made a post critical of Android's security practices.[1]
I remember reading years back metrics on who they publish bugs about, and on looking, I see they published something earlier this year about the prior year in review[2] with data.
It's really not hard to look some of this stuff up to see whether your feelings are supported by the data. Maybe this changes your opinion, maybe it doesn't, but at least you have some data to look at now.
And your second source is Google, so take that with a grain of salt. Not only that, but it backs up my claim. They even admit in the article that IOS gets 7 times more bugs than Android because Google applies the Android methodology to IOS arbitrarily even though the two update philosophies aren't really compatible.
> ARS is a pretty pedestrian source. Are you discounting it because of the site name over the content?
The Ars article just links to the Project Zero blog post (a very recent one).
> And your second source is Google, so take that with a grain of salt.
The Project Zero blog post I linked to is them reviewing their past submissions, and they provide a link to that, and review the data all you want. It's up to you to consider whether you think the researchers are hiding Google exploits, using this data, or other data, or other people's analysis, or just your own intuition.
> Not only that, but it backs up my claim. They even admit in the article that IOS gets 7 times more bugs than Android because Google applies the Android methodology to IOS arbitrarily even though the two update philosophies aren't really compatible.
What does that have to do with your claim that they "squirrel away zero days on their own products for the better part of a year or more and then quietly publish blog posts without actually filing for a CVE." ?
Also, you're taking their admission along with the data that the numbers paint iOS worse than what the reality is as evidence of them being heavy handed against iOS? That's an interesting interpretation.
[I work at Google, but not on anything related to TAG or P0]
I feel like you're misreading the timeline here. The Chrome vuln you mention was found in June 2021 and fixed in August 2021, not 2022. From the bug, it was found and fixed due to automated regression testing done by the chrome team.
This is the equivalent of asking every buffer overflow in Chrome to be assigned a CVE, which is odd. Further, it's exactly the same behavior as Mozilla follows, as demonstrated by the line
> The sandbox escape is specific to the Windows version of Firefox and was fixed without a CVE in September 2019.
in the blog post. Neither vendor is acting badly by not filing a CVE for vulnerabilities they found and fixed internally. CVEs are usually for communication across organizations, which isn't needed if everything is handled within the chrome or mozilla bug trackers.
Mozilla, Microsoft, and Apple can publish CVEs in Google's products if they want to fund the work --- and they should fund exactly that kind of work. Meanwhile: it is absolutely not a norm in the technology industry to publish arbitrary internal discoveries.
I do not need to explain to you what CVE means, but still the "C" is for Coordinated : CVE used to be that identifier where downstream actors could keep track of in order to keep their systems up to date.
Since Google and P0 are so worried about the safety of theirs users's ecosystem, they should issue CVEs for internally found bugs in Chrome so that CEF, Electron, and every chrome-like projects maintainers can verify if they have backported the correct fix. They even complained about downstreamers leaving a patch gap for attackers recently :)
Unfortunately, nowadays CVEs are a commodity (perhaps a currency in the future ?) where the less you have the more "secure" your system is, which is utter bullshit.
>squirrel away zero days on their own products for the better part of a year or more
The bug was discovered by Google on 2021-07-11, the fix was submitted on 2021-07-27, it was merged into the then-current Chrome version on 2022-08-11, and the bug was made public on 2021-11-02.
Since Google found the vulnerability internally and at the time had no knowledge that anyone else knew about it, Google didn't know it was a zero day a the time.
>quietly publish blog posts
I think publishing a blog post is the opposite of quiet.
Disclosure: I work at Google but not on any of these teams.
Why I don't care about or trust anything from Google TAG, PZ, or any other "security blog" that Google publishes.
They have no problems copping CVEs on competitors like Mozilla, Microsoft, or Apple.... but squirrel away zero days on their own products for the better part of a year or more and then quietly publish blog posts without actually filing for a CVE.