Michael Vincent van Rantwijk, MultiZilla wrote: > I can check my links, and the download files, but some of the download > mirrors might not be up to date, yet,
Then don't deploy the link until they are. > so we either have to choose to not > use link fingerprint at all, or something should change in the > implementation to prevent it from deleting any good files. Don't use Link Fingerprint if you don't mind users downloading different data. If you do mind, use Link Fingerprint and they won't be able to. It's that simple :-) > The implementation seems to assume that we, the people using download > mirrors, should know everything about the used download mirrors, which > we clearly don't obviously, so removing good downloads because of a hash > mismatch is wrong. No, it assumes that if someone publishes a URL with a Link Fingerprint, then they only want the users to get that particular data, and not any other data. That's what Link Fingerprints are _for_. > The end-user is or better should have control over > it, not a program, just like for visiting SSL and the Mozilla Firefox > phishing protection. We are changing the "visiting SSL" thing. As for phishing protection, false positives occur. So there is an (albeit very scary) override function. But in the case of Link Fingerprints, the provider of the URL has made an explicit decision to use the fingerprint. He should not do so if it's not going to work, or if he doesn't mind if the user gets different data to the data he wanted the user to get. That's what normal links do, and they do it very well. Gerv _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
