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

Status: VERIFIED FIXED

(Toolkit :: Downloads API, enhancement)

Description

[:Paolo Amadini]

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.

Comment 1

[:Paolo Amadini]

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.

Comment 2

[:Paolo Amadini]

Attachment: Bug 1472635 - Prevent suppressing executable warnings using the "don't ask me this again" checkbox.

This also cleans up duplicate unused strings in the "browser" folder.

Review commit: https://reviewboard.mozilla.org/r/254190/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/254190/

Comment 3

[:Paolo Amadini]

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

Comment 4

[Mark Straver]

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.

Comment 5

[:Paolo Amadini]

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

[Mark Straver]

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

[:Gijs (he/him)]

(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?

Comment 8

[:Gijs (he/him)]

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).

Comment 9

[Mark Straver]

> 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.

Comment 10

[:Paolo Amadini]

(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 11

[:Paolo Amadini]

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

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/254190/diff/1-2/

Comment 12

[:Gijs (he/him)]

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

Comment 13

[:Gijs (he/him)]

(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

[Mark Straver]

> 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

[Pulsebot]

Pushed by [e-mail]:
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

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/250255a7e318

Comment 17

[Ciprian Georgiu, Desktop QA]

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.

Comment 18

[:Paolo Amadini]

Thank you Ciprian for testing this!