Only debounce Google URLs when SafeBrowsing is disabled

[ryanbr]

Description

Debounce embedded google urls without targeting safebrowsing urls.

Steps to Reproduce

1. Received a tracking ticket on gmail, with the following google bounce
2. https://www.google.com/url?q=https://t.17track.net/%23nums%3D2222062731&source=gmail&ust=2239542218716022&usg=A12Vaw22aVcgCnimxpL3T22Gs--w
3. Able to target this bounce without causing safebrowsing urls.

Miscellaneous Information:

Original PR: https://github.com/brave/adblock-lists/pull/728 (And reverted https://github.com/brave/adblock-lists/pull/729)

[pes10k]

Thanks very much @ryanbr !

@pilgrim-brave , previously we discussed only debouncing Google URLs like these when SafeBrowsing is disabled. Let's use this issue to track that project. I'll assign now, but let's discuss whenever is convenient where in the priority queue this slots.

[fmarier]

Noting that this was discussed during the privacy meeting on 2022-06-07 and we were not able to find a way to debounce the URLs coming from Apple Mail without affecting outgoing links from GMail (web UI) or Google Docs.

The security team's opinion is that disabling this security-relevant bouncer for people without Safe Browsing is not a good tradeoff since users without Safe Browsing are even more vulnerable to phishing/malware links.

Perhaps we should close this issue until we can think of another way to address this?

[pes10k]

after thinking this through again, i do not think we came to the right conclusion. I don't think we should keep applying (effectively) Google's safebrowsing to users who have opted out of Google's safe browsing. I appreciate that the security team thinks that its unwise for users to disable safebrowsing, but if thats the case we should remove the ability for users to opt out of safebrowsing (note, i do not think we should do this).

But, continuing to apply safebrowsing (i.e. the google redirect) sometimes because we think the user shouldn't have disabled it at all seems both confusing and unkind to our users.

I appreciate others don't agree, but please leave this open until we can discuss at the next privacy confab then

[thypon]

I played with the Google bouncer, and it’s effectively an internal/interstitial bouncer, not an external one. By internal/interstitial bouncer I mean that whenever the link is directed out of Google it will bounce to a confirmation page, otherwise it will just redirect.

Test examples:

• https://www.google.com/url?q=https://en.wikipedia.org/wiki/Ciao blocked
• https://www.google.com/url?q=/search?q=ciao%26btnI=I%27m+Feeling+Lucky blocked - which means they even thought and worked on edge cases not to allow external bouncing

Plus, Google can inspect any on-click handler to deanon click if you are in a Google document.

IMHO, there is no point at all in debouncing internal bouncers, since in all the cases they can check for both on-click events and Referer, or even add a specific tracking parameter/cross-site cookie

Effectively debouncing (bouncer^-1) we are removing protections without real user benefits.

[thypon]

https://user-images.githubusercontent.com/581115/177705756-253d279c-4aed-430e-badf-6c41d0d1118a.mp4

The video shows that the ping URL is never hit to redirect the user when they click on the link.

[pes10k]

This is not correct. As discussed in slack and in privacy confab this bouncer is used to modify links in gmail accounts when those gmail accounts are accessed through 3p software (mail.app, thunderbird, etc)

On Jul 7, 2022, at 01:25, Andrea Brancaleoni @.***> wrote:

 https://user-images.githubusercontent.com/581115/177705756-253d279c-4aed-430e-badf-6c41d0d1118a.mp4

The video shows that the ping URL is never hit to redirect the user when they click on the link.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were assigned.