Fwd: [webappsec] Rechartering: Sub-Origins

[Brian Smith]

---------- Forwarded message ----------
From: Brad Hill <hill...@gmail.com>
Date: Mon, Nov 10, 2014 at 3:53 PM
Subject: Re: [webappsec] Rechartering: Sub-Origins
To: Brian Smith <br...@briansmith.org>
Cc: "public-w...@w3.org" <public-w...@w3.org>


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 <br...@briansmith.org> wrote:
> On Sun, Nov 9, 2014 at 4:04 PM, Brad Hill <hill...@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

[Monica Chew]

Yep, it's definitely not a perfect solution. A site operator who's willing to concede subdomain control through DNS to a third party provider will definitely be able to work around origin checks. We could try to combat this by, say, resolving domain names to IPs and then blocking those -- but that has its own issues.

Many security and privacy problems exhibit arms race qualities. For instance, email spam is at something like 80-90% of all mail. I doubt anyone would make the argument that we should therefore give up on spam fighting because the problem will never be completely solved.

Thanks,
Monica

[Brian Smith]

On Mon, Nov 10, 2014 at 7:15 PM, Monica Chew <m...@mozilla.com> wrote:
> Yep, it's definitely not a perfect solution. A site operator who's willing to concede subdomain control through DNS to a third party provider will definitely be able to work around origin checks. We could try to combat this by, say, resolving domain names to IPs and then blocking those -- but that has its own issues.
>
> Many security and privacy problems exhibit arms race qualities. For instance, email spam is at something like 80-90% of all mail. I doubt anyone would make the argument that we should therefore give up on spam fighting because the problem will never be completely solved.

Hi,

I agree with you Monica. I forwarded this email to dev.privacy so that
people here can be aware of this work in webappsec. In particular, it
might be worth trying to find ways to improve the planned suborigin
mechanism so that there is more information in the embedding page that
helps tracking protection and similar mechanisms--i.e. that allows the
mechanism to have the positive security benefits that are intended
without it contributing negatively and unintentionally to that arms
race. I don't have time to deal with that issue, but I do hope that
somebody takes it on.

Cheers,
Brian

[Monica Chew]

Hi Brian,

Thanks for forwarding, I didn't understand your point originally. I (or hopefully someone who's already involved in webappsec) will follow up.

Thanks,
Monica

----- Original Message -----