Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

[Benjamin Smedberg]

At this point it seems unlikely that I will have time to fix this for
Firefox 54, so most-likely it will be Firefox 55.

--BDS

On Tue, Feb 14, 2017 at 8:54 PM, 段垚  wrote:

> 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, 段垚  wrote:
>>
>>
>>> 在 2017/2/14 18:10, Till Schneidereit 写道:
>>>
>>> On Tue, Feb 14, 2017 at 12:14 AM, 段垚  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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

[段垚]

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, 段垚  wrote:



在 2017/2/14 18:10, Till Schneidereit 写道:


On Tue, Feb 14, 2017 at 12:14 AM, 段垚  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

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

[Till Schneidereit]

On Tue, Feb 14, 2017 at 12:00 PM, 段垚  wrote:

>
>
> 在 2017/2/14 18:10, Till Schneidereit 写道:
>
>> On Tue, Feb 14, 2017 at 12:14 AM, 段垚  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

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

[段垚]

在 2017/2/14 18:10, Till Schneidereit 写道:

On Tue, Feb 14, 2017 at 12:14 AM, 段垚  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?



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?



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.



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



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

[Till Schneidereit]

On Tue, Feb 14, 2017 at 12:14 AM, 段垚  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

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

[段垚]

在 2017/2/14 2:03, Ehsan Akhgari 写道:

On 2017-02-13 11:50 AM, 段垚 wrote:


在 2017/2/14 0:24, Ehsan Akhgari 写道:

On 2017-02-10 7:51 PM, 段垚 wrote:

在 2017/2/11 2:26, t...@ritter.vg 写道:

On Friday, 10 February 2017 08:32:27 UTC-6, Benjamin Smedberg  wrote:

I thought I enumerated the harm at first, but I'll elaborate a little.

1) Flash doesn't know about and breaks our "current and subdirectory
only"
file: origin policy.

2) Flash is a high-risk attack surface: if you can get somebody to
download
a SWF they can probably own your system. We don't have anyone
testing or
defending this effectively.

So we believe that there is significant harm in the current
situation, and
very little upside.

I think #1 is sufficient to remove this behavior, even ignoring #2. A
malicious flash applet open opened from file:// can read the user's
profile, take all their saved passwords, cookies, etc and steal data,
masquerade as them, and perform all manner of malicious activity.

I agree that this is a problem, but I disagree that Firefox must remove
this behavior now.

* This behavior has existed for decades in all desktop browsers, and the
usage of Flash is declining, which means the threaten is also declining.

That is not true.  It is public knowledge that Flash exploits are traded
as a commodity these days:
.


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.




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.



___
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

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

[Ehsan Akhgari]

On 2017-02-13 11:50 AM, 段垚 wrote:
> 
> 
> 在 2017/2/14 0:24, Ehsan Akhgari 写道:
>> On 2017-02-10 7:51 PM, 段垚 wrote:
>>>
>>> 在 2017/2/11 2:26, t...@ritter.vg 写道:
 On Friday, 10 February 2017 08:32:27 UTC-6, Benjamin Smedberg  wrote:
> I thought I enumerated the harm at first, but I'll elaborate a little.
>
> 1) Flash doesn't know about and breaks our "current and subdirectory
> only"
> file: origin policy.
>
> 2) Flash is a high-risk attack surface: if you can get somebody to
> download
> a SWF they can probably own your system. We don't have anyone
> testing or
> defending this effectively.
>
> So we believe that there is significant harm in the current
> situation, and
> very little upside.
 I think #1 is sufficient to remove this behavior, even ignoring #2. A
 malicious flash applet open opened from file:// can read the user's
 profile, take all their saved passwords, cookies, etc and steal data,
 masquerade as them, and perform all manner of malicious activity.
>>> I agree that this is a problem, but I disagree that Firefox must remove
>>> this behavior now.
>>>
>>> * This behavior has existed for decades in all desktop browsers, and the
>>> usage of Flash is declining, which means the threaten is also declining.
>> That is not true.  It is public knowledge that Flash exploits are traded
>> as a commodity these days:
>> .
>>
> 
> 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.

