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 ----- Original Message ----- > ---------- Forwarded message ---------- > From: Brad Hill <[email protected]> > Date: Mon, Nov 10, 2014 at 3:53 PM > Subject: Re: [webappsec] Rechartering: Sub-Origins > To: Brian Smith <[email protected]> > Cc: "[email protected]" <[email protected]> > > > 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 <[email protected]> wrote: > > On Sun, Nov 9, 2014 at 4:04 PM, Brad Hill <[email protected]> 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 > _______________________________________________ dev-privacy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-privacy
