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.
I don't understand what you mean by "Link Fingerprints for everything". If some URLs don't have Link Fingerprints, we can't make them up. Also, one of the big points of Link Fingerprints is that users are entirely unaware of it. In the common case, it has no UI. The download proceeds and succeeds and the user has no idea that the browser is checking on his behalf that he has the right file. > 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. That's fine. If someone sends out a URL with a bogus link fingerprint, then they should have tested it. Link Fingerprints is designed from the start as a hard-fail system. If the check fails, the user does _not_ get access to the data. If the person supplying the URL wants the user to have the data even if it's corrupt, then they shouldn't be using Link Fingerprints. > The end-user who requested a Link Fingerprinted download in a browser > that supports Link Fingerprints would expect the download to be checked. Assuming they know what they are, then I agree with that. Gerv _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