> 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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

[段垚]

在 2017/2/14 0:24, Ehsan Akhgari 写道:

On 2017-02-10 7:51 PM, 段垚 wrote:


在 2017/2/11 2:26, t...@ritter.vg 写道:

On Friday, 10 February 2017 08:32:27 UTC-6, Benjamin Smedberg  wrote:

I thought I enumerated the harm at first, but I'll elaborate a little.

1) Flash doesn't know about and breaks our "current and subdirectory
only"
file: origin policy.

2) Flash is a high-risk attack surface: if you can get somebody to
download
a SWF they can probably own your system. We don't have anyone testing or
defending this effectively.

So we believe that there is significant harm in the current
situation, and
very little upside.

I think #1 is sufficient to remove this behavior, even ignoring #2. A
malicious flash applet open opened from file:// can read the user's
profile, take all their saved passwords, cookies, etc and steal data,
masquerade as them, and perform all manner of malicious activity.

I agree that this is a problem, but I disagree that Firefox must remove
this behavior now.

* This behavior has existed for decades in all desktop browsers, and the
usage of Flash is declining, which means the threaten is also declining.

That is not true.  It is public knowledge that Flash exploits are traded
as a commodity these days:
.


I guess all popular softwares have exploits being traded. How this fact 
invalidates my argument?
Also I think forbidding non-http(s) Flash does not fix thoses exploits 
magically.



___
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

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

[Ehsan Akhgari]

On 2017-02-10 7:51 PM, 段垚 wrote:
> 
> 
> 在 2017/2/11 2:26, t...@ritter.vg 写道:
>> On Friday, 10 February 2017 08:32:27 UTC-6, Benjamin Smedberg  wrote:
>>> I thought I enumerated the harm at first, but I'll elaborate a little.
>>>
>>> 1) Flash doesn't know about and breaks our "current and subdirectory
>>> only"
>>> file: origin policy.
>>>
>>> 2) Flash is a high-risk attack surface: if you can get somebody to
>>> download
>>> a SWF they can probably own your system. We don't have anyone testing or
>>> defending this effectively.
>>>
>>> So we believe that there is significant harm in the current
>>> situation, and
>>> very little upside.
>> I think #1 is sufficient to remove this behavior, even ignoring #2. A
>> malicious flash applet open opened from file:// can read the user's
>> profile, take all their saved passwords, cookies, etc and steal data,
>> masquerade as them, and perform all manner of malicious activity.
> 
> I agree that this is a problem, but I disagree that Firefox must remove
> this behavior now.
> 
> * This behavior has existed for decades in all desktop browsers, and the
> usage of Flash is declining, which means the threaten is also declining.

That is not true.  It is public knowledge that Flash exploits are traded
as a commodity these days:
.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

[段垚]

在 2017/2/11 2:26, t...@ritter.vg 写道:

On Friday, 10 February 2017 08:32:27 UTC-6, Benjamin Smedberg  wrote:

I thought I enumerated the harm at first, but I'll elaborate a little.

1) Flash doesn't know about and breaks our "current and subdirectory only"
file: origin policy.

2) Flash is a high-risk attack surface: if you can get somebody to download
a SWF they can probably own your system. We don't have anyone testing or
defending this effectively.

So we believe that there is significant harm in the current situation, and
very little upside.

I think #1 is sufficient to remove this behavior, even ignoring #2. A malicious 
flash applet open opened from file:// can read the user's profile, take all 
their saved passwords, cookies, etc and steal data, masquerade as them, and 
perform all manner of malicious activity.


I agree that this is a problem, but I disagree that Firefox must remove 
this behavior now.


* This behavior has existed for decades in all desktop browsers, and the 
usage of Flash is declining, which means the threaten is also declining.

So I don't see the reason for an immediate removal.

* Flash plugin is still actively maintained by Adobe, so I think you can 
ask them to restrict permissions for local Flash contents.

This would benifit all browsers, not just Firefox.



