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.
----- Original Message -----
> ---------- Forwarded message ----------
> From: Brad Hill
> Date: Mon, Nov 10, 2014 at 3:53 PM
> Subject: Re: [webappsec] Rechartering: Sub-Origins
> To: Brian Smith
> Cc: "email@example.com"
> 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:
> >> 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