Should JSON MIME Types include all */*+json?

[hiroshige-g]

https://mimesniff.spec.whatwg.org/#json-mime-type defines JSON MIME Types as:

• application/json
• text/json
• */*+json

But I'm wondering whether it's better to limit the third case to application/*+json or something, or not, mainly in the context of JSON modules.

pros:

• The current browser implementations don't seem to consider all */*+json MIME types as JSON. JSON MIME types are used in https://html.spec.whatwg.org/C/#process-a-navigate-response, and thus navigations to responses with JSON MIME types should be like navigating to text page (e.g. text/plain page), but according to draft WPT ([TEST] Test MIME Types + navigation web-platform-tests/wpt#20169):
  • Following JSON MIME types are rejected (i.e. trigger download instead of navigation) on Firefox:
    • application/*+json
    • text/*+json
  • Following JSON MIME types are rejected on Firefox and Chromium:
    • All other */*+json
• As JSON modules is a fairly new feature, it might be worth considering to setting stricter restriction on MIME types (just like module scripts have stricter MIME type restriction than classic scripts).

cons:

• The current spec is aligned with how XML MIME Types are defined, i.e. including */*+xml in RFC7303, and the rationale behind it: https://tools.ietf.org/html/rfc7303#appendix-A.
  • Similarly, all */*+xml MIME Types don't seem considered as XMLs by the current browsers, according to the draft WPT above though.

WDYT?

[hiroshige-g]

@domenic @nhiroki @littledan

[annevk]

Your pros and cons mainly consider status in implementations, but what would the engineering benefit be, so to speak?

[littledan]

I am not an expert in this area so I don't have an opinion; I was just trying to follow existing spec conventions. Maybe @Ms2ger @dandclark @BoCupp-Microsoft would know more.

Will JSON modules be the first time that the JSON MIME type is actually checked in running an HTML page?

[annevk]

It might be yes, fetch() and XMLHttpRequest notably ignore it. (Web Manifest doesn't seem to check the MIME type, filed an issue on that.)

[dandclark]

(just like module scripts have stricter MIME type restriction than classic scripts)

Is anyone familiar with the reasoning behind that decision? That could help inform our thinking here. In particular I wonder if it was just a simplification or if there was some security concern.

I'm no expert in this area either, but it seems like engineering benefit of allowing */*+json is that JSON modules could import any future dual-format that is introduced someday with this MIME type, e.g. an image format that is also valid JSON. Although no such thing exists now that I'm aware of, so maybe that's an argument for keeping the MIME type check restricted for the time being while being open to loosening the restrictions to allow it in the future if needed.

[hiroshige-g]

(just like module scripts have stricter MIME type restriction than classic scripts)

IIUC:
Classic scripts allow MIME sniffing and accept a quite broad range of MIME types, including text/html which are clearly non-JavaScript, can be executed as scripts by attacks/mistake but are widely used.
Module scripts are new and don't have to be worried about breaking existing scripts, so allow only strict JavaScript MIME types for improved security.

I'm not sure whether similar argument applies to JSON modules.

The benefit to allow */*+json would be clarifying that we allow a broad range of MIME types (including e.g. image/foobar+json) intentionally as JSON modules.

The benefit to narrow the range would be improving security. WICG/webcomponents#839 will make JSON modules NOT to SOLELY rely on MIME types, but will we still need MIME type checks as a part of security guard? I don't have specific concerning cases for now and thus I filed this issue whether someone has specific thoughts aboud security.

[hiroshige-g]

Will JSON modules be the first time that the JSON MIME type is actually checked in running an HTML page?

Navigation (https://html.spec.whatwg.org/C/#process-a-navigate-response, see #112 (comment)) also checks JSON MIME type, but I'm not sure about its importance.

[annevk]

Ah, that's what you meant. So yes, requiring a JSON MIME type is important, just like it's important to require a JavaScript MIME type in new contexts (especially if they can parse differently), but it doesn't have to be a specific one, as far as I can tell.

Navigation is observable if you navigate an <iframe> or popup to a JSON response. Per those rules it ought to be rendered (and be accessible) as a text document.

[domenic]

Is anyone familiar with the reasoning behind that decision? That could help inform our thinking here. In particular I wonder if it was just a simplification or if there was some security concern.

It is a security concern. There have been attacks in the past (e.g. this paper (C)) based on non-JS files being treated as JS files and "executed".

In general, allowing web sites to treat the contents of URLs as a different type than their declared content-type is an attack vector that gets exploited fairly regularly.

[dandclark]

I'm thinking that in this case the benefit of allowing potential JSON-like types like image/foobar+json to be loaded as JSON modules outweighs any benefit of narrowing the JSON MIME-type set. I understand now the security concerns of loading non-JS as script, but it's hard to see how parsing even arbitrary content as JSON could be harmful on the same level. And adding +json to a MIME type seems like a pretty straightforward signal that the resource owner expects that it could be interpreted as JSON.

[hiroshige-g]

So, the concensus here can be:

• Importing */*+json, including image/foobar+json has valid use cases
• Importing (and navigating to) */*+json doesn't look to cause security problems (because JSON isn't executed)
• so let's keep the current spec and allow */*+json as-is.

Does this sounds good?

If so, Chromium will allow */*+json for JSON modules.
If fixing the existing interoperability issue of navigation + */*+json is desired, we might want to file a Pri-3 bug against Chromium (and other browsers), but currently I don't have immediate motivation to changing Chromium's behavior around navigation.

[hiroshige-g]

Created #113 that feeds the discussion here back to the spec.