HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
google
security-research
C2020–2026
google / security-research

security-research

This project hosts security advisories and their accompanying proof-of-concepts related to research conducted at Google which impact non-Google owned code.

28Distinct people
31Mentions
0Explicit recommenders
4.7KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

This project hosts security advisories and their accompanying proof-of-concepts related to research conducted at Google which impact non-Google owned code.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 11:34:28 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year31 dated mentions

Observed mentions: 2020-08-10 22:33:00 UTC to 2026-08-14 02:29:26 UTC.

02462020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 4 mentions; 2 submissions, 2 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 5 mentions; 5 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 6 mentions; 3 submissions, 3 comments20232024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 6 mentions; 3 submissions, 3 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC422
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC303
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC550
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC633
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC211
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC633
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC505

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Security Research This project hosts security advisories and their accompanying proof-of-concepts related to research conducted at Google which impact non-Google owned code. We believe that vulnerability disclosure is a two-way street. Vendors, as well as researchers, must act responsibly. This is why Google adheres to a 90-day disclosure deadline. We notify vendors of vulnerabilities immediately, with details shared in public with the defensive community after 90 days, or sooner if the vendor releases a fix. You can read up on our full policy at: https://www.google.com/about/appsecurity/. Advisories The disclosure of vulnerabilities are all in the form of security advisories, which can be browsed in the Security Advisories page. License & Patents The advisories and patches posted here are free and open source. See LICENSE for further details. Contributing The easiest way to contribute to our security research projects is to correct the patches when you see mistakes. Please read up our Contribution policy.
Read the full README on GitHub

What Hacker News says

2 sources
> Alright, let's take a step back. First, I am not a mobile developer. I think you're whichever kind of developer your current position requires. You've been talking about Android non-stop throughout this conversation, and conversations you've had with others on this website [1]. When you were lambasting me about my perceived knowledge of mobile development you were touting your Android knowledge, and taunting me about whether or not I've done anything outside the web. Now that I've proven Android is actually one of the primary tools Google uses to promote Chrome (and you admitted you don't know much about iOS) you want to distance yourself from mobile development altogether. > Other examples include whatever iOS does (which I don't know), containers (docker and the likes), VMs, and everything in-between (like what snap or flatpak use). W
Read the rest
e're not discussing theoretical means with which you could sandbox an application, we're talking about how apps are actually used in reality. If you need to fire up a virtual machine every time you use your favorite desktop apps, then you're only proving my point that they're not inherently very secure. Not to mention, the average user probably has no idea what Docker or a virtual machine even is. Like I said in my original response, lots of things are possible in theory, but in practice web browsers are much better at sandboxing apps than desktop operating systems (and even better than mobile operating systems). And by the way, you can run a browser inside of a vm too, so if anything the technologies you're advocating for bolster the security of web apps rather than compete with them. > If anything, modern browsers are so complex (and getting worse with time) that the attack surface is big Ironically, a lot of that complexity arises from the web's insistence on security. V8 is complex because it has so many safeguards in place to sandbox JavaScript, and that sandboxing is taken very seriously. There's a reward anywhere from 10,000 to 150,000 USD if you can escape the sandbox [2][3]. Browsers are inherently more secure than desktop apps because they limit access to the underlying platform. Someone developing malware as a web app has to first escape the browser sandbox, just to gain the privileges that a desktop app has natively. If it helps, you can think of every desktop app as a webapp which has already escaped the browser. > Moreover, Web UIs bring their own class of issues that don't really apply to native apps. No, web developers have just spent so much time thinking about security, that native app developers haven't even realized these security issues are relevant yet. It took years for Apple and Google to come to the brilliant conclusion that they should notify users when an app is reading from the clipboard, something which at the time was considered just a browser "class of issue". Maybe in 2034 they'll figure this out for desktop apps. > But CORS is really a browser thing, I don't think it really makes sense to compare it to anything outside the "webview world". It makes sense to compare it to things outside of the browser because it protects users and servers. You seem to want to disqualify any point I make that you can't disprove. If you don't think web technology is comparable to anything outside the browser, then what are we even arguing about? This whole discussion has been about comparing the security of web apps to non-web apps. > If security is your concern (and you seem to insist that it is), then webapps are really not better than the alternatives. Actually, the Apple Store and the Play Store (to give an example in the mobile world) allow Apple and Google to somehow monitor the apps that users install, which is most certainly more secure than a model where anyone can load any webapp from any website. Security is not some new thing I'm insisting on, it's been my whole point from the very beginning. You're just finally deciding to engage with me about it, instead of derailing the conversation constantly. Apple and Google have to monitor which apps make it to their app stores, BECAUSE apps are so much more prone to security problems. You once again have it completely backwards. No one has to gatekeep websites because browsers are so much better at sandboxing applications. And allow me to remind you that you admitted you have no idea how iOS sandboxing works, so you can't really be confident about this stance even if it did make sense. And now you're arguing in favor of the app store duopoly which contradicts your point about software diversity. You can't have it both ways. You're trying to hold on to two contradictory points at the same time: you don't like the supposed lack of browser diversity (which is why you seem to detest Chromium), but you like the supposed security guarantees of the mobile app store duopoly, which is even less diverse. [1] https://news.ycombinator.com/item?id=38919389 [2] https://github.com/google/security-research/blob/master/v8ct... [3] https://bughunters.google.com/about/rules/5745167867576320/c...
In Things engineers believe about Web development

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.