Google Security Blog
security.googleblog.com · Company blog · on HN since 2016
Google's Security Blog covers its security research and engineering, including memory safety in Android, Chrome certificate policy, and cryptography.
What HN saysHN links it for posts on Rust in Android, SHA-1 collisions, and internal security decisions, and commenters cite its record on breach avoidance.
680HN people shared it
414linked it in comments
506stories submitted
18Kstory points
3 months agolast shared
2016people per year2026
Most-shared posts
- 1Memory Safe Languages in Android 13 Reduce Vulnerabilities27 people · 46 points · first shared 2022 · 1 comments on HN
- 2Google and Android have your back by protecting your backups18 people · 10 points · first shared 2018 · 1 comments on HN
- 3Rust in Android: move fast and fix things17 people · 418 points · first shared 2025 · 412 comments on HN
- 4Eliminating Memory Safety Vulnerabilities at the Source17 people · 330 points · first shared 2024 · 190 comments on HN
- 5Announcing the first SHA-1 collision15 people · 3.0K points · first shared 2017 · 485 comments on HN
- 6Chrome's Plan to Distrust Symantec Certificates15 people · 496 points · first shared 2017 · 198 comments on HN
- 7Mitigating Spectre with Site Isolation in Chrome14 people · 6 points · first shared 2018 · discussion on HN
- 8Today's CPU vulnerability: what you need to know13 people · 39 points · first shared 2018 · 4 comments on HN
- 9Sustaining Digital Certificate Security (2015)13 people · 1 points · first shared 2016 · discussion on HN
- 10A Spectre proof-of-concept for a Spectre-proof web11 people · 117 points · first shared 2021 · 29 comments on HN
- 11Security of Passkeys in the Google Password Manager11 people · 2 points · first shared 2022 · discussion on HN
- 12How effective is basic account hygiene at preventing hijacking10 people · 15 points · first shared 2019 · 1 comments on HN
- 13Better protection against Man in the Middle phishing attacks10 people · 4 points · first shared 2019 · 1 comments on HN
- 14Moving towards a more secure web10 people · 4 points · first shared 2016 · discussion on HN
- 15Experimenting with Post-Quantum Cryptography9 people · 183 points · first shared 2016 · 39 comments on HN
What HN people wrote when they linked it
ameliaquining · 2026-08-15
Google's security record at avoiding that kind of breach is just about the best in the industry, and their system that handles custody of password manager secrets is designed to withstand even a compromise of their production infrastructure (https://security.googleblog.com/2022/10/SecurityofPasskeysintheGoogleP… I would advise almost all users to worry more about getting locked out of their password database than about that. Of course, I would also advise almost all users not to self-custody cryptocurrency.
SilasX · 2026-01-14
I wrote an April Fool's parody in 2021 that Google is going to get rid of authentication because they're following you around enough to know who you are anyway (modeling it after their No Captcha announcement[1]):
http://blog.tyrannyofthemouse.com/2021/04/leaked-google-initiative-no-…
Edit:
>I think the truth is, they just want your face.
I just realized the parody also predicted that part (emphasis added):
>>In cases where our tracking cookies and other behavioral metrics can't confidently predict who someone is, we will prompt the user for additional information, increasing the number of security checkpoints to confirm who the user really is. For example, you might need to turn on your webcam or upload your operating system's recent logs to give a fuller picture.
[1] https://security.googleblog.com/2014/12/are-you-robot-introducing-no-c…
IshKebab · 2025-12-09
Ah the classic "show me ironclad evidence of this impossible-to-prove-but-quite-clear thing or else you must be wrong!"
Although we did recently get pretty good evidence of those claims for humans and it would be very surprising if the situation were completely reversed for LLMs (i.e. humans write Rust more reliably but LLMs write C more reliably).
https://security.googleblog.com/2025/11/rust-in-android-move-fast-fix-…
I'm not aware of any studies pointing in the opposite direction.
weitendorf · 2025-07-21
No, it was about servers, and I worked there on similar stuff/with the same people involved in the serverside ("fleetwide") rollout. Public post describing the decision to disable it internally: https://security.googleblog.com/2023/06/learnings-from-kctf-vrps-42-li…
I'd love to see a post explaining a decision to consider it stable or that mentions that they've rolled it out on their fleet
agwa · 2025-03-31
> I worked on compilers at FAANG for quite a while and know quite well how these teams justify their existence. Telling executives "we cost the company $1M a quarter, but good news, we made the semantics of the language easier for programming language nerds to understand" instead of "we saved the company $10M last quarter" is an excellent strategy for getting the team axed next time downsizing comes around.
And yet, Google is willing to take a performance hit of not 0.1% but 0.3% for improved safety: https://security.googleblog.com/2024/11/retrofitting-spatial-safety-to…
And obviously there are better justifications for this than "we made the semantics of the language easier for programming language nerds to understand".
budro · 2025-02-01
> Only at the cost of runtime checks
And those checks are well worth paying for, enough that Rust also has them! I'm sure Rust would have even worse ergonomics if it insisted on no runtime bounds/unwrap checks. The performance cost is low enough that every systems programming language should have spatial safety. To illustrate, Google found that hardening libc++ by adding bounds checks only led to a 0.30% performance impact on their services [1]. It's not hard to imagine that a similar run-time cost affects Zig and Rust. Both languages make attempts to optimize the checks away if the operation is known-safe. Although, maybe Rust is more successful due to the borrow checker.
> and/or misusable allocator passing.
Could you clarify how allocator misuse might lead to a spatial safety violation?
[1] https://security.googleblog.com/2024/11/retrofitting-spatial-safety-to…
NavinF · 2024-12-28
Quantum computers don't break Differential Privacy. Read the toy example at https://security.googleblog.com/2014/10/learning-statistics-with-priva…
>Let’s say you wanted to count how many of your online friends were dogs, while respecting the maxim that, on the Internet, nobody should know you’re a dog. To do this, you could ask each friend to answer the question “Are you a dog?” in the following way. Each friend should flip a coin in secret, and answer the question truthfully if the coin came up heads; but, if the coin came up tails, that friend should always say “Yes” regardless. Then you could get a good estimate of the true count from the greater-than-half fraction of your friends that answered “Yes”. However, you still wouldn’t know which of your friends was a dog: each answer “Yes” would most likely be due to that friend’s coin flip coming up tails.
zellyn · 2024-12-09
Fair. That study on writing only new things in Rust was surprising! https://security.googleblog.com/2024/09/eliminating-memory-safety-vuln…
I do think for an OS/Kernel, it's worth having everything in a memory-safe language, and possibly worth formal verification too, if the very core of it is small enough…
jart · 2024-11-26
It was difficult to dig up, but I found it for you. https://security.googleblog.com/2024/09/eliminating-memory-safety-vuln… Also headlines do not accurately model reality. The news only reports on things that are newsworthy. It's comparatively rare that we'll discover new vulnerabilities in old code that's commonly used. That's what makes it newsworthy.
xyst · 2024-10-30
Notably, io_uring syscall has been a significant source of vulnerabilities. Last year, Google security team decided to disable it in their products (ChromeOS, Android, GKE) and production servers [1].
Containerd maintainers soon followed Google recommendations and updated seccomp profile to disallow io_uring calls [2].
io_uring was called out specifically for exposing increased attack surface by kernel security team as well long before G report was released [3].
Seems like less of a rust issue and more of a bug(s) in io_uring? I suppose user space apps can provide bandaid fix but ultimately needs to be handled at kernel.
[1] https://security.googleblog.com/2023/06/learnings-from-kctf-vrps-42-li…
[2] https://github.com/containerd/containerd/pull/9320
[3] https://lwn.net/Articles/902466/
alilleybrinker · 2024-10-24
Not everything will be rewritten in Rust. I've broken down the arguments for why this is, and why it's a good thing, elsewhere [1].
Google's recent analysis on their own experiences transitioning toward memory safety provide even more evidence that you don't need to fully transition to get strong safety benefits. They incentivized moving new code to memory safe languages, and continued working to actively assure the existing memory unsafe code they had. In practice, they found that vulnerability density in a stable codebase decays exponentially as you continue to fix bugs. So you can reap the benefits of built-in memory safety for new code while driving down latent memory unsafety in existing code to great effect. [2]
[1]: https://www.alilleybrinker.com/blog/cpp-must-become-safer/
[2]: https://security.googleblog.com/2024/09/eliminating-memory-safety-vuln…
edelbitter · 2024-08-02
de-clickbaited title: Google recommends leveraging Android settings to (mostly) avoid unencrypted networks
original press release: https://security.googleblog.com/2024/08/keeping-your-android-device-sa…
dcsommer · 2024-02-05
In the presentation there are links to multiple companies observing a consistent 60-70% of high severity security issues being attributed to memory safety issues. These are companies that are organized, well resourced, etc.
Rust eliminates these bugs and it results in fewer security issues in Rust code than C/C++. See https://security.googleblog.com/2022/12/memory-safe-languages-in-andro…
Additionally, even in brilliant soloist projects like curl, Linux, etc., you still get plenty of memory safety CVEs. The best still don't get it right.
> Are there any studies that show excluding memory overrun bugs...
Why exclude memory safety from the argument? That's the whole point -- to fix those significant fraction of vulnerabilities.
howinteresting · 2023-09-26
While yes, that's theoretically possible, do you have data to establish this? For example, having small sections of the code be marked as unsafe would allow for greater scrutiny of those sections. Also, unsafe access is more annoying to perform in Rust than in C or C++, so maybe that would have acted as a deterrent (or at least the code would have been profiled to make sure that unsafe access was worth it).
https://security.googleblog.com/2022/12/memory-safe-languages-in-andro… shows improvements at scale.
TechieKid · 2023-06-16
Also relevant news that Google has disabled io_uring for apps on Android and disabled it entirely on Chrome OS and production Google servers since 60% of the exploits (~$1M worth) submitted to the Google Vulnerability Rewards Program have been for io_uring: https://security.googleblog.com/2023/06/learnings-from-kctf-vrps-42-li…
aw1621107 · 2023-06-07
The Android team posted something on that topic about 6 months ago [0, HN discussion at 1].
One potentially relevant highlight:
> To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code.
> Historical vulnerability density is greater than 1/kLOC (1 vulnerability per thousand lines of code) in many of Android’s C/C++ components (e.g. media, Bluetooth, NFC, etc). Based on this historical vulnerability density, it’s likely that using Rust has already prevented hundreds of vulnerabilities from reaching production.
The post has more details, and I think the entire thing is worth a read.
[0]: https://security.googleblog.com/2022/12/memory-safe-languages-in-andro…
[1]: https://news.ycombinator.com/item?id=33819616
pjmlp · 2023-04-29
That was only the begining, followed by Keystore2, the new Ultra-wideband (UWB) stack, DNS-over-HTTP3, Android’s Virtualization framework (AVF) on Android 13.
https://security.googleblog.com/2022/12/memory-safe-languages-in-andro…
https://source.android.com/docs/setup/build/rust/building-rust-modules…
password11 · 2023-01-27
Ok but if some company puts out a clearly better tool that makes people better at their job, they will eventually adopt.
Examples: Rust vs. C++ (https://security.googleblog.com/2021/04/rust-in-android-platform.html?… Golang vs. [various] (personal experience), VSCode vs Notepad++.
LLMs are interchangeable tools trained to maximize an objective function. The best one will be adopted unless there's some incentives given out, etc.
johnthuss · 2022-12-09
This is great! There is more info from Google about this feature here:
https://security.googleblog.com/2022/10/SecurityofPasskeysintheGoogleP…
krono · 2022-11-09
At least some data is definitely shared with Google's safe browsing service by default, more and with greater detail still when "enhanced protection" or "make searches and browsing better" is enabled.
https://security.googleblog.com/2022/08/how-hash-based-safe-browsing-w…
https://security.googleblog.com/2020/05/enhanced-safe-browsing-protect…
Gwypaas · 2022-08-04
> Linearizability is just not as important as some people make it out to be.
That's my entire point. Start with strong models and weaken when you decide you need it. Thus rule out entire classes of bugs for 99% of your code and closely scrutinize the 1% with weakened guarantees to know that it works. That is kind of the entire premise behind Rust. Make it extremely visible where the dragons may exist, because you have the key to unlock that door.
Regarding memory safety, 70% of CVEs at Microsoft and in Chrome are memory safety bugs. I would say the choice of languages without memory safety is more based on legacy than some kind of insightful choice.
https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-mor…
https://security.googleblog.com/2022/03/whats-up-with-in-wild-exploits…
3np · 2022-07-30
Unfortunately, neither DoT nor DoH have any great features for client authorization. Client certificates would have been great.
On DoH you could put an API token in the URL. On DoT you could encode something similar in the `Host` header (though this isn't really secure as the SNI is retrievable so questionable how effective it really is and I'm not even sure if this is achievable on the edge runtimes).
Adding the DoH-token feature could still make sense, I guess? Unfortunately AFAIK Android supports only DoT, not DoH.
EDIT: This just in, DoH3 in Android: https://security.googleblog.com/2022/07/dns-over-http3-in-android.html
zdragnar · 2022-07-12
Google had a decent writeup and proof of concept for leaking via JavaScript:
https://security.googleblog.com/2021/03/a-spectre-proof-of-concept-for…
As for clouds, "retpoline" is (was?) a common measure taken against spectre v2, as seen in this fairly old post:
https://cloud.google.com/blog/topics/inside-google-cloud/answering-you…
What retbleed means for this is anyone's guess, but I'd hazard a thought that it's not great.
yyyk · 2022-04-28
Just yesterday, Microsoft found a few[0]. There's no shortage of these, but more important is the haphazard way fixes are backported to longterm (e.g. [1]). This reached the point that Google's security advice is 'always follow the latest kernel'[2], except most users and distros simply cannot afford it, so they are stuck with a vulnerable system.
Linux is not unique here. In the longterm, all the typical desktop OSs will need significant structural changes far beyond 'chase vulnerabilities and patch everything all the time'.
[0] https://www.theregister.com/2022/04/27/microsoft-linux-vulnerability/
[1] https://nvd.nist.gov/vuln/detail/CVE-2019-15902
[2] https://security.googleblog.com/2021/08/linux-kernel-security-done-rig…
loup-vaillant · 2022-04-21
I was just trying to mention the most widespread method. Sure you can use AES-CBC or AES-CTR, and combine it with HMAC or keyed BLAKE2…
but as tptaceck pointed out, all authentication methods are going to increase your message size. It's unavoidable: to get authentication you need some redundancy, and the only general way to get that redundancy is to have a message bigger than the plaintext. We do have attempts at length preserving authenticated encryption, but as far as I know they're not as well studied as the classical "encrypt-then-mac" methods such as AES-CBC + HMAC or AES-GCM. https://security.googleblog.com/2019/02/introducing-adiantum-encryptio…
azakai · 2021-09-09
I'm not close to Zig development, but in addition to the GeneralPurposeAllocator work that a comment already links to, there is other ongoing stuff in that space, like an allocator in 64-bit that does not reuse pages (and instead keeps using new addresses in the "infinite" 64-bit space).
There are also known techniques like Type-After-Type that can avoid use-after free in C and C++ [0]. And also advances in hardware like ARM MTE [1]. Those things - and GPA, and not reusing 64-bit pages - have various tradeoffs in terms of overhead, but Zig is a developing language that has a chance to explore possibilities that C and C++ can't. So this is an interesting area to follow.
[0] https://dl.acm.org/doi/10.1145/3274694.3274705
[1] https://security.googleblog.com/2019/08/adopting-arm-memory-tagging-ex…
zekrioca · 2021-08-06
I think instead of posting the reference of a source, it is best to post the source [1] itself :)
[1] https://security.googleblog.com/2021/08/linux-kernel-security-done-rig…
shakna · 2020-08-19
> It's unfortunate that the company best poised to provide the world complete end-to-end privacy and security, is also the one least likely to democratize it.
Titan was open-sourced at the end of last year. [0]
> Any idea where google manufactures the chips? Do they do it themselves in their own fabs?
Whilst Google avoided confirming anything, I believe the actual fabrication was probably done through Cypress Semiconductor, before Skywater Technology Foundry spun out of them. The foundry and Google have a long and ongoing relationship.
[0] https://security.googleblog.com/2019/11/opentitan-open-sourcing-transp…
sweis · 2019-09-18
It not exactly a young research area. We have had post-quantum public key cryptosystems based on linear codes for over 40 years.
Classic McEliece (https://classic.mceliece.org) was created in 1978 and is in the 2nd round of NIST's PQ-crypto contest ( https://csrc.nist.gov/projects/post-quantum-cryptography/round-2-submi…
The PQCrypto conference started 13 years ago: https://pqcrypto.org/conferences.html
Chrome ran large scale experiments with NewHope support 3 years ago: https://security.googleblog.com/2016/07/experimenting-with-post-quantu…
imiric · 2019-06-20
Thanks for your input, and for Authy. I was a long-time user until I recently switched to an open-source alternative.
> Third, U2F Hardware tokens. Its finally possible to do U2F to the iphone via Bluetooth and Feitan now has a key that supports it (Google sells one for project Titan).
Would you still recommend a Bluetooth key given the recently found vulnerability[0] in the Feitian/Titan? The initial criticism from Yubico[1] seems to suggest it's an inherent limitation of the BLE protocol.
[0]: https://security.googleblog.com/2019/05/titan-keys-update.html
[1]: https://www.yubico.com/2018/07/the-key-to-trust/