Intent to unship: remote jar: protocol pref

[Gijs Kruitbosch]

Hello,

jar: is an internal protocol that enables loading resources from inside
a jar/zip file . Firefox is the only browser I'm aware of that supports it.

In Firefox 55, due to security concerns, we put using jar: with remote
content (ie loaded over http(s), ftp - anything apart from file://,
really) behind a hidden (ie about:config) preference that is disabled by
default (
https://www.fxsitecompat.com/en-CA/docs/2015/jar-protocol-support-has-been-disabled-by-default/
;
https://developer.mozilla.org/en-US/docs/Mozilla/Security/Security_and_the_jar_protocol
; https://bugzilla.mozilla.org/show_bug.cgi?id=1329336 ).

I would like to unship the preference in Firefox 60 and completely
remove support.

When the code was originally written for Firefox 45, 2 years ago, IBM
Notes broke. That was fixed in Notes/Domino 9.0.1 (
http://www.ibm.com/support/docview.wss?uid=swg21978919 ) in May 2016, so
a good 2 and a bit years before 60 will ship. To my knowledge we are not
aware of any other breakage on the (semi-)public web since then. We also
successfully shipped this default-disabled back in August with 55, and
it'll have been 1 year since then before the previous esr (52) stops
being supported.

As a result, I don't expect there to be any significant use of this
preference anymore, nor do I see any good reason not to remove it. The
bug for the removal is
https://bugzilla.mozilla.org/show_bug.cgi?id=1427726 .

Please let me know if you have reason to believe remote jar: still has
significant usage to the point that we cannot remove support in Firefox 60.

Gijs

[Kris Maglione]

Do we have telemetry on the usage of the preference or of remote
JAR channels? If not, it shouldn't be hard to add, and would be
a lot safer than guessing[1]. Either way, I definitely agree
that it would be nice to get rid of this.

-Kris

[1]: Except, of course, that it wouldn't tell us much about
enterprise users, who are probably the most likely people to
make use of it.

[Tom Ritter]

Telemetry was removed in 55:
https://bugzilla.mozilla.org/show_bug.cgi?id=1358004

You can still query it on tmo for 54... except it seems to give me a JS error.

-tom

On Fri, Jan 12, 2018 at 3:55 PM, Kris Maglione <kmag...@mozilla.com> wrote:
> Do we have telemetry on the usage of the preference or of remote JAR
> channels? If not, it shouldn't be hard to add, and would be a lot safer than
> guessing[1]. Either way, I definitely agree that it would be nice to get rid
> of this.
>
> -Kris
>
> [1]: Except, of course, that it wouldn't tell us much about enterprise
> users, who are probably the most likely people to make use of it.
>
>
> On Fri, Jan 12, 2018 at 09:47:44PM +0000, Gijs Kruitbosch wrote:
>>

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Gijs Kruitbosch]

I should have been explicit about my considerations for telemetry;
apologies for not doing so upfront.

The bug for the removal of telemetry code claims usage was 0.01% of
sessions 9 months ago, before the pref was flipped. I think that's fine
in terms of removing things.

I don't think we should re-add telemetry for this because I don't think
it will tell us anything new/useful at this point - it'll just add
delays and keep the code on the next ESR (meaning we'll have to keep it
in mind for the next 1.5 years or so) when we should be getting rid of it.

As Kris already pointed out in his footnote, the most likely group of
people to have enabled this (given 0 public reports on breakage so far,
as far as I'm aware) are people on ESR or otherwise in enterprise
environments, and our collection rates on telemetry in enterprise
environments are unknown, but guaranteed to be low.

~ Gijs

[Gijs Kruitbosch]

On 12/01/2018 22:12, Gijs Kruitbosch wrote:
> As Kris already pointed out in his footnote, the most likely group of
> people to have enabled this (given 0 public reports on breakage so far,
> as far as I'm aware) are people on ESR or otherwise in enterprise
> environments, and our collection rates on telemetry in enterprise
> environments are unknown, but guaranteed to be low.

Addendum that should have followed this note: instead, the intent to
ship was cross-posted to the enterprise list. I'm hoping people there
will be more helpful in pointing out remaining consumers esp. in
enterprise, than telemetry would be.

~ Gijs

[Daniel Veditz]

On Fri, Jan 12, 2018 at 2:12 PM, Gijs Kruitbosch <gijskru...@gmail.com>
wrote:

> the most likely group of people to have enabled this (given 0 public
> reports on breakage so far, as far as I'm aware) are people on ESR or
> otherwise in enterprise environments
>

​Or those trying to run multi-file testcases packaged as a ZIP archive on
bugzilla (Hi!) without having to run a localhost server for it. Especially
handy when the testcase was demonstrating something specifically about our
handling of https pages.

Does removing this let us remove a good chunk of code? I'm glad it's
disabled by default (attack surface reduction) but afaik we still have to
support jar: internally. It may be just me using this at this point so if
we can kill a bunch of stuff that's a win, but if you're just taking away
the pref is that worth it?

-Dan Veditz

[Gijs Kruitbosch]

On 17/01/2018 00:01, Daniel Veditz wrote:
> On Fri, Jan 12, 2018 at 2:12 PM, Gijs Kruitbosch <gijskru...@gmail.com>
> wrote:
>
>> the most likely group of people to have enabled this (given 0 public
>> reports on breakage so far, as far as I'm aware) are people on ESR or
>> otherwise in enterprise environments
>>
>
> ​Or those trying to run multi-file testcases packaged as a ZIP archive on
> bugzilla (Hi!) without having to run a localhost server for it. Especially
> handy when the testcase was demonstrating something specifically about our
> handling of https pages.

Yes, I'm aware of this issue and mentioned it on the bug. You're not the
only one who does this.

> Does removing this let us remove a good chunk of code?

I am led to believe that the answer to this is 'yes'.

> I'm glad it's
> disabled by default (attack surface reduction) but afaik we still have to
> support jar: internally.

At this point I am actually not aware of any substantial consumers who
rely on jar: explicitly internally through gecko (Android has some
consumers that go through java, but that's not the same, see comments on
the bug). chrome: and resource: of course do so implicitly, but we
don't, as a rule, e.g. load documents with jar: URIs. So "support" is
relative.

> It may be just me using this at this point so if
> we can kill a bunch of stuff that's a win, but if you're just taking away
> the pref is that worth it?

Even if it was mostly the pref, it removes complexity and edgecases, and
I think that's something we should push for as we add complexity
elsewhere, to keep things reasonable, as it were. :-)

If "archives on bugzilla" is a significant thing, we should push for
better support from bugzilla. (Also for other formats like gz, bz2, rar,
etc. which jar: doesn't support!)

~ Gijs