Re: Security use cases for packaging
Brad Hill writes: > Paging (future Dr.) Deian Stefan to the ER... > > Any thoughts on using COWL for this kind of thing, with a pinned crypto key > as a confinement label to be combined with the regular Origin label? Thanks for paging me! I've thought about something like this---providing some form of code integrity---in the context of COWL as well. The idea was to grant a worker the privilege corresponding to the (hash of the) source, in addition to its origin. This would allow a server to verify if the code it is communicating with is trustworthy. (COWL labels are not limited to origins.) I really like Yan's use case. And I think it fits in pretty naturally with COWL: the app, if verification succeeds, can be granted the privilege corresponding to the (hash of the) crypto key: Privilege(https://cryptomail.yahoo.com).and(app-key:...). Other code from the same origin would only have Privilege(https://cryptomail.yahoo.com). I think this may partly address Chris and Dev's concerns. But deciding when not to run the app code is still a question. Though I think the github issue already brings this up. Deian
Re: Clarification of CSP sandbox and workers
+1 Mike West writes: > The CSP spec should just delegate to HTML here. If/when HTML defines > sandboxing with regard to Workers, CSP will just start using those hooks. Reasonable, the issue also appears outside CSP: if I create a worker in a sandboxed iframe, what should its origin be? (Or should I not be able to create a worker in this case?) > I'd agree, for example, that it does appear that sandboxing a worker into a > unique origin could be interesting. It's not clear to me whether any of the > other flags would be useful, though. Right, none of the other flags really make sense. (Though some of the flags similarly don't make sense when the sandbox directive is applied to a top-level page.) I do think it's reasonable to wait on the more general sandboxed worker idea, since some of the proposals in WebAppSec are thinking about this already. Thanks, Deian
Clarification of CSP sandbox and workers
Hey guys, I am implementing CSP for Workers in Firefox, but like to get a clarification on workers and the sandbox flag. Currently, a Worker can inherit or be accompanied by a CSP header. As written, the implications of the sandbox directive on the Worker context is not clear. [Following up on https://github.com/w3c/webappsec/issues/69] Arguably most of the sandbox flags don't make sense for Workers, but the empty directive (i.e., just sandbox) and sandbox allow-same-origin can have reasonable semantics. So, if a Worker inherits the CSP from the owner document (or parent worker in later specs) or is accompanied by a CSP header which has the 'sandbox' directive, should the worker script's origin be set to a unique origin? Or should we just ignore (and appropriately warn about) the sandbox flag for Workers and address the need for sandboxed Workers separately? Thanks, Deian signature.asc Description: PGP signature
