Re: [webappsec] Rechartering: Sub-Origins

I guess that is a (likely unintended) consequence of the feature.

Adversarial blocking tools like this are always going to lead to an
arms race / cat-and-mouse / pick your metaphor for neverending
game-theoretic churn.  Once there's enough money at stake, the
decision to take the risk will probably be made, with or without good
mitigation technologies available. Do we want to sacrifice the ability
to more easily partition applications in to securable components for a
position in that battle that will surely be overrun anyway?


On Mon, Nov 10, 2014 at 3:36 PM, Brian Smith <> wrote:
> On Sun, Nov 9, 2014 at 4:04 PM, Brad Hill <> wrote:
>> Rechartering Thread 5: Sub-Origins
>> Based on our survey results and discussion at TPAC, there is strong
>> consensus for supporting work on a sub-origin proposal based on the
>> following input document:
>> Joel Weinberger would be editor.
> Hi,
> I'd like to make sure I understand this correctly.
> Let's say there were a popular search engine at
> that uses <script
> src="> to insert an ad into
> the page. Let's say that ad-blocking tools know to block all requests
> to so the ads won't show up.
> could avoid the ad blocking (or at least make
> it much more difficult) by loading the ads from its own domain
> instead, but it doesn't do so currently
> because that would eliminate the protection that same-origin policy
> provides, causing undue risk. But, with this proposal,
> could safely serve the ads that it
> would normally serve and keep the
> protections of same-origin policy, while still making ad-blocking
> difficult.
> In particular, tools like Mozilla's just-announced-today tracking
> protection depend on being able to completely avoid making a request
> to a tracking service, but with the suborigin proposal, it wouldn't
> even know the suborigin until it received the response to the request
> that it is trying to avoid making.
> Is this correct?
> Cheers,
> Brian

Received on Monday, 10 November 2014 23:54:15 UTC