We Are Discontinuing the Dark Web Report
Key topics
Google's decision to discontinue its dark web report has sparked a lively discussion, with many commenters weighing in on the reasons behind the move. Some speculate that the report wasn't a revenue generator and was taking up valuable server resources, while others ponder the report's original purpose and the nature of the dark web it monitored. Interestingly, a sideline debate erupted over the status of a website tracking Google's discontinued services, with some claiming it was still active and others joking that the site's team had been laid off. As commenters dissect Google's reasoning, the thread reveals a mix of curiosity and cynicism about the tech giant's priorities.
Snapshot generated from the HN discussion
Discussion Activity
Active discussionFirst comment
10m
Peak period
11
6-9h
Avg / period
4.6
Based on 51 loaded comments
Key moments
- 01Story posted
Dec 15, 2025 at 9:56 AM EST
18 days ago
Step 01 - 02First comment
Dec 15, 2025 at 10:06 AM EST
10m after posting
Step 02 - 03Peak activity
11 comments in 6-9h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 17, 2025 at 12:49 PM EST
16 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
I know it's still active because I see someone with that handle posting on bluesky regularly.
Translation: We don’t actually want to keep spending time, money, and resources on this.
This is one where I don't blame them for killing it because "it" wasn't really even a product -- it was just a very basic, not useful at all, report.
I have a common name Gmail account. The password is rather complex and I would be surprised if it leaks as only I and Google know it. However, I would get reports that it’s on the dark web with blanked out password values. So I never knew if they actually compromised or just something else.
They would also report when some random site that used my Gmail address as user id was on the darknet that I don’t care about. I don’t care if my fidofido account is leaked. I never use it and if I did, then I would reset.
I think if the data were useful Google would have kept this up.
I bet they keep tracking though, just keep the reports internal.
The worst part is, it was an email address I hadn't used in about 10 years, and they wouldn't let me take it out of the report.
There are tens of services where I'd like it disposable, but hundreds of services where account is warranted. And some of those thousands will be compromised some day.
What are the common two-letter first or last names?
For first names… Jo, Ty, Al, maybe?
Tangental, but I found 'Have I Been Pwned' useless too because you can't enter your email and find leaked passwords associated with the address, instead you have to enter each password (and repeat for every password you want to check).
I know there's an explanation that the raw password is not being sent and instead being hashed locally and only part of the hash is sent. But I don't know how to verify that and it feels wild to type passwords into a random website. (if anyone knows how to verify HIBP does only what it says it does [rather than blindly trust and hope for the best], would love to read more about it)
Though perhaps there could be a service where you enter in an email address and it sends an email to that address containing the passwords. That would be a slightly more complicated server to set up though
It doesn't use any information that's not already exposed.
It reveals the extent of my problem to me.
Almost everyone interested in checking for password leaks knows how to generate SHA256 of a string. And those who don't shouldn't put their passwords on the internet.
Or even better, generate hash for all passwords in the database, package these hashes together with a simple search script and let people download it. That way, you are not sending any information anywhere, and noone can exploit the passwords, because hash is a one way function.
Then again, that download could be really large. I admit I have no idea how much storage would that take. But it's just text, so easily compressible. And with some smart indexing, it should be possible to keep most compressed and only unpack a relatively small portion to find a complete match.
Then again, I have virtually no background in cryptography, could be something horribly wrong with this.
When you do a check on https://haveibeenpwned.com/Passwords nothing is sent to the server. Instead the password is hashed locally and a list of the hash range is downloaded, which contains all the hashes and the number of occurrences.
The server doesn't receive the password, neither in plain-text nor hash form.
* user submits password * gets hashed client side * server compares it against stored hashes * server also re-hashes the stored hash, and compares it against the hash received from the client
This would effectively mean that either entering the password, or the password hash would correctly match, since when entering the hash you are effectively "double" hashing the password which gets compared to the double hashed password on the server.
The upside is that users who don't understand hashing or don't feel like opening a sha256 tool wouldn't have to change their behavior or even be confused by a dialog explaining why they should hash the input, while advanced users could find out about the feature via another channel (e.g. hackernews).
The downside would be that it adds an extra hash step to every comparison on the sever. It's hard to know how expensive this would be for them.
I don't know how to verify what the website does, but I think that in a few minutes I'll be able to put together a CURL call that does what we're hoping the website does.
[0]https://haveibeenpwned.com/API/v3#PwnedPasswords
Alternatives: haveibeenpwned.com (free), 1Password Watchtower, Bitwarden breach reports.
The harder part isn't knowing about breaches—it's actually rotating passwords afterward. Most people know they should but don't because it's tedious.
Automated rotation tools are emerging but need careful security architecture (local-only, zero-knowledge) to avoid creating new attack vectors.
5 more comments available on Hacker News