Let's analyze your response
1. Analyse Newly registered or newly seen.
Have a look at URLHAUS arround 95% to 99% of the malware and phishing classifies as "new" because most are short lived
2. Short-lived phishing/scam infrastrructure
Again what is wrong about checking them?
3. New URL's/paths on ontherwise known domains
Mhww that is a valid point, but these are also typical for hacked websites being used as "download" donkeys for malware distribution? So what is wrong about checking them
4. Redirect chains and tracking linkc
Chrome itself has a maximum on redirection and blocks it. It would not have implemented this practice when multiple redirection was not a way of malware distribution, so again what is wrong about this?
5. CDN-hosted content, file download URLs, and “one-off” campaign links
File download URL's should be checked so again, well done Chrome advanced malware protection. One-off's classify as new in my book and I don;t mind them being checked either.
Conclusion:
Only the CDN-hosted and one-off campaigns are the ones which I would not have chosen to send to Google servers. Compare that to Microsoft's advanced protection (sending every URL) and I still don't understand why Google's protection has such a bad name, compared to Edge (which is worst in terms of privacy when you compare head to head).
You’re right that every one of those categories is also a legitimate “high risk” signal, and from a pure security angle it makes sense to scrutinize them harder. The disagreement in these discussions usually isn’t “is it wrong to check?”, it’s “is it acceptable to share more of my browsing data with a vendor to enable that checking?”
Point-by-point (security value vs privacy cost)
1)
Newly registered / newly seen
Agreed: “new” is disproportionately represented in malicious infrastructure (URLhaus and similar feeds show that pattern very clearly). From a protection standpoint, escalating analysis for “new” URLs is rational.
The privacy cost is that “new” is also common for benign long-tail web content: niche forums, new blog posts, ephemeral tracking URLs, and share links. When full URLs are transmitted, they can contain sensitive context in the URL itself (query strings, campaign IDs, document IDs, etc.).
2)
Short-lived phishing/scam infrastructure
Agreed: fast, server-side, real-time checks help here because blocklists lag. This is one of the best arguments for Enhanced Protection.
3)
New URLs/paths on otherwise known domains
Also agreed: hacked-but-legit domains and “/download/…” droppers are common, and path-level granularity matters.
Privacy angle: paths can reveal very specific user activity on otherwise normal sites (account pages, internal app paths, password reset URLs, invite links, etc.). Even if a vendor says they only use it for security, the user still has to accept the disclosure.
4)
Redirect chains / tracking links
Agreed: redirect chains are heavily abused, and “more context” can improve detection. Chrome’s redirect limits help with some classes of abuse, but reputation decisions often benefit from seeing the chain, not just the final landing page.
Privacy angle: tracking links often embed unique IDs. Sending those as full URLs can effectively function as a cross-site identifier in the data you disclose.
5)
CDN-hosted content / download URLs / one-off campaign links
Agreed: downloads absolutely should be checked. That’s a core security use-case.
Privacy angle: CDNs and one-off links are extremely common for perfectly legitimate content (images, JS bundles, app updates, invites). So “CDN” and “one-off” can mean “routine browsing,” not just “suspicious browsing,” which makes some users uncomfortable with any server-side escalation that might include full URLs or page snippets.
So why does Google Enhanced Protection get a “bad name,” while Edge is often tolerated?
A few non-technical reasons drive this more than the actual mechanics:
- Trust and incentives: Google’s core business is advertising. Even if Safe Browsing is a separate security system with documented safeguards, many privacy-focused users are less willing to grant Google additional browsing-related signals than they are with a vendor they already “expect telemetry from.”
- Optics and misunderstandings: a lot of people oversimplify it to “Enhanced = sends everything,” which is not what Google documents. That bad simplification spreads easily.
- URL sensitivity: even “just URLs” can be very sensitive because URLs frequently contain identifiers and intent. Users who’ve been burned by link-based identifiers (invite links, reset links, shared docs) tend to default to minimizing any full-URL disclosure.
On the Edge SmartScreen comparison
I can’t safely confirm the claim that SmartScreen “sends every URL including unique user id since forever” as a general statement, because Microsoft’s behavior depends on specific features, settings, and versions, and the exact payload details aren’t consistently observable without controlled testing.
What is fair to say is that SmartScreen is a cloud reputation system and does involve network lookups; that tends to trade more data for better timeliness, similar in spirit to Enhanced Protection.
Bottom line
Your conclusion is consistent: for many threat models, Chrome Standard Protection is a solid privacy/security compromise, and Enhanced Protection is a reasonable choice if you accept the additional disclosure in exchange for faster, more context-aware blocking.
If someone wants “as little URL disclosure as possible,” the alternative isn’t “better security without tradeoffs,” it’s usually “different layers” (DNS filtering, local content blocking, AV web protection), each with its own privacy implications.
Sources