The default bug view has changed. See this FAQ.

Disable loading remote jars by default

NEW
Unassigned

Status

()

Core
Networking: JAR
3 months ago
21 days ago

People

(Reporter: tjr, Unassigned)

Tracking

({addon-compat, dev-doc-needed, site-compat})

Trunk
addon-compat, dev-doc-needed, site-compat
Points:
---

Firefox Tracking Flags

(firefox53 affected)

Details

(Whiteboard: [necko-would-take])

(Reporter)

Description

3 months ago
In #1255934 we added Telemetry for remote jars, as we learned IBM iNotes used it. Looking at the Telemetry we can see:

- It is overwhelmingly used only on Windows
- It is used in ~ .01% of sessions 

(As the earlier bug mentions, we can divide the number of sessions this probe is in by the number of sessions a different flag probe is in as long as that divisor probe is reliably reported every session.)

Because it's used so infrequently, it'd be great if we could completely disallow remote jar file loads to reduce the attack service available to the web.  

We have a preference for blocking this already, network.jar.block-remote-files.  It'd be great to switch it to 'on' by default and the minority who need it turn off the blocking.
Component: Networking → Networking: JAR
Whiteboard: [necko-would-take]
See also bug 1215235 where we tried to do this before (spawning the telemetry in bug 1255934 mentioned above), especially bug 1215235 comment 13 which mentions IBM has fixed more recent versions of Notes. We ought to be able to do this post-52 (to give Notes-using enterprises an easy path on the 52 ESR).

Updating the summary to reflect the proposal (disable, not "kill").

The patch in bug 1215235 will be a useful start in fixing tests broken by this change, but doesn't appear to have a test to verify that remote jars are in fact blocked by default.
See Also: → bug 1215235
Summary: Kill Remote Jar Loading Feature → Disable loading remote jars by default

Updated

2 months ago
Keywords: addon-compat, dev-doc-needed, site-compat
I think the interesting data here is how much this has dropped in the last few releases.  We probably can't really test this manually and I'm not sure who controls the upgrade cadence of all IBM Lotus iNotes installations out there (whether it's IBM or each individual site admin), so we should proceed really carefully here.
You need to log in before you can comment on or make changes to this bug.