Gervase Markham wrote: > 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.
I was expecting this answer, but wouldn't you agree that this gives a false sense of insecurity? I mean, _not_ having the link fingerprint attached to a link because of limitation outside the scope of the webmaster, will eventually make people belief that something is wrong with their links. Not good. >> 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 :-) I wish I had a say in this, really, but sometimes you have to rely on other people. I mean, most people over at mozdev.org, or other services using mirrors, don't have control over other peoples time and money. >> 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_. Yes, and the result will be, eventually, that people think that the links/downloads from mozdev.org are _insecure_ which we know both is not fair. Again, we don;t have control over the download mirrors, and please, don't come with it (and here it comes) you can use a.m.o >> 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. Fine, thanks. > As for phishing protection, > false positives occur. So there is an (albeit very scary) override > function. Which is how it should be, leave the end-user in control. You don't know everybody neither does the Mozilla Corporation, and let me remind you that most people just plain hate it when Microsoft is making decisions for them, so why would anyone accept yours? Deleting other peoples files, because of a simple hash mismatch, should be up to the end-user. There will always be false positives, extension writers to hack into this feature and what not. Also: people can no longer bookmark XPInstall links, because what is the point if the file will be deleted right after the download anyway? Then don't bookmark XPInstall files? Phew, another great feature bites the dust... > 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. OT: What about the ability to add a hash in the updates.rdf? That seems already implemented, so do you use it right now (and since when) or not? _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
