Temporarily allowing flash player should allow it for that session instead of just 1h
Categories
(Core Graveyard :: Plug-ins, defect, P1)
Tracking
(firefox-esr68 unaffected, firefox69 wontfix, firefox70 verified, firefox71 verified)
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox69 | --- | wontfix |
firefox70 | --- | verified |
firefox71 | --- | verified |
People
(Reporter: FredMcD, Assigned: Gijs)
Details
Attachments
(1 file)
47 bytes,
text/x-phabricator-request
|
lizzard
:
approval-mozilla-beta+
|
Details | Review |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:54.0) Gecko/20100101 Firefox/54.0
Steps to reproduce:
Many users are complaining about the removal of 'Always Allow' for
the flash player. This is from one such complaint;
https://support.mozilla.org/en-US/questions/1268957
We have medical data coming in 24/7. Our alarm runs off flash. Since the update there isn't a choice to "allow and remember", which is causing us to have to remember to refresh the page constantly. A big problem for the night-staff, problem for the day-staff also as we keep forgeting and data is not alarming. PLEASE HELP!!
Actual results:
While flash may be on its way out, there are still websites that use flash.
Thus, removing 'Always Allow' causes issues for the users.
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 2•5 years ago
|
||
https://support.mozilla.org/en-US/questions/1268957
We have medical data coming in 24/7. Our alarm runs off flash. Since the update there isn't a choice to "allow and remember", which is causing us to have to remember to refresh the page constantly. A big problem for the night-staff, problem for the day-staff also as we keep forgeting and data is not alarming. PLEASE HELP!!
They could use enterprise policy to allow flash on the domain on which they need it - see https://support.mozilla.org/af/kb/manage-flash-firefox-enterprise . (This also works on regular release, not just ESR.)
Chris: looks like temporarily allowing flash only allows it (on that site) for 1h - should we increase the interval?
Comment 3•5 years ago
|
||
(In reply to :Gijs (he/him) from comment #2)
They could use enterprise policy to allow flash on the domain on which they need it - see https://support.mozilla.org/af/kb/manage-flash-firefox-enterprise . (This also works on regular release, not just ESR.)
Yes. An enterprise policy file to whitelist Flash for specific sites is the right solution. That is the approach we recommended Adobe's Flash team use for their automated tests.
Chris: looks like temporarily allowing flash only allows it (on that site) for 1h - should we increase the interval?
Definitely. I thought that allowing Flash for a particular site would continue to allow it for the remainder of that browser session.
Gijs, what interval do you recommend? Perhaps we can just increase the timeout interval to infinity (for the current browser session). If we increase the interval, we can also uplift the change to Firefox 68 ESR.
Comment 4•5 years ago
•
|
||
(In reply to Chris Peterson [:cpeterson] from comment #3)
(In reply to :Gijs (he/him) from comment #2)
They could use enterprise policy to allow flash on the domain on which they need it - see https://support.mozilla.org/af/kb/manage-flash-firefox-enterprise . (This also works on regular release, not just ESR.)
Yes. An enterprise policy file to whitelist Flash for specific sites is the right solution. That is the approach we recommended Adobe's Flash team use for their automated tests.
For future reference, here are instructions for setting enterprise policy using a simple policies.json
text file in a new sub-directory called "distribution" in your Firefox directory:
https://support.mozilla.org/en-US/kb/customizing-firefox-using-policiesjson
You can also use this "Enterprise Policy Generator" extension to create the policies.json
text file using an easy GUI:
https://addons.mozilla.org/firefox/addon/enterprise-policy-generator/
Comment 5•5 years ago
•
|
||
For example, I created the following policies.json
text file to allow Flash on my favorite Flash site (zombo.com):
{
"policies": {
"FlashPlugin": {
"Allow": [
"http://www.zombo.com/"
]
}
}
}
I saved that file to my Firefox directory: C:\Program Files\Mozilla Firefox\distribution\policies.json
. I launched Firefox, opened zombo.com, and confirmed that Flash ran automatically. 😀
Note that to create the new "distribution" sub-directory and policies.json
file might require Administrator permission because the Mozilla Firefox directory is normally protected to prevent random third-party programs from messing with Firefox's files. You can create the new sub-directory and copy the policies.json
file using Windows Explorer and it should prompt you for Administrator permission when needed.
Assignee | ||
Comment 6•5 years ago
|
||
(In reply to Chris Peterson [:cpeterson] from comment #3)
(In reply to :Gijs (he/him) from comment #2)
Chris: looks like temporarily allowing flash only allows it (on that site) for 1h - should we increase the interval?
Definitely. I thought that allowing Flash for a particular site would continue to allow it for the remainder of that browser session.
Gijs, what interval do you recommend? Perhaps we can just increase the timeout interval to infinity (for the current browser session). If we increase the interval, we can also uplift the change to Firefox 68 ESR.
I'm not sure what the options are. Johann, you've been working more closely on/with permissions, thoughts?
I also wonder why this was originally set to 1h... looks like that happened in bug 880735 and was never changed afterwards.
Comment 7•5 years ago
|
||
(In reply to :Gijs (he/him) from comment #6)
(In reply to Chris Peterson [:cpeterson] from comment #3)
(In reply to :Gijs (he/him) from comment #2)
Chris: looks like temporarily allowing flash only allows it (on that site) for 1h - should we increase the interval?
Definitely. I thought that allowing Flash for a particular site would continue to allow it for the remainder of that browser session.
Gijs, what interval do you recommend? Perhaps we can just increase the timeout interval to infinity (for the current browser session). If we increase the interval, we can also uplift the change to Firefox 68 ESR.
I'm not sure what the options are. Johann, you've been working more closely on/with permissions, thoughts?
I also wonder why this was originally set to 1h... looks like that happened in bug 880735 and was never changed afterwards.
I think "rest of this session" is the most logical setting. It is site-specific, so that behavior wouldn't create any unexpected new exposure. (In fact, I also assumed that's how it worked now.)
Assignee | ||
Comment 8•5 years ago
|
||
(In reply to jscher2000 from comment #7)
I think "rest of this session" is the most logical setting. It is site-specific, so that behavior wouldn't create any unexpected new exposure.
Intuitively yes, until you realize that especially on mac, sessions can last for weeks/months, as people don't turn them off, just sleep/hibernate.
I suspect 12 or 16h would be a good compromise.
(In fact, I also assumed that's how it worked now.)
I mean, so did I, despite refactoring the code...
Comment 9•5 years ago
|
||
I also wonder why this was originally set to 1h... looks like that happened in bug 880735 and was never changed afterwards.
Right, this is the main thing I'm not clear on. What do we want to achieve by limiting the time (the exact duration is probably not important to this question)? Generally I think it's a good idea to disallow "permanent" to avoid collecting the permanent permissions in the user's profile and to be able to reduce flash UI. However, this could be achieved with "session" as well. So I have no idea what the 1h limit is supposed to do.
I'm not sure what the options are. Johann, you've been working more closely on/with permissions, thoughts?
We can do session length or any particular expiry time we like. Though again, I would not recommend just bumping the expiry without understanding why we're doing it. Through some hackery we could also do temporary allows that are only valid for the current tab, but that's mostly used for blocking in the front-end right now and would need to be adapted for this use case, so it's not a trivial "one-line" solution to implement.
Another thing I don't understand: Isn't the Flash permission only checked when loading the plugin? Why would Flash stop working when the permission expires? (especially since in permission manager there's no internal "timer" that would expire the permission or set off an event, it just expires if the timestamp is too high the next time the permission is checked) Does the affected page periodically reload or something?
Assignee | ||
Comment 10•5 years ago
|
||
(In reply to Johann Hofmann [:johannh] from comment #9)
I also wonder why this was originally set to 1h... looks like that happened in bug 880735 and was never changed afterwards.
Right, this is the main thing I'm not clear on. What do we want to achieve by limiting the time (the exact duration is probably not important to this question)? Generally I think it's a good idea to disallow "permanent" to avoid collecting the permanent permissions in the user's profile and to be able to reduce flash UI. However, this could be achieved with "session" as well. So I have no idea what the 1h limit is supposed to do.
Looks like the design docs are lost to time here, and Benjamin has left, so we can only guess. I think the point of all this is to limit exposure... If the idea is that I don't generally need flash but I might need it for one task (like a gov't or bank website or whatever) then 1h would usually be enough for that one task, and that site can't then track me using flash for the rest of the session (once the document containing the plugin is closed, anyway) if they're iframed into other things, etc.
The problem is that at this point, there is now no "always" for people who routinely use flash, and so our current click-to-play implementation doesn't fit well for that group of users.
I'm not sure what the options are. Johann, you've been working more closely on/with permissions, thoughts?
We can do session length or any particular expiry time we like. Though again, I would not recommend just bumping the expiry without understanding why we're doing it. Through some hackery we could also do temporary allows that are only valid for the current tab, but that's mostly used for blocking in the front-end right now and would need to be adapted for this use case, so it's not a trivial "one-line" solution to implement.
OK, so I think the options are time-limited or session-limited. Both have downsides (see comment #8). Doing additional hackery doesn't sound attractive in terms of cost/benefit trade-off, esp. with having to fix up tests etc. From a quick look at Chrome's settings, it looks like they "just" keep things until quitting, though I haven't verified what happens with super long sessions on mac. I'm probably over-thinking it...
Chris, can you make a call?
Another thing I don't understand: Isn't the Flash permission only checked when loading the plugin?
I believe so. I don't think there's any continuous checking inside plugin code that will unload the plugin once the pref expires.
Why would Flash stop working when the permission expires? (especially since in permission manager there's no internal "timer" that would expire the permission or set off an event, it just expires if the timestamp is too high the next time the permission is checked) Does the affected page periodically reload or something?
I expect so.
Comment 11•5 years ago
|
||
Instead of making people (especially the average user) jump through hoops : just create a preference on the "about:config" page to force-enable Flash, which they can set to "true" or leave it at the default value of "false".
Then, add it in the release notes of the next Firefox update, to let people know.
Remove the preference at the end of 2020.
Comment 12•5 years ago
|
||
(In reply to :Gijs (he/him) from comment #10)
Looks like the design docs are lost to time here, and Benjamin has left, so we can only guess. I think the point of all this is to limit exposure... If the idea is that I don't generally need flash but I might need it for one task (like a gov't or bank website or whatever) then 1h would usually be enough for that one task, and that site can't then track me using flash for the rest of the session (once the document containing the plugin is closed, anyway) if they're iframed into other things, etc.
I think the bsmedberg's original concern was that allowing Flash on a news site to watch one Flash video would leave the user forever vulnerable to drive-by malware attacks from Flash ads. Even when we supported "Allow and Remember my decision", we would expire the decision after 90 days or something.
OK, so I think the options are time-limited or session-limited. Both have downsides (see comment #8). Doing additional hackery doesn't sound attractive in terms of cost/benefit trade-off, esp. with having to fix up tests etc. From a quick look at Chrome's settings, it looks like they "just" keep things until quitting, though I haven't verified what happens with super long sessions on mac. I'm probably over-thinking it...
Chris, can you make a call?
I think we should remember the allow decision for the current session. Expiring the decision while the browser, or even the page, is still open would surprise the user.
Whether we want to add an about:config pref to restore "Always Allow" is different decision.
Assignee | ||
Updated•5 years ago
|
Comment 13•5 years ago
|
||
firefox70=fix-optional because we should consider uplifting this fix to Firefox 70 Beta (release date: 2019-10-23).
Assignee | ||
Comment 14•5 years ago
|
||
Comment 15•5 years ago
|
||
The priority flag is not set for this bug.
:jimm, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 16•5 years ago
|
||
This bug is a P1 because it is nuisance for users who rely on Flash sites. We'd like to uplift the fix to Firefox 70 Beta, if possible, though there are only three weeks remaining in the current Beta cycle.
Comment 17•5 years ago
|
||
Pushed by gijskruitbosch@gmail.com: https://hg.mozilla.org/integration/autoland/rev/41f38d4062fc use unlimited session length permission for 'Allow Now' for plugins, r=mconley,handyman
Comment 18•5 years ago
|
||
bugherder |
Assignee | ||
Comment 19•5 years ago
|
||
Comment on attachment 9094895 [details]
Bug 1581664 - use unlimited session length permission for 'Allow Now' for plugins, r?jmathies!,mconley!
Beta/Release Uplift Approval Request
- User impact if declined: Flash permissions have to be re-requested after 1h
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: 1. go to https://helpx.adobe.com/uk/flash-player.html
- click "Check now", then allow flash on the page
- wait for more than 1h
- refresh the page
ER:
flash is still allowed on the page
Results without patch:
flash is no longer allowed
Note: on builds without this patch, you can modify plugin.sessionPermissionNow.intervalInMinutes
in about:config to have a different number of minutes (e.g. 1), which will make it easier to test in that you won't need to wait a whole hour. You may need to restart to get the pref to take effect. On builds with the patch, you could still create this preference but it will have no effect (which I guess you could test...).
- List of other uplifts needed: n/a
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Fairly straightforward change in how we deal with flash permissions
- String changes made/needed: Nope
Assignee | ||
Updated•5 years ago
|
Updated•5 years ago
|
Comment 20•5 years ago
|
||
Comment on attachment 9094895 [details]
Bug 1581664 - use unlimited session length permission for 'Allow Now' for plugins, r?jmathies!,mconley!
Seems reasonable, let's uplift for beta 13.
Comment 21•5 years ago
|
||
bugherder uplift |
Reporter | ||
Comment 22•5 years ago
|
||
Your pardon, if you please.
User; Sin Shadow Fox, wanted to know your plans.
https://support.mozilla.org/en-US/questions/1268957
We have medical data coming in 24/7. Our alarm runs off flash. Since the update there isn't a choice to "allow and remember",
which is causing us to have to remember to refresh the page constantly. A big problem for the night-staff, problem for the day-staff
also as we keep forgeting and data is not alarming. PLEASE HELP!!
Comment 23•5 years ago
|
||
Verified as fixed on the latest Nightly 71.0a1 on Windows 10 x64, Ubuntu 18.04 x64 and Mac OS X 10.14. I can confirm that flash player, is now allowed per session and not just for one hour.
Comment 24•5 years ago
|
||
Verified as fixed also on Firefox 70 beta 13 on Windows 10 x64, Ubuntu 18.04 and Mac Os X 10.14.
Assignee | ||
Comment 26•4 years ago
|
||
(In reply to Sin Shadow Fox from comment #25)
How do you allow flash per session?
Clicking "Allow" on the permission dropdown will allow flash until the browser is shut down in Firefox 70 and later.
Comment 28•4 years ago
|
||
(In reply to Sin Shadow Fox from comment #27)
Where is the permission dropdown?
It's usually near the top of my screen, but sometimes it doesn't show on the two Facebook games I play unless I click in the blank black box where the content is supposed to be. Then the permission box shows up at the top of the screen.
Comment 29•4 years ago
|
||
(In reply to Simona Badau from comment #24)
Verified as fixed also on Firefox 70 beta 13 on Windows 10 x64, Ubuntu 18.04 and Mac Os X 10.14.
Has the "fix" made it to a regular update yet? If so, it's not working. I have version 70.0.1 in my "About Firefox" box and it says "Firefox is up to date." However, when I am playing Bejeweled Blitz on Facebook and go out of it and back in, or if I need to refresh the page for some reason, I have to "allow" Flash again even though I don't close the browser. It's not a big deal for me, but I was wondering why this is still happening. Thank you.
Assignee | ||
Comment 30•4 years ago
•
|
||
(In reply to ajpeavler from comment #29)
(In reply to Simona Badau from comment #24)
Verified as fixed also on Firefox 70 beta 13 on Windows 10 x64, Ubuntu 18.04 and Mac Os X 10.14.
Has the "fix" made it to a regular update yet?
Yes.
when I am playing Bejeweled Blitz on Facebook and go out of it and back in, or if I need to refresh the page for some reason, I have to "allow" Flash again even though I don't close the browser. It's not a big deal for me, but I was wondering why this is still happening. Thank you.
Please file a new bug with more specific details (like a link to the page you see this on, what OS you're using, what version of flash player, etc.)
Comment 31•4 years ago
|
||
Ok, thank you. I have just filed new bug 1595647. I hope I provided you with all of the necessary info. It's not a big deal to me because it's only Facebook games, but if it's still not working as expected for me it could be an actual problem for someone else.
Comment 32•4 years ago
|
||
I dont see it. Is it only on facebook? I dont have a facebook account.
Comment 33•4 years ago
|
||
(In reply to Sin Shadow Fox from comment #32)
I dont see it. Is it only on facebook? I dont have a facebook account.
I normally only need Flash for those two Facebook games, so I don't know if it's a problem on other sites or not. You do need a Facebook account to access those games. It may be just a problem limited to Facebook, as I just went back to Adobe's page (where I went previously to verify whether I was missing a Flash update) and did not need to re-allow Flash on the Adobe page even though I had closed the old tab and was re-accessing the page in a brand new tab.
Comment 34•4 years ago
|
||
(In reply to ajpeavler from comment #33)
(In reply to Sin Shadow Fox from comment #32)
I dont see it. Is it only on facebook? I dont have a facebook account.
I normally only need Flash for those two Facebook games, so I don't know if it's a problem on other sites or not. You do need a Facebook account to access those games. It may be just a problem limited to Facebook, as I just went back to Adobe's page (where I went previously to verify whether I was missing a Flash update) and did not need to re-allow Flash on the Adobe page even though I had closed the old tab and was re-accessing the page in a brand new tab.
I just want to be able to click the "log in" button on https://www.pandora.com/account/sign-in
Comment hidden (advocacy) |
Assignee | ||
Comment 36•4 years ago
|
||
(The issues the user in comment #35 has are being followed up on at support.mozilla.org . )
Comment 37•2 years ago
|
||
Ok, how do I clear the request for more info from my inbox? This is an old thread. I added the info to the other bug way back when you asked me to do so. I've tried checking the box below to clear the request, but it won't go away. Does an admin need to clear it? It's annoying to log in and see I have what appears to be a new request when it's 2 years old. Thank you.
Comment 38•2 years ago
|
||
(In reply to ajpeavler from comment #37)
Ok, how do I clear the request for more info from my inbox? This is an old thread. I added the info to the other bug way back when you asked me to do so. I've tried checking the box below to clear the request, but it won't go away. Does an admin need to clear it? It's annoying to log in and see I have what appears to be a new request when it's 2 years old. Thank you.
Hi ajpeavler, sorry about that. I'll clear the info box below.
Comment 39•2 years ago
|
||
(In reply to Chris Peterson [:cpeterson] from comment #38)
(In reply to ajpeavler from comment #37)
Ok, how do I clear the request for more info from my inbox? This is an old thread. I added the info to the other bug way back when you asked me to do so. I've tried checking the box below to clear the request, but it won't go away. Does an admin need to clear it? It's annoying to log in and see I have what appears to be a new request when it's 2 years old. Thank you.
Hi ajpeavler, sorry about that. I'll clear the info box below.
Thank you! The notification is finally gone! :)
Updated•2 years ago
|
Description
•