Importing modules inside HTML imports
On Fri, Aug 15, 2014 at 3:06 PM, Ian Hickson <ian at hixie.ch> wrote:
Suppose you have an HTML import foo.html that declares two modules:
<script type=module id=a> ... </script> <script type=module id=b> ... </script>
As we noted in another thread, Web devs no longer control servers. And servers no longer allow inline script (for the most part going forward). So I don't see this feature as worth investing effort in. (I don't like it either, but it is what it is).
How should they refer to each other? For example, if module id=b wants to import module id=a? I suppose the logical way is like this:
import "#a";
import './a';
Now, in the main page, you reference the HTML import:
<link rel=import href="foo.html">
Now how would you refer to the modules? We can't have #b refer to it, since the scope of IDs is per-document, and the import has a separate document.
Separate document implies separate JS global: each needs its own Loader. So the rest of the questions aren't needed.
On Sat, Aug 16, 2014 at 2:46 AM, John Barton <johnjbarton at google.com> wrote:
As we noted in another thread, Web devs no longer control servers. And servers no longer allow inline script (for the most part going forward). So I don't see this feature as worth investing effort in. (I don't like it either, but it is what it is).
That doesn't ring true. CSP didn't, but does now based on feedback that not having inline scripts was too painful. I very much doubt they will go away anytime soon.
Yes -- inline scripts, like document.write, the drive-in, disco, and Fortran, will never die.
On Sat, Aug 16, 2014 at 10:22 AM, Brendan Eich <brendan at mozilla.org> wrote:
Yes -- inline scripts, like document.write, the drive-in, disco, and Fortran, will never die.
More things I don't suggest investing effort in.
John Barton wrote:
On Sat, Aug 16, 2014 at 10:22 AM, Brendan Eich <brendan at mozilla.org <mailto:brendan at mozilla.org>> wrote:
Yes -- inline scripts, like document.write, the drive-in, disco, and Fortran, will never die.More things I don't suggest investing effort in.
Seriously, inline scripts were and are important, both for avoiding extra requests (even with HTTP++ these cost) and, more important, for easiest and smoothest beginner/first-script on ramp.
I have no idea why anyone would seriously contend otherwise. Latency still matters; tools didn't replace hand-authoring. These are not subjective matters.
On Sun, Aug 17, 2014 at 10:08 AM, Brendan Eich <brendan at mozilla.org> wrote:
John Barton wrote:
On Sat, Aug 16, 2014 at 10:22 AM, Brendan Eich <brendan at mozilla.org
<mailto:brendan at mozilla.org>> wrote:
Yes -- inline scripts, like document.write, the drive-in, disco, and Fortran, will never die.More things I don't suggest investing effort in.
Seriously, inline scripts were and are important, both for avoiding extra requests (even with HTTP++ these cost) and, more important, for easiest and smoothest beginner/first-script on ramp.
I have no idea why anyone would seriously contend otherwise. Latency still matters; tools didn't replace hand-authoring. These are not subjective matters.
I agree, but the forces behind CSP control the servers. You'll have to convince them.
On Sunday, August 17, 2014, John Barton <johnjbarton at google.com> wrote:
On Sun, Aug 17, 2014 at 10:08 AM, Brendan Eich <brendan at mozilla.org <javascript:_e(%7B%7D,'cvml','brendan at mozilla.org');>> wrote:
John Barton wrote:
On Sat, Aug 16, 2014 at 10:22 AM, Brendan Eich <brendan at mozilla.org
<javascript:_e(%7B%7D,'cvml','brendan at mozilla.org');> <mailto: brendan at mozilla.org <javascript:_e(%7B%7D,'cvml','brendan at mozilla.org');>>> wrote:
Yes -- inline scripts, like document.write, the drive-in, disco, and Fortran, will never die.More things I don't suggest investing effort in.
Seriously, inline scripts were and are important, both for avoiding extra requests (even with HTTP++ these cost) and, more important, for easiest and smoothest beginner/first-script on ramp.
I have no idea why anyone would seriously contend otherwise. Latency still matters; tools didn't replace hand-authoring. These are not subjective matters.
I agree, but the forces behind CSP control the servers. You'll have to convince them.
Forgive me, but I don't follow this—could you elaborate? It would be appreciated.
Rick Waldron wrote:
I agree, but the forces behind CSP control the servers. You'll have to convince them.Forgive me, but I don't follow this—could you elaborate? It would be appreciated.
Inside-Google baseball, and I'll believe it when I see it.
On Sun, Aug 17, 2014 at 11:14 AM, Rick Waldron <waldron.rick at gmail.com>
wrote:
On Sunday, August 17, 2014, John Barton <johnjbarton at google.com> wrote:
On Sun, Aug 17, 2014 at 10:08 AM, Brendan Eich <brendan at mozilla.org> wrote:
John Barton wrote:
On Sat, Aug 16, 2014 at 10:22 AM, Brendan Eich <brendan at mozilla.org
<mailto:brendan at mozilla.org>> wrote:
Yes -- inline scripts, like document.write, the drive-in, disco, and Fortran, will never die.More things I don't suggest investing effort in.
Seriously, inline scripts were and are important, both for avoiding extra requests (even with HTTP++ these cost) and, more important, for easiest and smoothest beginner/first-script on ramp.
I have no idea why anyone would seriously contend otherwise. Latency still matters; tools didn't replace hand-authoring. These are not subjective matters.
I agree, but the forces behind CSP control the servers. You'll have to convince them.
Forgive me, but I don't follow this—could you elaborate? It would be appreciated.
The argument goes like this: we all want secure Web pages, we can't secure Web pages that allow inline scripts, therefore we have to ban inline scripts.
If the argument is wrong, ignore my advice, CSP will die. I personally think that would be great.
If the argument is correct, then people who run servers and thus are liable for security failures will have to choose between security and "easiest and smoothest beginner/first-script on ramp". In my opinion, security will win this contest every time. Server operators are under a lot of pressure to improve security so they are likely to adopt CSP requirements.
Of course I could be wrong, that's the thing about advice.
HTH, jjb
Le 17/08/2014 20:52, John Barton a écrit :
On Sun, Aug 17, 2014 at 11:14 AM, Rick Waldron <waldron.rick at gmail.com <mailto:waldron.rick at gmail.com>> wrote:
On Sunday, August 17, 2014, John Barton <johnjbarton at google.com <mailto:johnjbarton at google.com>> wrote: On Sun, Aug 17, 2014 at 10:08 AM, Brendan Eich <brendan at mozilla.org> wrote: John Barton wrote: On Sat, Aug 16, 2014 at 10:22 AM, Brendan Eich <brendan at mozilla.org <mailto:brendan at mozilla.org>> wrote: Yes -- inline scripts, like document.write, the drive-in, disco, and Fortran, will never die. More things I don't suggest investing effort in. Seriously, inline scripts were and are important, both for avoiding extra requests (even with HTTP++ these cost) and, more important, for easiest and smoothest beginner/first-script on ramp. I have no idea why anyone would seriously contend otherwise. Latency still matters; tools didn't replace hand-authoring. These are not subjective matters. I agree, but the forces behind CSP control the servers. You'll have to convince them. Forgive me, but I don't follow this—could you elaborate? It would be appreciated.The argument goes like this: we all want secure Web pages, we can't secure Web pages that allow inline scripts
How so? I can write secure web pages that allow inline scripts. As far as I'm concerned, unsafe-inline is part of what I consider my default CSP policy. Maybe we need to reconsider our server-side pratices that mostly consist of concatenating strings, though. I'm personally exploring generating a DOM on the server-side (with .textContent, etc.)
Assuming control of the server-side, can you give an example of an application where the page has inline scripts and cannot be secure?
therefore we have to ban inline scripts.
If the argument is wrong, ignore my advice, CSP will die. I personally think that would be great.
CSP isn't only about inline scripts. It's mostly about whitelisting domains a page can load data from and send data to. That's extremely useful.
On Sun, Aug 17, 2014 at 2:52 PM, John Barton <johnjbarton at google.com> wrote:
On Sun, Aug 17, 2014 at 11:14 AM, Rick Waldron <waldron.rick at gmail.com> wrote:
On Sunday, August 17, 2014, John Barton <johnjbarton at google.com> wrote:
On Sun, Aug 17, 2014 at 10:08 AM, Brendan Eich <brendan at mozilla.org> wrote:
John Barton wrote:
On Sat, Aug 16, 2014 at 10:22 AM, Brendan Eich <brendan at mozilla.org
<mailto:brendan at mozilla.org>> wrote:
Yes -- inline scripts, like document.write, the drive-in, disco, and Fortran, will never die.More things I don't suggest investing effort in.
Seriously, inline scripts were and are important, both for avoiding extra requests (even with HTTP++ these cost) and, more important, for easiest and smoothest beginner/first-script on ramp.
I have no idea why anyone would seriously contend otherwise. Latency still matters; tools didn't replace hand-authoring. These are not subjective matters.
I agree, but the forces behind CSP control the servers. You'll have to convince them.
Forgive me, but I don't follow this—could you elaborate? It would be appreciated.
The argument goes like this: we all want secure Web pages, we can't secure Web pages that allow inline scripts, therefore we have to ban inline scripts.
If the argument is wrong, ignore my advice, CSP will die. I personally think that would be great.
If the argument is correct, then people who run servers and thus are liable for security failures will have to choose between security and "easiest and smoothest beginner/first-script on ramp". In my opinion, security will win this contest every time. Server operators are under a lot of pressure to improve security so they are likely to adopt CSP requirements.
Of course I could be wrong, that's the thing about advice.
Thanks John, I disagree, but I still appreciate your time in explaining.
John Barton wrote:
The argument goes like this: we all want secure Web pages, we can't secure Web pages that allow inline scripts, therefore we have to ban inline scripts.
Nice syllogism but for the minor premise. Evidence? Links? Proof would be even better, but we're far afield from logic or Math.
On Sun, Aug 17, 2014 at 8:52 PM, John Barton <johnjbarton at google.com> wrote:
The argument goes like this: we all want secure Web pages, we can't secure Web pages that allow inline scripts, therefore we have to ban inline scripts.
If the argument is wrong, ignore my advice, CSP will die. I personally think that would be great.
It seems you did not read what I wrote. CSP does support inline scripts these days.
On Mon, Aug 18, 2014 at 12:57 AM, Anne van Kesteren <annevk at annevk.nl>
wrote:
On Sun, Aug 17, 2014 at 8:52 PM, John Barton <johnjbarton at google.com> wrote:
The argument goes like this: we all want secure Web pages, we can't secure Web pages that allow inline scripts, therefore we have to ban inline scripts.
If the argument is wrong, ignore my advice, CSP will die. I personally think that would be great.
It seems you did not read what I wrote. CSP does support inline scripts these days.
So you are claiming that CSP no longer restricts inline scripts and that the various online docs are incorrect? Or only that the server set the "unsafe-inline" value to opt out of the restriction?
Some of the sites that make me think this has not changed:
www.w3.org/TR/CSP In either case, authors should not include 'unsafe-inline' in their CSP policies if they wish to protect themselves against XSS.
developer.mozilla.org/en-US/docs/Web/Security/CSP/CSP_policy_directives Note: Both 'unsafe-inline' and 'unsafe-eval' are unsafe and can open your web site up to cross-site scripting vulnerabilities.
jjb
On Mon, Aug 18, 2014 at 4:57 PM, John Barton <johnjbarton at google.com> wrote:
So you are claiming that CSP no longer restricts inline scripts and that the various online docs are incorrect? Or only that the server set the "unsafe-inline" value to opt out of the restriction?
Neither. See w3c.github.io/webappsec/specs/content-security-policy for the new nonce-source and hash-source features. (Don't read TR/, it's kind of equivalent to reading the previous version of ES, but worse.)
On Mon, Aug 18, 2014 at 8:02 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
On Mon, Aug 18, 2014 at 4:57 PM, John Barton <johnjbarton at google.com> wrote:
So you are claiming that CSP no longer restricts inline scripts and that the various online docs are incorrect? Or only that the server set the "unsafe-inline" value to opt out of the restriction?
Neither. See w3c.github.io/webappsec/specs/content-security-policy for the new nonce-source and hash-source features. (Don't read TR/, it's kind of equivalent to reading the previous version of ES, but worse.)
Excellent thanks! Hope those new features are adopted and servers routinely implement the hash-source feature.
jjb
John, you can also use SPDY/HTTP2.0 PUSH to send sticky code alongside with the original HTML that will mimic the use of inline scripts but behaves like an external script. Essentially, you will have: <script src="/my-sticky-data-and-initialization-per-page.js"></script>, while that script is actually sent thru the SPDY multi-plex, which means no roundtrip is issued, no perf penalty, and it complies with CSP restrictions, the best of both worlds!
Sounds promising, but the key use case cited by Brendan is ease-of-use so it's important that all of this happens by default as far as Web devs are concerned.
Suppose you have an HTML import foo.html that declares two modules:
<script type=module id=a> ... </script> <script type=module id=b> ... </script>
How should they refer to each other? For example, if module id=b wants to import module id=a? I suppose the logical way is like this:
import "#a";
Now, in the main page, you reference the HTML import:
<link rel=import href="foo.html">
Now how would you refer to the modules? We can't have #b refer to it, since the scope of IDs is per-document, and the import has a separate document. The logical way to do it would be:
import "foo.html#a";
...but that means that "#a" and "foo.html#a" should resolve to the same canonical string in the "normalize" hook. Presumably then, that's the full absolute URL? And we look up the document in the import list? But what if the import hasn't been instantiated yet? Should "normalize" just wait until it has been? (Otherwise, the module registry won't have the module and so "locate" will be called and "locate" won't have any idea what to do with that URL.)
None of this is very compelling. Is there some expected way to do this that I haven't thought of?
(Similar questions apply to referencing other things in imports, e.g. style sheets, images, etc.)