Seems I failed to convince you to change the plan.
So the last question is: when will this happen?
在 2017/2/15 2:54, Till Schneidereit 写道:
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
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
