Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Safe Browsing setting is potentially misleading #5125

Open
fmarier opened this issue Jul 4, 2019 · 4 comments
Open

Safe Browsing setting is potentially misleading #5125

fmarier opened this issue Jul 4, 2019 · 4 comments

Comments

@fmarier
Copy link
Member

@fmarier fmarier commented Jul 4, 2019

The Safe Browsing setting in chrome://settings/privacy says that some unsafe pages might be sent to Brave:

Screenshot from 2019-07-03 23-17-36

I'm not 100% sure what part of Safe Browsing it's referring to, but I doubt it's sending Brave URLs. It's most likely sending these to nobody (because we turned it off) or it's sending these to Google under some limited circumstances.

cc @jumde

@fmarier fmarier added this to Untriaged Backlog in Security & Privacy via automation Jul 4, 2019
@bsclifton
Copy link
Member

@bsclifton bsclifton commented Jul 4, 2019

@fmarier these URLs are being sent to us and then proxied to Google. We have a Google Cloud platform account which has a token used to handle this service

@fmarier
Copy link
Member Author

@fmarier fmarier commented Jul 4, 2019

Yes, we do proxy Safe Browsing requests. In the case of browsing protection (e.g. the phishing warning pages), that includes both updates and requests for full hashes, but those are not actual URLs.

On the other hand, for download protection (i.e. how downloads are checked for maliciousness with Google Safe Browsing) we do currently send URLs to Google (to be disabled in #4341).

There are other parts of Safe Browsing which use URLs and which I need to investigate (and disable if they're active): client-side phishing detection), extended_reporting and password_protection.

While we proxy all of the requests, we're not looking at them, only Google is. So it seems misleading to state that some URLs might get sent to Brave, when they are really sent to Google via Brave.

@rebron rebron self-assigned this Jul 5, 2019
@rebron rebron added this to P3 backlog in Settings Jul 9, 2019
@tomlowenthal
Copy link
Member

@tomlowenthal tomlowenthal commented Jul 20, 2019

@fmarier Do we have access to the plaintext of either the hash-prefix requests or the URL-based requests as they transit our proxy?

@fmarier
Copy link
Member Author

@fmarier fmarier commented Jul 23, 2019

Since we are using a brave.com endpoint for the requests, I believe we have access to the hash prefixes and the soon-to-be-disabled URLs in download protection requests.

@tomlowenthal tomlowenthal assigned tomlowenthal and unassigned rebron Jul 23, 2019
@fmarier fmarier moved this from Untriaged Backlog to P3, P4, & P5 Backlog in Security & Privacy Sep 27, 2019
tmancey pushed a commit that referenced this issue Apr 9, 2020
…ons_1.7.x

Embedded map fingerprinting exceptions (uplift to 1.7.x)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Security & Privacy
  
P3, P4, & P5 Backlog
Settings
P3 backlog
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.