Some legacy applications happen to set "X-Content-Type-Options: nosniff" but not provide a Content Type.
Currently we're handling the Situation by trying to print the Content as "text/plain" or prompt a download.
As this can break Websites (we've also seen Device-Websites in an unusable state) - We should allow sniffing in this case for now and get data on how much the breakage would be.

What do other browsers do? What does the spec say to do, if anything?

Past that, reverting to our previous behavior and adding telemetry seems fine to me, I guess, though it would have been nice to do that before we shipped this to release...

What do other browsers do?

I've run a quick test for that. Table shows what type of content
the browser has been sent with no Content-Type + Xtco and what it inferred.

We can see here that safari just downloads everything, chrome favors text/plain and we try text/plain if possible otherwise switch to application/octet-stream.

What does the spec say to do, if anything?

7.1. Identifying a resource with an unknown MIME type
The spec says that setting xtco does not disable sniffing but forbids to sniff for anything that can run script.

I guess my main question is whether the pages that we have observed misbehaving in Firefox also misbehave in other browsers...

https://hg.mozilla.org/mozilla-central/rev/35436d4e7917

I've been a bit slow catching up on this, but I'm surprised by the development here.

Disabling content sniffing on XCTO nosniff is a security feature. Particularly for HTML navigation this is risky and causes some security problems that are hard to fix otherwise. I expanded on this in a talk here [1].

Now this change has been reverted with a very vague justification. The original comment in this bug refers to some "legacy applications", however no specific example is given. I wonder what those applications are, because they wouldn't work in chrome or safari either. Also they do something obviously contradictory: Requesting to disable content sniffing while at the same time relying on content sniffing. (I was jokingly thinking at some point that maybe we need a new "X-Content-Type-Optoins: reallynosniff" header...)

I'd ask to reconsider. XCTO nosniff is an important security feature that web developers should be able to rely on. Weakening a security feature should have a good justification, I don't see one here.

[1] https://www.youtube.com/watch?v=8t8JYpt0egE

I probably should have provided more context here, sorry about that.
Totally with you that nosniff is supposed to mean "really don't sniff" and that's what we want to end on.
As mentioned we encountered breaking Pages because they sent nosniff + no content-type (e.g. Bug 1579176, Bug 1580607)
which is as you said super contradictory but that just seems to be out in the wild.
My current assumption is that those are rather rare cases but we don't have telemetry to back this up.
So the plan is to gather some telemetry on this and move back to "nosniff == reallynosniff" as soon we're confident.

As mentioned we encountered breaking Pages because they sent nosniff + no content-type (e.g. Bug 1579176, Bug 1580607)

Bug 1579176 has no website URL that is breaking.
For bug 1580607, we should fallback to text/plain as Chrome does. We should never enable sniffing that may execute script.

So the plan is to gather some telemetry on this and move back to "nosniff == reallynosniff" as soon we're confident.

Do we keep enable sniffing if many malware sites use this "feature" to run script? I disgree.

Per https://mimesniff.spec.whatwg.org/#mime-type-sniffing-algorithm:

If the supplied MIME type is undefined or if the supplied MIME type’s essence is "unknown/unknown", "application/unknown", or "/", execute the rules for identifying an unknown MIME type with the sniff-scriptable flag equal to the inverse of the no-sniff flag and abort these steps.

Per https://mimesniff.spec.whatwg.org/#no-sniff-flag:

A no-sniff flag, which defaults to set if the user agent does not wish to perform sniffing on the resource and unset otherwise.
Note: The user agent can choose to use outside information, such as previous experience with a site, to determine whether to opt out of sniffing for a particular resource. The user agent can also choose to opt out of sniffing for all resources. However, opting out of sniffing does not exempt the user agent from using the MIME type sniffing algorithm.

See also: https://fetch.spec.whatwg.org/#should-response-to-request-be-blocked-due-to-nosniff?

Fundamentally, it seems like what we should do when nosniff is combined with no type is to sniff text-or-binary only. That would be compatible with comment 10 (though that one also allows sniffing for images and whanot), and compatible with the Chrome behavior of always using "text/plain" in most cases.

Is there a bug tracking that?

Updated the site compatibility note as the pref has been flipped in Bug 1592975.

Added to: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/72#Security
Updated: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options