Darien others replied about CSP but also `script-src data: unsafe-inline` would work as well. There is no evaluation, or at least, nothing different from loading static content there (OK, the dynamic import could be a different story, yet if pre-processed I don't see it as useful, but surely one day someone will prove me wrong ^_^;; ).
About IANA vs HTML, I think both should be supported, specially because IANA states text/javascript is deprecated and most developers serve JS via application/javascript, or JSON as application/json (and there is no text/json). WebKit / Safari handles both cases without issues, Chrome chokes on the application/javascript but it's IMO a non sense to allow one but not the other, so I've filed a bug: https://bugs.chromium.org/p/chromium/issues/detail?id=854370 Regards On Wed, Jun 20, 2018 at 1:56 AM, 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
