Re: Importing modules inside HTML imports

[John Barton]

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.


On Mon, Aug 18, 2014 at 11:23 AM, caridy  wrote:

> 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: ` src="/my-sticky-data-and-initialization-per-page.js">`, 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!
>
> /caridy
>
> On Aug 18, 2014, at 11:35 AM, John Barton  wrote:
>
>
>
>
> On Mon, Aug 18, 2014 at 8:02 AM, Anne van Kesteren 
> wrote:
>
>> On Mon, Aug 18, 2014 at 4:57 PM, John Barton 
>> 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
>> https://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
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Importing modules inside HTML imports

[caridy]

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: ``, 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!

/caridy

On Aug 18, 2014, at 11:35 AM, John Barton  wrote:

> 
> 
> 
> On Mon, Aug 18, 2014 at 8:02 AM, Anne van Kesteren  wrote:
> On Mon, Aug 18, 2014 at 4:57 PM, John Barton  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 https://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
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Importing modules inside HTML imports

[John Barton]

On Mon, Aug 18, 2014 at 8:02 AM, Anne van Kesteren  wrote:

> On Mon, Aug 18, 2014 at 4:57 PM, John Barton 
> 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
> https://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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Importing modules inside HTML imports

[Anne van Kesteren]

On Mon, Aug 18, 2014 at 4:57 PM, John Barton  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 https://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.)


-- 
http://annevankesteren.nl/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Importing modules inside HTML imports

[John Barton]

On Mon, Aug 18, 2014 at 12:57 AM, Anne van Kesteren 
wrote:

> On Sun, Aug 17, 2014 at 8:52 PM, 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.
> >
> > 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:

http://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.

https://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.

http://content-security-policy.com/

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Importing modules inside HTML imports

[Anne van Kesteren]

On Sun, Aug 17, 2014 at 8:52 PM, 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.
>
> 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.


-- 
http://annevankesteren.nl/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Importing modules inside HTML imports

[Brendan Eich]

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.


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Importing modules inside HTML imports

[Rick Waldron]

On Sun, Aug 17, 2014 at 2:52 PM, John Barton  wrote:

>
>
>
> On Sun, Aug 17, 2014 at 11:14 AM, Rick Waldron 
> wrote:
>
>>
>>
>> On Sunday, August 17, 2014, John Barton  wrote:
>>
>>>
>>>
>>>
>>> On Sun, Aug 17, 2014 at 10:08 AM, Brendan Eich 
>>> wrote:
>>>
 John Barton wrote:

  On Sat, Aug 16, 2014 at 10:22 AM, Brendan Eich  > 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.

Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Importing modules inside HTML imports

[David Bruant]

Le 17/08/2014 20:52, John Barton a écrit :


On Sun, Aug 17, 2014 at 11:14 AM, Rick Waldron > wrote:



On Sunday, August 17, 2014, John Barton mailto:johnjbar...@google.com>> wrote:


On Sun, Aug 17, 2014 at 10:08 AM, Brendan Eich
 wrote:

John Barton wrote:

On Sat, Aug 16, 2014 at 10:22 AM, Brendan Eich
mailto:bren...@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.


David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Importing modules inside HTML imports

[John Barton]

On Sun, Aug 17, 2014 at 11:14 AM, Rick Waldron 
wrote:

>
>
> On Sunday, August 17, 2014, John Barton  wrote:
>
>>
>>
>>
>> On Sun, Aug 17, 2014 at 10:08 AM, Brendan Eich 
>> wrote:
>>
>>> John Barton wrote:
>>>
>>>  On Sat, Aug 16, 2014 at 10:22 AM, Brendan Eich >>> > 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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Importing modules inside HTML imports

[Brendan Eich]

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.

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Importing modules inside HTML imports

[Rick Waldron]

On Sunday, August 17, 2014, John Barton  wrote:

>
>
>
> On Sun, Aug 17, 2014 at 10:08 AM, Brendan Eich  > wrote:
>
>> John Barton wrote:
>>
>>  On Sat, Aug 16, 2014 at 10:22 AM, Brendan Eich >>  >> bren...@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



>
>
>>
>>
>> /be
>>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Importing modules inside HTML imports

[John Barton]

On Sun, Aug 17, 2014 at 10:08 AM, Brendan Eich  wrote:

> John Barton wrote:
>
>  On Sat, Aug 16, 2014 at 10:22 AM, Brendan Eich > > 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.


>
>
> /be
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Importing modules inside HTML imports

[Brendan Eich]

John Barton wrote:
On Sat, Aug 16, 2014 at 10:22 AM, Brendan Eich > 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.


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Importing modules inside HTML imports

[John Barton]

On Sat, Aug 16, 2014 at 10:22 AM, Brendan Eich  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.


>
>
> /be
>
>
> Anne van Kesteren wrote:
>
>> On Sat, Aug 16, 2014 at 2:46 AM, John Barton
>> 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.
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Importing modules inside HTML imports

[Brendan Eich]

Yes -- inline scripts, like document.write, the drive-in, disco, and 
Fortran, will never die.


/be

Anne van Kesteren wrote:

On Sat, Aug 16, 2014 at 2:46 AM, John Barton  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.

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Importing modules inside HTML imports

[Anne van Kesteren]

On Sat, Aug 16, 2014 at 2:46 AM, John Barton  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.


-- 
http://annevankesteren.nl/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Importing modules inside HTML imports

[John Barton]

On Fri, Aug 15, 2014 at 3:06 PM, Ian Hickson  wrote:

>
> Suppose you have an HTML import foo.html that declares two modules:
>
> ... 
> ... 
>

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:
>
>
>
> 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.



> 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.)
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Importing modules inside HTML imports

[Ian Hickson]

Suppose you have an HTML import foo.html that declares two modules:

... 
... 

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:

   

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.)

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss