IIUC, JS6 module import is equivalent to injecting a <script type=module> which should already be handled by script-src.
It seems to me that web workers are very much like JS6 modules. So, why isn't <script src> used to control web workers too? What is additionally threatening about web workers that make them deserving of special treatment compared to other kinds of script? IMO, the threading issue for web workers is not a significant issue w.r.t. security and so I see no reason to treat them differently than JS6 modules.
Off the top of my head, I can't identify a clear problem that would warrant shared workers getting special treatment compared to other scripts either. Do shared workers actually enable any functionality that a script can't accomplish without them? If not, it seems there's no point in treating shared workers differently from JS6 modules either.
OTOH, despite the similarity in naming, Service Workers seem quite different from web workers and shared workers. I believe Service Workers fundamentally do provide powerful functionality that can't be accomplished another way, though I could be convinced otherwise. In fact, when considering the footgun aspect, Service Workers are potentially much more dangerous than regular script. This makes me think that, regardless of whether script-src should affect Service Workers (#31), it makes sense to have a separate directive that allows one to block Service Workers from origins where other scripts are allowed. However, I wouldn't want to block web workers or shared workers or JS6 modules too.
This makes me think that script-src should control JS6 modules, web workers, and shared workers. Maybe it should also affect service workers (#31). But, there should be a separate directive for controlling service workers, separate from the directive used for web workers, shared workers, and JS6 modules. And, it seems to me that a directive separate from script-src isn't needed for web workers, shared workers, and JS6 modules.
IIUC, JS6 module
importis equivalent to injecting a<script type=module>which should already be handled byscript-src.It seems to me that web workers are very much like JS6 modules. So, why isn't
<script src>used to control web workers too? What is additionally threatening about web workers that make them deserving of special treatment compared to other kinds of script? IMO, the threading issue for web workers is not a significant issue w.r.t. security and so I see no reason to treat them differently than JS6 modules.Off the top of my head, I can't identify a clear problem that would warrant shared workers getting special treatment compared to other scripts either. Do shared workers actually enable any functionality that a script can't accomplish without them? If not, it seems there's no point in treating shared workers differently from JS6 modules either.
OTOH, despite the similarity in naming, Service Workers seem quite different from web workers and shared workers. I believe Service Workers fundamentally do provide powerful functionality that can't be accomplished another way, though I could be convinced otherwise. In fact, when considering the footgun aspect, Service Workers are potentially much more dangerous than regular script. This makes me think that, regardless of whether
script-srcshould affect Service Workers (#31), it makes sense to have a separate directive that allows one to block Service Workers from origins where other scripts are allowed. However, I wouldn't want to block web workers or shared workers or JS6 modules too.This makes me think that
script-srcshould control JS6 modules, web workers, and shared workers. Maybe it should also affect service workers (#31). But, there should be a separate directive for controlling service workers, separate from the directive used for web workers, shared workers, and JS6 modules. And, it seems to me that a directive separate fromscript-srcisn't needed for web workers, shared workers, and JS6 modules.