Inline ES Modules

[Mike Samuel]

Sorry for the confusion.

Nonces are just for elements with url attributes.

I mentioned nonces to point out that strict CSP policies can allow some
data: urls without having to explicitly whitelist or hash the entire
content.

Separately I wanted to say that there is no incompatibility between the
goals of CSP and import statements that use a data: module specifier, since
we already trust the compilation unit and there's no actual network message
leaked.

But there is a risk with the import operator since it's input is not part
of an already trusted input.

On Tue, Jun 19, 2018, 8:22 PM Darien Valentine <valentinium at gmail.com>
wrote:

> Mike: Ah, cool, I didn’t realize that — I had thought that nonces were
> just for whitelisting inline script elements. How does one specify a nonce
> in association with a data URI? I’m having trouble turning up a description
> / example of how it would work. Or possibly I’m misunderstanding this quite
> a bit, hm ... I’m also confused by the relationship between import/import()
> and XSS that you’ve described.
>
> On Tue, Jun 19, 2018 at 8:06 PM Mike Samuel <mikesamuel at gmail.com> wrote:
>
>> CSP with data URIs is possible via nonce sources.  For data: module
>> descriptors browsers could safely skip the CSP check since it doesn't allow
>> XSS unless one can already specify an import statement which typically
>> means one can specify arbitrary JS.  That argument doesn't extend to the
>> import operator though so you'd have to tolerate assymetry there.
>>
>> On Tue, Jun 19, 2018, 7:57 PM Darien Valentine <valentinium at gmail.com>
>> wrote:
>>
>>> Andrea: That is a really interesting approach. I would point out that
>>> using data URIs for js means the `data:` scheme has to be a permitted
>>> source for script-src. This allowance has roughly the same security
>>> implications as permitting `unsafe-eval`. I know most people aren’t using
>>> CSPs yet, but personally I’d be wary of a solution that makes it harder to
>>> adopt a strong CSP.
>>>
>>> A super dorky/tangential aside that probably doesn’t matter at all but
>>> ... I notice you used application/javascript for the media type. There’s a
>>> contradiction between the IANA media type registry and the HTML 5 spec with
>>> regard to the "correct" media type to use for JS. RFC 4329 says
>>> application/javascript is the only value that should be used, while HTML
>>> says text/javascript is the only value that should be used. I believe (not
>>> sure though) that this is because it’s the most backwards-compatible value.
>>> Given that the media types registry seems to be basically dead to web
>>> standards (if we follow the registry we can’t serve or post a bunch of
>>> media types acknowledged or defined by web standards at all, including
>>> image/webp, application/csp-report, etc) and the code has to run in a
>>> browser, I’d tend to think HTML is the better spec to follow ... though I
>>> guess when two specs contradict each other it’s hard to make an objective
>>> case for one being more authoritative. (I’d be curious if there’s a
>>> specific reason you know of to prefer to RFC definition though. When
>>> standards don’t align it breaks my tiny heart.)
>>>
>>> On Tue, Jun 19, 2018 at 4:09 PM Andrea Giammarchi <
>>> andrea.giammarchi at gmail.com> wrote:
>>>
>>>> sorry, I meant:
>>>>
>>>> JSON.stringify('data:text/javascript,' + moduleContentAfterTreeShaking)
>>>> ;
>>>>
>>>>
>>>> On Tue, Jun 19, 2018 at 10:09 PM, Andrea Giammarchi <
>>>> andrea.giammarchi at gmail.com> wrote:
>>>>
>>>>>
>>>>> I think these are all nice to have features, but I also think we have
>>>>>> all the primitives we need to make it happen via pre-processing.
>>>>>>
>>>>>>>
>>>>> I meant even synchronously, with a pre-processor that replace the
>>>>> imported module with
>>>>>
>>>>> 'data:text/javascript,' +
>>>>> JSON.stringify(moduleContentAfterTreeShaking);
>>>>>
>>>>
>>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180619/fed467b5/attachment-0001.html>