1648786 - JNLP should not be considered an executable extension

Status: RESOLVED FIXED

(Firefox :: File Handling, defect)

Description

[Pieter Breugelmans]

+++ This bug was initially created as a clone of Bug #1576616 +++

Name: Firefox
Version: 78.0
Build ID: 20200625152958
Update Channel: beta
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0

Testing performed using the latest Firefox 78.0 beta has shown that Java Web Start (.jnlp) files are still falsely being considered as executables. Therefore a scary warning window is shown to the end user each time a JNLP file is downloaded, with the intend to execute it using the pre-installed Java Web Start launcher. To put it mildly, the user experience is just terrible.

For completeness, the warning message titled: Open Executable File?

"example.jnlp" is an executable file. Executable files may contain viruses or other malicious code that could harm your computer. Use caution when opening this file. Are you sure you want to launch "example.jnlp"?

We had reported this very same issue last year, ref. the following bugs:

• Bug 1576616 (RESOLVED FIXED) - Should not treat JNLP files as Executables (revert bug 1392955) on ESR-68
  • The bug I had created last year for the same issue
  • Linked to base bug 1392955 by Mozilla
  • Reused to revert the security fix as of Firefox ESR 68.2, restoring the 'user friendly' behavior for EBS users without extra warning messages.
• Bug 1392955 (VERIFIED FIXED) JNLP should be treated as executable
  • Base bug that fixed the 'security issue'
  • The code change was included with Firefox 67.0 and the behavior has not changed till this date, incl. the latest Firefox 78.0 beta. Only Firefox ESR 68.2+ does NOT included the code change.
• Bug 1576762 - Improve usability for JNLP and other executable
  • Created by Mozilla, intended to work out a more comprehensive approach, such as e.g. handling Windows executables ".exe" differently from others like ".jnlp"
  • Status NEW and Unassigned

Our concerns are two folded:

1. Firefox 78.0 is expected to be the baseline for Firefox ESR 78.0 due next week. Given that the code change was reverted only for Firefox ESR 68.2+ it is our expectation that Firefox ESR 78.0 will re-introduce the warning message. We cannot confirm this today but if this is the case, then we yet again ask for the code change to be reverted for Firefox ESR 78.x.
2. In bug 1576616 and bug 1392955 myself (Oracle) and Donald Smith (Java SE Product management at Oracle) had given several arguments that explain why JNLP files are NOT executables. We'd highly appreciate some progress on bug 1576762 to get this issue sorted out in both Firefox Rapid Release and ESR. We can provide any further clarifications if needed via that bug concerning the handling of JNLP once Firefox passes it over to our Java Web Start launcher.

Comment 1

[Mike Kaply [:mkaply]]

When we originally made this change, there was an expectation that JNLP would be removed in Java 11. Did that not happen?

FYI, Firefox ESR 68 will continue to be supported with overlap of ESR 78 for a few releases. See:

https://wiki.mozilla.org/Release_Management/Calendar

We don't expect Firefox 68 ESR users will move immediately to Firefox 78 ESR (and we don't force them to until September).

We can investigate making the same change in the next ESR update (78.1)

Comment 2

[johannes.michler]

Even if it is removed in Java 11 then Java 8 will be in support from Oracle until 2025 (at least). A lot of Business Applications are still built upon those concept with JNLP being at least a medium if not long term replacement for Java Applets. I suggest to consider JNLP as "not bad" for ESR 78(.1) at least,

Comment 3

[Donald Smith]

To expand on this a bit, we have updated our Java Client Roadmap, which you can find here: https://blogs.oracle.com/java-platform-group/java-client-roadmap-updates

Java SE 8 has had support extended from March 2025 to at least 2030 and for desktop consumer use it has been extended from December 2020 to indefinitely (more details in link above). Java SE 8 continues to be the recommended version of Java for desktop use. This includes all related security updates we provide on a quarterly basis, with auto-updates, etc.

Comment 4

[Donald Smith]

I would also like to add a couple other points in helpful:

• We have extended Java 8 for free desktop use indefinitely given there are many applications around the world still relying on it extensively including from many government-citizen operations, banking systems and there's still measurable audiences using for online games, etc. That is in addition to many commercial users relying on various products and services based on Forms -- where Firefox gives the best overall experience.
• I know that Java via browser had many security related concerns through 2013-2014 time frame, but around that time frame and by 2015 we had taken extreme measures of ensuring apps were always signed, always requiring click-approval to run, and many other measures. We'd be happy to run through this if helpful (we did this in the 2015 time frame with security folks at Mozilla but I believe most people from that era have moved on - happy to reconnect if needed).
• I know that Java on consumer desktops had a reputation for trying to install browser toolbars and addons -- however that was terminated many years ago and should no longer be a concern.

Comment 5

[Pieter Breugelmans]

Thanks for your comments :mkaply. Yes, we are well aware of the Firefox ESR release schedule and its 2 months overlap from one major release to a new one, offering sufficient time to report issues before Firefox 68.x ESR gets automatically updated to Firefox 78.2 ESR late August.

May I propose the following actions:

1. Revert the code change for Firefox ESR 78.1 and if possible Firefox 79 (Rapid Release) using this bug. Note that we have no concerns over the fact that the issue will temporarily exist in Firefox ESR 78.0. After all, end users can and probably will be using Firefox ESR 68.10 anyway. Let us this bug to track the necessary actions to achieve that objective.
2. Continue any further discussions about JNLP / Java 8 in bug 1576762 - Improve usability for JNLP and other executable so via that way, a final solution can be worked out for both Firefox ESR and Rapid Release. After all, that was the intended usage of that bug in the first place.

Comment 6

[Mike Kaply [:mkaply]]

Attachment: Bug 1648786 - Mark JNLP as not an executable for esr78. r?Gijs

Comment 7

[Mike Kaply [:mkaply]]

Comment on attachment 9160467 [details]
Bug 1648786 - Mark JNLP as not an executable for esr78. r?Gijs

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: This is an ESR specific patch so JNLP will continue to launch on ESR only.
• User impact if declined: JNLP files require extra work to launch
• Fix Landed on Version: 68
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This is the same patch we did for 68.
• String or UUID changes made by this patch:

Comment 8

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9160467 [details]
Bug 1648786 - Mark JNLP as not an executable for esr78. r?Gijs

Restores parity with ESR68. Approved for 78.1esr.

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr78/rev/3c95bdf58d7d