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?

-Brad

On Mon, Nov 10, 2014 at 3:36 PM, Brian Smith <brian@briansmith.org> wrote:
> On Sun, Nov 9, 2014 at 4:04 PM, Brad Hill <hillbrad@gmail.com> 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:
>>
>> http://www.chromium.org/developers/design-documents/per-page-suborigins
>>
>> 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
> https://centillion.example.com that uses <script
> src=https://tripletap.example.com/insert-ad.js"> to insert an ad into
> the page. Let's say that ad-blocking tools know to block all requests
> to tripletap.example.com so the ads won't show up.
> centillion.example.com could avoid the ad blocking (or at least make
> it much more difficult) by loading the ads from its own domain
> https://centillion.example.com 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,
> https://centillion.example.com could safely serve the ads that it
> would normally serve https://tripletap.example.com 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