I do think Content Security Policy offers a good opportunity to address
the use cases Anne brought up.
CSP already has a directive, frame-ancestors, that restricts the context
in which a resource can be embedded as a iframe, frame or object
to a list of origins. Perhaps we should expand the scope of the
directive to include other elements (and change the directive name to
something less frame-centric).
I'd personally support such a change.
-Brandon
On 03/01/2011 12:32 AM, Adam Barth wrote:
+dveditz and +bsterne because they have strong opinions about CSP.
Adam
On Tue, Mar 1, 2011 at 12:26 AM, Adam Barth w...@adambarth.com wrote:
On Mon, Feb 28, 2011 at 11:57 PM, Maciej Stachowiak m...@apple.com wrote:
For what it's worth, I think this is a useful draft and a useful
technology. Hotlinking prevention is of considerable interest to Web
developers, and doing it via server-side Referer checks is inconvenient and
error-prone. I hope we can fit it into Web Apps WG, or if not, find another
goo home for it at the W3C.
One thing I am not totally clear on is how this would fit into CSP. A big
focus for CSP is to enable site X to have a policy that prevents it from
accidentally including scripts from site Y, and things of that nature. In
other words, voluntarily limit the embedding capabilities of site X itself
But the desired feature is kind of the opposite of that. I think it would
be confusing to stretch CSP to this use case, much as it would have been
confusing to reuse CORS for this purpose.
There's been a bunch of discussion on the public-web-security mailing
list about the scope of CSP. Some folks think that CSP should be a
narrow feature targeted at mitigating cross-site scripting. Other
folks (e.g., as articulated in
http://w2spconf.com/2010/papers/p11.pdf) would like to see CSP be
more of a one-stop shop for configuring security-relevant policy for a
web site.
From-Origin is closely related to one of the proposed CSP features,
namely frame-ancestors, which also controls how the given resource can
be embedded in other documents:
https://wiki.mozilla.org/Security/CSP/Specification
Aside from the aesthetic questions, I'd imagine folks will want to
include a list of permissible origins in the From-Origin header (or
else they'd have to give up caching their resources). CSP already has
syntax, semantics, and processing models for lists of origins,
including wildcards. At a minimum, we wouldn't want to create a
gratuitously different syntax for the same thing.
Adam
On Feb 28, 2011, at 11:35 PM, Anne van Kesteren wrote:
The WebFonts WG is looking for a way to prevent cross-origin embedding of
fonts as certain font vendors want to license their fonts with such a
restriction. Some people think CORS is appropriate for this, some don't.
Here is some background material:
http://weblogs.mozillazine.org/roc/archives/2011/02/distinguishing.html
http://annevankesteren.nl/2011/02/web-platform-consistency
http://lists.w3.org/Archives/Public/public-webfonts-wg/2011Feb/0066.html
More generally, having a way to prevent cross-origin embedding of
resources can be useful. In addition to license enforcement it can help
with:
* Bandwidth theft
* Clickjacking
* Privacy leakage
To that effect I wrote up a draft that complements CORS. Rather than
enabling sharing of resources, it allows for denying the sharing of
resources:
http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html
And although it might end up being part of the Content Security Policy
work I think it would be useful if publish a Working Draft of this work to
gather more input, committing us nothing.
What do you think?
Kind regards,
--
Anne van Kesteren
http://annevankesteren.nl/
