+dveditz and +bsterne because they have strong opinions about CSP. Adam
On Tue, Mar 1, 2011 at 12:26 AM, Adam Barth <[email protected]> wrote: > On Mon, Feb 28, 2011 at 11:57 PM, Maciej Stachowiak <[email protected]> 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/ >>> >> >> >> >
