Intent to Implement: JSON Modules

569 views
Skip to first unread message

Daniel Clark

unread,
Jul 11, 2019, 5:04:51 PM7/11/19
to blin...@chromium.org, Sam Sebree, Travis Leithead, Bo Cupp, Greg Whitworth, litt...@igalia.com, ms2...@igalia.com

Intent to Implement: JSON Modules

Contact emails

dan...@microsoft.comsase...@microsoft.comtra...@microsoft.compc...@microsoft.comgw...@microsoft.com, litt...@igalia.com, ms2...@igalia.com

Design doc/Spec

The Synthetic Modules Design Doc describes how JSON modules will be implemented using Synthetic Modules.  See in particular the Blink Changes section.

JSON modules is already part of the HTML spec; see https://html.spec.whatwg.org/#json-module-script

 

TAG has approved the feature: https://github.com/w3ctag/design-reviews/issues/375

Summary

JSON modules are another type of module script alongside JavaScript module script.  JSON module scripts are fetched in the same way as JavaScript module
scripts, e.g. with the "cors" mode and using strict MIME type checking.  They share the same module import syntax, e.g.
import data from "./resource.json".  

The JSON object parsed from the fetched file is provided as the module's single default export, with parse errors checked before instantiating the module graph. 

Motivation

There is not currently a way for developers to statically import JSON content as part of module graph instantiation.  Currently developers are forced to consume JSON content dynamically through e.g. fetch().

See GitHub thread here for extensive discussion and many comments indicating support: https://github.com/whatwg/html/issues/4315.

The StackOverflow thread here also contains comments highlighting the lack of this feature in ES6: https://stackoverflow.com/questions/34944099/how-to-import-a-json-file-in-ecmascript-6

Risks

Interoperability and Compatibility

Given that this feature is part of the HTML spec and has indications of support expressed by multiple browser vendors, we do not expect long-term interoperability or compatibility issues.

Edge: Public support; Microsoft is driving the Blink implementation: https://github.com/whatwg/html/issues/4315#issuecomment-489799200

Firefox: Public support: https://github.com/whatwg/html/issues/4315#issuecomment-489537002

Safari: No signals

Web / Framework developers: Quite positive. litt...@igalia.com and ms2...@igalia.com drove the spec work, and there were many expressions of support in #4315.  There were some requests in that thread to expand the feature to support named exports, but the due to the complexity and ambiguity involved this was not included.

  

Ergonomics

We expect the feature to be commonly used in tandem with JavaScript modules (and potentially other module types yet to come).

The feature will be built on Synthetic Modules as part of the existing module graph infrastructure so we don't expect any new performance issues.

 

Activation

Since the feature shares the existing modules syntax and infrastructure we expect that developers already familiar with ES6 modules will have very little difficulty learning and taking advantage of the feature.

  

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes. 

Link to entry on the feature dashboard

TBD

Requesting approval to ship?

No

 

Kouhei Ueno

unread,
Jul 12, 2019, 12:17:57 AM7/12/19
to blin...@chromium.org
non-API OWNER (core/script OWNER) LGTM. We are super excited to see the work happen!

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/BN8PR00MB062883D413AAB266CFA2B269C5F30%40BN8PR00MB0628.namprd00.prod.outlook.com.


--
kouhei

Yoav Weiss

unread,
Jul 12, 2019, 8:42:59 AM7/12/19
to Kouhei Ueno, blin...@chromium.org
Not necessary for an I2I, but LGTM

Will this play nicely with current module infrastructure, e.g. modulepreload?


J Decker

unread,
Jul 12, 2019, 11:41:21 PM7/12/19
to Yoav Weiss, Kouhei Ueno, blin...@chromium.org
I see benefit; though I'm not sure the cost of module overhead on a JSON.parse() result is really worth it; and it's only for static content...
but mostly it's only JSON.  what about other, user extensions?  (.json5, .json6, .hjson ) can we register module loaders?  

a...@google.com

unread,
Jul 15, 2019, 8:23:50 AM7/15/19
to blink-dev, Sam.S...@microsoft.com, travis....@microsoft.com, pc...@microsoft.com, gw...@microsoft.com, litt...@igalia.com, ms2...@igalia.com
On Thursday, July 11, 2019 at 11:04:51 PM UTC+2, Daniel Clark wrote:

