On Tue, Feb 14, 2017 at 12:00 PM, 段垚 <duan...@ustc.edu> wrote: > > > 在 2017/2/14 18:10, Till Schneidereit 写道: > >> 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. >> > I agree. So let me ask this question instead: is there any proof that > local-only Flash > exploits are increasing? >
I don't know. I do know that legitimate usage of Flash, be it via file: or otherwise, is steadily declining. That's all that's needed to change the cost/benefit balance here. > >> 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. >> > > I would assume Adobe will actively test Flash plugin with local contents > for a reasonablely long time. Do you mean tests in Firefox for local Flash > contents > will inevitably decrease even if you don't disable it? > What I'm saying is that testing and hardening against attacks isn't free, so requires investing resources. This entire thread is based on the conclusion that Flash usage has diminished to a point where it's can no longer a good investment of resources to keep doing these activities for this fairly niche-usage of Flash. > >> 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. >> > > Although usage of local Flash is rare, I'd point out that local Flash > contents usually have higher > value than those on web sites, Because users only save important contents > to disks. > Additionally, local Flash contents are much harder to replace than those > on web sites > because users can hardly contact the author. Please consider more for > users. > We are doing precisely that, but we believe that our users are better served by us investing resources in tasks that have more impact. Again, the underlying assumption in this entire thread is that our users won't be affected as strongly as you assume, or few enough will. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