-tom
___
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

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

[段垚]

在 2017/2/10 22:34, Benjamin Smedberg 写道:

On Fri, Feb 10, 2017 at 12:36 AM, 段垚  wrote:


在 2017/2/10 1:28, Benjamin Smedberg 写道:


On Wed, Feb 8, 2017 at 2:26 AM, 段垚  wrote:

Is this just preventing auto-loading (like "click to play") or completely

disable Flash for non-http(s) contents?

This is completely disabling this content.


Can users get back old behavior by flipping a preference?

That is not the plan, no.

Well, this plan seems too aggressive. I'd rather recommend implementing

"click to play" for non-http(s) Flash first and deferring complete removal.

IE requires user's confirmation to load local Flash for a long time.


We are planning on making Flash click-to-play by default for all content.
However, our implementation of click-to-play is based on remembering that
setting per site. This implementation does not work with file: URIs and the
engineering and QA effort to make it work is well beyond what we think is a
reasonable investment.


I think it is OK to not remember that setting for file-urls - just 
require confirmation on each reload.

Is this simpler to implementation?


Flash is a dying technology and this is one low-cost
way we can reduce attack surface and make users safer.

--BDS
___
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

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

[tom]

On Friday, 10 February 2017 08:32:27 UTC-6, Benjamin Smedberg  wrote:
> I thought I enumerated the harm at first, but I'll elaborate a little.
> 
> 1) Flash doesn't know about and breaks our "current and subdirectory only"
> file: origin policy.
> 
> 2) Flash is a high-risk attack surface: if you can get somebody to download
> a SWF they can probably own your system. We don't have anyone testing or
> defending this effectively.
> 
> So we believe that there is significant harm in the current situation, and
> very little upside.

I think #1 is sufficient to remove this behavior, even ignoring #2. A malicious 
flash applet open opened from file:// can read the user's profile, take all 
their saved passwords, cookies, etc and steal data, masquerade as them, and 
perform all manner of malicious activity.

-tom
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

[Benjamin Smedberg]

On Fri, Feb 10, 2017 at 12:36 AM, 段垚  wrote:

>
> 在 2017/2/10 1:28, Benjamin Smedberg 写道:
>
>> On Wed, Feb 8, 2017 at 2:26 AM, 段垚  wrote:
>>
>> Is this just preventing auto-loading (like "click to play") or completely
>>> disable Flash for non-http(s) contents?
>>>
>>> This is completely disabling this content.
>>
>>
>> Can users get back old behavior by flipping a preference?
>>>
>>> That is not the plan, no.
>>
>> Well, this plan seems too aggressive. I'd rather recommend implementing
> "click to play" for non-http(s) Flash first and deferring complete removal.
>
> IE requires user's confirmation to load local Flash for a long time.
>

We are planning on making Flash click-to-play by default for all content.
However, our implementation of click-to-play is based on remembering that
setting per site. This implementation does not work with file: URIs and the
engineering and QA effort to make it work is well beyond what we think is a
reasonable investment. Flash is a dying technology and this is one low-cost
way we can reduce attack surface and make users safer.

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

[Benjamin Smedberg]

I thought I enumerated the harm at first, but I'll elaborate a little.

1) Flash doesn't know about and breaks our "current and subdirectory only"
file: origin policy.

2) Flash is a high-risk attack surface: if you can get somebody to download
a SWF they can probably own your system. We don't have anyone testing or
defending this effectively.

So we believe that there is significant harm in the current situation, and
very little upside.

--BDS

On Thu, Feb 9, 2017 at 7:09 PM, Xidorn Quan  wrote:

> On Fri, Feb 10, 2017, at 04:29 AM, Benjamin Smedberg wrote:
> > Will this also prevent loading downloaded .swf files into Firefox? This
> > is
> > > useful for running Flash games, which tend to work best in the browser
> > > (some media players also support loading Flash files, but their hotkeys
> > > tend to conflict).
> >
> > It will prevent them from loading via File > Open, yes (and that is the
> > fundamental change we need to make). If you were to serve them via
> > localhost you could still use them (e.g. with python -m
> > SimpleHTTPServer).
>
> I kind of disagree with this. SimpleHTTPServer is simple for developers
> but not at all for normal users. I think it should be allowed to load a
> top level Flash file. What harm could it do if we allow that?
>
> - Xidorn
> ___
> 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

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

