Edward Lee wrote: > The main reason for /Link Fingerprints for everything/ is that only > doing the checks on a subset of things could confuse users that have > learned the Link Fingerprint provides some level of security. > > Nils Maier wrote: >> What will happen in the case of not fully retrieved channels? >> I would have expected a "hint" to the consumer saying UNABLE_TO_CHECK >> instead of VERIFIED, CORRUPT or UNSUPPORTED. > > As things are implemented right now (for me), the channel consumers > (listeners) will still get the transferred data as it arrives > (OnDataAvailable). The only difference is that OnStopRequest will have > an error code if the Link Fingerprint failed. > > In the case of the built in Firefox download manager, it will need to > explicitly remove the file after the transfer has finished provided the > status is NS_ERROR_INVALID_LINK_FINGERPRINT. > > One caveat is that as of *right now*, my implementation will kill a > transfer if the expected hash is syntactically wrong (i.e., wrong length > or contains non-hex characters). In this case, there will be no > OnDataAvailables. > > And of course, these things are up for discussion and can change. :) > > >> Generally enforcing the check even for "range-less" requests would >> probably hurt DownThemAll and similar products. > > That's only if they don't update to know about Link Fingerprints. If > those products make the decision to not support Link Fingerprints, all > they need to do is strip off the #fragment-id before making the request. > > The end-user who requested a Link Fingerprinted download in a browser > that supports Link Fingerprints would expect the download to be checked. > If we go down the path of (1), download managers that haven't updated or > lack knowledge of Link Fingerprints would download the file in chunks > and *not* do the check - breaking the user's security trust of using > Link Fingerprints.
All link fingerprints can do is check the link against a download file, and only after the download is completed, but nothing more, so the use of the word "security" here is a bit too far stretched IMHO. Michael _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
