W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: Cross-Origin Resource Embedding Restrictions

From: Adam Barth <w3c@adambarth.com>
Date: Tue, 1 Mar 2011 00:32:23 -0800
Message-ID: <AANLkTimsBPXEyNmWpg5y39OeTUysavD6CZFw_SWRt_tH@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Anne van Kesteren <annevk@opera.com>, WebApps WG <public-webapps@w3.org>, Daniel Veditz <dveditz@mozilla.com>, Brandon Sterne <bsterne@mozilla.com>
+dveditz and +bsterne because they have strong opinions about CSP.

Adam


On Tue, Mar 1, 2011 at 12:26 AM, Adam Barth <w3c@adambarth.com> wrote:
> On Mon, Feb 28, 2011 at 11:57 PM, Maciej Stachowiak <mjs@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/
>>>
>>
>>
>>
>
Received on Tuesday, 1 March 2011 08:33:28 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:43 GMT