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 <valentin...@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.giammar...@gmail.com> wrote:
>
>> sorry, I meant:
>>
>> JSON.stringify('data:text/javascript,' + moduleContentAfterTreeShaking);
>>
>>
>> On Tue, Jun 19, 2018 at 10:09 PM, Andrea Giammarchi <
>> andrea.giammar...@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@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
