On Tue, Feb 14, 2017 at 12:14 AM, 段垚 <duan...@ustc.edu> wrote: > I guess all popular softwares have exploits being traded. How this fact >>> invalidates my argument? >>> >> I was responding to your point about the threat declining because of the >> declining usage of Flash. This is demonstrably not true. >> > > Why? Assume > > threat_of_flash = exploits_of_flash_per_year * usage_of_flash_per_year > > If usage_of_flash_per_year is declining but threat_of_flash is increasing, > then exploits_of_flash_per_year must be increasing. > But the report you cited does not provide such data. >
That assumption doesn't hold: malicious uses of Flash don't need non-malicious ones. In fact it seems quite likely that there'll be an inverse relationship: less (non-malicious) usage means less testing of potentially exploitable code paths, which would increase the threat. One solution to this is to decouple the amount of testing done for those code paths from how frequently they're used. In practice that's not trivial because at least some testing comes in the form of investigating crash reports from users. Another solution is what's proposed here: disable less-well tested configurations altogether. > > >> Also I think forbidding non-http(s) Flash does not fix thoses exploits >>> magically. >>> >> Sure, this is about reducing attack surface, not completely eliminating >> it. >> > > Non-http(s) Flash takes only a small fraction of all Flash contents, even > for users who do use non-http(s) Flash. > I don't think users want to drop their local Flash for a small fraction of > reduced attack surface, > especially if those local Flash don't have alternatives yet. The more > practical reaction is trying another browser. The underlying assumption here is that these usages of Flash are rare enough that the incompatibility, while unfortunate, becomes acceptable. Note that other browser vendors are planning their own measures for restricting Flash usage, too. I understand that none of this helps you, and that's very unfortunate. I hope you appreciate that we don't have infinite resources and thus have to make, sometimes painful, trade-offs. Much as you probably have to in your own projects. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