[Frederik Braun]

On 10.02.2017 01:09, Xidorn Quan wrote:
> On Fri, Feb 10, 2017, at 04:29 AM, Benjamin Smedberg wrote:
>> Will this also prevent loading downloaded .swf files into Firefox? This
>> is
>>> useful for running Flash games, which tend to work best in the browser
>>> (some media players also support loading Flash files, but their hotkeys
>>> tend to conflict).
>>
>> It will prevent them from loading via File > Open, yes (and that is the
>> fundamental change we need to make). If you were to serve them via
>> localhost you could still use them (e.g. with python -m
>> SimpleHTTPServer).
> 
> I kind of disagree with this. SimpleHTTPServer is simple for developers
> but not at all for normal users. I think it should be allowed to load a
> top level Flash file. What harm could it do if we allow that?
> 

toplevel loads includes opened via window.open and target=_blank, no?

This means HTML/JS from file:, ftp: etc. could still find a way to open
SWF from those non-HTTP/HTTPs sites.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

[段垚]

在 2017/2/10 1:28, Benjamin Smedberg 写道:

On Wed, Feb 8, 2017 at 2:26 AM, 段垚  wrote:


Is this just preventing auto-loading (like "click to play") or completely
disable Flash for non-http(s) contents?


This is completely disabling this content.



Can users get back old behavior by flipping a preference?


That is not the plan, no.

Well, this plan seems too aggressive. I'd rather recommend implementing 
"click to play" for non-http(s) Flash first and deferring complete removal.


IE requires user's confirmation to load local Flash for a long time.


We have developed a Firefox based tool to edit/view local EPub files,
which may contain Flash.

If this feature can't be opt-out , we and our customs will be in trouble.


My mind is filled with questions about how epub+Flash could ever be a good
idea, but I will avoid asking them here.
Epub+Flash is not quite a good idea, it is just because our Flash assets 
can't be replaced in a short term.



Instead, could you work around
this by serving the content and loading it from http://localhost ? That is
what we intend to recommend for developers building Flash websites and
wanting to test locally.
Local http server could trigger security alarm of OS/firewall, which 
confuses users: why a desktop app want to start a server?


Also local http server may be more insecure than direct file access, 
e.g. misconfigured or flawed server may allow

anyone on the net to access your files. So I'd rather not head to this way.


Otherwise, you will have to build your own builds with this restriction
removed.

--BDS
___
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

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

[Xidorn Quan]

On Fri, Feb 10, 2017, at 04:29 AM, Benjamin Smedberg wrote:
> Will this also prevent loading downloaded .swf files into Firefox? This
> is
> > useful for running Flash games, which tend to work best in the browser
> > (some media players also support loading Flash files, but their hotkeys
> > tend to conflict).
> 
> It will prevent them from loading via File > Open, yes (and that is the
> fundamental change we need to make). If you were to serve them via
> localhost you could still use them (e.g. with python -m
> SimpleHTTPServer).

I kind of disagree with this. SimpleHTTPServer is simple for developers
but not at all for normal users. I think it should be allowed to load a
top level Flash file. What harm could it do if we allow that?

- Xidorn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

[Benjamin Smedberg]

On Tue, Feb 7, 2017 at 5:19 PM, Chris Peterson 
wrote:

> On 2/7/2017 1:15 PM, Benjamin Smedberg wrote:
>
>> I intend to ship a change which will prevent Flash from loading from
>> file:,
>> ftp:, or any other URL scheme other than http: or https:.  The purpose of
>> this change is to increase security and limit Flash to well-tested
>> configuraitons.
>>
>
> Do you want to also block Flash content from loading file: or ftp: URLs?
>

