Prevent suppressing security warnings using browser.download.manager.alertOnEXEOpen

VERIFIED FIXED in Firefox 63

Status

()

enhancement
VERIFIED FIXED
11 months ago
7 months ago

People

(Reporter: Paolo, Assigned: Paolo)

Tracking

(Blocks 1 bug)

Trunk
mozilla63
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox63 verified)

Details

Attachments

(1 attachment)

Assignee

Description

11 months ago
The "application is an executable file" interstitial dialog, which is shown when launching dangerous file types except for "exe", can be disabled globally and permanently using a checkbox. I think this ability should be removed, because it applies to every file type, not just the individual file being opened, and also applies to actions triggered by browser extensions. This is unclear from the current user interface, and there is no way to undo this action save from editing "about:config".

Thinking this over, we don't have an actual need for this setting, conversely we rely on users _never_ selecting the checkbox in order to protect from accidental dangerous file execution. If there is a use case that we missed, we can consider supporting it through the Policy Engine in a separate bug, but this would be specific to configured file extensions, and not a blanket waiver.
Assignee

Comment 1

11 months ago
Bug 1471981 is on file to add regression tests, but it's not trivial since we mock this function in other tests. Given that the function is self-contained and easily tested manually, I suggest to go for manual testing for now.
Blocks: 1471981
Flags: qe-verify+
Comment hidden (mozreview-request)
Assignee

Comment 3

11 months ago
If you think this needs UX review, let me know who you think we should ask.

Comment 4

11 months ago
What about us power users who just don't want to be bugged with a confirmation dialog box every single time an executable-class download is launched from the browser? I can see the benefit for preventing this from extensions, but from deliberate user interaction? Not really.
Assignee

Comment 5

11 months ago
To be clear, this doesn't apply to "exe" on Windows, where the operating system provides its own confirmation dialog. As far as I can tell, running executables that are not "exe" from the browser is rare enough that the assumption that a generality of users will be bugged by this is probably false.

If do find a use case later, we can implement a mechanism in the Policy Engine, but we shouldn't spend time upfront on it.

Also, let's not forget that this dialog provides defense in depth from spoofing attacks where one could be tricked into believing that a safe document has been downloaded, when this is actually an executable file. This may be accidental or a spoofing exploit in the browser - we've had some of these filed over the history of Firefox, so they are a possibility even for users who can notice minute detail.

Comment 6

11 months ago
I'm very much aware of the different treatment of .exe vs other executables by the OS.
I fully understand the reason for this bug filed, and not making it obvious in the UI to disable this warning has my full support -- there are however situations where you really DO want to disable this warning with blanket permission, so at least leave the pref in place?

Comment 7

11 months ago
(In reply to Mark Straver from comment #6)
> there are however
> situations where you really DO want to disable this warning with blanket
> permission, so at least leave the pref in place?

Situations like what? What's the concrete usecase where you want this disabled?
Flags: needinfo?(mark)

Comment 8

11 months ago
mozreview-review
Comment on attachment 8989123 [details]
Bug 1472635 - Prevent suppressing executable warnings using the "don't ask me this again" checkbox.

https://reviewboard.mozilla.org/r/254190/#review261020

I'm in favour of removing the checkbox.

I could be convinced either way about the hidden pref, maybe.

However... can we do one better and enforce showing the dialog if the download name is confusing (ie has a second file extension or whatever), or if it's being launched by an add-on, but allow it to be turned off for cases where it's being launched from our own download UI where it's (hopefully) obvious that it's executable?

The other option in that department would be asking UX/design folks to come up with a way to flag up executable files explicitly in the UI (big red warning triangle type icon or something).
Attachment #8989123 - Flags: review?(gijskruitbosch+bugs)

Comment 9

11 months ago
> Situations like what? What's the concrete usecase where you want this disabled?

Intranet/trusted use: delivery and running of script/shell/batch/macro/java files and other executables that are delivered from a trusted source.

> ... enforce showing the dialog if the download name is confusing (ie has a second file extension or whatever), or if it's being launched by an add-on, but allow it to be turned off for cases where it's being launched from our own download UI

This would be the best solution, IMHO. If it's from a user interaction, it really should be allowed to be turned off.
Flags: needinfo?(mark)
Assignee

Comment 10

11 months ago
(In reply to Mark Straver from comment #9)
> Intranet/trusted use: delivery and running of script/shell/batch/macro/java
> files and other executables that are delivered from a trusted source.

This use case would be best supported by the Policy Engine, with specifics on the file types you want to deliver without warning, and a local site whitelist. Anyways, I chatted with Gijs and I'm going to keep an "about:config" preference matching the current behavior, at his request. Anything more will have to wait as I've taken this bug on the side of other front-end work I'm doing.
Comment hidden (mozreview-request)

Comment 12

11 months ago
mozreview-review
Comment on attachment 8989123 [details]
Bug 1472635 - Prevent suppressing executable warnings using the "don't ask me this again" checkbox.

https://reviewboard.mozilla.org/r/254190/#review261142
Attachment #8989123 - Flags: review?(gijskruitbosch+bugs) → review+

Comment 13

11 months ago
(In reply to Mark Straver from comment #9)
> > Situations like what? What's the concrete usecase where you want this disabled?
> 
> Intranet/trusted use: delivery and running of script/shell/batch/macro/java
> files and other executables that are delivered from a trusted source.

A browser seems like an extraordinarily over-engineered thing to do this. curl/wget and so on were designed for automating this type of thing.

> > ... enforce showing the dialog if the download name is confusing (ie has a second file extension or whatever), or if it's being launched by an add-on, but allow it to be turned off for cases where it's being launched from our own download UI
> 
> This would be the best solution, IMHO. If it's from a user interaction, it
> really should be allowed to be turned off.

Not really; if it was from *informed* user interaction. Which is a very hard thing to define, and not something the API implementation itself can check for when the UI is potentially implemented by add-ons (which have access to this API, AIUI).

Comment 14

11 months ago
> A browser seems like an extraordinarily over-engineered thing to do this.
> curl/wget and so on were designed for automating this type of thing.

Absolutely! But this is what you get in 2018 where everything has to be done through web/http.

Unfortunately the concept of using *nix command-line utilities to distribute and open e.g. a windows help file for workstation users won't fly very well in corporate environments. There are plenty of intranet use cases that can be detailed to make this availability of a waiver a valid request.

> Not really; if it was from *informed* user interaction. Which is a very hard thing to define,
> and not something the API implementation itself can check for

Exactly, so give users/administrators the choice to determine their own level of hand-holding required, considering the difficulty to automate it. It would be the best solution from a usage point of view, but it may be hard/impossible to implement properly.
As an aside: endpoint security is generally managed by other software than the browser, so don't let it get in the way.

Comment 15

11 months ago
Pushed by paolo.mozmail@amadzone.org:
https://hg.mozilla.org/integration/mozilla-inbound/rev/250255a7e318
Prevent suppressing executable warnings using the "don't ask me this again" checkbox. r=Gijs

Comment 16

11 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/250255a7e318
Status: NEW → RESOLVED
Last Resolved: 11 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
Assignee: nobody → paolo.mozmail
I have reproduced this bug using a .bat and .com file extension, on an affected Nightly (2018-07-02) build under Windows 10 x64.

I can confirm that on Beta 63.0b13 (20181008155858) the warning dialog is properly displayed but without "Don't ask me this again" checkbox, when opening the above file extension mentioned.

Thanks Paolo, for the extra info provided on irc. Marking this as verified fixed.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
Assignee

Comment 18

7 months ago
Thank you Ciprian for testing this!
You need to log in before you can comment on or make changes to this bug.