Serious Discussion Enhanced protection (Chromium based browsers)

Your read of Google’s wording is reasonable, but it helps to separate “known to Google Search” from “known to Safe Browsing,” and to understand what “unknown” can mean in practice.

“Unknown websites” does not necessarily mean “rare”

Google’s indexing/crawling for Search is a different system from Safe Browsing reputation and classification. A site can be “indexed” (or simply exist) without being “known/assessed enough” for Safe Browsing’s purposes at the moment you visit it.

“Unknown” can include things like:
  • Newly registered domains and freshly created subdomains
  • Short-lived phishing/scam infrastructure
  • New URLs/paths on otherwise known domains (Safe Browsing often reasons at URL-level granularity, not just domain-level)
  • Redirect chains and tracking links
  • CDN-hosted content, file download URLs, and “one-off” campaign links

So it’s true that Enhanced Protection isn’t designed to upload full telemetry for every normal page view, but “unknown” can still be triggered more often than many users expect, especially if you browse broadly, click external links, or encounter lots of redirects.
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).
 
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
 
  • Like
Reactions: Halp2001
Agree but you don't know what the privacy policy is of the services it sends your shortened URL to.

Mainly hashes (partial versions) of URLs.
Only in cases of suspicious verification may the full URL be sent.
So, in my case, the second scenario rarely occurs.;)

P.S.
For those who want to extract an opinion from me, I suspect that Chrome's Standard Protection protects my privacy more than Osprey (which I don't use).:)
Although minimal exposure is acceptable for protection functionality.
 
Last edited:
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.

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.
Well I certainly agree on the Trust and incentives point you are raising. About the third point (URL sensitivity) may i remind you that Google promises to make them non-identifiable (and please @Bot don't start a discussion on this). This thread was intended to put things in perspective about the second point (optics and misunderstanding), (so @Bot thanks for helping out and raising this "Trust and incentives" aspect).

I am happy with the conclusion: Google's enhanced security actually does not have a bad privacy policy. Problem is that the executing organisation of that policy has a questionable reputation on that matter.
 
Well I certainly agree on the Trust and incentives point you are raising. About the third point (URL sensitivity) may i remind you that Google promises to make them non-identifiable (and please @Bot don't start a discussion on this). This thread was intended to put things in perspective about the second point (optics and misunderstanding), (so @Bot thanks for helping out and raising this "Trust and incentives" aspect).

I am happy with the conclusion: Google's enhanced security actually does not have a bad privacy policy. Problem is that the executing organisation of that policy has a questionable reputation on that matter.
That’s a fair way to frame it.

Perspective that usually gets lost in these debates
  • From Google’s own documentation, Enhanced Protection is not “send everything you browse,” and it includes stated privacy safeguards (limited-purpose use, retention limits, and efforts to reduce identifiability).
  • The negative perception often comes less from the written policy and more from institutional trust: users are weighing the same data flow very differently depending on who receives it and what their business incentives are.

Practical takeaway for readers
If someone accepts Google as a counterparty, Enhanced Protection is a sensible security upgrade.

If someone does not accept Google as a counterparty, then the “privacy debate” is mostly settled before any technical details, and Standard Protection plus other layers (DNS filtering, reputable AV web protection, careful extension permissions) is the more consistent choice.

That keeps the discussion grounded: the optics/overstatements are real, but so is the trust dimension.
 
Indeed, Brave has proxied Google Safe Browsing requests since they implemented it in 2018. No data is directly communicated with Google.

Safe Browsing already promoted privacy as a standard by using partial hash matching since 2007. Brave periodically downloads a local hash prefix list through the proxy for this purpose, and full hashes are only compared in the case of a prefix match.

I do recommend bolstering your browser security by adding another reputation and URL blocking service to your setup, but it's unlikely to be quite as privacy-friendly.
Avira Browser Safety as long as it is German (Avast transferred legal to US for browser plugin already) and not Gen Digital is okay (they should only keep anonymized known bad URL hits).
 
Avira Browser Safety as long as it is German (Avast transferred legal to US for browser plugin already) and not Gen Digital is okay (they should only keep anonymized known bad URL hits).
I don't use the browser plugin, just Web Guard. As a user in the US, my Avast data is stored and processed by Gen Digital Inc. in the United States according to this privacy policy statement:
Note that samples (files, URLs and other malicious identifiers) used for malware and scam analysis are kept in our systems as long as it is necessary to ensure proper functionality of the AV product. These samples are not connected with users or other individuals and the retention periods indicated above do not apply to this use.
For EEA users, the primary controller is often Avast Software s.r.o. (Czech Republic) or NortonLifeLock Ireland Limited, but your data may still be transferred to and processed by Gen Digital entities elsewhere.

Avira stores and processes data for American users the same way at Gen Digital. Again, data can be shared with Gen Digital entities worldwide having followed laws in the original jurisdiction. This what I found in the privacy policy on Avira Safe Shopping / Avira Browser Safety:
…We collect much of this data in a pseudonymized or anonymized form…

Location Data may include:
  • IP address
Device Data may include:
  • Operating system (including version or platform)
  • Browser type, version, and settings
Security Data may include:
  • Browsing activity
  • Search terms
Product Data may include:
  • Product version and preferred Language
  • URL of blocked websites
  • Metadata (e.g., number of blocked websites and number of unsafe websites clicked)
 
Last edited by a moderator: