Module loader
On Tue, Apr 9, 2013 at 6:36 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
Using harmony:module_loaders to give feedback on.
- There should be a way to opt into CORS for cross-origin remote script debugging.
What exactly do you mean here? Our plan is that the module loading facility would follow CORS automatically. This will require slight modification to the current design to support the current CORS-ignoring behavior of <script src="">. In particular, some
requests will not go through the translation and link hooks. However, what would opting in to CORS involve, and who would be doing it?
- I think we should force utf-8 decoding on these new types of resources just as we do with workers and anything else that's new and text.
Which step are you referring to? The module loader API is defined entirely in terms of JS strings, not encoded data. If you're suggesting that the default module loader should have different decoding behavior than <script> or <script src="">, then my initial
thought is that that would be a mistake, but I'd be interested in your rationale.
- The request.redirect() callback should be invoked with an absolute URL. No need to leave resolving the URL correctly up to developers.
3a) Why are redirects up to the developer however? Every other part of the platform handles them automatically.
Our current plan is to eliminate the redirect response entirely.
On Tue, Apr 9, 2013 at 2:58 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
On Tue, Apr 9, 2013 at 6:36 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
- There should be a way to opt into CORS for cross-origin remote script debugging.
What exactly do you mean here? Our plan is that the module loading facility would follow CORS automatically. This will require slight modification to the current design to support the current CORS-ignoring behavior of <script src="">. In particular, some requests will not go through the translation and link hooks. However, what would opting in to CORS involve, and who would be doing it?
What do you mean by "follow CORS automatically"? Are you introducing fetch semantics that differ from <script>?
- I think we should force utf-8 decoding on these new types of resources just as we do with workers and anything else that's new and text.
Which step are you referring to? The module loader API is defined entirely in terms of JS strings, not encoded data. If you're suggesting that the default module loader should have different decoding behavior than <script> or <script src="">, then my initial thought is that that would be a mistake, but I'd be interested in your rationale.
It's what we do for workers and basically any new type of text resource. We want to avoid exposing new features to the complexity of encodings, the security implications around them, and various other issues that keep cropping up. Furthermore, by standardizing these new formats on utf-8 we encourage everyone to move to that format and avoid these issues.
- The request.redirect() callback should be invoked with an absolute URL. No need to leave resolving the URL correctly up to developers.
3a) Why are redirects up to the developer however? Every other part of the platform handles them automatically.
Our current plan is to eliminate the
redirectresponse entirely.
Sounds good.
On Tue, Apr 9, 2013 at 10:11 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
On Tue, Apr 9, 2013 at 2:58 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
On Tue, Apr 9, 2013 at 6:36 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
- There should be a way to opt into CORS for cross-origin remote script debugging.
What exactly do you mean here? Our plan is that the module loading facility would follow CORS automatically. This will require slight modification to the current design to support the current CORS-ignoring behavior of <script src="">. In particular, some requests will not go through the translation and link hooks. However, what would opting in to CORS involve, and who would be doing it?
What do you mean by "follow CORS automatically"? Are you introducing fetch semantics that differ from <script>?
Yes, the default fetch behavior will be to follow CORS, rather than to behave like <script>. This is the only way that things like the
translate hook make sense. Additionally, it's my understanding that the ability of <script> to avoid CORS is a legacy compatibility issue,
rather than an intentional design.
- I think we should force utf-8 decoding on these new types of resources just as we do with workers and anything else that's new and text.
Which step are you referring to? The module loader API is defined entirely in terms of JS strings, not encoded data. If you're suggesting that the default module loader should have different decoding behavior than <script> or <script src="">, then my initial thought is that that would be a mistake, but I'd be interested in your rationale.
It's what we do for workers and basically any new type of text resource. We want to avoid exposing new features to the complexity of encodings, the security implications around them, and various other issues that keep cropping up. Furthermore, by standardizing these new formats on utf-8 we encourage everyone to move to that format and avoid these issues.
In that case, it's substantially more difficult to describe the behavior of existing platform behavior in terms of the module loader API. Additionally, since the module system is designed to allow smooth migration from existing code, this seems like it could make developers lives more difficult in unexpected ways.
On Tue, Apr 9, 2013 at 3:32 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
On Tue, Apr 9, 2013 at 10:11 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
What do you mean by "follow CORS automatically"? Are you introducing fetch semantics that differ from <script>?
Yes, the default fetch behavior will be to follow CORS, rather than to behave like <script>. This is the only way that things like the translate hook make sense. Additionally, it's my understanding that the ability of <script> to avoid CORS is a legacy compatibility issue, rather than an intentional design.
It's what we do for workers and basically any new type of text resource. We want to avoid exposing new features to the complexity of encodings, the security implications around them, and various other issues that keep cropping up. Furthermore, by standardizing these new formats on utf-8 we encourage everyone to move to that format and avoid these issues.
In that case, it's substantially more difficult to describe the behavior of existing platform behavior in terms of the module loader API. Additionally, since the module system is designed to allow smooth migration from existing code, this seems like it could make developers lives more difficult in unexpected ways.
You realize these two answers are contradictory right?
If you do a CORS-enabled fetch by default, you also need to decide on whether that will include credentials or not. Currently that is typically exposed as flag in the platform (see with XMLHttpRequest.withCredentials). It's not entirely done yet, but fetch.spec.whatwg.org/#requests might give you an idea what kind of things you need to take into consideration when designing something new that fetches.
Le 09/04/2013 16:32, Sam Tobin-Hochstadt a écrit :
On Tue, Apr 9, 2013 at 10:11 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
On Tue, Apr 9, 2013 at 2:58 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
On Tue, Apr 9, 2013 at 6:36 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
- There should be a way to opt into CORS for cross-origin remote script debugging. What exactly do you mean here? Our plan is that the module loading facility would follow CORS automatically. This will require slight modification to the current design to support the current CORS-ignoring behavior of <script src="">. In particular, some requests will not go through the translation and link hooks. However, what would opting in to CORS involve, and who would be doing it? What do you mean by "follow CORS automatically"? Are you introducing fetch semantics that differ from <script>? Yes, the default fetch behavior will be to follow CORS, rather than to behave like <script>. This is the only way that things like the translate hook make sense.
Why is it the only way?
Additionally, it's my understanding that the ability of <script> to avoid CORS is a legacy compatibility issue, rather than an intentional design.
Opinions differ. Some would say the Same Origin Policy is a legacy compatibility issue. I'm of that side. It's pretty annoying that a server-side opt-in is required for sharing. It would be lovely if sharing on the web was as simple as sharing a URL [1]. It very often isn't (cookies, CORS as an opt-in). Anyway, the web have survived until 2013 to cross-domain scripts; I don't think modules add security issues, so I don't see a reason module imports should act differently than <script>. Especially given how easy
it is to confine a module.
Following CORS for module imports would make fetching a module require 2 HTTP round-trips (one for the pre-flight IIUC) which is a bummer for performance. CDN would need to add CORS headers (though maybe HTTP 2 will be there and the need for CDN will be different) It would make using modules more annoying than script at src and the consequence of that could range from slowed-down adoption to people just never bothering transitioning to modules.
David
On 4/9/2013 8:03 AM, David Bruant wrote:
It would make using modules more annoying than script at src and the consequence of that could range from slowed-down adoption to people just never bothering transitioning to modules.
I agree. Requiring CORS for modules seems like almost a non-starter. The backward-compatibility path of using scripts will have to exist indefinitely into the future, and frankly CORS is a really hostile API to use. I imagine requiring CORS will cripple uptake in any situation where cross origin resources are needed, which is very often these days with scripts.
On Tue, Apr 9, 2013 at 4:03 PM, David Bruant <bruant.d at gmail.com> wrote:
Following CORS for module imports would make fetching a module require 2 HTTP round-trips (one for the pre-flight IIUC) which is a bummer for performance.
False. That's only the case if you can set custom headers for module loads and they would use anything but the HTTP GET method, neither of which should be the case (at least by default).
I'm not sure if this matters to you, but the current proposal (I believe) is to resolve module "names" by appending a ".js" extension; clearly a deviation from the web at large.
import x from "x"; // supposedly fetches "x.js"
On Tue, Apr 9, 2013 at 7:32 AM, Sam Tobin-Hochstadt <samth at ccs.neu.edu>wrote:
On Tue, Apr 9, 2013 at 10:11 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
On Tue, Apr 9, 2013 at 2:58 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
On Tue, Apr 9, 2013 at 6:36 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
- There should be a way to opt into CORS for cross-origin remote script debugging.
What exactly do you mean here? Our plan is that the module loading facility would follow CORS automatically. This will require slight modification to the current design to support the current CORS-ignoring behavior of <script src="">. In particular, some requests will not go through the translation and link hooks. However, what would opting in to CORS involve, and who would be doing it?
What do you mean by "follow CORS automatically"? Are you introducing fetch semantics that differ from <script>?
Yes, the default fetch behavior will be to follow CORS, rather than to behave like <script>. This is the only way that things like the translate hook make sense.
Hi Sam, I don't recall this being discussed before. Perhaps I missed it.
Additionally, it's my understanding that the ability of <script> to avoid CORS is a legacy compatibility issue, rather than an intentional design.
Most of the bizarreness of CORS are also driven by legacy compatibility issues and are best avoided if we can.
Most importantly, we should not send credentials by default, as this creates confused deputy hazards. Best would be to do an origin-independent http[s] GET without preflight (as script tags do) and without credentials (as UMP does and CORS does by default). This combination of "without"s would be new, and would be in the no man's land between the jurisdictions of w3c and tc39, so it is probably impossible to have a sensible conversation that arrives at a sensible conclusion. Given a choice between preflight (the UMP and CORS cost) and credentials (the script-tag cost), preflight is probably the better price to pay.
Sorry, not preflight. Anne is right -- a normal GET does not require a preflight. Rather, the UMP and CORS cost that would be good to avoid if we can is the need for the need for the "Access-Control-Allow-Origin: *" header. But the conclusion is the same. Given a choice between this and credentials, I'd prefer to require this header.
On Tue, Apr 9, 2013 at 4:54 PM, Mark S. Miller <erights at google.com> wrote:
Sorry, not preflight. Anne is right -- a normal GET does not require a preflight. Rather, the UMP and CORS cost that would be good to avoid if we can is the need for the need for the "Access-Control-Allow-Origin: *" header. But the conclusion is the same. Given a choice between this and credentials, I'd prefer to require this header.
- Given translation you're required to use CORS for cross-origin fetching to protect intranets (unfortunate as that may be). So like <script src> is out of the equation. This also means the header is
required for such cross-origin resources.
- I suspect you want a way to opt into using credentials (similar to <script crossorigin=use-credentials src>), but I agree that by default
you should not include them (similar to <script crossorigin src>).
On 4/9/2013 9:27 AM, Anne van Kesteren wrote:
Given translation you're required to use CORS for cross-origin fetching to protect intranets (unfortunate as that may be). So like
<script src>is out of the equation. This also means the header is required for such cross-origin resources.I suspect you want a way to opt into using credentials (similar to
<script crossorigin=use-credentials src>), but I agree that by default you should not include them (similar to<script crossorigin src>).
Based on these two, it would seem to make sense to tie CORS to the translate step. If translation isn't needed (which is the common use case) then CORS isn't needed either.
On Tue, Apr 9, 2013 at 9:33 AM, Brandon Benvie <bbenvie at mozilla.com> wrote:
On 4/9/2013 9:27 AM, Anne van Kesteren wrote:
Given translation you're required to use CORS for cross-origin fetching to protect intranets (unfortunate as that may be). So like <script src> is out of the equation. This also means the header is required for such cross-origin resources.
I suspect you want a way to opt into using credentials (similar to <script crossorigin=use-credentials src>), but I agree that by default you should not include them (similar to <script crossorigin src>).
Based on these two, it would seem to make sense to tie CORS to the translate step. If translation isn't needed (which is the common use case) then CORS isn't needed either.
That would be an annoying non-uniformity, but I see the sense of it. However, if we do adopt that non-uniformity, we should still not send credentials by default -- even if the request is same origin. In this regard, we should strive to be safer than the script tag.
Le 09/04/2013 17:38, Anne van Kesteren a écrit :
On Tue, Apr 9, 2013 at 4:03 PM, David Bruant <bruant.d at gmail.com> wrote:
Following CORS for module imports would make fetching a module require 2 HTTP round-trips (one for the pre-flight IIUC) which is a bummer for performance. False.
My mistake :
Le 09/04/2013 17:51, Mark S. Miller a ?crit :
Best would be to do an origin-independent http[s] GET without preflight (as script tags do) and without credentials (as UMP does and CORS does by default).
What is UMP? (search engines gives me the French political party even when I try to mix it with other terms)
David Bruant wrote:
Le 09/04/2013 17:51, Mark S. Miller a ?crit :
Best would be to do an origin-independent http[s] GET without preflight (as script tags do) and without credentials (as UMP does and CORS does by default).
What is UMP? (search engines gives me the French political party even when I try to mix it with other terms)
Try "CORS UMP":
dev.w3.org/2006/waf/UMP via www.w3.org/Security/wiki/Comparison_of_CORS_and_UMP
Mark and Tyler's answer to CORS.
Le 09/04/2013 18:48, Bjoern Hoehrmann a ?crit :
David Bruant wrote:
Opinions differ. Some would say the Same Origin Policy is a legacy compatibility issue. I'm of that side. It's pretty annoying that a server-side opt-in is required for sharing. It would be lovely if sharing on the web was as simple as sharing a URL 1. It very often isn't (cookies, CORS as an opt-in).
Just to be clear, the traditional problem is that browser cannot know if any given resource is "on the web" or some kind of "intranet" resource, and allowing arbitrary web pages to access intranet resources is bad.
I agree. Notice that holes in the Same Origin Policy allow to gather information anyway; sometimes enough to enable an attack to find someone's location to ~30 feet accuracy. And these holes can't be fixed per spec.
The talk I linked to is just another proof of that that the browser fails in its mission to enforce a strict Same-Origin Policy (and that can't be fixed)
I believe it actually shouldn't be the browser mission. I believe it should be human beings role to organize their URLs so that they're just plain unguessable to any malicious website trying to scan your local network when the resource they locate is precious.
Interestingly, if you start making your URLs unguessable to attackers, you start to realize you don't need browsers to enforce the Same Origin Policy anymore, but that's a different topic.
Although the browser provides some mitigation by enforcing the Same-Origin Policy, it isn't clear what prevents an iOS or Android app to scan a local network (because I don't believe apps have to enforce the Same Origin Policy as the web does).
For sure, if you local network have unguessable URLs, you're protected from network-scanning phones. (I heard that in some big companies/military places, people who do not work for the organization are asked to leave their phone at the entrance...)
Anyway, the web have survived until 2013 to cross-domain scripts; I don't think modules add security issues, so I don't see a reason module imports should act differently than
<script>. Especially given how easy it is to confine a module.A constraint with
<script>is that you cannot actually read the source text that the browser evaluates, accordingly people would use "JSON-P", JSON wrapped inside a function call, to read JSON data, rather than referencing the content directly via<script>.
JSON-P is a pre-CORS technique that should probably be forgotten. If a
third-party accepts to share data in a cross-domain fashion, they can
make the data available and add the CORS headers. iframe+postMessage can
work too. I imagine there is a way to make cross-domain Server-Sent
Events and WebSockets work too (I have never tried)
There are legitimate ways to share data across domains without the
<script>-abusing JSON-P technique.
The devil here is usually in the details, bugzilla.mozilla.org/show_bug.cgi?id=485645 is an example.
This has been fixed both in the ES5 spec and implementations, but I see what you mean.
On Apr 9, 2013, at 9:33 AM, Brandon Benvie <bbenvie at mozilla.com> wrote:
On 4/9/2013 9:27 AM, Anne van Kesteren wrote:
Given translation you're required to use CORS for cross-origin fetching to protect intranets (unfortunate as that may be). So like
<script src>is out of the equation. This also means the header is required for such cross-origin resources.I suspect you want a way to opt into using credentials (similar to
<script crossorigin=use-credentials src>), but I agree that by default you should not include them (similar to<script crossorigin src>).Based on these two, it would seem to make sense to tie CORS to the translate step. If translation isn't needed (which is the common use case) then CORS isn't needed either.
This is closer to what we've been talking about doing. My rough plan (still working through details) is to preserve the separation of JS from web by allowing a loader to disallow some module sources from going through the translate step. Then the browser's built-in loader will be defined to allow cross-origin modules without CORS headers to be loaded but not translated.
On Tue, Apr 9, 2013 at 10:03 PM, David Herman <dherman at mozilla.com> wrote:
This is closer to what we've been talking about doing. My rough plan (still working through details) is to preserve the separation of JS from web by allowing a loader to disallow some module sources from going through the translate step. Then the browser's built-in loader will be defined to allow cross-origin modules without CORS headers to be loaded but not translated.
I think what you want to do is define two request modes. "Fetch and run" and "fetch, translate, and run". The former fetches as tainted cross-origin (meaning remote script debugging is not possible for cross-origin sources), the latter fetches as CORS.
There's no API anywhere in the platform today that does a CORS request and then does not treat it as a network error if the necessary headers are missing (which is what your proposal seems to do).
Using harmony:module_loaders to give feedback on.
There should be a way to opt into CORS for cross-origin remote script debugging.
I think we should force utf-8 decoding on these new types of resources just as we do with workers and anything else that's new and text.
The request.redirect() callback should be invoked with an absolute URL. No need to leave resolving the URL correctly up to developers.
3a) Why are redirects up to the developer however? Every other part of the platform handles them automatically.
-- annevankesteren.nl