Firefox3/Link Fingerprints
Link Fingerprints is a Firefox 3 feature to automatically ensure file downloads match the embedded checksums provided in a link.
Status
- Feature tracking bug
- [SoC] Link Fingerprints bug 377245
- Link Fingerprints Internet Draft
- Existing implementation for necko in bug 377245 can be modified for Firefox 3 Download Manager
Overview
Link Fingerprints allows Firefox to verify automatically that an end user downloads the same file that the link provider intended. This can be accomplished by the download manager looking for a specially crafted URL of the format: http://site/file#hash(sha256:abc123) where the #fragment-id indicates that the link has a Link Fingerprint and the expected sha256 hash is abc123.
The changes are backwards compatible and only require surgical modifications to the download manager client (no changes to servers or networks), and in the common case, everything will look the same as before. Link Fingerprints is easily incrementally deployable because with Firefox supporting it, site administrators will get faster feedback that a linked download might have been compromised and fix the download which helps all users (not just Firefox users).
Use Cases
File downloads that are spread across mirrors and referenced from a central site can use Link Fingerprints to extend the increased security of the central site. For example, www.mozilla.com links to 3rd party mirrors that could have the Firefox binary modified to contain a virus; however, if the link pointing to the mirror has a Link Fingerprint, the download manager can automatically check the hash and prevent the user from using the file.
In the common case where the download does not have a Link Fingerprint or when the hash matches, the user sees nothing different from now. Only if there is a fingerprint mismatch will the file be removed and have the user notified to contact the site administrators with an error such as "<file> was not saved because the file appears to be corrupted. Please contact the site administrator."
Requirements
- Detect if a download has a Link Fingerprint
- Compute and check the hash of the downloaded file (nsICryptoHash)
- Remove file and alert user if there's a failure
Schedule
- Simplify the existing implementation in bug 377245, perhaps all in javascript or nsDownloadManager.cpp?
- Potentially coordinate with download resuming implementation
Implementation Plan
- Reuse the parsing from necko implementation or do it in javascript: url.match(/#hash\(sha256:[0-9a-f]{64}\))
- Update the hash directly from the data (webbrowserpersist/exthandler) or read from the file (incrementally or at the end)
- Reuse the prompter service for failure to alert the user
- Perhaps leverage the antivirus/malware scanning state (see CON-006a)
UI Design Documentation
- The user would get an alert on failure, which reuses the existing download manager's failure message code logic
Design Impact
Security and Privacy
Link Fingerprints doesn't necessarily affect security, but it can help ensure security related file downloads are correctly retrieved.
Exported APIs
The download manager implementation can be stand-alone, but potentially a new Link Fingerprints interface can be created to provide functionality such as "URIHasLinkFingerprints"
Web Compatibility
The current status of Link Fingerprints is an Internet Draft going through IETF, but there are potential existing implementations such as the Firefox DownThemAll extension (dTa wiki).
Link Fingerprints uses the fragment identifier of a URL, which isn't used for file downloads anyway, and its format is backwards compatible.
Performance
The computation of the file hash can be done incrementally as the download transfers, so when it finishes, the user can access the file right away or be notified that the file was corrupted.
Reliability
The user does not need to decide on anything for successful or failed Link Fingerprint downloads. Firefox will either make the file available or delete it without a user decision.
l10n and a11y
There is a new string letting the user know that the file is corrupt and that the site administrator should be contacted.
Configuration
A hidden pref could potentially be added to turn off Link Fingerprints checking, but that isn't really necessary as the user can manually remove the Link Fingerprint #fragment-id and download.
Relationships to other projects
The implementation might change depending on download resuming..
Documentation
Other
Discussion & Implications
Caveats / What We've Tried Before
Necko implementation works is has Link Fingerprints tied too closely to networking code.
