Two question here:
@mikewest, I'm reading the CSP spec again - hence my filing bugs over on your repo. However, I'm a CSP n00b so your guidance would be appreciated. I don't have an opinion, so I'm pretty open to whatever recommendations you might have.
Hopefully later today I will be able to have a bit more of an informed opinion about this.
Just to be clear, #iamdoincsp 💃
<meta http-equiv="Content-Security-Policy" content="[policy goes here]">
I see you're working at Mozilla, @marcoscaceres ;) If you're testing in Firefox, you have to use the HTTP Header for now.
For the "CSP in the manifest", we a draft extension at: http://w3c.github.io/manifest-csp/
In the "core" manifest spec we state that "The appropriate time to obtain the manifest is left up to implementations". That is, some implementations might obtain the manifest only when the user explicitly asks the UA to do so (think how the Atom/RSS feed is obtained only when the user clicks the feed button), while some may obtain it upfront when the page associated with the manifest is loading (we don't delay the load event, however). I assume this would mean that both the HTTP header as well as the security policy of the resource associated with the manifest (the page that includes ) could be technically enforced for the manifest.
The question is, do we want to have a dependency on CSP delivered with the resource that is associated with the manifest? That is, the Content-Security-Policy HTTP header and the associated ? We can only deliver CSP for the manifest via the HTTP headers. That may be problematic using hosting services (such as GH pages, I think).
Not answering your questions perhaps, as I'm not yet settled on this issue. Please let us know what makes sense to you?
@mozfreddyb thanks for the tip!
Summary of chat with @mikewest and @anssiko about how this is gonna work.
Question: What is the default policy for manifests? Can they get images from anywhere?
For instance, in the following example, the second icon would not load:
HTTP/1.1 200 OK
Content-Security-Policy: img-src icons.example.com;
"name": "custom manifest",
Note that the csp member DOES NOT apply to the manifest itself - authors MUST use a HTTP header to control, for instance, where icons can be obtained from.
Please confirm that I have gotten this correctly.
Question. What happens if the user agent load manifest from "bar.com" and it includes the following?:
"csp": "manifest-src foo.com"
I guess it's too late by then, as the manifest has loaded.
@marcoscaceres Thanks for documenting our discussion, this is exactly how I recall it as we adjourned :)
Re your last question: I'd say we ignore the manifest-src directive in the csp member, as we cannot introspect the manifest without first fetching it (similarly to how a <meta> cannot prevent the HTML document from being loaded). But I'll defer to @mikewest to give us a more informed answer, and check whether this issue is unique to this directive. I'll update the csp extension spec accordingly once we have consensus on this issue.
Btw. I'd like to borrow some of the illustrations to a non-normative section of the http://w3c.github.io/manifest-csp/ spec.
@anssiko happy to give you the graphics. I have them as SVG as they were created in Sketch.
Described how manifest+CSP works (closes #207)
Seems I accidentally reopened this... was closed via 5d2eccc.