Michael Vincent van Rantwijk, MultiZilla wrote: > 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.
I don't understand what you are getting at. Having a link fingerprint ==> the link creator cares what data you get Not having a fingerprint ==> the link creator doesn't mind what data you get. It's not about "secure" or "insecure" in the general terms in which you phrase it. >> 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. But that's entirely irrelevant. The question is solely about the sender, the potential recipient, and the data. If the sender wants to send particular, specific data to the recipient, they should use a link fingerprint. If not, then not. If you want to send specific data, and someone at mozdev has not done their job, then the link will fail. Which is good, because you wanted to send specific data and the recipient doesn't have that data. You can't both want to send specific data, _and_ not care if they get other data! >> 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. Why? >> 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? Firefox makes decisions for the user all the time. If you think that the average Firefox user wants to make every decision for themselves, then you don't understand our target market at all. A lot of the things that differentiate Firefox from Seamonkey are to do with giving the user fewer choices, and just Doing The Right Thing. The purpose of the existence of Link Fingerprints is to get _specific_ data from person A to person B. This necessarily implies that if person B receives different data, it is not the data A wanted to send, nor the data that B should be receiving. So it should be deleted as if it were never downloaded, and ideally both parties, but certainly person B should be alerted that there was a problem. > 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. There will not "always be false positives" with sha256. If extension writers break this feature, then that's their problem. They could break any feature of Firefox if they so chose. That doesn't mean we change the design of those features - because they could just break the new design anyway. > 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... I don't understand your point here. Why does Link Fingerprints prevent people from bookmarking XPInstall links? We don't delete data if the hash matches! And if you don't mind which version of the addon you get, don't use Link Fingerprints. > 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? I don't know. While the idea of checking against hashes is similar, Link Fingerprints is not connected to this idea. Gerv _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
