|Status note||Monica is working out the last follow-ups to enable verifying signed binaries on Windows to enable remote lookups. Local lookups are landed and shipping in FF 28.|
|Product manager||Sid Stamm|
|Directly Responsible Individual||Monica Chew|
|Lead engineer||Monica Chew|
|Privacy lead||Sid Stamm|
|Product marketing lead||`|
|Additional members||Doug Turner|
= $all-$resolved ?> Open; = $resolved ?> Resolved; = $all ?> Total (0% complete)
Stage 1: Definition
1. Feature overview
We warn on every application download, which causes warning fatigue and doesn't help users make good decisions. We should track the reputation of download URLs and hashes.
See Security/Features/Application_Reputation_Design_Doc for implementation details.
2. Users & use cases
Downloading popular, legitimate applications: warnings should become less severe and less redundant.
Downloading known malware or unknown applications: warnings should become more severe and clearer about the origin of the download. Perhaps more similar to the UI for installing Firefox addons (since the result is equivalent).
Google maintains an extension to Safe Browsing that tracks binary file reputation. We can harness their API to provide application reputation whitelisting for Firefox users.
- Preserve privacy as much as possible. This should only apply to downloaded applications, not documents. The URL should not be sent to Mozilla if the download is declined. Users should have the option to use this feature without contributing data to it.
- Virus scanning.
- Offering to sandbox untrusted native applications.
- Preventing downgrade attacks.
- Forcing application download sites to use https.
- Foist AMO-style user reviews upon application download sites.
Stage 2: Design
5. Functional specification
6. User experience design
- Checkbox to enable/disable in Security pref panel next to the phishing/malware stuff?
- We should add a note to the download history that says, for binary downloads, what action was taken (e.g., "file whitelisted by google", or "requested analysis from Mozilla, might be malware".
Stage 3: Planning
7. Implementation plan
Lets do this in stages:
- Implement prefed-off support for downloading and updating Google's reputation whitelists
- Implement easier UI (or none) for downloads matching the whitelist
- Run tests to see how often unknown URLs are transmitted to the API
- Based on tests, perhaps enable the feature by default
- Eventually provide pluggable support for other reputation systems (like the search plugins)
Quality Assurance review
Stage 4: Development
Stage 5: Release
10. Landing criteria
|Theme / Goal||Product Hardening|
Team status notes