Intent to Implement: JSON Modules

Contact emails

Design doc/Spec

The Synthetic Modules Design Doc describes how JSON modules will be implemented using Synthetic Modules.  See in particular the Blink Changes section.

JSON modules is already part of the HTML spec; see https://html.spec.whatwg.org/#json-module-script

 

TAG has approved the feature: https://github.com/w3ctag/design-reviews/issues/375


I've been trying to understand the security delta of this feature, but I haven't this discussed in any of the design docs linked above. Is there an explainer that would cover it? (The design doc seems fairly low level and doesn't make it obvious what the security consequences are.)

More specifically, being able to import JSON cross-origin can be dangerous because it could create new XSSI vectors. Is the idea to require CORS as the main protection?

dan...@microsoft.com

unread,
Jul 16, 2019, 5:57:07 PM7/16/19
to blink-dev, Sam.S...@microsoft.com, travis....@microsoft.com, pc...@microsoft.com, gw...@microsoft.com, litt...@igalia.com, ms2...@igalia.com

Thanks for the feedback so far!  Answers to the questions that came up follow below:

 

Yoav Weiss:

> Will this play nicely with current module infrastructure, e.g. modulepreload?

 

Yes – the feature is built as part of the current module system and will integrate with all the existing infrastructure such as modulepreload It’s just another module variant in the same module graph.

 

J Decker:

> I see benefit; though I'm not sure the cost of module overhead on a JSON.parse() result is really worth it; and it's only for static content...

> but mostly it's only JSON.  what about other, user extensions?  (.json5, .json6, .hjson ) can we register module loaders?  

 

As a first-class participant in the ES module system, JSON modules can also be consumed non-statically with dynamic import.

We don’t plan to incorporate user extensions as part of this proposal -- our current focus is on further extending the native module infrastructure with JSON, CSS modules and eventually HTML Modules.  However, Synthetic Modules would be a great building block for a future proposal for user extensions (as it was for JSON modules).

 

Artur Janc:

> I've been trying to understand the security delta of this feature, but I haven't this discussed in any of the design docs linked above. Is there an explainer that would cover it? (The design doc seems fairly low level and doesn't make it obvious what the security consequences are.)

> More specifically, being able to import JSON cross-origin can be dangerous because it could create new XSSI vectors. Is the idea to require CORS as the main protection?

 

This feature builds on the current JavaScript module infrastructure and thus inherits all of its security characteristics.  Specifically, JSON modules have the same behavior as JavaScript modules with respect to protection again cross-origin loading by requiring CORS, as well as enforcing strict MIME-type checking.  If there is any particular kind of documentation or further info in this area that I can provide then I'm happy to do so; we just didn't see value in a separate writeup here given that JSON modules follow the same tried-and-tested security model of JS modules.  If there's any particular threat beyond those already mentioned that you think we should investigate, please let me know and we'll take a look.

Artur Janc

unread,
Jul 17, 2019, 4:56:39 AM7/17/19
to dan...@microsoft.com, blink-dev, Sam.S...@microsoft.com, Travis Leithead, pc...@microsoft.com, gw...@microsoft.com, litt...@igalia.com, ms2...@igalia.com
On Tue, Jul 16, 2019 at 11:57 PM daniec via blink-dev <blin...@chromium.org> wrote:

Thanks for the feedback so far!  Answers to the questions that came up follow below:

 

Yoav Weiss:

> Will this play nicely with current module infrastructure, e.g. modulepreload?

 

Yes – the feature is built as part of the current module system and will integrate with all the existing infrastructure such as modulepreload It’s just another module variant in the same module graph.

 

J Decker:

> I see benefit; though I'm not sure the cost of module overhead on a JSON.parse() result is really worth it; and it's only for static content...

> but mostly it's only JSON.  what about other, user extensions?  (.json5, .json6, .hjson ) can we register module loaders?  

 

As a first-class participant in the ES module system, JSON modules can also be consumed non-statically with dynamic import.

We don’t plan to incorporate user extensions as part of this proposal -- our current focus is on further extending the native module infrastructure with JSON, CSS modules and eventually HTML Modules.  However, Synthetic Modules would be a great building block for a future proposal for user extensions (as it was for JSON modules).

 

Artur Janc:

> I've been trying to understand the security delta of this feature, but I haven't this discussed in any of the design docs linked above. Is there an explainer that would cover it? (The design doc seems fairly low level and doesn't make it obvious what the security consequences are.)

> More specifically, being able to import JSON cross-origin can be dangerous because it could create new XSSI vectors. Is the idea to require CORS as the main protection?

 

This feature builds on the current JavaScript module infrastructure and thus inherits all of its security characteristics.  Specifically, JSON modules have the same behavior as JavaScript modules with respect to protection again cross-origin loading by requiring CORS, as well as enforcing strict MIME-type checking.  If there is any particular kind of documentation or further info in this area that I can provide then I'm happy to do so; we just didn't see value in a separate writeup here given that JSON modules follow the same tried-and-tested security model of JS modules.  If there's any particular threat beyond those already mentioned that you think we should investigate, please let me know and we'll take a look.


There is an important distinction between HTTP responses which parse as JavaScript and those which parse as JSON. JavaScript resources can be directly loaded cross-origin in `no-cors` mode (via <script src="//victim/resource.js">) and thus developers already have to be careful to not include any authenticated data in responses which parse as JS. This is not the case for JSON because there is no web API that allows no-cors loads of JSON replies (including them as a <script> will result in a SyntaxError); so developers can expect that if they serve straight-up JSON it should not leak cross-origin via XSSI.

Loading in CORS mode should be sufficient to address it, but my concern is that the security posture of JavaScript modules is quite different from JSON modules. For example, if a future version of the spec allows no-cors loads this will not be a problem for JavaScript, but will result in a leak for all web-exposed JSON resources. Having this explicitly considered and documented seems somewhat useful.

Cheers,
-Artur



On Monday, July 15, 2019 at 5:23:50 AM UTC-7, Artur Janc wrote:
On Thursday, July 11, 2019 at 11:04:51 PM UTC+2, Daniel Clark wrote:

Intent to Implement: JSON Modules

Contact emails

--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/ojwkySW-bpQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/45b44f01-be53-49a7-ac73-f3c19cb639bf%40chromium.org.

Mathias Bynens

unread,
Jul 17, 2019, 5:35:00 AM7/17/19
to Artur Janc, dan...@microsoft.com, blink-dev, Sam.S...@microsoft.com, Travis Leithead, pc...@microsoft.com, gw...@microsoft.com, litt...@igalia.com, Ms2ger
On Wed, Jul 17, 2019 at 10:56 AM 'Artur Janc' via blink-dev <blin...@chromium.org> wrote:
On Tue, Jul 16, 2019 at 11:57 PM daniec via blink-dev <blin...@chromium.org> wrote:

Thanks for the feedback so far!  Answers to the questions that came up follow below:

 

Yoav Weiss:

> Will this play nicely with current module infrastructure, e.g. modulepreload?

 

Yes – the feature is built as part of the current module system and will integrate with all the existing infrastructure such as modulepreload It’s just another module variant in the same module graph.

 

J Decker:

> I see benefit; though I'm not sure the cost of module overhead on a JSON.parse() result is really worth it; and it's only for static content...

> but mostly it's only JSON.  what about other, user extensions?  (.json5, .json6, .hjson ) can we register module loaders?  

 

As a first-class participant in the ES module system, JSON modules can also be consumed non-statically with dynamic import.

We don’t plan to incorporate user extensions as part of this proposal -- our current focus is on further extending the native module infrastructure with JSON, CSS modules and eventually HTML Modules.  However, Synthetic Modules would be a great building block for a future proposal for user extensions (as it was for JSON modules).

 

Artur Janc:

> I've been trying to understand the security delta of this feature, but I haven't this discussed in any of the design docs linked above. Is there an explainer that would cover it? (The design doc seems fairly low level and doesn't make it obvious what the security consequences are.)

> More specifically, being able to import JSON cross-origin can be dangerous because it could create new XSSI vectors. Is the idea to require CORS as the main protection?

 

This feature builds on the current JavaScript module infrastructure and thus inherits all of its security characteristics.  Specifically, JSON modules have the same behavior as JavaScript modules with respect to protection again cross-origin loading by requiring CORS, as well as enforcing strict MIME-type checking.  If there is any particular kind of documentation or further info in this area that I can provide then I'm happy to do so; we just didn't see value in a separate writeup here given that JSON modules follow the same tried-and-tested security model of JS modules.  If there's any particular threat beyond those already mentioned that you think we should investigate, please let me know and we'll take a look.


There is an important distinction between HTTP responses which parse as JavaScript and those which parse as JSON. JavaScript resources can be directly loaded cross-origin in `no-cors` mode (via <script src="//victim/resource.js">) and thus developers already have to be careful to not include any authenticated data in responses which parse as JS. This is not the case for JSON because there is no web API that allows no-cors loads of JSON replies (including them as a <script> will result in a SyntaxError);

Note that including JSON as a <script> is not guaranteed to throw a SyntaxError. That happens if the JSON data represents an object:

{"foo":42}

But not if the JSON data is an array or a number or a boolean or null:

[{"foo":42}]
"foo"
42
true
false
null


You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPYVjqpVJNbPEGyMV%3DQaqUTyrGBqfa51ei2FAE8b8%3DpqHwvhJQ%40mail.gmail.com.

PhistucK

unread,
Jul 17, 2019, 6:43:52 AM7/17/19
to Mathias Bynens, Artur Janc, dan...@microsoft.com, blink-dev, Sam.S...@microsoft.com, Travis Leithead, Bo Cupp, gw...@microsoft.com, litt...@igalia.com, Ms2ger
But since there is no export keyword (that would be a JSON syntax error), nothing will actually be imported and exposed. It might be worth a mention, though.

PhistucK


dan...@microsoft.com

unread,
Jul 17, 2019, 3:17:39 PM7/17/19
to blink-dev, mt...@google.com, a...@google.com, dan...@microsoft.com, Sam.S...@microsoft.com, travis....@microsoft.com, pc...@microsoft.com, gw...@microsoft.com, litt...@igalia.com, ms2...@igalia.com
I added a section to the design document stating generally that opening the module system to more resource types implies that we must be more careful with changes involving the module infrastructure overall, as resource types other than JavaScript can now be affected.  I've used the JSON case as an example.  https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/SyntheticModules/designDoc.md#security-considerations-for-new-module-types

Thanks for raising the issue -- while I don't expect to ever see a 'no-cors' version of modules gain much support, it's definitely worth noting that adding more module types widens the scope of any change to the module system.
To unsubscribe from this group and all its topics, send an email to blin...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

Artur Janc

unread,
Jul 18, 2019, 5:42:50 AM7/18/19
to dan...@microsoft.com, blink-dev, Mathias Bynens, Sam.S...@microsoft.com, Travis Leithead, pc...@microsoft.com, gw...@microsoft.com, litt...@igalia.com, ms2...@igalia.com
On Wed, Jul 17, 2019 at 9:17 PM daniec via blink-dev <blin...@chromium.org> wrote:
I added a section to the design document stating generally that opening the module system to more resource types implies that we must be more careful with changes involving the module infrastructure overall, as resource types other than JavaScript can now be affected.  I've used the JSON case as an example.  https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/SyntheticModules/designDoc.md#security-considerations-for-new-module-types

Thanks for raising the issue -- while I don't expect to ever see a 'no-cors' version of modules gain much support, it's definitely worth noting that adding more module types widens the scope of any change to the module system.

Excellent, thank you!

@Mathias, it's true that in some cases JSON responses will load without a SyntaxError -- IIRC this was used in the past to achieve XSSI by redefining the Array constructor. But having an object at the top level is generally considered safe(-ish) with respect to XSSI and there are some applications which rely on this and do not include a parser-breaking prefix on such responses; my original worry was about accidentally introducing a leak in this case.
 
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ecdb12ab-fa31-4ef3-bee3-aa993e3437e2%40chromium.org.

tra...@microsoft.com

unread,
Aug 12, 2019, 1:03:24 PM8/12/19
to blink-dev, Sam.S...@microsoft.com, travis....@microsoft.com, pc...@microsoft.com, gw...@microsoft.com, litt...@igalia.com, ms2...@igalia.com

Link to entry on the feature dashboard

TBD 


FYI: JSON Modules is now up on the Feature Dashboard: https://www.chromestatus.com/feature/5749863620804608
Reply all
Reply to author
Forward
0 new messages