That is not part of this bug. I will consult with Adobe and see whether
that is likely to break anything, and perhaps propose it as a separate
change.

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

[Benjamin Smedberg]

Will this also prevent loading downloaded .swf files into Firefox? This is
> useful for running Flash games, which tend to work best in the browser
> (some media players also support loading Flash files, but their hotkeys
> tend to conflict).


It will prevent them from loading via File > Open, yes (and that is the
fundamental change we need to make). If you were to serve them via
localhost you could still use them (e.g. with python -m SimpleHTTPServer).

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

[Benjamin Smedberg]

On Wed, Feb 8, 2017 at 2:26 AM, 段垚  wrote:

> Is this just preventing auto-loading (like "click to play") or completely
> disable Flash for non-http(s) contents?
>

This is completely disabling this content.


>
> Can users get back old behavior by flipping a preference?
>

That is not the plan, no.


>
> We have developed a Firefox based tool to edit/view local EPub files,
> which may contain Flash.
>
> If this feature can't be opt-out , we and our customs will be in trouble.
>

My mind is filled with questions about how epub+Flash could ever be a good
idea, but I will avoid asking them here. Instead, could you work around
this by serving the content and loading it from http://localhost ? That is
what we intend to recommend for developers building Flash websites and
wanting to test locally.

Otherwise, you will have to build your own builds with this restriction
removed.

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

[段垚]

Is this just preventing auto-loading (like "click to play") or 
completely disable Flash for non-http(s) contents?


Can users get back old behavior by flipping a preference?

We have developed a Firefox based tool to edit/view local EPub files, 
which may contain Flash.


If this feature can't be opt-out , we and our customs will be in trouble.

I understand and appreciate the trend of web without plugins, but we and 
our customs just have too many Flash assets.


Thanks.

Duan, Yao

在 2017/2/8 5:15, Benjamin Smedberg 写道:

I intend to ship a change which will prevent Flash from loading from file:,
ftp:, or any other URL scheme other than http: or https:.  The purpose of
this change is to increase security and limit Flash to well-tested
configuraitons.


- file: same-origin security mechanism is different, and so there have
been problems in the past with Flash content bypassing normal controls.
- Flash is normally not tested with ftp: or other protocols, and we've
had security issues in the past as a result of interactions between Flash
and these sites.

I am not yet sure whether we will be able to prevent Flash from loading in
data: contexts or not. I'd like to, but it may not be possible without
breaking existing content.
This work is being tracked in
https://bugzilla.mozilla.org/show_bug.cgi?id=1335475

--BDS
___
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

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

[Emanuel Hoogeveen]

On Tuesday, February 7, 2017 at 10:16:27 PM UTC+1, Benjamin Smedberg wrote:
> I intend to ship a change which will prevent Flash from loading from file:,
> ftp:, or any other URL scheme other than http: or https:.  The purpose of
> this change is to increase security and limit Flash to well-tested
> configuraitons.
> 
> 
>- file: same-origin security mechanism is different, and so there have
>been problems in the past with Flash content bypassing normal controls.
>- Flash is normally not tested with ftp: or other protocols, and we've
>had security issues in the past as a result of interactions between Flash
>and these sites.
> 
> I am not yet sure whether we will be able to prevent Flash from loading in
> data: contexts or not. I'd like to, but it may not be possible without
> breaking existing content.
> This work is being tracked in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1335475
> 
> --BDS

Will this also prevent loading downloaded .swf files into Firefox? This is 
useful for running Flash games, which tend to work best in the browser (some 
media players also support loading Flash files, but their hotkeys tend to 
conflict). Obviously if we get to the point where we stop supporting Flash 
altogether this use case will break anyway, so mostly asking for clarification.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

[Chris Peterson]

On 2/7/2017 1:15 PM, Benjamin Smedberg wrote:

I intend to ship a change which will prevent Flash from loading from file:,
ftp:, or any other URL scheme other than http: or https:.  The purpose of
this change is to increase security and limit Flash to well-tested
configuraitons.


Do you want to also block Flash content from loading file: or ftp: URLs?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform