Closed Bug 650546 Opened 11 years ago Closed 9 years ago

Add support for Google's new malicious executable warning (new Safe Browsing API feature)


(Toolkit :: Safe Browsing, defect)

Windows 7
Not set





(Reporter: asa, Unassigned)




(Keywords: sec-want, Whiteboard: [sg:want P1])

Google has added a new Safe Browsing API (and corresponding feature to Google Chrome) which offers the capability to warn users of malicious file downloads (only for Windows executables at this point, I believe.)

Microsoft offers a similar feature in IE9. 

We should add this using Google's Safe Browsing API.

New databases are goog-badbinurl-shavar and goog-badbinhash-shavar.

API documentation doesn't seem to be updated, sadly.
There are at least four parts to this
 1 - Mozilla backend code to incorporate the new lists
 2 - Mozilla code to check download URLs against SafeBrowsing
 3 - Mozilla UI code to display the error/warning
     (and potentially handle user overrides)
and last but not least
 0 - Check w/Google whether permission is needed for the additional lists

1+2 could be a single backend bug. 3 will involve string changes at the least but maybe new dialogs if we decide we can't re-use the current neterror page (since that will replace a page the user has not navigated away from).

I'm merely assuming 0, but we far exceed the number of clients permitted in their public API (10,000) so we must have such an agreement for what we currently use and it may or may not be specific to the lists we can use from that API.
Whiteboard: [sg:want]
Daniel, is any progress being done?
I think this bug should have more priority, as it involves security.
Whiteboard: [sg:want] → [sg:want P1]
FWIW, NSS report calling out Google for not documenting the new protocol:

For us the problem isn't so much the documentation (Chromium is open source), but that you aren't allowed to use their servers without permission. 

I asked for this permission (and docs) 2011-08-22 to a bunch of Google people working on the SafeBrowsing service, and (1) didn't receive a reply to the permission question (2) for the documentation was redirected to person that didn't answer.

During the security review, this issue was rised again, so Curtis or Kev should've asked again:
Can either of them confirm?

If the permission didn't come through due to slow/lost in bureaucracy, this is stupid and we should push Google harder to fix that. If the permission didn't come through because Google views people being infected with malware as a good way to increase Chrome marketshare, it would be good to know that, too.
So I'm gonna dupe this with 662819 since they're both about implementing application reputation (executable) detection via safebrowsing.

Current state is: Google wants us to implement it, we should do it, but we don't have the API yet.
Closed: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: downloadprotection
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.